지난 글에서는 스키마 레지스트리에 대해서 공부했고, 실습을 진행했다.
(지난 내용 : [Kafka 활용] Kafka 심화 4 - 스키마 레지스트리와 실습하기)
그리고 책은 다 읽긴 했다. 다 읽은 기념으로 독서 회고록도
이번 글에서는 Kafka에 대한 글 정리를 마무리하는 시간을 가지려고 한다.
너무나 방대한 카프카의 생태계와 정말 다양한 사용법이 존재하며 이를 일일히 다 공부한다 해도 어짜피 기억도 안나는거 핵심만 가져가고 이런게 있구나~ 하고 다음 관심사로 넘어가는것이 옳다고 생각한다.
우선 기존에 참고하던 도서인 "실전 카프카 개발부터 운영까지 (저자 : 고승범)" 를 마무리 했다.
(교보문고 링크 : 실전 카프카 개발부터 운영까지 : 데이터플랫폼의 중추 아파치 카프카의 내부동작과 개발, 운영, 보안의 모든것)
(독서 회고록 : [도서 회고록] "실전 카프카 개발부터 운영까지"를 읽고)
물론 회고록도 쓰고 마무리 지엇다고 하는 와중에...! 책만 마무리 하려고 했으나...
단순히 책의 글보다는 실전 사례로 토스증권에서 재난 대응을 위한 노력으로 kafka 의 이중화 도입 사례를 읽어보는게 더 재미있어 보여서 읽어보고자 한다. 물론 Uber의 사례도 있어서 이것도 읽어보려고 한다.
목표
1. 토스증권의 Apache Kafka를 활용한 데이터 센터 이중화 구성 블로그를 읽어보고 이해한다.
2. Uber 에서의 Kafka Tired Storage 에 대해 읽어보고 이해한다.
0. 들어가기 전에
글을 정리하기 전에 법정 규정에 대한 배경 지식이 필요하다.
이것이 어느 정보와 이어져 있길래 정리하는지 궁금해하면서 읽는 것이 재미를 한층 끌어올리는데 좋을 것이다.
(키킥! 변태같은 개발자녀석!)
국가법령정보센터에서 전자금융감독규정 제 23조를 확인해보면 다음과 같이 명시 되어있다.
전자금융감독규정 제23조(비상대책 등의 수립ㆍ운용) : 中 ① 금융회사 또는 전자금융업자는 장애ㆍ재해ㆍ파업ㆍ테러 등 긴급한 상황이 발생하더라도 업무가 중단되지 않도록 다음 각 호의 내용을 포함한 업무지속성 확보방안을 수립ㆍ준수하여야 한다.
<개정 2013. 12. 3., 2016. 10. 5.>
그리고 다음을 확인할 수 있다.
전자금융감독규정 제23조(비상대책 등의 수립ㆍ운용) : 中 ⑧ 다음 각 호의 금융회사 및 전자금융업자는 시스템 오류, 자연재해 등으로 인한 전산센터 마비에 대비하여 업무지속성을 확보할 수 있도록 적정 규모ㆍ인력을 구비한 재해복구센터를 주전산센터와 일정거리 이상 떨어진 안전한 장소에 구축ㆍ운용하여야 한다.<개정 2013. 12. 3., 2015. 6. 24, 2025. 2. 5..>
심지어 핵심업무의 복구 목표 시간은 3시간 이내로 규정하고 있다.
전자금융감독규정 제23조(비상대책 등의 수립ㆍ운용) : 中 ⑨ 제8항 각 호의 금융회사는 업무별로 업무지속성 확보의 중요도를 분석하여 핵심업무를 선정하여야 하며, 업무별 복구목표시간을 정하여야 한다. 이 경우 핵심업무의 복구목표시간은 3시간 이내로 하되, 「보험업법」에 의한 보험회사의 핵심업무의 경우에는 24시간 이내로 한다. <신설 2015. 6. 24.>
이는 전자금융감독규정 제13조(전산자료 보호 대책)과 얼핏보면 비슷해 보이지만 제13조 소산백업의 의무는 최후의 데이터 복원으로 데이터가 날아가도 회사가 망하는 것을 막기 위함이다.
전자금융감독규정 제13조(전산자료 보호대책) : 中 ① 금융회사 또는 전자금융업자는 전산자료의 유출, 파괴 등을 방지하기 위하여 다음 각 호를 포함한 전산자료 보호대책을 수립ㆍ운용하여야 한다.
... (중략)
8. 중요도에 따라 정보처리시스템의 운영체제 및 설정내용 등을 정기 백업 및 원격 안전지역에 소산하고 백업자료는 1년 이상 기록·관리할 것
1. Kafka Stretched Cluster와 Kakfa MirrorMaker
해당 섹션의 설명은 다음 AutoMQ 라는 사이트에서 잘 정리해서 이를 참고했다.
AutoMQ - Kafka Stretch Clusters Explained: A Deep Dive into Multi-Datacenter Architecture)
카프카 연장된 클러스터? Kafka Stretched Cluster를 해석하면 그런거 같다.
하나의 kafka cluster를 사용하는데 브로커와 다른 요소들이 물리적으로 다른 데이터 센터들에 분산되어 있는 것이다.
주된 목적은 고가용성(High Availabilty)와 0에 가까운 RPO와 RTO를 가진 재해 복구를 제공하기 위함이다.
이전에 docker 로 실습을 해 봤을 때, kafka cluster라는 것은 그냥 논리적인 하나의 테두리라고 할까?
그림을 잘 보면 데이터 센터만 다를 뿐 복제를 다른 데이터센터에 함으로 단순 kafka cluster에서 kafka stretched cluster 로
문자 그대로 늘어난 카프카 클러스터로 명칭을 정한것 같다.
이와 비슷한 것은 Kafka MirrorMaker라는 게 있다.
(참고 : Kafka MirrorMaker: A Comprehensive Guide With Use Cases & Best Practices)
참고하는 confluent사이트에서는 그림을 영... 보이지 않게 그려놓아서 그렸다.
Kafka MirrorMaker는 Kafka Cluster의 백업을 만들기 위해 사용되는 것 같다.
그림을 보면 별도의 Backup cluster로 Kafka MirrorMaker2 가 data replication 을 진행함을 볼 수 있다.
데이터 복제 기능 (Data Replication Capabilities)
- MM2는 여러 Kafka 클러스터 간에 데이터를 효율적으로 복제하여, 다수의 환경에서 메시지의 실시간 가용성을 보장합니다.
- 이는 곧 MM2가 이중화(Redundancy), 재해 복구(Disaster Recovery), 그리고 하이브리드 또는 멀티 클라우드 배포 환경을 더욱 효과적으로 지원함을 의미합니다.
서로 다른 리전 또는 환경 간의 다중 클러스터 복제
- 지리적으로 분산된 Kafka 클러스터 간의 복제를 지원합니다.
- 글로벌 이벤트 스트리밍, 교차 리전(Cross-region) 간의 데이터 가용성 확보, 그리고 데이터 주권(Data sovereignty) 규정 준수를 가능하게 합니다.
컨슈머 그룹 지원
- MM2는 컨슈머 그룹의 오프셋(Offsets)을 함께 복제하여, 복제된 토픽의 데이터를 소비하는 애플리케이션이 자신의 읽기 위치(Position)를 그대로 유지할 수 있도록 보장합니다.
- 이를 통해 컨슈머의 장애 조치(Failover) 프로세스가 단순해지며, 클러스터 간 애플리케이션을 중단 없이 매끄럽게 마이그레이션할 수 있습니다.
선택적 복제
- 이전 버전인 MM1처럼 클러스터 전체를 무조건 복제하는 대신, 특정 토픽들만 선택하여 복제할 수 있습니다.
- 데이터 동기화를 정밀하게 제어할 수 있으므로 네트워크 대역폭 및 스토리지 비용을 최적화할 수 있습니다.
네트워크 또는 클러스터 장애 발생 시 자동 복구
- 네트워크 단절이나 클러스터에 문제가 발생할 경우, MM2는 자동으로 복구 프로세스를 거쳐 토픽을 다시 동기화합니다.
- 이 기능은 시스템의 고가용성(High Availability)을 보장하며, 서비스 중단 시간(Outage) 동안 발생할 수 있는 데이터 유실을 최소화합니다.
이 MirrorMaker2와 Stretched Cluster의 차이점을 요약 정리해보자.
- MirrorMaker 2 (Cross-Cluster Replication)
- 구조: 두 개의 완전히 독립적인 클러스터로 구성됩니다. (Upstream 클러스터와 Downstream 클러스터)
- 복제 주체: 외부의 별도 애플리케이션(Kafka Connect 워커)이 데이터를 소비하여 타겟에 생산합니다. 주로 비동기(Asynchronous) 방식으로 복제됩니다.
- 목적: 장애 도메인의 완벽한 격리. AWS 리전(Region) 간 복제처럼 물리적 거리가 멀고 네트워크 지연이 큰 환경에 적합합니다.
- Stretched Cluster (Intra-Cluster Replication)
- 구조: 물리적 위치는 다르지만, 논리적으로는 하나의 거대한 클러스터입니다.
- 복제 주체: Kafka 내부의 기본 파티션 복제 메커니즘(Leader-Follower)을 그대로 사용합니다.
- 목적: 고가용성(High Availability) 확보. acks=all 옵션을 사용하면 데이터 센터 간 동기(Synchronous) 복제를 강제할 수 있으며, 특정 데이터 센터 장애 시 클라이언트 애플리케이션의 엔드포인트 변경 없이 즉각적인 Failover가 가능합니다.
여기서 upstream, downstream이라는 개념이 나오는데 이것은 상대적인 개념이다.
순서대로 사전적 의미는 강의 상류와 하류이다.
물은 상류에서 하류로 흐르듯이 데이터가 모이는 곳을 Upstream, 데이터를 받아가는 곳을 Downstream이라고 표현한다.
이상하게 필자는 해당 단어를 듣고 원피스가 생각났다.
주인공 루피는 위대한 항로에 가기 위해 리버스 마운틴이라는 산을 올라타서 (upstream) 방향을 잘 틀어서 그랜드 라인쪽으로 내려간다. (downstream)
그림상에서 화살표를 잘 보면 North Blue, East Blue, West Blue, South Blue 는 upstream이지만
grandline만이 downtream하는 방향으로 그려져 있다.
Kafka에 대입하면 produccer는 4개인데 (각 4개의 바다) 그랜드 라인만이 consumer로 보인다.
이상하게 상류 하류 하니까 어떻게 상류를 거슬러 올라가? 하는 것이 헷갈려서 이게 좋은 연상 도구(?)로 판단한다.
막상 이렇게 말하니 정말 개발 쌉(?) 변태같은(?) 느낌이 살짝 들었지만 뭐... 기억만 잘하면 되지.
2. 토스증권 데이터센터 이중화 구성
엄청난 데이터 처리를 위해서 Kafka 를 도입하는것은 현명하다.
이 엄청난 데이터를 처리하는 토스증권에서 데이터센터 이중화를 구성하기위해 어떻게 했는지의 히스토리를 알려준다.
이것의 근거는? 바로 전자금융감독규정에 있다
전자금융감독규정 제23조(비상대책 등의 수립ㆍ운용) 中 ⑨ 제8항을 근거로 하는 목표 시간(RTO) 3시간을 달성하려면 단순 데이터 백업을 넘어 즉각적인 트래픽 전환(Fail-over)이 가능한 인프라 설계가 필수적이다.
- Multi-AZ 및 물리적 분리: AWS 환경을 기준으로, 핵심업무 서비스는 반드시 2개 이상의 가용 영역(AZ)에 Active-Active 또는 Active-Standby 구조로 분산 배치되어야 합니다.
- 데이터 정합성 (RPO): 핵심업무는 데이터 유실(RPO)이 '0'에 수렴해야 하므로, 주 DB와 복구용 DB 간 동기 방식 리플리케이션(Synchronous Replication)이 강제됩니다. 세션 등 상태 정보를 다루는 Redis 역시 단일 장애점(SPOF)이 되지 않도록 클러스터링 구성 및 영속성(AOF) 전략이 요구됩니다.
- 외부 장애 전파 차단: PG사 결제망 등 외부 시스템의 응답 지연이 내부 핵심업무의 리소스 고갈로 이어지지 않도록, 빠른 실패(Fail-fast)를 유도하는 서킷 브레이커 패턴이 핵심업무 보호의 필수 요소로 작용합니다.
토스 증권에서는 이를 위해 kafka를 active-active로 구성할 것인지 아니면 stretched cluter로 구성할 것인지 고민했다고 한다.
결론적으로 active-active로 선택했다고 한다.
또한, 미러링 위해서 MM2(MirrorMaker2)를 사용하려다 보니 한계점이 있어서 직접 개발을 했다고 한다.
Kafka Connect 프레임워크 중 Sink Connector로 한계를 해결했다고 한다.
데이터센터 이중화 구성 2, 3에서는 생생한 kafka 사용기가 있으니 읽어보길 강력 추천한다.
토스증권 Apache Kafka 데이터센터 이중화 구성 #2
토스증권 Apache Kafka 데이터센터 이중화 구성 #3
그냥 읽고 요약하는건 크게 의미가 없다 생각해서... 몇 번 읽어보고 부족하다 싶은 것은 추가할 예정이다.
3. Kafka Tiered Stoarge from Uber (KIP-405)
또 Uber의 kafka 사용 사례를 찾아보고 있었는데 Kafa Tiered Storage가 눈에 띈다.
(참고 : KIP-405: Kafka Tiered Storage)
KIP는 이름이 붙어서 Kafka Inprovement Proposal의 약자로 수 많은 제안사항이 있고
현 시점으로 KIP-1357 까지 올라와 있는데 2026년 7월 23일 글이 마지막 업데이트가 되어있다.
KIP-405는 우버의 개발자들이 제안했다고 한다.
일반적으로 우리는 broker를 늘림으로써 kafka cluster 저장소를 더 키운다.
그런데 문제점은 broker를 늘리게 되면 불필요한 memory와 CPU를 추가해서 성능을 저하시킨다.
이를 해결하기 위해서, 즉 저장소와 broker에서의 데이터처리의 강결합을 없애기 위해 Uber에서 KIP-405를 제안했다고 한다.
해결책은 단순하다. local저장소와 remote 저장소 이 2개로 나누는 것이다.
Tiered Storage를 도입하면 데이터가 'Hot Data(로컬)'와 'Cold Data(S3)'로 물리적으로 분리된다.
여기서 중요한 점은 S3에 저장된 Cold Data는 특정 브로커에 종속된 것이 아니라, 권한만 있으면 어떤 브로커든 꺼내볼 수 있다.
해당 장점에 대해서 Gemini에게 정리를 요청했다.
- Cold Data 복제 생략: 새 브로커는 S3에 있는 1.99TB의 과거 데이터를 자신의 로컬 디스크로 복사해오지 않습니다. 대신 "오프셋 1번부터 1억 번까지는 S3의 A 경로에 있다"는 메타데이터(인덱스 및 상태 정보)만 동기화합니다. 메타데이터는 용량이 매우 작습니다.
- Hot Data만 복제: 리더 브로커의 로컬 디스크에 남아있는 최근 며칠 치 데이터(예: 10GB)만 네트워크를 통해 새 브로커의 로컬 디스크로 복사합니다.
- ISR 즉시 완료: 새 브로커는 메타데이터와 최근 10GB 데이터만 확보하면 즉시 동기화(ISR)를 마치고 정상 작동을 시작합니다.
그렇다고 한다.
키메라는 멘탈이 나가버렸습니다. 너무 많은 방대한 카프카의 내용 때문인데요, 이때 한 개발자가 기발한 아이디어를 생각해냅니다.
아얘 글을 안적기로 한 것인데요(?)
이제 kafka 관련 글은 이번 글을 마지막으로 다른것도 하다가 생각이 나면 정리하려고 한다.
kafka에 대해서 책을 바탕으로 여러 기능을 알아보고 찍먹을 한 정도이다.
해당 글도 사실 찍먹을 많이 했다.
이거 어짜피 다 못외운다. 이런게 있고, 굉장히 흥미롭다! 하는 정도로만 잘 알아도 충분하다고 생각한다.
이제 하... 또 뭐 공부하지 너무 카프카만 2달 동안 보니까 재미가 없네...
참고 글:
Introduction to Kafka Tiered Storage at Uber
토스증권 Apache Kafka 데이터센터 이중화 구성 #1
토스증권 Apache Kafka 데이터센터 이중화 구성 #2
토스증권 Apache Kafka 데이터센터 이중화 구성 #3
카프카를 활용한 액티브-액티브 DR 구성과 성능 최적화
AutoMQ - Kafka Stretch Clusters Explained: A Deep Dive into Multi-Datacenter Architecture
Kafka MirrorMaker: A Comprehensive Guide With Use Cases & Best Practices
'programming language > Kakfa' 카테고리의 다른 글
| [Kafka 활용] Kafka 심화 4 - 스키마 레지스트리와 실습하기 (0) | 2026.07.24 |
|---|---|
| [Kafka 활용] Kafka 심화 3 - 보안 적용 : Kafka SSL, SASL, ACL (0) | 2026.07.17 |
| [Kafka 활용] Kafka 심화 2 - 안정적인 운영을 위한 지식 한꼬집 + 모니터링 도구 한꼬집 (0) | 2026.07.06 |
| [Kafka 활용] Kafka 심화 1 - Uber System Design와 Kafka 사용 (0) | 2026.07.04 |
| [Kafka 기초 학습] 카프카 기초 개념 7 - KRaft 간단 이해 및 실습 진행 + 사용 사례 조사 (0) | 2026.06.20 |