<div id="readability-page-1" class="page"><div>안녕하세요. 토스증권 실시간 데이터팀 송지수입니다. <a target="_blank" rel="noreferrer noopener" href="https://toss.tech/article/kafka-distribution-1">Kafka 데이터센터 이중화 1편</a>에서 소개된 것처럼, 토스증권은 현재 Active-Active 구성으로 Kafka를 운영하고 있습니다. 오늘은 Active-Active를 유지하기 위해 필요한 양방향 데이터 미러링에 대해 소개하려고 합니다.<h3 id="17ba360d-33e3-804c-8c4e-d27f0d29141c">양방향 데이터 미러링 오픈소스</h3>Apache Kafka에서 제공하는 MirrorMaker2(MM2) 등 다양한 오픈소스 데이터 미러링 도구가 있습니다. 이러한 도구들은 클러스터 간 데이터 복제를 손쉽게 구현할 수 있도록 설계되었습니다.MM2는 Kafka Connect 프레임워크 중 Source Connector 기반으로 동작하며, 두 가지 주요 기능을 제공합니다.<ol><li id="17ba360d-33e3-8049-ab3e-e4267252038e">데이터 전송: Source Cluster(A)에서 발생한 데이터를 Target Cluster(B)로 복제.</li><li id="17ba360d-33e3-801f-9059-cd303a19be12">오프셋 관리: A와 B 간 오프셋 차이를 Source Cluster(A)에 MM2용 내부 토픽으로 저장.</li></ol><figure id="17ba360d-33e3-8036-850a-fca04fab926d"><img src="https://static.toss.im/ipd-tcs/toss_core/live/bd4df790-28e5-4709-bfa5-306f5d40df8f/tech-0114-1.png" alt=""></figure>MM2를 사용하면, 복제된 토픽 이름에 Source Cluster의 alias(접두사)가 자동으로 추가됩니다. 예를 들어, A 클러스터의 <code>topic.test.1</code>은 B 클러스터에서 <code>A.topic.test.1</code>로 미러링됩니다.MM2를 이용해서 양방향 미러링 구성이 가능하지만, 토스증권에서는 MM2를 사용하는 데 한계가 있었습니다. 각 Kafka에서 동일한 토픽 이름으로 미러링하여, 서버 개발자 등 Kafka 사용자들이 단일 토픽으로 데이터에 접근할 수 있는 환경을 제공하는 것이 목표였기 때문입니다. 어떤 데이터 센터의 Kafka에 프로듀스/컨슘하더라도 항상 동일한 한 개의 토픽 이름을 사용할 수 있다면, 사용자들이 Kafka 이중화 구성에 대해 인지하거나, 서버가 배포되는 데이터 센터를 신경쓰지 않아도 되기에, 사용자 편의성을 위해 동일한 토픽명으로 이중화 구성으로 하고자 하였습니다.<h3 id="17ba360d-33e3-805a-94c4-ea42558749ee">토스증권에서 개발한 양방향 데이터 미러링 도구</h3>MM2와 같은 오픈소스는 토스증권 상황에 사용하기엔 한계점이 있어서 직접 만들기로 결정했습니다.토스증권의 환경에 맞춘 데이터 미러링 도구는 Kafka Connect 프레임워크 중 Sink Connector로 구현되었습니다. Sink Connector는 Kafka에서 데이터를 소비한 후, 외부 시스템에 데이터를 저장하는 역할을 수행합니다. 이 외부 시스템을 다른 데이터 센터(DC)의 Kafka로 설정하여, 양방향 데이터 복제를 가능하게 했습니다.저희 팀에서 개발한 양방향 데이터 미러링 도구는 크게 3가지 기능에 집중하였습니다.<ol><li id="17ba360d-33e3-803c-98db-e6b73a3c3b4c">동일한 토픽명으로 양방향 미러링 기능</li><li id="17ba360d-33e3-8043-8677-e49809c35fe7">Dead Letter Queue 기능을 활용한 정합성 보장</li><li id="17ba360d-33e3-801f-99fb-f98d2e5620fc">수 천개의 잡을 모니터링을 위한 메트릭</li></ol><figure id="17ba360d-33e3-802b-8fb7-fc7cef36a3e9"><img src="https://static.toss.im/ipd-tcs/toss_core/live/21d9cb93-869c-494d-a843-d0d4c34dfc29/tech-0114-2.png" alt=""></figure>동일한 토픽명으로 양방향 미러링 기능첫 번째 기능인 동일 토픽명으로의 양방향 데이터 미러링은 위 그림에서처럼 실제 사용자로는 DC1에는 message1, 2를 DC2에는 message 3을 전송하였지만, 결과적으로는 각 DC에 모두 message 1,2,3이 존재하도록 만들어야 합니다.즉, DC1으로 들어온 메시지는 DC2로, DC2로 들어온 메시지는 DC1으로 전송하면 됩니다. 그러나 이러한 구조만으로는 무한 루프 문제가 발생할 수 있습니다.<ol><li id="17ba360d-33e3-8040-b782-d5f7a866ed99">DC1의 <code>test.topic.1</code> 파티션 0번에 메시지가 기록됩니다.</li><li id="17ba360d-33e3-802f-a3dd-d0db7cced3ad">이 메시지는 양방향 데이터 미러링을 통해 DC2의 동일한 토픽과 파티션으로 복제됩니다.</li><li id="17ba360d-33e3-8013-ade8-dbecceff00cb">DC2에서는 새로운 데이터가 들어왔다고 인식하고, 이를 다시 DC1의 <code>test.topic.1</code> 파티션 0번으로 전송합니다.</li><li id="17ba360d-33e3-805f-988a-c2f2e17717fe">이 과정이 반복되며 동일한 메시지가 두 DC 사이를 계속해서 오가며 끝없이 복제됩니다.</li></ol>이 문제를 해결하기 위해 Kafka 메시지 헤더를 활용했습니다. 메시지를 전송할 때, 메시지의 헤더에 Source DC 정보를 추가하여 메시지가 실제 사용자로부터 생성된 것인지, 아니면 미러링을 통해 전송된 것인지를 구분할 수 있도록 했습니다.<ul><li id="17ba360d-33e3-805f-ac0f-ec3aab95ee19">헤더에 Source DC 정보가 있는 메시지는 미러링을 통해 전송된 데이터로 간주되어 다시 전송되지 않습니다.</li><li id="17ba360d-33e3-808c-bb70-d804416cd5f5">반면, 헤더에 Source DC 정보가 없는 메시지는 실제 사용자로부터 생성된 데이터로 간주되며, 상대 데이터 센터로 전송됩니다.</li></ul>이러한 필터링 로직을 통해 무한 루프 문제를 방지하고, 양쪽 데이터 센터에 동일하게 100%의 데이터만 존재하도록 구성했습니다.또한, 추가적인 기능으로 데이터 미러링 과정에서 헤더에 원천 클러스터에서 해당 메시지의 오프셋 정보를 포함하여 전송합니다. 헤더에 담긴 오프셋 정보를 활용하는 방식에 대해서는 추후 발행될 3편 Offset Sync 글에서 자세히 다루겠습니다.Dead Letter Queue 기능을 활용한 정합성 보장두 번째로, 데이터 정합성 보장을 위해 Dead Letter Queue(DLQ) 기능을 사용했습니다. Kafka Connect는 2.0 버전부터 DLQ 기능을 지원합니다. DLQ는 처리 실패한 메시지를 보관하는 큐로, 에러 발생 시 원천 토픽이 아닌 별도 DLQ용 토픽으로 메시지가 발행됩니다. 원본 메시지와 함께 토픽, 파티션, 오프셋, exception 메시지와 같은 메타정보가 포함되어 별도 DLQ용 토픽에 전송됩니다. DLQ 토픽에 인입된 메시지에 대해서는, 재처리하여 최종 타겟에 전송할 수 있는 시스템을 구축하여 유실 없는 미러링 도구를 완성하였습니다.수 천개의 잡을 모니터링을 위한 메트릭대규모 파이프라인 운영에서는 모든 잡이 정상적으로 작동하고 있는지 실시간으로 모니터링하는 것이 매우 중요합니다. 초기에는 필요한 메트릭을 MBean에 등록하고 JMX를 통해 Prometheus로 수집한 뒤, 모니터링에 활용했습니다. 하지만 Prometheus 기반 모니터링은 몇 가지 한계가 있었습니다.<ol><li id="17ba360d-33e3-8055-98e8-ffe30c6ac6e9">보관 기간의 제약: Prometheus는 기본적으로 데이터 보존 기간이 짧아, 장기간의 데이터를 분석하기 어려웠습니다.</li><li id="17ba360d-33e3-802c-8b65-c386b8159f6b">복잡한 쿼리 조건: PromQL 연산 시, label을 일치시켜야 하는 제약이 있어 유연한 분석이 어려웠습니다.</li></ol>이러한 문제를 해결하기 위해, 기존의 MBean 기반 방식을 벗어나 Kafka가 제공하는 메트릭 포맷을 기반으로 새로운 모니터링 시스템을 설계했고, 커스텀 메트릭 리포터를 개발해 주요 메트릭을 Kafka로 직접 전송하도록 구현했습니다. 메트릭 리포터는 메트릭 데이터를 외부 시스템으로 전송하거나 저장할 수 있도록 설계된 기능입니다. 정의한 메트릭들을 Kafka로 전송하도록 개발하여, 수 천개의 잡에서 발생되는 메트릭들을 안정적으로 통합하여 수집했습니다.가장 주목할 만한 메트릭은 지연 시간 메트릭입니다. 이는 메시지가 원천 Kafka에 들어온 시점부터 대상 Kafka로 전송되는 데 걸리는 시간을 측정하며, ms 단위의 정밀한 지연 시간만 허용해 높은 성능을 보장합니다. 이러한 지표는 성능 진단과 개선 작업에 있어 핵심적인 역할을 합니다.<h3 id="17ba360d-33e3-80a9-96b0-fb6c1d384cbd">대규모 양방향 데이터 미러링 클러스터 운영 노하우</h3>Kafka Connect는 Kafka와 외부 시스템 간의 효율적인 데이터 전송을 위한 클러스터 기반의 프레임워크로, 클러스터는 Connector와 Task를 실행, 관리, 스케줄링하는 역할을 합니다. Connector는 Kafka와 외부 시스템 간 데이터를 이동시키는 작업이며, Task는 Connector의 작업 단위로 병렬 처리를 가능하도록 합니다. Kubernetes(k8s) 위에 하나의 큰 Connect 클러스터를 생성하고, 한 토픽 당 하나의 Connector 작업을 생성하는 방식으로 운영했습니다. 각 Connector 잡이 하나의 토픽만 미러링하도록 구성함으로써, 미러링 성능과 독립성을 보장하며, 토픽-파티션 단위의 세밀한 모니터링이 가능했습니다. 그러나, 시간이 지나면서 토픽 수가 점점 증가하였고, 하나의 클러스터에 몇 백개의 Connector 잡이 추가되면서 운영 부담이 크게 늘어났습니다.이를 해결하기 위해 하나의 대규모 클러스터를 N개의 작은 클러스터로 분리하였습니다. 이러한 분리를 통해 각 Connector 잡의 Task 수를 유연하게 조정할 수 있게 됐고, 적절한 Task 분배를 통해 기존 대비 성능을 향상시켰습니다. 또한, 클러스터가 너무 많은 Connector 잡을 스케줄링 하지 않아도 되어 부담이 줄어들고, N개로 분리된 클러스터를 부분적으로 작업할 수 있어서 운영 안정성 및 편의성이 크게 향상되었습니다.<figure id="17ba360d-33e3-801b-82f2-e7fbf32a6369"><img src="https://static.toss.im/ipd-tcs/toss_core/live/0bd3fef4-dfec-4a54-92e5-7aeeac19cd5d/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-01-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_10.31.41.png" alt=""></figure>또한, 앞서 소개한 커스텀 메트릭 리포터를 통해, Kafka로 수집된 다양한 메트릭들을 실시간 분석 처리에 강점을 가진 OLAP 성격의 데이터베이스 ClickHouse에 저장하였습니다. SQL로 다양한 데이터 소스와의 조인 연산을 손쉽게 수행할 수 있어, 쿼리 기반의 다양한 데이터 분석과 모니터링에 필요한 실시간 대시보드 생성이 가능해졌습니다.<figure id="17ba360d-33e3-8084-8741-f792bf1d303b"><img src="https://static.toss.im/ipd-tcs/toss_core/live/30fce72c-daaa-4d55-a43f-77c931db6a86/tech-0114-3_(1).png" alt=""></figure>Clickhouse에는 장기간 데이터를 저장할 수 있어, 메트릭 데이터를 활용한 추이 분석, 이상치 탐지 등 Prometheus를 통해서는 구현하기 어려웠던 고급 분석도 가능해졌습니다. 시계열 데이터를 기반으로 한 장기적인 트렌드 분석을 바탕으로 운영 문제의 사전 예측 또한 가능해졌습니다. 하나의 예로, 각 토픽에 대하여 메시지 인입 건 수 메트릭의 트렌드 데이터를 바탕으로 현재 데이터 인입량이 과도하게 적은지/많은지를 측정하여, 이상징후를 빠르게 확인할 수 있게 되었습니다.<h3 id="17ba360d-33e3-8094-bfd2-f87c1ddf1e4a">마무리</h3>본 글에서는 토스증권의 환경에 맞는 양방향 데이터 미러링 도구에 대해 소개하였습니다. 현재 1,000개 넘는 토픽에 대하여 미러링 잡들을 안정적으로 운영하는 것은 물론, 앞으로 더 늘어날 토픽들에 대해서도 적은 비용으로 운영할 수 있는 구조를 갖추었습니다. 다음 3부 글에서는 데이터가 이중화된 환경에서 컨슈머 그룹은 어떻게 데이터 센터 간을 넘나들 수 있는지에 대해 소개할 예정입니다. 많은 관심 부탁드립니다. 감사합니다</div></div>

토스테크

안녕하세요. 토스증권 실시간 데이터팀 송지수입니다. 
Kafka 데이터센터 이중화 1편에서 소개된 것처럼, 토스증권은 현재 Active-Active 구성으로 Kafka를 운영하고 있습니다. 오늘은 Active-Active를 유지하기 위해 필요한 양방향 데이터 미러링에 대해 소개하려고 합니다.
양방향 데이터 미러링 오픈소스
Apache Kafka에서 제공하는 MirrorMaker2(MM2) 등 다양한 오픈소스 데이터 미러링 도구가 있습니다. 이러한 도구들은 클러스터 간 데이터 복제를 손쉽게 구현할 수 있도록 설계되었습니다.
MM2는 Kafka Connect 프레임워크 중 Source Connector 기반으로 동작하며, 두 가지 주요 기능을 제공합니다.
데이터 전송: Source Cluster(A)에서 발생한 데이터를 Target Cluster(B)로 복제.
오프셋 관리: A와 B 간 오프셋 차이를 Source Cluster(A)에 MM2용 내부 토픽으로 저장.
MM2를 사용하면, 복제된 토픽 이름에 Source Cluster의 alias(접두사)가 자동으로 추가됩니다. 예를 들어, A 클러스터의 topic.test.1은 B 클러스터에서 A.topic.test.1로 미러링됩니다.
MM2를 이용해서 양방향 미러링 구성이 가능하지만, 토스증권에서는 MM2를 사용하는 데 한계가 있었습니다. 각 Kafka에서 동일한 토픽 이름으로 미러링하여, 서버 개발자 등 Kafka 사용자들이 단일 토픽으로 데이터에 접근할 수 있는 환경을 제공하는 것이 목표였기 때문입니다. 어떤 데이터 센터의 Kafka에 프로듀스/컨슘하더라도 항상 동일한 한 개의 토픽 이름을 사용할 수 있다면, 사용자들이 Kafka 이중화 구성에 대해 인지하거나, 서버가 배포되는 데이터 센터를 신경쓰지 않아도 되기에, 사용자 편의성을 위해 동일한 토픽명으로 이중화 구성으로 하고자 하였습니다.
토스증권에서 개발한 양방향 데이터 미러링 도구
MM2와 같은 오픈소스는 토스증권 상황에 사용하기엔 한계점이 있어서 직접 만들기로 결정했습니다.
토스증권의 환경에 맞춘 데이터 미러링 도구는 Kafka Connect 프레임워크 중 Sink Connector로 구현되었습니다. Sink Connector는 Kafka에서 데이터를 소비한 후, 외부 시스템에 데이터를 저장하는 역할을 수행합니다. 이 외부 시스템을 다른 데이터 센터(DC)의 Kafka로 설정하여, 양방향 데이터 복제를 가능하게 했습니다.
저희 팀에서 개발한 양방향 데이터 미러링 도구는 크게 3가지 기능에 집중하였습니다.
동일한 토픽명으로 양방향 미러링 기능
Dead Letter Queue 기능을 활용한 정합성 보장
수 천개의 잡을 모니터링을 위한 메트릭
동일한 토픽명으로 양방향 미러링 기능
첫 번째 기능인 동일 토픽명으로의 양방향 데이터 미러링은 위 그림에서처럼 실제 사용자로는 DC1에는 message1, 2를 DC2에는 message 3을 전송하였지만, 결과적으로는 각 DC에 모두 message 1,2,3이 존재하도록 만들어야 합니다.
즉, DC1으로 들어온 메시지는 DC2로, DC2로 들어온 메시지는 DC1으로 전송하면 됩니다. 그러나 이러한 구조만으로는 무한 루프 문제가 발생할 수 있습니다.
DC1의 test.topic.1 파티션 0번에 메시지가 기록됩니다.
이 메시지는 양방향 데이터 미러링을 통해 DC2의 동일한 토픽과 파티션으로 복제됩니다.
DC2에서는 새로운 데이터가 들어왔다고 인식하고, 이를 다시 DC1의 test.topic.1 파티션 0번으로 전송합니다.
이 과정이 반복되며 동일한 메시지가 두 DC 사이를 계속해서 오가며 끝없이 복제됩니다.
이 문제를 해결하기 위해 Kafka 메시지 헤더를 활용했습니다. 메시지를 전송할 때, 메시지의 헤더에 Source DC 정보를 추가하여 메시지가 실제 사용자로부터 생성된 것인지, 아니면 미러링을 통해 전송된 것인지를 구분할 수 있도록 했습니다.
헤더에 Source DC 정보가 있는 메시지는 미러링을 통해 전송된 데이터로 간주되어 다시 전송되지 않습니다.
반면, 헤더에 Source DC 정보가 없는 메시지는 실제 사용자로부터 생성된 데이터로 간주되며, 상대 데이터 센터로 전송됩니다.
이러한 필터링 로직을 통해 무한 루프 문제를 방지하고, 양쪽 데이터 센터에 동일하게 100%의 데이터만 존재하도록 구성했습니다.
또한, 추가적인 기능으로 데이터 미러링 과정에서 헤더에 원천 클러스터에서 해당 메시지의 오프셋 정보를 포함하여 전송합니다. 헤더에 담긴 오프셋 정보를 활용하는 방식에 대해서는 추후 발행될 3편 Offset Sync 글에서 자세히 다루겠습니다.
Dead Letter Queue 기능을 활용한 정합성 보장
두 번째로, 데이터 정합성 보장을 위해 Dead Letter Queue(DLQ) 기능을 사용했습니다. Kafka Connect는 2.0 버전부터 DLQ 기능을 지원합니다. DLQ는 처리 실패한 메시지를 보관하는 큐로, 에러 발생 시 원천 토픽이 아닌 별도 DLQ용 토픽으로 메시지가 발행됩니다. 
원본 메시지와 함께 토픽, 파티션, 오프셋, exception 메시지와 같은 메타정보가 포함되어 별도 DLQ용 토픽에 전송됩니다. DLQ 토픽에 인입된 메시지에 대해서는, 재처리하여 최종 타겟에 전송할 수 있는 시스템을 구축하여 유실 없는 미러링 도구를 완성하였습니다.
수 천개의 잡을 모니터링을 위한 메트릭
대규모 파이프라인 운영에서는 모든 잡이 정상적으로 작동하고 있는지 실시간으로 모니터링하는 것이 매우 중요합니다. 초기에는 필요한 메트릭을 MBean에 등록하고 JMX를 통해 Prometheus로 수집한 뒤, 모니터링에 활용했습니다. 하지만 Prometheus 기반 모니터링은 몇 가지 한계가 있었습니다.
보관 기간의 제약: Prometheus는 기본적으로 데이터 보존 기간이 짧아, 장기간의 데이터를 분석하기 어려웠습니다.
복잡한 쿼리 조건: PromQL 연산 시, label을 일치시켜야 하는 제약이 있어 유연한 분석이 어려웠습니다.
이러한 문제를 해결하기 위해, 기존의 MBean 기반 방식을 벗어나 Kafka가 제공하는 메트릭 포맷을 기반으로 새로운 모니터링 시스템을 설계했고, 커스텀 메트릭 리포터를 개발해 주요 메트릭을 Kafka로 직접 전송하도록 구현했습니다. 메트릭 리포터는 메트릭 데이터를 외부 시스템으로 전송하거나 저장할 수 있도록 설계된 기능입니다. 정의한 메트릭들을 Kafka로 전송하도록 개발하여, 수 천개의 잡에서 발생되는 메트릭들을 안정적으로 통합하여 수집했습니다.
가장 주목할 만한 메트릭은 지연 시간 메트릭입니다. 이는 메시지가 원천 Kafka에 들어온 시점부터 대상 Kafka로 전송되는 데 걸리는 시간을 측정하며, ms 단위의 정밀한 지연 시간만 허용해 높은 성능을 보장합니다. 이러한 지표는 성능 진단과 개선 작업에 있어 핵심적인 역할을 합니다.
대규모 양방향 데이터 미러링 클러스터 운영 노하우
Kafka Connect는 Kafka와 외부 시스템 간의 효율적인 데이터 전송을 위한 클러스터 기반의 프레임워크로, 클러스터는 Connector와 Task를 실행, 관리, 스케줄링하는 역할을 합니다. Connector는 Kafka와 외부 시스템 간 데이터를 이동시키는 작업이며, Task는 Connector의 작업 단위로 병렬 처리를 가능하도록 합니다. 
Kubernetes(k8s) 위에 하나의 큰 Connect 클러스터를 생성하고, 한 토픽 당 하나의 Connector 작업을 생성하는 방식으로 운영했습니다. 각 Connector 잡이 하나의 토픽만 미러링하도록 구성함으로써, 미러링 성능과 독립성을 보장하며, 토픽-파티션 단위의 세밀한 모니터링이 가능했습니다. 그러나, 시간이 지나면서 토픽 수가 점점 증가하였고, 하나의 클러스터에 몇 백개의 Connector 잡이 추가되면서 운영 부담이 크게 늘어났습니다.
이를 해결하기 위해 하나의 대규모 클러스터를 N개의 작은 클러스터로 분리하였습니다. 이러한 분리를 통해 각 Connector 잡의 Task 수를 유연하게 조정할 수 있게 됐고, 적절한 Task 분배를 통해 기존 대비 성능을 향상시켰습니다. 또한, 클러스터가 너무 많은 Connector 잡을 스케줄링 하지 않아도 되어 부담이 줄어들고, N개로 분리된 클러스터를 부분적으로 작업할 수 있어서 운영 안정성 및 편의성이 크게 향상되었습니다.
또한, 앞서 소개한 커스텀 메트릭 리포터를 통해, Kafka로 수집된 다양한 메트릭들을 실시간 분석 처리에 강점을 가진 OLAP 성격의 데이터베이스 ClickHouse에 저장하였습니다. SQL로 다양한 데이터 소스와의 조인 연산을 손쉽게 수행할 수 있어, 쿼리 기반의 다양한 데이터 분석과 모니터링에 필요한 실시간 대시보드 생성이 가능해졌습니다.
Clickhouse에는 장기간 데이터를 저장할 수 있어, 메트릭 데이터를 활용한 추이 분석, 이상치 탐지 등 Prometheus를 통해서는 구현하기 어려웠던 고급 분석도 가능해졌습니다. 시계열 데이터를 기반으로 한 장기적인 트렌드 분석을 바탕으로 운영 문제의 사전 예측 또한 가능해졌습니다. 하나의 예로, 각 토픽에 대하여 메시지 인입 건 수 메트릭의 트렌드 데이터를 바탕으로 현재 데이터 인입량이 과도하게 적은지/많은지를 측정하여, 이상징후를 빠르게 확인할 수 있게 되었습니다.
마무리
본 글에서는 토스증권의 환경에 맞는 양방향 데이터 미러링 도구에 대해 소개하였습니다. 현재 1,000개 넘는 토픽에 대하여 미러링 잡들을 안정적으로 운영하는 것은 물론, 앞으로 더 늘어날 토픽들에 대해서도 적은 비용으로 운영할 수 있는 구조를 갖추었습니다. 다음 3부 글에서는 데이터가 이중화된 환경에서 컨슈머 그룹은 어떻게 데이터 센터 간을 넘나들 수 있는지에 대해 소개할 예정입니다. 많은 관심 부탁드립니다. 감사합니다

토스증권 Apache Kafka 데이터센터 이중화 구성 #2: 데이터 미러링

댓글