Phase 7레슨 33

Spanner

Global ACID, TrueTime, Paxos — 전 세구에서 일관된 트랜잭션

💡ELI5·

세계 시계와 Spanner

문제: 서울, 도쿄, 뉴욕 서버가 각각 다른 시계를 가짐
  → "누가 먼저?"를 합의하기 어려움

TrueTime:
  now() → [earliest: 10:00:00.000, latest: 10:00:00.007]
  → 7ms의 불확실성 구간

Commit Wait:
  커밋 타임스탬프 = latest
  → 이 시간이 확실히 지날 때까지 대기 (7ms)
  → 이후 다른 노드가 읽으면 일관된 순서 보장
💡 비유 — 세계 각국의 회의실에서 회의 순서를 정해야 하는데, 각 회의실 시계가 1-2초씩 다르다. TrueTime은 '현재 시간이 이 구간 안에 있다'라고 명시하고, 그 구간이 확실히 지난 후에 다음 회의를 시작하여 순서가 꼬이지 않게 한다.
🔬Deep Dive·

TrueTime API

TrueTime API:
  TT.now() → TTinterval { earliest, latest }
  TT.after(t) → bool  // t가 확실히 지났는가?
  TT.before(t) → bool // t가 확실히 이전인가?

  불확실성(epsilon) = latest - earliest
  GPS + 원자시계로 epsilon을 1-7ms 수준으로 유지

  일반 NTP: 수십~수백 ms 불확실성
  TrueTime: 1-7ms (하드웨어 지원)
🔬Deep Dive·

글로벌 분산 복제

Replica Group (Paxos 기반):
  서울 (Primary)  ──┐
  도쿄 (Replica)  ──┼── Paxos 합의
  뉴욕 (Replica)  ──┘

  쓰기: Primary가 받아서 Paxos로 복제
  읽기: 로컬 Replica에서 읽기 (Read-Only, 과거 데이터 가능)
  강한 읽기: Primary에서 읽기 (최신 보장)

  데이터가 여러 대륙에 복제 → 대륙 장애에도 서비스 유지
⚖️Trade-off·

Spanner의 Trade-off

이점대가
글로벌 ACID 트랜잭션Commit Wait 지연 (수 ms)
전 세구 일관성GPS + 원자시계 하드웨어 필요
대륙 장애에도 서비스 유지비용 매우 높음
강한 일관성 읽기일반 DB보다 복잡한 인프라
Spanner는 '일관성이 비즈니스에 절대적인' 경우에만 가치가 있다. 대부분의 웹 서비스는 최종 일관성으로 충분하다.

❓ 체크포인트 질문

  1. 1.Spanner가 기존 분산 DB와 다른 점은?
  2. 2.TrueTime이 해결하는 핵심 문제는?
  3. 3.Commit Wait이 왜 필요한가?
  4. 4.Spanner가 CAP에서 CP인 이유는?
  5. 5.Spanner의 비용이 높은 이유는?
← 이전
Bigtable
목록
다음 →
Dynamo