Eventual Consistency
분산 시스템을 구성하려면 CAP 이론에 의해서 일관성과 가용성 중 하나를 포기해야하는 상황이 올 수 있습니다.
클라이언트의 요청을 받았을 때, A서버의 데이터가 변경되면 즉시 다른 서버에 반영되지 않습니다. 아래 두가지 경우가 있습니다.
-
모든 서버가 동일한 데이터를 갖도록 동기화 하는동안 클라이언트의 접근을 막는 경우 (가용성의 문제)
-
다른 클라이언트들이 변경된 데이터를 요청했을 때 어떤 클라이언트는 최신의 데이터를, 어떤 클라이언트는 오래된 데이터를 받게되는 경우.(일관성의 문제)
그러나 2번의 경우 언젠가는 동기화가 되면, 모든 클라이언트가 동일한 데이터를 받아볼 수 있게 됩니다.
이것이 Eventual Consistency 입니다.
Eventual consistency는 항목이 새롭게 업데이트되지 않는다는 전제하에 항목의 모든 읽기 작업이 최종적으로는 마지막으로 업데이트된 값을 반환한다는 것을 이론적으로 보장합니다. 인터넷 DNS(도메인 이름 시스템)는 eventual consistency 모델이 사용된 시스템의 예로 잘 알려져 있습니다. 링크
이미지 출처 : https://www.acodersjourney.com/eventual-consistency/
Strong Consisttency
반대되는 개념으로 Strong Consistency 가 있습니다. 관계형 데이터베이스가 대표적인 모델입니다.
관계형 데이터베이스에서 트랜잭션의 속성 ACID를 떠올려보면,
-
Consistency - 트랜잭션이 완료되면 일관된 데이터를 유지해야한다.
-
클라이언트가 서로 다른 데이터를 조회할 수 없습니다.
-
그렇기 때문에 서버간 데이터를 복사할 때 락킹 메커니즘이 동작하고, 가용성에 문제가 생기게 됩니다.
blocked until replication of the new data to all the nodes are complete.
이미지 출처 : https://www.acodersjourney.com/eventual-consistency/
Eventual Consistency VS Strong Consistency
Eventual Consistency는 오래된 데이터를 가져올 가능성이 있는데 왜 사용할까? 바로 가용성 때문입니다. Strong Consistency는 일관성을 유지하려면 replication copy를 해야하기 때문에 그 동안 클라이언트가 데이터를 가져올 수 없다.
그러나 Eventaul Consistency는 동기화 전이라도 이를 노드에 접근을 허용하기 때문에 가용한 상태를 유지합니다.
예를들어 소셜미디어 같은 경우가 일관성이 떨어지더라도 가용성이 중요한 경우일 수 있습니다.
유저 입장에서는 서비스가 멈추는 경험보단, 누군가 글을 썼는지 모르고 조금 늦게 보는 것이 낫기 때문입니다.
로컬 캐시 Caffeine 에서의 Eventual Consistency
- expireAfterWrite와 refreshAfterWrite 옵션을 통해 주기적인 캐시 삭제 또는 리프레쉬로 Eventual Consistency를 만족할 수 있습니다.
expireAfterWrite handles data freshness and can be combined with refreshAfterWrite to retain the active entries. This is commonly useful for local caches which are allowed to be eventually consistent across a cluster. 카페인 제작자의 답글 링크
레퍼런스
Eventual consistency - Wikipedia
Datastore로 strong consistency와 eventual consistency 간에 균형 유지
System Design Interview Concepts - Eventual Consistency
