Block 2: Data Sync & Replication

쓰기는 어디서 받고, 복제는 얼마나 늦으며, 장애 때 무엇을 잃는가

서비스마다 맞는 저장소가 다르다

CloudFront→ VPC origin→ internal ALB→ EKS 서비스 (private subnet)→ 데이터 계층은 모두 private 연결로만 접근

Aurora PostgreSQL Global DB

order, payment, inventory: ACID 트랜잭션, 단일 writer

DocumentDB Global Cluster

catalog, user-profile, review: 유연한 문서 스키마, 읽기 위주

ElastiCache for Valkey

cart, session, rate-limit: 밀리초 응답, 원본이 아닌 사본

Amazon MSK

order.created 등 도메인 이벤트, saga 조율의 백본

DynamoDB Global Tables

payment idempotency key, 주문 상태 조회처럼 key 단위 접근

Aurora DSQL (대안)

양 리전 쓰기와 RPO 0이 꼭 필요한 SQL 워크로드의 선택지

원칙

저장소마다 복제 모델, 지연, 장애 시 손실이 다릅니다. 서비스별로 "쓰기 위치"와 "허용 RPO"를 먼저 정하고 저장소를 고릅니다.

복제 모델은 세 가지, 대가는 지연

← 강한 일관성, 쓰기 지연 큼쓰기 지연 작음, 결과적 일관성 →

① 동기 multi-Region

커밋 전에 다른 리전에 기록
Aurora DSQL, DynamoDB MRSC
RPO 0, 대신 쓰기마다 리전 간 왕복

② 단일 writer + 비동기 복제

쓰기는 primary 한 곳
Aurora Global DB, DocumentDB Global, Valkey Global Datastore
읽기는 로컬, 장애 시 lag만큼 손실 가능

③ multi-writer + 비동기

모든 리전이 로컬 쓰기
DynamoDB MREC, MSK active-active
충돌 해소 규칙(last writer wins)을 앱이 수용

설계 규칙

쓰기 경로는 일관성을, 읽기 경로는 지연을 우선합니다. 같은 서비스 안에서도 쓰기와 읽기의 모델이 다를 수 있습니다.

Aurora Global DB: 스토리지가 복제한다

us-east-1 (primary)

Writer 1대

Reader 최대 15 - s대

order, payment, inventory

→ 스토리지 복제
보통 1초 미만 →

us-west-2 (secondary)

Reader 최대 16대

로컬 읽기

write forwarding (선택)

s = secondary 리전 수. secondary가 늘면 primary의 reader 한도가 그만큼 줄어듭니다 (예: secondary 10개면 primary reader 5대).

secondary 최대 10개 리전

예전 자료의 "최대 5개"는 구버전 한도. 리전마다 클러스터는 1개

Aurora PostgreSQL 18.3 이상 지원

Global DB는 PG 11부터 18까지 지원. 2026-09 기준 최신 minor는 18.6, 17.11

global writer endpoint

switchover, failover 후에도 같은 이름이 새 primary를 가리킴. 앱 연결 문자열 변경 불필요

비동기라는 사실은 변하지 않음

RPO는 보통 초 단위의 0이 아닌 값입니다. 그래서 다음 슬라이드들의 write forwarding, switchover, RPO 상한 설정이 필요합니다.

Write Forwarding은 대신 전달한다

us-west-2

order-service

secondary reader endpoint

→ DML 전달 →

us-east-1

primary writer 실행, 커밋

→ 스토리지 복제 →

us-west-2

변경 반영 후 읽기

DML만 전달되고, 전달된 쓰기마다 리전 간 왕복이 붙습니다. statement가 많은 긴 트랜잭션보다 가끔 발생하는 짧은 쓰기에 적합하며, 지연 수치는 반드시 실측하세요.

값	같은 세션의 쓰기	다른 세션, 리전의 커밋	대기 비용
`SESSION` (기본)	즉시 보임 (복제 대기)	기다리지 않음	중간
`EVENTUAL`	복제된 뒤에야 보임	기다리지 않음	가장 낮음
`GLOBAL`	즉시 보임	쿼리 시작 시점까지의 모든 커밋을 기다림	가장 높음
`OFF`	해당 세션에서 write forwarding 끔

파라미터 apg_write_forward.consistency_mode, 세션 단위로 바꿀 수 있고 재부팅 불필요. 격리 수준은 READ COMMITTED, REPEATABLE READ만 지원 (SERIALIZABLE 불가).

# secondary 클러스터에서 켜기 (중단, 재부팅 없음, 기본은 꺼짐)
aws rds modify-db-cluster --region us-west-2 \
  --db-cluster-identifier orders-usw2 \
  --enable-global-write-forwarding

# 세션에서 일관성 모드 확인
SHOW apg_write_forward.consistency_mode;

버전: PG 16 이상은 모든 minor, 15는 15.4 이상, 14는 14.9 이상. 상태는 GlobalWriteForwardingStatus로 확인합니다.

한 줄 정리

write forwarding은 "secondary에서 쓰기 가능"이 아니라 "secondary가 대신 전달"입니다. write-heavy 서비스는 primary 리전에 둡니다.

Switchover만 RPO 0이다

동기화 후 전환 → RPO 0

대상 secondary가 완전히 따라잡을 때까지 기다린 뒤 primary를 read-only로 바꾸고 승격

보통 30초 미만

Aurora PostgreSQL 16.8, 15.12, 14.17, 13.20 이상에서 read/write 복구 시간

조건

모든 클러스터가 정상이고 major, minor 버전이 같아야 함. DR 훈련, 리전 순환, failback 용도

# --region 은 현재 primary 리전
# USW2_ARN: us-west-2 secondary 클러스터 ARN
aws rds switchover-global-cluster \
  --region us-east-1 \
  --global-cluster-identifier shop-global \
  --target-db-cluster-identifier "$USW2_ARN"

DSQL: 두 리전 모두 쓰고 동기 커밋

us-east-1

peered cluster
읽기, 쓰기

⇄ 동기 복제 ⇄

us-west-2

peered cluster
읽기, 쓰기

us-east-2 (witness)

전체 사본 없음, 쓰기 로그로 내구성과 quorum 제공

multi-Region 클러스터는 같은 Region set 안에서만 구성 (북미 set: us-east-1, us-east-2, us-west-2, 캐나다 2개 리전). 대륙 간 구성은 미지원.

RPO 0, 수동 failover 없음

한 리전이 사라져도 나머지 리전이 계속 처리. 가용성 설계 목표 99.999%

OCC, Repeatable Read 고정

잠금 대신 커밋 시 충돌 검사. 충돌한 트랜잭션은 앱이 재시도

트랜잭션 한도

3,000 rows, 10 MiB, DDL 1개, 연결 1시간, SAVEPOINT 미지원

private 연결

AWS PrivateLink interface endpoint와 IAM 인증 토큰으로 접속

DocumentDB: 카탈로그는 읽기 로컬로

us-east-1 (primary)

writer + replica

catalog, review 쓰기

→ 스토리지 기반
물리 복제 →

us-west-2 (secondary)

replica 최대 16대

상품 조회 로컬 처리

예전 자료 정정

"oplog 기반, 2초 이내"가 아니라 전용 인프라의 스토리지 기반 물리 복제이며 일반적인 lag은 1초 미만입니다. 관측: GlobalClusterReplicationLag (secondary)

secondary 최대 10개

쓰기는 primary cluster endpoint로만

switchover (RPO 0)

모든 리전이 같은 engine version일 때만

failover

AllowDataLoss, 미복제분은 스냅샷으로 보존 시도

제약

v3.6과 db.t3, db.t4g, db.r4 인스턴스는 global cluster 미지원

Valkey 캐시: 읽기만 로컬

us-east-1: primary (active)

읽기, 쓰기

cart, session 쓰기 지점

→ 비동기 복제, 보통 1초 미만
(전송 구간 암호화) →

us-west-2: secondary (passive)

읽기 전용

장애 시 수동 promote

secondary 최대 2개

primary 1 + 다른 리전 secondary 2. Valkey 7.2 이상 (최신 9.0, 2026-05)

자동 failover 없음

secondary promote는 직접 실행, 보통 1분 미만. 미복제 쓰기는 손실 가능

동일 구성 강제

node type, engine version, shard 수가 같아야 함. replica 수만 리전별로 다르게

지원 노드

large 이상 M5, M6g, M7g, M8g, R5, R6g, R6gd, R7g, R8g, C7gn, C8gn

장바구니 설계 포인트

us-west-2 사용자의 장바구니 쓰기는 us-east-1 primary까지 갑니다. 캐시는 원본이 아니라 사본으로 두고, 잃어도 재구성 가능한 데이터만 둡니다.

캐시 일관성은 TTL로 관리한다

Cache-aside

miss 때 DB 조회 후 SET. 읽기 많고 쓰기 적은 상품 정보

Write-through

쓰기 시 DB와 캐시를 함께 갱신. 세션, 장바구니

Event-driven invalidation

MSK 이벤트(product.updated)로 키 삭제. 비동기 일관성 허용

TTL 만료

자연 만료 후 재적재. 모든 키의 최종 안전장치

키 패턴	자료형	TTL (설계 예시)	패턴
`product:{id}`	Hash	1h	cache-aside + 이벤트 무효화
`cart:{userId}`	Hash	7d (item별 field TTL 가능)	write-through
`session:{id}`	Hash	2h	write-through
`ratelimit:{userId}`	String counter	60s	INCR + EXPIRE
`stock:{productId}`	String	30s	표시용 사본, 원본은 Aurora

Valkey 9.0의 hash field expiration으로 장바구니 item마다 만료를 따로 둘 수 있습니다. TTL 값은 서비스 요구에 맞춘 예시입니다.

MSK Replicator: offset도 복제

us-east-1 MSK (source)

order.created, payment.completed

IAM 인증 9098, multi-VPC private connectivity

→ 비동기 →

MSK Replicator (us-west-2에 생성)

topic, config, ACL, consumer offset 복제

→

us-west-2 MSK (target)

standby consumer

장애 시 producer 전환

topic 이름

PREFIXED(기본) 또는 identical. identical이면 전환 시 앱 설정 변경 불필요

offset 동기화

LEGACY(기본, 단방향), ENHANCED(양방향 Replicator 필요)

시작 위치, 한도

기본 latest, 생성 후 변경 불가. Replicator당 750 topic

중복은 필연

비동기라 전환 시 재처리 발생. consumer를 idempotent하게

관측

ReplicationLatency(ms), MessageLag, target 리전 AWS/Kafka

Kafka 4.x는 KRaft 전용

3.9가 ZooKeeper 마지막. Standard 4.1, Express 4.2 지원

DynamoDB: MREC와 MRSC 중 고른다

active-active 비동기

모든 replica가 로컬 쓰기, 보통 1초 안에 전파 (SLA 없음)

last writer wins

같은 item을 거의 동시에 쓰면 item 단위로 마지막 쓰기가 이김. 충돌은 기록되지 않음

리전 수 제한 없음

파티션 내 모든 리전에 replica 가능. 트랜잭션은 리전 간 묶여서 복제되지 않음

관측

리전 쌍별 ReplicationLatency 평균, 최대로 최악의 lag 확인

장애 때 무엇을 잃는가: RPO 표

저장소	복제 모델	평시 lag	계획 전환	비계획 장애 시 손실	볼 메트릭
Aurora PostgreSQL Global DB	단일 writer, 비동기	보통 1초 미만	switchover RPO 0	lag만큼 (`rds.global_db_rpo`로 상한)	`AuroraGlobalDBRPOLag`
Aurora DSQL multi-Region	동기, active-active	커밋에 포함	불필요	0	OCC 재시도율
DocumentDB Global	단일 writer, 비동기	보통 1초 미만	switchover RPO 0	lag만큼	`GlobalClusterReplicationLag`
DynamoDB MREC	multi-writer, 비동기	보통 1초 이내, SLA 없음	불필요	미전파 쓰기는 해당 리전 복구 전까지 없음	`ReplicationLatency`
DynamoDB MRSC	동기, 3개 리전	쓰기에 포함	불필요	0	충돌 예외 수

저장소	복제 모델	평시 lag	계획 전환	비계획 장애 시 손실	볼 메트릭
Valkey Global Datastore	단일 writer, 비동기	보통 1초 미만	수동 promote	lag만큼 (캐시는 재구성)	`ReplicationLag`
OpenSearch CCR	leader → follower, 비동기 pull	측정 필요	follower 승격(replication 중지)	미복제 문서, 원천 DB에서 재색인	replication 상태 API
MSK Replicator	비동기	측정 필요	producer 전환	in-flight 유실, 재처리 중복	`ReplicationLatency`, `MessageLag`
S3 CRR + RTC	비동기	대부분 수초	해당 없음	99.99% 객체 15분 내 (SLA 99.9%)	RTC 복제 메트릭

공통 방어선

손실 0이 아닌 행이 대부분입니다. 모든 쓰기 API를 idempotent하게 만들고, 표의 메트릭에 RPO 기준 알람을 겁니다.

Knowledge Check (1/2)

Q1: Aurora write forwarding에서 기본값이며, 내 세션이 방금 쓴 값을 바로 읽게 해 주는 consistency_mode는?

Q2: 리전 장애로 failover-global-cluster --allow-data-loss를 실행했다. 맞는 설명은?

Knowledge Check (2/2)

Q3: 두 리전에서 같은 결제 요청이 재시도될 때 이중 결제를 막는 저장 방식은?

Key Takeaways

① 쓰기 위치부터 정한다

서비스별 쓰기 리전과 허용 RPO를 정의한 뒤 저장소와 복제 모델을 고릅니다

② 계획 전환과 장애 전환은 다르다

switchover는 RPO 0, failover는 lag만큼 손실. global writer endpoint로 연결을 고정

③ RPO 0은 동기 모델에서만

Aurora DSQL, DynamoDB MRSC. 대신 쓰기 지연, OCC 재시도, 트랜잭션 제약을 수용

④ idempotency와 lag 알람

MSK 재처리, 캐시 stale, 비동기 손실을 견디려면 idempotent API와 lag 메트릭 알람이 기본

Thank You

Block 2: Data Sync & Replication 완료

← 목차로 돌아가기 다음: Traffic Routing & Edge →