Eventual Consistency

분산 시스템을 구성하려면 CAP 이론에 의해 일관성과 가용성 중 하나를 포기해야 하는 상황이 올 수 있다.

다음과 같은 상황을 뜻한다.

클라이언트의 요청을 받았을 때, A 서버 데이터가 변경되면 즉시 다른 서버에 반영되지 않는다. 다음 2가지 경우를 보자.

1. 모든 서버가 같은 데이터를 갖도록(일관성) 동기화하는 동안 클라이언트의 접근을 막는다. → 가용성 문제
2. 다른 클라이언트들이 변경된 데이터를 요청했을 때, 각자 다른 데이터를 받을 수가 있다. → 일관성 문제

2번의 경우, 언젠가 동기화가 되면, 모든 클라이언트가 동일한 데이터를 받아볼 수 있게 된다.

이를 Eventual Consistency 라고 한다.

Eventual Consistency

Eventual Consitency는 항목이 새롭게 업데이트되지 않는다는 전제하에 항목의 모든 읽기 작업이 최종적으로는 마지막으로 업데이트된 값을 반환한다는 것을 이론적으로 보장한다.

Eventual Consitency 모델이 사용된 시스템의 예로 잘 알려진 DNS

DNS 서버가 항상 최신의 값을 반영하는 것은 아니며, 이러한 값들은 인터넷상의 수많은 디렉터리에서 캐싱되고 복제된다. 수정된 값을 모든 DNS 클라이언트와 서버에 복제하려면 어느 정도의 시간이 소요된다.

하지만 DNS 시스템은 인터넷의 근간을 이루는 요소로 자리잡은 매우 성공적인 시스템이다. 가용성이 매우 높으며 엄청난 확장성이 증명되었고, 인터넷 전체에서 수천만 대 기기의 이름 조회를 가능하게 하고 있다.

위의 다이어그램은 복제본을 읽는 것은 언제든 가능하지만, 일부 복제본은 특정 시점에 상위 노드에 쓰여진 값과 일치하지 않을 수 있음을 알 수 있다.

Strong Consistency

반대로 기존의 관계형 데이터베이스는 즉각적 일관성이라고 하는 Strong Consistency 개념을 토대로 설계되었다.

즉, 업데이트 즉시 조회된 데이터는 항목을 보는 모든 사용자에게 일관성 있게 표시된다. 하지만 Strong Consistency를 얻기 위해서는 개발자가 애플리케이션의 확장성과 성능을 어느 정도 포기해야 한다.

간단히 말해 업데이트 또는 복제 프로세스 도중에는 데이터를 잠금 설정하여 다른 프로세스에서 동일한 데이터를 업데이트하지 않도록 해야 한다.

Eventual Consistency vs Strong Consistency

Eventual Consistency는 오래된 데이터를 가져올 가능성이 있지만 사용되는 이유는 가용성 때문이다.

Strong Consistency는 일관성을 유지하려면 replication copy를 해야하기 때문에 그동안 클라이언트가 데이터를 가져올 수 없다.

그러나 Eventaul Consistency는 동기화 전이라도 이를 노드에 접근을 허용하기 때문에 가용한 상태를 유지한다.

예를 들어 소셜미디어 같은 경우가 일관성이 떨어지더라도 가용성이 중요한 경우일 수 있다. 유저 입장에서는 서비스가 멈추는 경험보단, 누군가 글을 썼는지 모르고 조금 늦게 보는 것이 낫기 때문이다. 이러한 예시에선 Eventual Consistency를 활용하면 확장성과 성능을 확보할 수 있다.

Strong Consistency를 필요로 하는 경우로는 '사용자가 결제 프로세스를 완료했는지' 또는 '게임 플레이어가 한 전투 세션 동안 획득한 포인트' 정보 등의 사용 사례를 예시로 들 수 있다.

 

 

🔗  참고 링크

Datastore로 strong consistency와 eventual consistency 간에 균형 유지  |  Cloud Datastore 문서  |  Google Cloud