Eventually Consistent 리뷰

서론

-클라우드 컴퓨팅을 통해 수백만 명의 고객들의 요구사항을 맞춰야 하는 입장에서 인프라적인 측면에서의 지속적인 성능과 높은 가용성이 요구됨

-단순 replication(복제)를 통해서는 완벽히 이를 수행할 수 없음, 어떠한 접근으로 세계적 서비스를 문제없이 수행할만큼의 신뢰성 높은 분산 시스템을 구축할 수 있을지에 대해 알아볼 것

 

 

HISTORICAL PERSPECTIVE

 

-1970년대 과거 database system의 등장과 함께 많은 기술들이 distribution transparency를 달성하려고 함

-distribution transparency란 사용자에게는 하나의 시스템으로 보여지지만 그 이면에는 여러 개의 시스템의 서로 협력하는 구조로 이루어진 것

-90년대 Internet이 등장

-availability가 시스템의 가장 중요한 요소일 수도 있다는 관점의 등장

-CAP theorem : data consistency, system availability, tolerance to network partition의 3가지 중 2가지만 달성될 수 있음

조금 이해가 어려워 추가적으로 찾아봄

Consistency는 업데이트가 즉각 반영되는지

Availability는 요구에 따른 응답이 무조건적으로 이루어지는지

Partition Tolerance - 네트워크의 문제로 일부가 영향 받아도 전체 시스템은 동작

즉각 업데이트가 중요한 것과 조금은 업데이트가 느릴 순 있어도 시스템이 꼭 잘 동작하는 것, 즉 consistency와 availability는 trade-off의 관계인 것.

 

 

CONSISTENCY-CLIENT AND SERVER

 

developer/client point of view of consistency

storage와 process a, 그리고 이와 독립적인 process b and c

 

Strong consistency

-A가 어떠한 data에 대해 update를 하면 이후 어떠한 프로세스든 그 update된 값을 return

 

Weak consistency

-위의 예시에서 A 이후의 프로세스가 update된 값을 return하는 것을 보장하지 않음.

 

Eventual consistency

-weak consistency의 특수한 형태임

-새로운 업데이트가 이뤄지지 않는다면 결국에는 모든 접근에 대해 update된 value를 return하는 것을 보장

-DNS가 이를 차용한 가장 유명한 예시

 

 

Eventual consistency의 변형들

 

Causal consistency

-프로세스 A가 item을 업데이트했다고 B와 알리면 B는 update된 value를 보장 받음, 하지만 C는 보장받지 못함.

 

Read-your-writes consistency

-A가 업데이트를 이루고 나서는 계속 그 업데이트 된 최신값을 접근하게 됨

Session consistency

-session이 유효한 동안만 Read-your-writes consistency가 보장됨

 

Monotonic read consistency

-프로세스가 한번 접근했던 값이 있다면, 그 이전의 값은 절대 볼일이 없음

 

Monotonic write consistency

-같은 프로세스에 의한 write를 직렬화하는 것을 보장(프로그래밍을 수월하게 함)

 

RDBMS의 replica 복제 → synchronous와 asynchronous의 혼용

asynchronous의 경우 비동기적으로 이뤄지기에 log shipping자체가 실패하는 경우 consistency가 보장되지 않을 수 있음.

 

 

SERVER SIDE VIEW OF CONSISTENCY

 

N = data 복제본 저장 노드 수

W = update가 이루어지기전 이를 인증해야하는 복제본 노드의 개수

R = 어떠한 data에 대한 read를 수행했을 때 확인하게 되는 복제본 노드의 수

 

W+R > N인 경우 strong consistency가 보장됨

W+R = N 인 경우 consistency가 보장되지 않을 수 있음

W+R ≤ N 인 경우 weak/eventual consistency

 

consistency를 중요시하면 W=N

fault tolerance를 중요시하면 N을 크게 하고, R는 작게 함

 

높은 성능과 가용성을 보장해야 하는 장애 어느정도 내구성이 있는 시스템의 경우 N, 즉 복제본을 3개 두는 경우가 많음(W=2, R=2)

 

partition(다수결로 많은 node의 데이터를 채택)

그렇지 않고 둘다 데이터가 중요한 경우 따로 저장후 복구되면 병합(amazon cart system)

 

 

마무리

Data inconsistency는 커다란 규모의 distributed system에서

읽기 쓰기 성능을 높이기 위해서, partition으로 처리해야하는 문제가 발생했을 경우를 위해서 어느정도 감내될 필요가 있음.