Weak Consistency

약한 일관성 (Weak Consistency)

Weak Consistency 는 데이터 일관성을 부분적으로 희생해 시스템 성능과 가용성을 높이는 모델이다. 쓰기 작업이 완료되면 즉시 모든 노드에 동기화되지 않으며, 애플리케이션 요구사항에 따라 일관성 수준을 조절한다. 일시적인 불일치를 허용함으로써 시스템의 가용성과 성능을 향상시킨다. 실시간 스트리밍, 소셜 미디어, 캐시 등에 활용되며, CAP 정리에서 Availability 와 Partition Tolerance 를 우선시한다. 최종 일관성 (Eventual Consistency) 등의 변형이 있다.

핵심 개념

약한 일관성 (Weak Consistency) 은 분산 시스템에서 사용되는 일관성 모델로, 데이터 일관성보다 시스템의 가용성과 성능을 우선시하는 패턴이다.

1. 정의: 데이터가 업데이트된 후, 시스템의 다른 노드에서 수행되는 후속 읽기 작업이 최신 데이터를 즉시 반영하지 않을 수 있는 모델리가. 즉, 쓰기 연산 후에 읽기 연산이 최신 데이터를 볼 수도 있고 그렇지 않을 수도 있다.

2. 최소 보장: 약한 일관성은 " 최선의 노력 (best-effort)" 접근 방식을 취하며, 특정 시간이 경과하거나 특정 조건이 충족된 후에만 최신 데이터가 반환될 수 있다.

3. CAP 정리와의 관계: CAP 정리에 따르면, 일관성 (Consistency), 가용성 (Availability), 파티션 허용성 (Partition Tolerance) 중 세 가지를 모두 동시에 충족할 수 없다. 약한 일관성은 일관성을 희생하고 가용성과 파티션 허용성을 우선시한다 (AP 시스템).

4. 최종 일관성과의 관계: 최종 일관성 (Eventual Consistency) 은 약한 일관성의 한 형태로, 새로운 업데이트가 없을 때 모든 노드가 결국 동일한 상태로 수렴하는 것을 보장한다.

5. 주요 특징: 비동기적 데이터 복제, 낮은 지연 시간, 높은 가용성, 파티션 허용성이 특징이다.

목적 및 필요성

약한 일관성 모델은 다음과 같은 목적과 필요성을 가진다:

1. 성능 향상: 강한 일관성 (Strong Consistency) 은 모든 노드 간의 동기화를 필요로 하여 지연 시간이 증가할 수 있다. 약한 일관성은 즉각적인 동기화가 필요하지 않아 응답 시간이 개선된다.

2. 가용성 증대: 네트워크 파티션이나 노드 장애 상황에서도 시스템이 계속 작동할 수 있게 한다. 강한 일관성 모델에서는 이런 상황에서 시스템이 차단되거나 사용 불가능해질 수 있다.

3. 확장성 지원: 대규모 분산 시스템에서 강한 일관성을 유지하는 것은 매우 복잡하고 비용이 많이 든다. 약한 일관성은 더 쉽게 확장할 수 있는 시스템 구축을 가능하게 한다.

4. 지리적 분산 지원: 전 세계적으로 분산된 시스템에서는 물리적 거리로 인한 지연 시간이 발생한다. 약한 일관성은 이러한 환경에서 더 효율적으로 작동할 수 있다.

5. 일시적 일관성 부족의 허용: 일부 애플리케이션에서는 데이터가 완벽하게 일관되지 않아도 충분히 기능할 수 있다. 약한 일관성은 이런 애플리케이션에 적합하다.

주요 기능 및 역할

약한 일관성 모델의 주요 기능과 역할은 다음과 같다:

1. 비동기 데이터 복제: 데이터 업데이트가 비동기적으로 다른 노드에 전파되어, 즉각적인 동기화 없이도 시스템이 계속 작동할 수 있게 한다.
2. 가용성 최적화: 네트워크 문제나 노드 장애가 발생해도 시스템이 계속 작동하도록 하여 높은 가용성을 제공한다.
3. 성능 향상: 즉각적인 동기화가 필요 없어 읽기 및 쓰기 작업의 지연 시간이 감소한다.
4. 확장성 지원: 대규모 분산 시스템에서도 효율적으로 작동할 수 있게 한다.
5. 부하 분산: 여러 노드에 걸쳐 데이터를 분산시켜 시스템 부하를 균등하게 분배한다.
6. 유연한 일관성 계층: 애플리케이션마다 다른 일관성 요구사항 지원
7. 조건적 일관성: 특정 시간/이벤트 발생 시 일관성 보장 (예: 사용자 새로고침)
8. 충돌 허용 및 지연 처리: 충돌 발생 시 나중에 해결 가능

특징

약한 일관성 모델의 주요 특징은 다음과 같다:

1. 비동기 복제: 데이터 업데이트가 비동기적으로 시스템 전체에 전파된다.
2. 낮은 지연 시간: 즉각적인 일관성 확인이 필요 없어 응답 시간이 빠르다.
3. 부분적 일관성: 일시적으로 노드 간에 데이터가 불일치할 수 있으나, 시간이 지나면 일관성이 달성될 수 있다.
4. Best-Effort 접근 방식: 시스템은 최선을 다해 데이터를 전파하지만, 즉각적인 일관성을 보장하지는 않는다.
5. 고가용성: 네트워크 파티션이나 노드 장애 상황에서도 시스템이 계속 작동한다.
6. 확장성: 대규모 분산 환경에서 효율적으로 확장할 수 있다.

핵심 원칙

약한 일관성의 핵심 원칙은 다음과 같다:

1. 가용성 우선: 일관성보다 시스템의 가용성과 응답성을 우선시한다.
2. 점진적 수렴: 시간이 지남에 따라 모든 노드가 동일한 데이터 상태로 수렴할 수 있다.
3. 경쟁 상태 허용: 동시 업데이트로 인한 일시적인 데이터 불일치를 허용한다.
4. 부분적 실패 대응: 일부 노드가 실패하더라도 시스템이 계속 작동할 수 있어야 한다.
5. 비동기 통신: 노드 간 통신이 비동기적으로 이루어져 지연 시간을 줄인다.

주요 원리 및 작동 원리

1. 클라이언트가 노드 A 에 데이터 쓰기
2. 노드 A 는 즉시 응답 후 비동기적으로 다른 노드에 전파
3. 읽기 요청 시 로컬 노드 데이터 반환 (최신 여부 무관)
4. 주기적 동기화 또는 사용자 트리거로 일관성 검증

1
2
3

[클라이언트] → 쓰기 → [노드 A]  
노드 A → (비동기) → [노드 B], [노드 C]  
클라이언트 읽기 요청 → 최신 데이터 없을 수 있음

구현 기법

비동기 복제 (Asynchronous Replication)

주 복제본에서 쓰기 작업이 완료된 후 클라이언트에 응답하고, 다른 복제본으로의 전파는 비동기적으로 진행하는 기법.

구성:

• 주 복제본과 부 복제본 구조
• 주 복제본에서 쓰기 작업 즉시 확인
• 배경에서 비동기적으로 부 복제본에 변경사항 전파

목적: 낮은 지연 시간과 높은 가용성 제공

실제 예시:

1
2
3
4
5
6
7
8

시스템 구성: 1개의 주 노드와 2개의 부 노드를 가진 MySQL 복제 설정

시나리오:
1. 클라이언트가 주 노드에 데이터 X 업데이트 요청: X = "new_value"
2. 주 노드가 로컬에서 변경 적용 후 즉시 클라이언트에 성공 응답
3. 비동기적으로 복제 로그를 부 노드로 전송
4. 일시적으로 주 노드에서는 X = "new_value", 부 노드에서는 X = "old_value"
5. 네트워크 상태와 시스템 부하에 따라 부 노드 동기화 시간 달라짐

클라이언트 측 버퍼링 (Client-side Buffering)

클라이언트가 쓰기 작업을 로컬에 버퍼링하고 나중에 서버에 일괄 전송하는 방식.

구성:

• 클라이언트 로컬 메모리에 쓰기 작업 저장
• 배경에서 또는 특정 조건 (시간, 크기 등) 에 따라 서버로 전송
• 오프라인 작업 지원 메커니즘

목적: 네트워크 지연이나 연결 문제에 강한 사용자 경험 제공

실제 예시:

1
2
3
4
5
6
7
8
9

시스템 구성: 모바일 메모 애플리케이션과 백엔드 서버

시나리오:
1. 사용자가 오프라인 상태에서 메모 작성 및 편집
2. 모바일 앱이 모든 변경사항을 로컬 데이터베이스에 저장
3. 네트워크 연결 감지 시:
   - 변경사항을 묶어서 서버에 전송
   - 충돌 해결 로직 실행(필요한 경우)
4. 사용자는 네트워크 상태와 무관하게 앱 사용 가능

리더리스 복제 (Leaderless Replication)

중앙 조정자 없이 모든 노드가 읽기와 쓰기를 수용하는 방식.

구성:

• 클라이언트가 다수의 또는 모든 노드에 직접 쓰기
• 읽기 시 다수의 노드에서 응답을 수집하여 최신 값 선택
• 읽기 복구 (Read Repair) 나 반 - 엔트로피 (Anti-entropy) 프로세스로 일관성 유지

목적: 단일 실패 지점 제거 및 고가용성 제공

실제 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

시스템 구성: 5개의 대등한 노드로 구성된 Cassandra 클러스터

시나리오:
1. 클라이언트가 키 K에 대한 쓰기 요청: K = "value_x"
2. 쓰기 요청이 모든 노드에 전송됨(실제로는 쿼럼 W 설정에 따라 다름)
3. 일부 노드(예: 3개)가 성공적으로 쓰기를 확인하면 작업 성공으로 간주
4. 나머지 노드는 일시적으로 오래된 값 보유
5. 이후 읽기 요청 시:
   - 여러 노드에서 데이터 요청(쿼럼 R 설정에 따라 다름)
   - 타임스탬프 비교로 최신 값 결정
   - 오래된 값을 가진 노드들에 대한 읽기 복구 진행

로컬 쓰기, 글로벌 읽기 (Local Write, Global Read)

지리적으로 분산된 시스템에서 쓰기는 로컬에서 처리하고 읽기는 전역적으로 수행하는 방식.

구성:

• 각 지역에서 로컬 쓰기 우선 처리
• 글로벌 읽기 요청은 여러 지역의 데이터 통합
• 지역간 비동기 복제

목적: 지리적으로 분산된 시스템에서 쓰기 지연 시간 최소화

실제 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

시스템 구성: 미국, 유럽, 아시아에 데이터 센터를 둔 소셜 미디어 플랫폼

시나리오:
1. 아시아 사용자가 상태 업데이트: "Hello World"
2. 업데이트가 아시아 데이터 센터에 즉시 기록되고 사용자에게 확인
3. 비동기적으로 미국, 유럽 데이터 센터로 복제 시작
4. 동시에 유럽 사용자가 같은 프로필 조회 요청
5. 시스템이 여러 지역 데이터 센터에 질의:
   - 아시아: 새 상태 "Hello World"
   - 유럽, 미국: 아직 이전 상태
6. 값 병합 정책에 따라(보통 최신 타임스탬프) 표시할 데이터 결정

델타 복제 (Delta Replication)

전체 데이터 대신 변경된 부분 (델타) 만 복제하는 기법.

구성:

• 변경 사항만 추적하는 델타 저장소 유지
• 델타 변경 사항 비동기 전송
• 수신 노드에서 델타 적용

목적: 네트워크 대역폭 절약 및 복제 효율성 향상

실제 예시:

1
2
3
4
5
6
7
8
9

시스템 구성: 파일 동기화 서비스(Dropbox와 유사)

시나리오:
1. 사용자가 100MB 문서의 마지막 페이지만 수정
2. 클라이언트가 변경된 부분만 감지하여 델타(~10KB) 생성
3. 델타만 서버로 전송
4. 서버가 기존 파일에 델타 적용하여 업데이트
5. 다른 사용자의 디바이스로 델타만 전송
6. 각 디바이스가 로컬 파일에 델타 적용

느슨한 쿼럼 (Sloppy Quorum)

일시적인 네트워크 분할 상황에서 정상적인 쿼럼 노드를 사용할 수 없을 때 일시적으로 다른 노드를 대체 사용하는 방식.

구성:

• 원래 지정된 노드 집합 정의
• 일부 노드 접근 불가 시 임시 대체 노드 사용
• 원래 노드 복구 시 힌티드 핸드오프 (Hinted Handoff) 로 데이터 전달

목적: 네트워크 분할 상황에서도 쓰기 작업 가용성 유지

실제 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

시스템 구성: 10개 노드 클러스터의 DynamoDB, 쓰기 쿼럼 W=3

시나리오:
1. 데이터 항목 X는 노드 1, 2, 3에 저장되도록 해시됨
2. 네트워크 장애로 노드 3 접근 불가
3. 느슨한 쿼럼 적용:
   - 시스템이 노드 1, 2에 쓰기 후
   - 노드 3 대신 노드 4에 임시로 데이터 저장
   - 노드 4에는 "이 데이터는 노드 3에 전달될 예정"이라는 힌트 기록
4. 노드 3 복구 시 노드 4가 저장했던 데이터 전달

읽기 시점 일관성 (Read-your-writes Consistency)

약한 일관성 모델 내에서 최소한 자신의 쓰기 작업 결과는 볼 수 있도록 보장하는 방식.

구성:

• 클라이언트별 세션 추적
• 쓰기 작업의 타임스탬프 또는 버전 기록
• 읽기 요청 시 자신의 쓰기가 반영된 복제본에서만 읽기 수행

목적: 사용자 경험 향상을 위한 최소한의 일관성 보장

실제 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

시스템 구성: 웹 애플리케이션과 백엔드 데이터 저장소

시나리오:
1. 사용자가 프로필 정보 업데이트: "name": "John Doe"
2. 시스템이 세션에 {key: "profile", version: 5} 기록
3. 사용자가 자신의 프로필 페이지 로드 요청
4. 시스템이 세션 정보 확인:
   - 사용자가 profile을 version 5로 업데이트했음을 인식
   - 최소한 version 5 이상의 데이터를 가진 복제본에서만 읽기 수행
5. 아직 복제가 완료되지 않았다면 최신 복제본을 찾거나 업데이트 완료까지 대기

세션 일관성 (Session Consistency)

클라이언트 세션 내에서는 강한 일관성을 보장하지만, 세션 간에는 약한 일관성을 허용하는 방식.

구성:

• 클라이언트 세션 식별 및 추적
• 세션 내에서는 동일 서버/복제본 세트에 요청 라우팅
• 세션 메타데이터 유지

목적: 사용자 경험과 시스템 확장성 간의 균형 제공

실제 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

시스템 구성: 전자상거래 웹사이트와 분산 백엔드

시나리오:
1. 사용자가 로그인하여 새 세션 시작
2. 시스템이 세션 ID와 서버 할당 정보 생성
3. 사용자가 장바구니에 상품 추가
4. 모든 후속 요청이 동일한 서버 세트로 라우팅됨:
   - 장바구니 조회 시 방금 추가한 상품 확인 가능
   - 주문 처리 시 최신 장바구니 상태 사용
5. 다른 디바이스에서 로그인하면 새 세션 생성:
   - 이전 세션의 변경사항이 아직 복제되지 않았을 수 있음
   - 점진적으로 일관성 달성

시간 기반 조정 (Time-based Reconciliation)

타임스탬프를 사용하여 충돌을 자동으로 해결하는 방식.

구성:

• 모든 쓰기 작업에 타임스탬프 부여
• 충돌 시 가장 최근 타임스탬프를 가진 값 선택
• 물리적 또는 논리적 시계 사용

목적: 간단하면서도 예측 가능한 충돌 해결 메커니즘 제공

실제 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

시스템 구성: 다중 리전 NoSQL 데이터베이스

시나리오:
1. 아시아 리전에서 객체 O 업데이트: {value: "A", timestamp: 2023-01-01T12:00:00Z}
2. 네트워크 지연으로 인해 미국 리전으로 복제 진행 중
3. 동시에 미국 리전에서 같은 객체 업데이트: {value: "B", timestamp: 2023-01-01T12:00:05Z}
4. 복제 과정에서 충돌 발생
5. 타임스탬프 비교:
   - 미국 리전 업데이트가 더 최근(12:00:05 > 12:00:00)
   - 최종적으로 모든 리전에서 값 "B" 선택

우선순위 기반 조정 (Priority-based Reconciliation)

미리 정의된 우선순위 규칙에 따라 충돌을 해결하는 방식.

구성:

• 데이터 타입, 작업 유형, 노드 등에 우선순위 부여
• 충돌 감지 시 우선순위 규칙 적용
• 애플리케이션 특성에 맞는 커스텀 규칙 정의

목적: 비즈니스 로직에 맞는 충돌 해결 정책 제공

실제 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

시스템 구성: 항공 예약 시스템

시나리오:
1. 시스템에 좌석 예약 상태에 대한 우선순위 규칙 정의:
   - 예약 > 대기 > 비어있음
   - 관리자 작업 > 시스템 자동화 > 고객 요청
2. 고객 A가 좌석 S를 "예약" 상태로 변경
3. 네트워크 지연으로 일부 노드에 아직 반영 안 됨
4. 시스템 자동화가 동시에 같은 좌석을 "비어있음"으로 변경 시도
5. 충돌 감지 시:
   - "예약"이 "비어있음"보다 우선순위 높음
   - 최종적으로 모든 노드에서 "예약" 상태 유지

애플리케이션 특화 해결 (Application-specific Resolution)

애플리케이션 도메인 지식을 활용하여 충돌을 해결하는 방식.

구성:

• 데이터 타입별 특화된 병합 함수 정의
• 비즈니스 규칙 기반 해결 로직
• 충돌 감지 시 커스텀 해결 로직 호출

목적: 애플리케이션의 의미론적 요구사항에 맞는 일관성 제공

실제 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

시스템 구성: 협업 문서 편집 플랫폼

시나리오:
1. 문서의 다양한 부분에 대한 특화된 병합 규칙 정의:
   - 텍스트: 충돌 시 모든 변경사항 하이라이트하여 사용자 선택 요청
   - 숫자 데이터(예: 예산): 최대값, 최소값, 또는 평균값 자동 선택
   - 체크리스트: 항목별 병합(한 쪽에서 체크된 항목은 병합 시 체크 유지)
2. 사용자 A가 문서의 숫자 필드를 100에서 120으로 변경
3. 사용자 B가 동시에 같은 필드를 100에서 130으로 변경
4. 병합 시 "숫자 필드의 최대값 선택" 규칙 적용
5. 최종 값으로 130 선택

구성 요소

약한 일관성 모델의 주요 구성 요소와 그 역할은 다음과 같다:

장점과 단점

도전 과제

약한 일관성 모델을 구현하고 유지하는 데 있어서의 주요 도전 과제는 다음과 같다:

1. 충돌 해결: 동시 업데이트로 인한 데이터 충돌을 효과적으로 해결하는 것은 복잡한 문제이다. 적절한 충돌 해결 전략을 선택하고 구현해야 한다.

2. 최종 일관성 달성 보장: 시스템이 안정적으로 최종 일관성을 달성하도록 보장하는 것은 어려울 수 있다. 특히 지속적인 업데이트나 네트워크 문제가 있는 경우 더욱 그렇다.

3. 데이터 신선도 관리: 사용자가 오래된 데이터를 볼 수 있다는 점을 고려하여, 애플리케이션 수준에서 데이터 신선도를 어떻게 관리할지 결정해야 한다.

4. 개발자 친화적 인터페이스: 약한 일관성의 복잡성을 추상화하면서도 개발자가 필요한 제어를 할 수 있는 균형 잡힌 API 를 설계해야 한다.

5. 모니터링 및 디버깅: 분산된 노드에서 발생하는 일관성 문제를 모니터링하고 디버깅하는 것은 어려울 수 있다.

6. 데이터 손실 가능성 최소화: 노드 장애 시 데이터 손실을 최소화하기 위한 전략을 구현해야 한다.

7. 일관성 수준 조정: 애플리케이션의 요구사항에 맞게 일관성 수준을 조정하는 것은 복잡한 작업이다.

분류에 따른 종류 및 유형

실무 적용 예시

활용 사례

사례 1

소셜 미디어 플랫폼은 약한 일관성 모델의 대표적인 활용 사례이다.
사용자가 글을 게시하거나 댓글을 달면, 이 정보는 즉시 모든 팔로워에게 전파되지 않고 비동기적으로 전파된다.

시나리오:

1. 사용자 A 가 새 게시물을 작성한다.
2. 게시물은 사용자 A 의 로컬 데이터 센터에 저장된다.
3. 사용자 A 는 즉시 성공 응답을 받는다.
4. 게시물은 비동기적으로 다른 지역의 데이터 센터로 복제된다.
5. 사용자 B(다른 지역) 가 타임라인을 로드할 때, A 의 게시물이 아직 복제되지 않았다면 보이지 않을 수 있다.
6. 시간이 경과하면 복제가 완료되고 사용자 B 는 A 의 게시물을 볼 수 있게 된다.

이 시나리오에서 약한 일관성은 다음과 같은 이점을 제공한다:

• 게시물 작성 시 즉각적인 응답으로 사용자 경험이 향상된다.
• 데이터 센터 간 동기화가 비동기적으로 이루어져 시스템 부하가 분산된다.
• 네트워크 문제가 있어도 사용자는 계속해서 서비스를 이용할 수 있다.

사례 2

약한 일관성 모델의 대표적 사례인 Amazon DynamoDB를 중심으로 아키텍처와 구현 방식을 설명한다.

Amazon DynamoDB 아키텍처 다이어그램

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

[클라이언트]
       │
       ├─ (쓰기 요청) ──▶ [마스터 노드]
       │                    │
       │                    ├─ 비동기 복제 ──▶ [복제본 노드 1]
       │                    └─ 비동기 복제 ──▶ [복제본 노드 2]
       │
       └─ (읽기 요청) ──▶ [가장 가까운 노드]
                          │
                          ├─ 최종적 일관성: 즉시 응답 (과거 데이터 가능)
                          └─ 강력한 일관성: 모든 노드 동기화 확인 후 응답

핵심 아키텍처 요소

1. 파티셔닝

   • 데이터를 해시 키 기반으로 자동 분할 (샤딩)
   • 각 파티션은 3 개 이상의 가용 영역 (AZ) 에 복제

2. 비동기 복제 메커니즘

   • 쓰기 작업 시 마스터 노드에서 즉시 처리 후 복제본에 비동기 전파
   • 복제 지연 시간: 일반적으로 1 초 미만

3. 충돌 해결 전략

   • Last Write Wins(LWW): 타임스탬프 기반 최신 데이터 선택
   • 클라이언트 측 병합: 애플리케이션에서 버전 벡터 비교 후 처리

구현 방식 예시: 전자상거래 장바구니 시스템

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# DynamoDB 항목 구조 예시
item = {
    "CartID": "user123",
    "Items": {
        "productA": 2,
        "productB": 1
    },
    "Version": 3  # 버전 관리를 위한 벡터 클럭
}

# 쓰기 작업 (강력한 일관성)
dynamodb.put_item(
    TableName='ShoppingCart',
    Item=item,
    ConditionExpression='Version = :prev_version',
    ExpressionAttributeValues={':prev_version': 2}
)

# 읽기 작업 (최종적 일관성)
response = dynamodb.get_item(
    TableName='ShoppingCart',
    Key={'CartID': 'user123'},
    ConsistentRead=False  # 약한 일관성 모드
)

동작 흐름:

1. 사용자 A 가 제품 추가 → 마스터 노드에 즉시 반영
2. 복제본 노드들은 비동기적으로 업데이트 수신 (지연 가능)
3. 사용자 B 가 장바구니 조회 → 가장 가까운 복제본에서 데이터 제공
4. 일시적 불일치 발생 시 자동 충돌 해결 (버전 비교)

주요 설계 고려사항

1. 세션 일관성 (Session Consistency)
   • 동일 클라이언트는 동일 노드로 라우팅되어 일관성 유지
2. 모니터링 메트릭
   • ReplicationLatency 지표로 복제 지연 추적
3. 폴백 전략
   • 일관성 읽기 실패 시 버전 비교 후 재시도 구현

사례 3

캐시 시스템 (Cache System)

시스템:

• Redis / Memcached 기반 캐시 계층
• CDN (Content Delivery Network) 캐시 서버
• 로그 수집 시스템의 버퍼 노드
• IoT 장치의 임시 로컬 저장소

시나리오:
쇼핑몰에서 상품 상세 페이지를 열 때, DB 에서 데이터를 직접 읽기엔 느리기 때문에 캐시에서 빠르게 가져오도록 설계됨.

• 데이터는 Weak Consistency 를 따르는 캐시에 먼저 저장됨.
• 캐시는 일정 TTL(Time-To-Live) 혹은 비동기적인 방식으로만 갱신됨.
• DB 의 데이터가 바뀌어도 캐시에 즉시 반영되지 않을 수 있음.

쇼핑몰 상품 조회

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

시간(Time) 흐름 →
사용자 A:     ──── Update(Product#123, price=300) ────► [DB]
                                                  └────X (캐시 반영 안 됨)

사용자 B:         ◄──── Read(Product#123) ─────── [Cache: price=250]
                                                          ↓
                                                        오래된 값

시간 경과 후...
                            ◄──── Cache Refresh (price=300)

사용자 C:         ◄──── Read(Product#123) ─────── [Cache: price=300]

• 사용자 A 가 DB 에 상품 가격을 업데이트했지만,
• 사용자 B 는 아직 캐시에 저장된 오래된 값 (price=250) 을 읽음
• 일정 시간이 지나 캐시가 갱신되어 사용자 C 부터는 최신 값 (price=300) 을 보게 됨

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

최적화하기 위한 고려사항 및 주의할 점

최신 동향

주제와 관련하여 주목할 내용

주제와 관련하여서 하위 주제로 분류해서 추가적으로 학습해야할 내용

주제와 관련하여서 추가로 알아야 하거나 학습해야할 내용들

용어 정리

용어 정리

참고 및 출처

• Weak vs Eventual Consistency in System Design – GeeksforGeeks
• Consistency Patterns – CS.fyi
• Amazon Dynamo: A Highly Available Key-value Store (SOSP 2007)
• Designing Data-Intensive Applications – Martin Kleppmann
• AWS DynamoDB 공식 문서 – 일관성 설정
• Conflict-free Replicated Data Types (CRDTs)
• Weak Consistency Models - Microsoft Research
• Amazon DynamoDB Consistency Models
• Weak Consistency in Distributed Systems – InfoQ
• CAP Theorem and Consistency in Distributed Systems – InfoQ
• The Art of Scalability – AKF Partners 블로그
• System Design - Consistency Patterns
• Consistency Model in Distributed System – GeeksforGeeks
• Eventual vs Strong Consistency in Distributed Databases – HackerNoon
• Consistency in Distributed Systems – Michael Whittaker
• What are Consistency Models? – ScyllaDB
• Eventually Consistent - Revisited – All Things Distributed
• Eventual Consistency vs. Strong Eventual Consistency vs. Strong Consistency – Baeldung