백엔드 데이터 인프라 102편 — Kafka 다중 데이터센터 (Stretched · Local + Mirror)

2026-05-17•백엔드 데이터 인프라

백엔드 데이터 인프라 102편. Kafka 다중 데이터센터 운영 — Stretched Cluster vs Local Cluster + Mirror 두 가지 전략, Aggregate Cluster 패턴, WAN 환경 socket buffer 조정, 지연 vs 가용성 trade-off 까지 풀어쓴 학습 노트.

이 글은 백엔드 데이터 인프라 시리즈 130편 중 102편이에요. 101편 까지 단일 cluster 운영 을 잡았다면, 이번 102편은 지역 분산 — 여러 데이터센터·리전에 걸친 Kafka 운영.

다중 데이터센터가 어렵게 느껴지는 이유

CAP theorem(일관성·가용성·분할내성 중 둘만) 영역이다. 다중 DC(데이터센터)는 Partition Tolerance 가 필수라 C 와 A 사이 trade-off 가 강제된다.

첫째는 Stretched(여러 DC 에 한 cluster) 와 Local(DC 마다 별도 cluster + mirror) 중 무엇을 고르느냐 다. 정답은 환경에 따라 다르다. 둘째는 MirrorMaker 2(cluster 간 복제 도구) 의 위치 — 언제·어떻게 운영하느냐. 이 글에서 두 가지를 중심으로 전략·아키텍처 패턴·운영 trade-off 를 정리한다.

핵심 권장 — Local Cluster + Mirror

공식 문서의 첫 줄:

"Our recommended approach is to deploy a local Kafka cluster in each datacenter, with application instances in each datacenter interacting only with their local cluster and mirroring data between clusters."

패턴

DC1                              DC2
[App A] → [Local Kafka A]        [Local Kafka B] ← [App B]
              │                       ↑
              │ Mirror                │
              └───────────────────────┘
              (MirrorMaker 2)

각 DC 가 자체 Kafka cluster 를 띄우고, 애플리케이션은 local cluster 만 접근한다. DC 간 데이터 동기화는 Mirror 라는 별도 컴포넌트가 맡는다.

장점

DC 독립성이 가장 크다. DC1 이 죽어도 DC2 는 혼자 굴러간다. local read/write 이므로 WAN(광역 네트워크) 을 안 거쳐 latency 도 낮고, WAN link 가 끊겨도 각 DC 가 정상 동작한다. 관리 측면에서도 DC 간 복제만 따로 들여다보면 된다.

단점

Mirror lag 가 따라온다. DC1 의 데이터가 DC2 에 도착하기까지 수 ms ~ 수 초가 걸리고, 결과적으로 DC 사이는 eventual consistency(시간이 지나야 일치) 다. MirrorMaker 2 cluster 를 별도로 운영해야 하니 운영 부담도 따로 생긴다.

안티 패턴 — Stretched Cluster

공식 문서의 강한 경고:

"It is generally not advisable to run a single Kafka cluster that spans multiple datacenters over a high-latency link."

패턴 (안 좋음)

[Broker 1, 2 in DC1] ─── replication ─── [Broker 3, 4, 5 in DC2]
                       (high latency WAN)

문제

모든 write 가 WAN replication 을 거치니 latency 가 폭증한다. min.insync.replicas 의 대상이 다른 DC 까지 걸치면 결국 WAN 에 의존하는 셈이고, DC 간 link 가 끊기면 Kafka 전체가 멈춘다. Quorum(과반 합의) split-brain 위험도 따라온다.

언제 OK?

Low-latency link 일 때만이다. 같은 metro 안 다른 AZ(Availability Zone, 가용 영역) 정도, 즉 5~10 ms 이내 가 기준. 진정한 지역 분산 (다른 대륙) 이면 절대 X.

Aggregate Cluster 패턴

여러 DC 의 데이터를 한 곳에 모아 분석하고 싶을 때 쓰는 구조다.

DC1 (Asia)   → [Local Kafka A] ─┐
DC2 (US)     → [Local Kafka B] ─┼→ [Aggregate Kafka] → 분석·ML
DC3 (Europe) → [Local Kafka C] ─┘

각 DC 는 운영용 local cluster 로 돌리고, Aggregate Cluster(통합 집계용 cluster) 가 모든 DC 데이터를 mirror 로 받아간다. 글로벌 분석·ML 학습·BI(Business Intelligence, 경영 분석) 는 aggregate 에서 돌린다. Netflix·Uber·LinkedIn 같은 대규모 환경의 표준 패턴이다.

MirrorMaker 2

DC 간 mirror 의 표준 도구이고, Kafka Connect(외부 시스템 연동 프레임워크) 위에서 돈다.

기본 사용

# mm2.properties
clusters = primary, secondary
primary.bootstrap.servers = kafka-dc1:9092
secondary.bootstrap.servers = kafka-dc2:9092

primary->secondary.enabled = true
primary->secondary.topics = orders, payments

$ bin/connect-mirror-maker.sh mm2.properties

특징

기본은 Active-Passive 라 DC1 에서 DC2 로 단방향 복제다. secondary->primary.enabled=true 를 추가하면 양방향 Active-Active 로 바뀐다. 복제된 topic 이름에는 원본 cluster 이름이 prefix 로 붙어 primary.orders 같은 형태가 되고, consumer 가 DC 를 옮길 때를 위해 consumer offset 도 자동으로 매핑(translation) 해준다. Topic 설정과 ACL(Access Control List, 접근 권한 목록) 까지 함께 sync 된다.

자세한 내용은 103편 Geo-Replication 에서.

WAN 환경 조정

다중 DC 환경에서는 Kafka 자체 설정 도 조정이 필요하다.

TCP Buffer

# producer / consumer / broker
socket.send.buffer.bytes=1048576       # 1MB (기본 128KB)
socket.receive.buffer.bytes=1048576    # 1MB (기본 64KB)

대역폭이 크고 latency 가 긴 환경이면 TCP buffer 를 늘려야 한다. 적정값은 Bandwidth-Delay Product(대역폭 × RTT, 회선이 동시에 띄울 수 있는 데이터 양) 로 계산한다.

Replication Timeout

replica.lag.time.max.ms=60000          # 60초 (DC 간 안정성)
replica.socket.timeout.ms=60000

WAN latency 가 수십 ms 면 기본값 30초가 빠듯할 수 있다.

Producer linger

linger.ms=20
batch.size=65536

WAN 환경에서는 batch 를 크게 묶는 쪽이 효율적이다. RTT(Round-Trip Time, 왕복 지연) 가 전체 성능을 좌우하기 때문이다.

4가지 다중 DC 전략

Strategy 1: Active-Active (양방향 mirror)

DC1 ⇄ DC2 (both serve traffic)

같은 topic 을 양쪽에서 publish/consume 한다. Topic 이름으로 DC 를 구분(dc1.orders·dc2.orders) 해야 하고, 합쳐서 보면 중복 위험이 생기는 데다 cross-DC 일관성 관리도 복잡하다. 운영이 매우 까다로워서 대규모 + 명확한 use case 가 있을 때만 쓴다.

Strategy 2: Active-Passive (DR)

DC1 (primary) → mirror → DC2 (standby, read-only)

평소에는 DC1 만 운영하고, DR(Disaster Recovery, 재해 복구) 상황에서 DC2 로 failover 한다. 단순하고 운영 부담이 낮아 가장 일반적인 패턴이다.

Strategy 3: Aggregate-Only

DC1, DC2, DC3 → 각자 local → Aggregate DC4 (read-only for analytics)

운영은 각 DC 의 local cluster 에 맡기고 분석만 aggregate 에서 돌린다. 책임 분리가 명확하다.

Strategy 4: Stretched (low-latency only)

같은 metro 의 AZ-1, AZ-2, AZ-3 = 한 cluster

replication factor 3 으로 AZ 마다 한 copy 를 두는 rack-aware 구성이라, AZ 한 곳이 죽어도 정상이다. AWS Multi-AZ MSK 같은 환경에서 일반적이다.

Rack Awareness — AZ 분산 (Stretched 변형)

# broker 별 설정
broker.rack=us-east-1a
broker.rack=us-east-1b
broker.rack=us-east-1c

Rack Awareness(같은 rack 에 replica 안 몰리게 분산) 를 켜면 Kafka 가 replica 를 다른 rack 에 자동 배치한다. AZ 한 곳이 죽어도 안전하다. Stretched cluster 의 안전한 형태 = same-region multi-AZ + rack awareness.

다중 DC 모니터링 핵심

Mirror Lag — DC1 → DC2 복제 지연 (MirrorMaker 2 메트릭)
WAN throughput — 대역폭 활용
WAN packet loss — link 건강
DC 별 cluster health — 각자 monitoring

한계·실무 함정

1. Stretched cluster 강행 (먼 거리)

WAN latency 가 수십~수백 ms 면 모든 write 가 그만큼 느리다. 절대 금지.

2. Active-Active 의 중복

같은 메시지가 두 DC 에 publish 되면 consumer 가 같은 걸 두 번 처리한다. Topic naming 과 ACL 로 source 를 명확히 구분해야 한다.

3. Mirror 일관성 가정

mirror 는 eventual consistency 라는 점을 잊으면 안 된다. real-time cross-DC consistency 가 필요하면 분산 DB 같은 다른 도구를 써야 한다.

4. WAN 비용

데이터 mirror 는 곧 WAN traffic 이라 클라우드 inter-region 비용이 폭증할 수 있다. retention·compression 을 조이고 필요한 topic 만 골라 mirror 하는 식으로 비용을 관리한다.

5. Failover 시나리오 미준비

DR 시뮬레이션을 안 해두면 실제 장애 상황에서 어떻게 동작할지 알 수 없다. 주기적인 DR 훈련이 필수다.

시험 직전 한 번 더 — Kafka 다중 DC 함정 압축 노트

권장 패턴 = 각 DC 별 local cluster + mirror (단일 stretched X)
장점 — DC 독립성·낮은 latency·WAN 장애 안전·중앙 관리
단점 — Mirror lag (eventual consistency)
Stretched Cluster 금지 — WAN latency 환경
Stretched OK = low-latency link (같은 metro, < 10ms)
Aggregate Cluster = 글로벌 분석용 (Netflix·Uber·LinkedIn 표준)
MirrorMaker 2 = DC 간 mirror 도구 (Kafka Connect 기반)
특징 — topic prefix, consumer offset translation, ACL/config sync
4가지 전략 = Active-Active · Active-Passive (가장 흔함) · Aggregate-Only · Stretched (low-latency only)
WAN 조정 = socket.*.buffer.bytes 늘림 · replica.lag.time.max.ms 늘림 · linger.ms/batch.size 늘림
Bandwidth-Delay Product 계산으로 TCP buffer 결정
Rack Awareness = broker.rack 으로 AZ 분산 replica
AWS Multi-AZ MSK = stretched 의 안전한 형태
모니터링 = mirror lag·WAN throughput·packet loss·DC 별 health
함정 — Stretched 강행 (먼 거리)
함정 — Active-Active 중복 위험
함정 — Mirror eventual consistency 가정 누락
함정 — WAN 비용 폭증 (mirror 신중)
함정 — DR 시나리오 미훈련

공식 문서: Kafka Datacenters 에서 자세한 운영 가이드를 확인할 수 있어요.

시리즈 다른 편 (앞뒤 글 모음)

이전 글:

다음 글:

※ 이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.