[Kafka DR ①] Kafka DR 설계의 기초 — RPO/RTO부터 토폴로지 선택까지

리전 하나가 통째로 사라지는 순간, 여러분의 Kafka는 어디까지 견딜 수 있을까요? 평소에는 보이지 않던 질문이지만, 장애가 터지는 순간 가장 먼저 답해야 하는 질문입니다. "데이터를 얼마나 잃어도 되는가"와 "얼마나 빨리 복구해야 하는가" — 이 두 숫자가 정해지지 않은 DR 설계는 사실 설계가 아니라 희망 사항에 가깝습니다. 이 글은 Kafka DR 구축 시리즈(전 5부) 의 첫 편으로, 본격적인 구축에 앞서 모든 결정의 토대가 되는 RPO/RTO와 토폴로지 선택을 다룹니다.

이 글에서 배우는 것

• RPO와 RTO가 무엇이고, 왜 모든 DR 설계의 출발점인지
• 비동기 복제에서 RPO가 절대 0이 될 수 없는 이유
• Active-Passive, Active-Active, Stretch 세 가지 토폴로지의 동작 원리와 트레이드오프
• 토폴로지별 RPO·RTO·비용·복잡도·쓰기 지연을 정량 비교한 표
• 컴플라이언스·비용·글로벌 서빙 등 요구사항별 토폴로지 선택 기준
• 시리즈 2~5부에서 다룰 구축·페일오버·검증 로드맵

---

1. 왜 RPO/RTO부터 시작하는가

DR을 이야기하면 흔히 "이중화하면 되는 거 아닌가요?"라는 반응이 나옵니다. 하지만 이중화의 방식과 수준은 두 가지 목표 수치가 결정합니다. 이 숫자를 먼저 합의하지 않으면, 과하게 비싼 아키텍처를 짓거나 정작 장애 때 데이터를 잃는 설계를 하게 됩니다.

RPO와 RTO의 정의

RPO는 시간으로 표현된 데이터 손실 허용치입니다. RPO가 5분이라면, 재해 직전 5분간 들어온 데이터는 잃어도 비즈니스가 감당할 수 있다는 뜻입니다. RTO는 시간으로 표현된 다운타임 허용치입니다. RTO가 15분이라면, 장애 발생 후 15분 안에는 컨슈머·프로듀서가 다시 정상 동작해야 한다는 뜻입니다.

두 숫자가 아키텍처를 결정한다

RPO를 작게 만들수록 복제는 더 자주·더 동기적으로 일어나야 하고, 이는 쓰기 지연과 비용을 끌어올립니다. RTO를 작게 만들수록 페일오버는 자동화·사전 준비가 필요하고, 이는 운영 복잡도를 끌어올립니다. DR 설계는 결국 RPO·RTO 목표와 비용·복잡도·지연 사이의 균형점을 찾는 작업입니다.

핵심 질문은 "장애를 막을 수 있는가"가 아니라 "장애가 났을 때 얼마나 잃고, 얼마나 빨리 복구하는가"입니다. RPO/RTO는 그 답을 숫자로 적은 계약서입니다.

---

2. 비동기 복제와 RPO의 한계

Kafka의 크로스 클러스터 복제(예: MirrorMaker 2)는 기본적으로 비동기(asynchronous) 입니다. 프로듀서가 프라이머리 클러스터에 메시지를 쓰면, 복제 도구가 그 메시지를 읽어 DR 클러스터에 다시 씁니다. 이 "읽어서 다시 쓰는" 과정에는 필연적으로 시간 차, 즉 복제 지연(replication lag) 이 존재합니다.

RPO ≈ 재해 시점의 복제 지연

비동기 복제에서 재해가 발생하면, 프라이머리에는 도착했지만 아직 DR로 복제되지 못한 메시지들이 함께 사라집니다. 따라서:

비동기 복제의 RPO ≈ 재해가 발생한 바로 그 순간의 복제 지연

복제 지연이 항상 200ms라면 RPO는 약 200ms입니다. 하지만 지연은 고정값이 아닙니다. 트래픽이 몰리거나 네트워크가 출렁이면 지연은 수 초~수 분까지 벌어질 수 있고, 하필 그 순간 재해가 나면 RPO도 그만큼 커집니다. 그래서 비동기 복제의 RPO는 절대 0이 될 수 없습니다. 0에 가깝게 만들 수는 있어도, "잃는 데이터가 정확히 0"을 보장하려면 동기 복제(뒤에서 다룰 Stretch 클러스터)가 필요합니다.

복제 지연을 키우는 요인

이 표가 시사하는 바는 명확합니다. 복제 지연을 상시 모니터링하고, 그 지연이 곧 여러분의 실질 RPO임을 인지해야 합니다. (지연 모니터링과 오프셋 추적은 시리즈 3부에서 자세히 다룹니다.)

---

3. 세 가지 DR 토폴로지

Kafka DR을 구성하는 대표 토폴로지는 세 가지입니다. 각각이 RPO·RTO·비용·복잡도에서 전혀 다른 지점에 위치합니다.

3.1 Active-Passive (Warm Standby)

가장 보편적이고 단순한 구성입니다. 프라이머리 클러스터만 트래픽을 처리하고, DR 클러스터는 비동기 복제(예: MirrorMaker 2)로 데이터를 받아 대기합니다.

• 동작: 평상시 모든 읽기/쓰기는 프라이머리에서 일어납니다. DR은 복제만 받으며 서빙하지 않습니다.
• 페일오버: 재해 시 컨슈머·프로듀서를 DR 클러스터로 전환합니다. 이때 컨슈머는 번역된 오프셋부터 소비를 재개해야 합니다(4부 주제).
• 장점: 구성이 단순하고, 단방향 복제라 루프나 충돌을 고민할 필요가 없습니다. 비용도 가장 낮습니다.
• 단점: 비동기이므로 RPO가 0이 아닙니다. DR은 평소 트래픽을 받지 않아 자원이 노는 셈입니다. 페일오버에는 사람/자동화의 개입과 약간의 시간이 필요해 RTO가 분 단위가 되기 쉽습니다.

3.2 Active-Active (양방향)

두 클러스터가 동시에 트래픽을 처리하고, 서로의 데이터를 양방향으로 복제합니다. 글로벌 서비스에서 지역별로 가까운 클러스터를 쓰면서도 전체 데이터를 공유하고 싶을 때 적합합니다.

• 동작: 두 클러스터 모두 쓰기를 받고, 각자의 토픽을 상대에게 복제합니다.
• 사이클 방지 필수: A → B로 복제된 메시지가 다시 B → A로 되돌아오는 무한 루프를 막아야 합니다. MM2는 토픽에 소스 클러스터 별칭을 접두어로 붙여(예: A.orders) 자기 자신이 복제한 토픽은 다시 복제하지 않도록 합니다.
• 충돌 처리: 같은 키를 양쪽에서 동시에 갱신하면 순서/충돌 문제가 생깁니다. 키별로 "쓰기를 받는 클러스터"를 고정하거나(파티셔닝), 애플리케이션 레벨에서 충돌을 해소하는 설계가 필요합니다.
• 장점: 모든 클러스터가 자원을 활용하고, 지역별 저지연 서빙이 가능합니다. 한쪽이 죽어도 다른 쪽이 이미 트래픽을 처리 중이라 RTO가 가장 짧을 수 있습니다.
• 단점: 복잡도가 가장 높습니다. 사이클 방지, 충돌 처리, 양쪽 오프셋/컨슈머 그룹 관리까지 고려해야 합니다. 비동기 복제이므로 RPO는 여전히 0이 아닙니다.

3.3 Stretch 클러스터 (AZ/리전 걸친 단일 클러스터)

별도의 두 클러스터가 아니라, 하나의 Kafka 클러스터를 여러 가용 영역(AZ) 또는 리전에 걸쳐 배치합니다. 복제는 클러스터 간이 아니라 클러스터 내부의 동기 복제로 이루어집니다.

• 랙 인식(rack awareness): 각 브로커에 broker.rack을 지정하면, Kafka가 한 파티션의 복제본(replica)을 서로 다른 AZ에 분산 배치합니다. 한 AZ가 통째로 죽어도 다른 AZ에 복제본이 살아 있습니다.
• 동기 복제: 프로듀서가 acks=all, 토픽이 min.insync.replicas=2(이상)로 설정되면, 쓰기는 여러 AZ의 복제본이 받았음을 확인한 뒤에야 성공으로 응답됩니다. 즉 한 AZ가 죽어도 이미 커밋된 데이터는 다른 AZ에 보장되어 있습니다.
• RPO ≈ 0: 동기 복제 덕분에 데이터 손실이 사실상 0에 수렴합니다. 이것이 Stretch의 가장 큰 강점입니다.
• 쿼럼 요건: 컨트롤러 쿼럼(KRaft)과 min.insync.replicas를 동시에 만족하려면 최소 3개 영역이 권장됩니다. 2개 영역은 한쪽이 죽으면 쿼럼을 잃을 수 있습니다.
• 단점: 모든 쓰기가 영역 간 동기 복제를 기다리므로 쓰기 지연이 영역 간 네트워크 왕복(RTT)에 직접 묶입니다. 영역(리전) 간 거리가 멀수록 지연이 커져, 보통 같은 메트로/근거리 리전 또는 멀티 AZ에 적합합니다.

---

4. 토폴로지 정량 비교

세 토폴로지를 한 표로 비교하면 트레이드오프가 명확해집니다.

핵심 트레이드오프를 한 문장으로 요약하면 이렇습니다. Stretch는 RPO를 0에 가깝게 만드는 대신 쓰기 지연과 영역 간 거리 제약을 받고, Active-Passive/Active-Active는 쓰기 지연 없이 먼 리전까지 보호하는 대신 RPO를 일부 포기합니다.

---

5. 요구사항별 토폴로지 선택 기준

정답은 하나가 아닙니다. 여러분의 RPO/RTO 목표, 컴플라이언스 요건, 지리적 분포, 예산에 따라 달라집니다. 아래 기준으로 시작하세요.

결정 가이드

흔한 함정

• "DR 클러스터만 두면 RPO가 0"이라는 오해 — 비동기 복제인 한 RPO는 복제 지연만큼 존재합니다. 진짜 0이 필요하면 Stretch(동기)를 검토하세요.
• 2개 영역만으로 Stretch 구성 — 쿼럼을 잃을 수 있습니다. 컨트롤러/ISR 쿼럼을 위해 최소 3개 영역을 확보하세요.
• 원거리 리전에 Stretch 적용 — 영역 간 RTT가 그대로 쓰기 지연이 됩니다. 원거리 보호가 목적이면 비동기 복제 토폴로지가 맞습니다.
• RTO만 보고 RPO를 잊는 것 — "빨리 복구"만 신경 쓰다 보면 "얼마나 잃는가"를 놓칩니다. 두 숫자를 함께 정하세요.

---

6. 시리즈 로드맵

이 글은 토대를 다지는 1부였습니다. 남은 4부에서 설계를 실제 구축·운영·검증으로 이어갑니다.

2부에서는 가장 보편적인 Active-Passive 구성을 MirrorMaker 2로 실제 구축하는 과정을 단계별로 다룹니다.

---

마치며 — 핵심 요약

• 모든 DR 설계는 RPO(허용 데이터 손실)와 RTO(허용 다운타임) 두 숫자에서 출발합니다. 이 숫자가 없으면 설계가 아니라 희망입니다.
• 비동기 크로스 클러스터 복제의 RPO는 재해 시점의 복제 지연과 같으며, 절대 정확히 0이 될 수 없습니다. 0에 가깝게는 만들 수 있어도 0을 보장하려면 동기 복제가 필요합니다.
• Active-Passive는 가장 단순·저렴하지만 RPO가 0이 아니고 RTO는 분 단위입니다. 비용에 민감하고 분 단위 손실을 허용할 때 적합합니다.
• Active-Active는 자원을 완전히 활용하고 글로벌 저지연 서빙이 가능하지만, 사이클 방지와 충돌 처리로 복잡도가 가장 높습니다.
• Stretch 클러스터는 동기 복제로 RPO를 0에 수렴시키지만, 영역 간 쓰기 지연과 최소 3개 영역(쿼럼) 요건이 붙고 원거리 리전에는 부적합합니다.
• 컴플라이언스·무손실 → Stretch, 비용 민감 → Active-Passive, 글로벌 저지연 → Active-Active. 요구사항이 선택을 결정합니다.
• 다음 2부에서는 이 토대 위에 MirrorMaker 2로 실제 Active-Passive DR을 구축합니다.

참고 자료

• Apache Kafka. "Geo-Replication (Cross-Cluster Data Mirroring)" — https://kafka.apache.org/documentation/#georeplication
• Apache Kafka. "MirrorMaker 2.0 (KIP-382)" — https://cwiki.apache.org/confluence/display/KAFKA/KIP-382%3A+MirrorMaker+2.0
• Apache Kafka. "Rack Awareness & Replica Placement" — https://kafka.apache.org/documentation/#basic_ops_racks
• Confluent. "Disaster Recovery for Multi-Region Kafka" — https://docs.confluent.io/platform/current/multi-dc-deployments/index.html
• Confluent. "Multi-Region Clusters" — https://docs.confluent.io/platform/current/multi-dc-deployments/multi-region.html

---

— Data Dynamics 엔지니어링 팀