Day 87 · 3/5
🌳 고급 distributed-systems

Eventual Consistency가 뭔가요?

쉽게 이해하기

전국에 있는 편의점 체인의 재고 시스템을 생각해보세요. 서울 지점에서 음료수가 팔렸을 때 부산 지점의 재고판에 즉시 반영되진 않아요. 몇 초나 몇 분 뒤에 반영되죠. 하지만 시간이 지나면 결국 모든 지점의 재고판이 정확한 숫자를 보여줘요. 즉시는 아니지만 '결국엔' 일치하는 거예요.

핵심 정리

분산 시스템에서 데이터가 즉시는 아니지만 결국엔 일치하게 되는 특성이에요.

자세히 알아보기

Eventual Consistency(최종 일관성)는 분산 시스템에서 데이터가 즉시 일치하지 않더라도, 일정 시간이 지나면 결국 모든 노드에서 같은 값을 갖게 되는 특성이에요. CAP 이론에서 가용성(Availability)과 파티션 허용성(Partition Tolerance)을 선택하면 일관성(Consistency)을 즉시 보장할 수 없게 되는데, 이때 사용하는 전략이죠. 실제 사례를 보면 이해가 쉬워요. 인스타그램에서 좋아요를 누르면 내 화면에는 즉시 반영되지만, 다른 사람들 화면에는 몇 초 뒤에 반영돼요. 페이스북도 마찬가지죠. 게시물을 올리면 내 친구들이 모두 동시에 보는 게 아니라 시차를 두고 뉴스피드에 나타나요. 즉시 전 세계 서버에 동기화하면 시스템이 느려지니까, 일단 빠르게 저장하고 나중에 천천히 퍼뜨리는 거예요. AWS DynamoDB, Cassandra, MongoDB 같은 NoSQL 데이터베이스들이 이 방식을 써요. 예를 들어 DynamoDB는 미국, 유럽, 아시아에 데이터를 복제하는데, 서울에서 데이터를 쓰면 서울 리전에는 즉시 반영되지만 다른 리전에는 몇 밀리초~몇 초 뒤에 반영돼요. 대신 서울 서버가 죽어도 다른 리전에서 계속 서비스할 수 있죠. 반대 개념은 Strong Consistency(강한 일관성)예요. 은행 계좌 이체처럼 '즉시' 정확해야 하는 작업은 강한 일관성을 써야 해요. 송금 버튼을 누르는 순간 내 계좌에서 돈이 빠지고 상대 계좌에 들어가는 게 동시에 일어나야 하거든요. 하지만 SNS 좋아요 수나 조회수 같은 건 몇 초 차이가 나도 문제없으니까 최종 일관성을 써서 성능을 높이는 거죠. 최종 일관성을 쓸 때는 타임스탬프나 버전 번호를 활용해서 충돌을 해결해요. 두 사용자가 동시에 같은 데이터를 수정하면 나중에 합칠 때 어떤 걸 우선할지 정해야 하거든요. 보통 '가장 최근 값 우선' 전략을 쓰지만, 상황에 따라 다른 방법을 쓸 수도 있어요.