이전 글에서는 데이터 중심의 일관성 모델에 대해서 알아봤다.
이번엔 클라이언트 중심 일관성 모델에 대해서 알아보자.
Client-centric Consistency Models: 클라이언트 중심 일관성 모델
데이터 중심 일관성 모델은 데이터 저장소에 대해 시스템 전체의 일관성 보장을 목표로 한다.
하지만 클라이언트 중심 일관성 모델은 주로 동시 업데이트가 거의 없는 애플리케이션에 사용되기 때문에, 대부분의 연산은 데이터를 읽는데 중점을 둔다.
따라서 매우 약한 일관성이 특징이다.
시스템 전반의 일관성을 유지하기 보다는, 특정 클라이언트의 요구에 집중함으로써 시스템 전체의 일관성을 피할 수 있는 방법을 보여준다.
대부분의 대규모 분산 시스템은 확장성을 위해 복제를 적용하지만, 약한 일관성만 지원한다.
예들 들어, DNS는 업데이트가 천천히 전파되며, 새로 삽입된 항목은 즉시 보이지 않을 수 있다. 뉴스 시스템 역시 인터넷 전반에서 기사와 반응이 푸시되거나 풀링되고, 이로 인해 게시물보다 반응이 먼저 보이는 경우도 있다. WWW는 전 세계적으로 캐시가 존재하지만, 사용자가 읽는 페이지가 최신 버전이라는 보장이 필요하지 않을 수도 있다.
Eventual Consistency: 최종 일관성
DNS와 WWW 같은 시스템은 대규모 분산 및 복제된 데이터베이스로 볼 수 있으며, 상당히 높은 수준의 불일치를 허용할 수 있다.
이러한 시스템들의 공통점은, 오랜 시간 동안 업데이트가 발생하지 않으면 모든 복제본이 점차적으로(최종적으로) 일관된 상태에 도달한다는 것이다. 이와 같은 형태를 최종 일관성이라고 한다. 최종 일관성은 업데이트가 모든 복제본으로 전파되는 것만을 보장하면 된다.
최종 일관성 데이터 저장소는 클라이언트가 항상 동일한 복제본에 접근하는 경우에는 정상적으로 작동한다. 하지만, 다른 복제본에 접근하는 경우에는 문제가 발생할 수 있다.
예를 들어서, 클라이언트가 하나의 복제본에서 업데이트를 한 후, 다른 복제본에 접근 했을 때 최신 상태가 보이지 않거나 일관되지 않은 상태로 데이터를 조회할 수 있다.
Monotonic-Read Consistency: 단조 증가 읽기 일관성
프로세스가 데이터 항목 x의 값을 읽으면, 이후 해당 프로세스가 x에 대해 수행하는 모든 읽기 연산은 이전과 동일하거나 더 최신의 값을 반환한다.
일단 위 그림에서의 표기법을 한 번 살펴보자.
$W_1(x_2)$는 프로세스 $P_1$이 $x_2$ 버전을 생성한 쓰기 연산을 의미한다.
$W_1(x_i;x_j)$는 프로세스 $P_1$이 이전 버전 $x_i$에 기반하여 $x_j$ 버전을 생성한 쓰기 연산을 의미한다.
$W_1(x_i|x_j)$는 프로세스 $P_1$이 $x_i$와 동시에 $x_j$버전을 생성한 쓰기 연산을 의미한다. 두 버전이 연관이 없는 것이다.
자, (a)는 단조 증가 읽기 일관성을 제공하는 데이터 저장소이다.
프로세스 P가 두 개의 로컬 복제본에서 동일한 데이터 항목을 읽을 때, 항상 이전에 읽은 값과 동일하거나 최신 값만 볼 수 있다.
따라서 (a)에는 $x_1$ 버전에 기반하여 $x_2$버전을 생성했기 때문에, 최신 값($x_2$)을 반환할 수 있는 것이다.
(b)는 단조 증가 읽기 일관성을 제공하지 않는 데이터 저장소이고, 프로세스 P가 동일한 데이터 항목을 다른 복제본에서 읽을 때 이전보다 더 오래된 값을 읽을 수 있는 경우가 발생할 수 있다. 새로 생성된 $x_2$버전은 동일한 값도 아니고, 최신 값도 아니게 된다.
- 예시1: 사용자가 서로 다른 서버에서 개인 일정 업데이트를 자동으로 읽는 경우를 가정한다. 사용자는 어떤 서버에서 일정을 읽든 모든 업데이트를 볼 수 있어야 한다. 즉, 이전에 본 일정 데이터보다 더 오래된 데이터를 읽지 않도록 보장한다.
- 예시2: 사용자가 이동하면서 다른 이메일 서버에 접속하여 메일을 읽는 경우를 가정한다. 사용자가 각각의 이메일 서버에 연결할 때마다, 이전에 방문한 서버에서 모든 업데이트를 가져와야한다. 이를 통해 사용자가 모든 최신 메일을 일관되게 확인할 수 있다.
Monotonic-Write Consistency: 단조 증가 쓰기 일관성
특정 프로세스가 데이터 항목 x에 대해 쓰기 연산을 완료한 후에, 같은 프로세스에 의해 수행되는 모든 후속 쓰기 연산은 이전 연산이 완료된 상태에서 이루어져야한다.
(a)는 단조 증가 쓰기 일관성을 제공하는 저장소이다.
(b)는 단조 증가 쓰기 일관성을 제공하지 않는 저장소이다.
(c)는 일관성이 없는 상태다. $W_2(x_1|x_2)$처럼 특정 프로세스가 x1과 x2에 대해 동시적으로 병행 쓰기 연산을 수행하면 일관성이 깨진다.
(d)는 일관성이 있는 상태다. $x_2$버전이 생성되긴 했지만, 사실상 무시하기 때문에 $x_1$버전을 기반으로 생성된 $x_3$으로 연속적인 쓰기 연산이 이루어진 것이다.
- 예시1: 특정 프로그램을 서버S2에서 업데이트할 때, 컴파일과 링크에 필요한 모든 구성 요소가 반드시 S2에 배치되도록 보장한다. 이로써 이전 상태가 완료된 후에 후속 작업이 이루어져 프로그램이 올바르게 업데이트 된다.
- 예시2: 복제된 파일의 버전을 모든 서버에서 올바른 순서로 유지해야한다. 가장 최신 버전이 설치된 서버로 이전 버전을 전파하여 쓰기 연산이 올바른 순서로 수행되도록 한다.
Read-Your-Writes Consistency
특정 프로세스가 데이터 항목x에 대해 쓰기 연산을 수행한 후, 해당 프로세스가 x에 대해 수행하는 모든 후속 읽기 연산은 반드시 최신 값을 반환해야한다.
(a)는 Read-Your-Wirtes 일관성을 제공하는 데이터 저장소이고, (b)는 아니다.
$P_2$에서 $x_2$버전을 썼으니, $P_1$에서 $x_2$를 읽을 수 있다.
이는 사용자가 자신의 웹 페이지를 업데이트 한 후, 웹 브라우저가 최신 버전을 보여주도록 보장한다.
Writes-Follow-Reads Consistency
특정 프로세스가 데이터 항목 x를 읽은 후에 수행하는 쓰기 연산은 해당 프로세스가 이전 읽기에서 본 값 또는 더 최신의 값에 대해서만 이루어져야한다.
(a)는 Writes-Follow-Reads 일관성을 제공하는 데이터 저장소이고, (b)는 아니다.
이는 사용자가 게시된 기사를 읽은 후에만 해당 기사에 반응을 볼 수 있도록 한다. 즉, 읽기 연산이 쓰기 연산을 가져오도록 보장한다.
음.. 교수님께서 동시성이 존재하면 다 틀린거라고 말씀하시긴 했다. 말이 워낙 비슷비슷하고 복잡해서 설명하시는데 어려움을 겪으신 것 같다. 나중에 좀 더 알아봐야지 .. 사실 설명 들으면서 이해를 하나도 못했다.
Consistency Protocols
일관성 프로토콜은 특정 일관성 모델의 구현 방식을 정의한다.
Primary-based Remote-Wrtie Protocols: 기본 기반 원격 쓰기 프로토콜
모든 쓰기 연산은 (원격) 고정된 서버에서 수행된다. 읽기 연산은 로컬 복제본에서 수행될 수 있으며, 쓰기 연산은 고정된 기본 복제본으로 전달된다.
클라이언트가 W1(쓰기 요청)을 보냈다. W1을 받은 저장소는 프라이머리로 이 요청을 넘긴다. 프라이머리는 업데이트를 수행한 후에 백업 저장소들에게 업데이트를 넘겨준다.(W3) 업데이트를 받은 백업들은 프라이머리에게 업데이트 완료 ACK(W4)를 보내고, W1을 받은 저장소는 클라이언트에게도 쓰기가 완료되었다는 ACK(W5)를 보낸다.
읽기 요청과 응답(R1, R2)은 백업 저장소에서 바로 이루어진다.
이 프로토콜의 문제점은, blocking 연산으로 구현될 경우 업데이트할 때 병목 현상이 발생할 수 있다는 것이다.
모든 쓰기 요청이 프라이머리에서 순차적으로 처리되기 때문에, 대기 시간이 발생하고 시스템 전체 성능이 저하될 수 있다.
그러나, 순차적 일관성은 보장된다. 즉, 모든 읽기 연산은 가장 최근의 쓰기 결과를 보장한다.
하지만 non-blocking 연산으로 구현될 경우, 순차적 일관성을 보장할 수 없다. 또한, 장애 허용(fault tolerance)을 보장하지 못할 수 있다.
Primary-based Local-Write Protocols: 기본 기반 로컬 쓰기 프로토콜
모든 쓰기 연산은 로컬에서 수행되며, 그 결과는 다른 복제본으로 전달된다. primary copy는 쓰기 연산을 수행하려는 프로세스 간 이동을 한다. 여러 번의 연속적인 쓰기 연산이 로컬에서 non-blocking 프로토콜을 통해 수행될 수 있다.
클라이언트가 쓰기 요청(W1)을 보냈다. 쓰기 요청을 받은 복제본이 새로운 프라이머리가 되며, 최근 값인 아이템x를 이전 프라이머리가 새로운 프라이머리로 전송한다(W2). 쓰기 요청이 완료되었다고 클라이언트에 ACK(W3)을 보낸다. 후에 프라이머리는 백업 저장소들에게 업데이트를 전송한다(W4). 업데이트를 완료한 저장소들이 완료했다고 ACK(W5)을 보낸다.
Active Replicaiton: 활성 복제
각 복제본은 업데이트 연산을 수행하며, 그 결과를 다른 복제본에 전파한다. 이를 통해 모든 복제본이 동일한 상태로 유지된다.
이 방식에는 완전히 순서가 정해진 멀티캐스트가 필요하다. 만약 복제본마다 중복된 요청을 처리하거나, 동시에 연산이 수행될 경우 동기화가 어렵거나 예기치 않은 일관성 문제가 발생할 수 있다.
Replicated invocation problem에 대한 해결책으로,
그룹 내에서 특정 코디네이터가 복제된 호출을 관리하고 조정하여 일관성을 유지해주는 Group coordinator 가 있다.
Sender-driven(송신자 중심)은 , 송신자가 호출 및 업데이트를 전파하는 과정을 관리한다.
Receiver-driven(수신자 중심)은, 수신자가 업데이트를 관리하며, 필요한 경우 데이터를 요청하거나 처리 순서를 보장한다.
Quorum-based Protocols: 쿼럼 기반 프로토콜
이 프로토콜은 클라이언트가 복제본에 대한 연산을 수행하기 전에 여러 서버의 허가(쿼럼)를 요청하고 획득해야한다.
Quorum set이라는게 있는데, 쓰기 쿼럼(W)은 전체 투표 수의 절반보다 많아야하며, 읽기 쿼럼(R)과 쓰기 쿼럼(W)의 합은 그룹의 총 투표 수보다 커야한다는 규칙이 존재한다. 모든 읽기 쿼럼과 쓰기 쿼럼은 반드시 공통된 복제본을 포함해야 하므로, 동일 복제본에서 충돌하는 연산이 발생하지 않도록 보장한다.
따라서 읽기 연산과 쓰기 연산은 충분한 수의 복제본 (>= R or W)이 있는지 확인하고, 모든 복제본에 대해 연산을 수행한다.
위 그림에서는 실선이 Read quorum이고, 점선이 Write quorum이다.
(a)는 쓰기 쿼럼이 과반수 이상으로 적합하고, 쓰기 쿼럼과 읽기 쿼럼의 합이 그룹의 투표권 수보다 높으므로 적합하다.
(b)는 쓰기 쿼럼이 과반수 이상이 되지 않는다. 이는 Write-Write 연산이 될 가능성이 높다.
(c) 역시 적합한 선택이고, ROWA라고 할 수 있다. (Read one, write all)
중간고사가 끝나고 헤이해져서 도통 진도를 못 따라잡고 있다가, 한 번의 휴강으로 그나마 쫒아오는 정도가 되었다.
다만 다른 수업의 복습이 산더미처럼 남아있지만.. 이 과목이라도 끝낸게 어디야 ㅠ ㅠ
** 대학교 수업을 듣고 이해한 부분을 최대한 풀어서 작성한 글입니다.
틀린 정보가 존재할 수 있으며, 언제나 피드백은 환영입니다. **
'DKU > 분산처리' 카테고리의 다른 글
| Distributed System 15 (1) | 2024.11.21 |
|---|---|
| Distributed System 14 (1) | 2024.11.18 |
| Distributed System 12 (0) | 2024.11.05 |
| Distributed System 11 (0) | 2024.11.05 |
| Distributed System 10 (1) | 2024.10.17 |