grep

Backend

공통 Kafka 전환기 [Part 2. 공통 Kafka 전환 여정]

Sofie여기어때

2025년 12월 22일

원문에서 보기 ↗

안녕하세요 여기어때컴퍼니 공통플랫폼개발팀 소피입니다.

2024년 11월에 공통 Kafka 전환기 Part 1포스팅에서 공통 Kafka 전환 배경 및 전략에 대한 내용을 공유드렸었는데요.

1년여간 긴 여정을 통해 최종적으로 도메인 팀에서 운영되던 8개의 Kafka 클러스터 대상으로 전사 공통 Kafka로 전환이 완료되었습니다. 🎉

이번 글에서는 공통 Kafka 전환을 진행하며 고민했던 부분들과 전환 과정 및 결과에 대한 내용을 공유하고자 합니다.

1. 전환 시 고려사항

각 도메인 Kafka는 운영 방식, 클러스터 규모, 트래픽 수준, 인증 방식 등이 모두 달라 하나의 접근 방식으로 모든 클러스터를 전환하기에는 현실적으로 어려운 구조입니다.

이에 따라 전환을 시작하기 전 도메인별 기존 구조와 운영 특성을 파악하고 각 클러스터에 가장 적합한 전환 전략을 선택하는 것이 필요했습니다.

아래는 실제 전환 과정에서 고려한 주요 항목들입니다.

1️⃣ 도메인 Kafka 클러스터별 상이한 운영 특성에 따른 전환 방식 구분

도메인별로 운영하던 Kafka 클러스터는 규모, 사용 팀 수, 트래픽 수준 등 모두 제각각이었습니다.

일부 클러스터는 단일팀 혹은 최대 2~3개 팀만 사용하는 소규모 환경이었던 반면, 다른 일부 클러스터는 10개 이상의 팀과 애플리케이션이 연결된 대규모 공유 환경이었습니다.

이처럼 도메인별 운영 특성이 달랐기 때문에 전환 방식 또한 구분하여 단계적으로 전환하는 방식이 필요했습니다.

2️⃣ 전환 시 서비스 영향 최소화

전환 과정에서 가장 최우선적으로 고려한 부분은 서비스 영향 최소화입니다.

소규모 도메인 클러스터처럼 비교적 트래픽이 적고 사용팀이 적은 환경에서는 공통 Kafka에 신규 Topic을 생성한 뒤 Producer/Consumer의 엔드포인트만 변경하는 방식으로도 충분히 전환이 가능하지만

다수의 팀이 공유하고 서비스 영향도가 큰 Topic이 많은 대규모 환경에서는 단순 엔드포인트 변경 방식으로는 중복 소비, 누락, 메시지 순서 변경 등과 같은 위험 가능성이 있습니다.

따라서 대규모 환경에서는 메시지 데이터와 Consumer Offset을 유지한 채 점진적으로 전환할 수 있는 구조가 필요했습니다.

3️⃣ 전사 운영 표준 정책 적용

도메인 Kafka 클러스터에는 운영 방식과 계정/인증 정책이 통일되어 있지 않아 전환 과정에서 다음과 같은 공통 Kafka 운영 표준에 맞춘 재구성 작업이 필요했습니다.

이처럼 도메인별 운영 특성, 서비스 영향도, 전사 운영 표준 등 고려사항을 충족하기 위해 전환 대상의 규모에 따라 전환 방식을 구분하여 아래와 같은 전략으로 전환 방안을 세우게 되었습니다.

➤ 소규모 단일팀 사용 도메인 클러스터 → 신규 Topic 생성 + 엔드포인트 일괄 전환 방식

➤ 대규모 다중팀 사용 도메인 클러스터 → MirrorMaker2 기반 점진 전환 방식

2. 전환 방안 : Kafka MirrorMaker2

기존 도메인별로 분산 운영되던 Kafka 클러스터들을 전사 공통 Kafka로 전환하는 과정에서 저희는 서비스 영향 최소화를 최우선 목표로 삼았고, 이 요구사항을 충족시키고 데이터 일관성과 Offset 유지를 보장하며 전환하기 위한 도구로 Kafka MirrorMaker2를 채택하게 되었습니다.

그럼 MirrorMaker2가 무엇이며, 어떻게 도메인 Kafka에서 공통 Kafka로 전환을 가능하게 했는지 자세히 살펴보겠습니다.

MirrorMaker2 란?

Kafka MirrorMaker2(MM2)는 Kafka 클러스터 간 데이터를 실시간으로 복제(Mirroring)하기 위해 Apache Kafka에서 공식적으로 제공하는 도구입니다.

MM2의 가장 큰 특징은 단순한 메시지 복제를 넘어 Kafka Connect 프레임워크 기반으로 동작하여 강력하고 안정적인 복제 기능을 제공한다는 점입니다. MM2는 다음과 같은 핵심 기능을 지원합니다.

➤ 실시간 Topic 데이터 복제 : Source 클러스터의 Topic 데이터를 Target 클러스터로 스트리밍 복제합니다.

➤ Topic 메타데이터 복제 : Topic 설정, 파티션 수 등의 메타데이터를 함께 복제하여 환경 일관성을 유지합니다.

➤ Consumer Group Offset 동기화 : Consumer를 Target Kafka로 전환 시 Source Kafka에서 소비하던 위치를 Target Kafka에서 그대로 이어받아 소비할 수 있도록 Offset 정보를 동기화합니다.

➤ 클러스터 상태(Heartbeat) 모니터링 : Source와 Target 클러스터 간의 연결 상태 및 동기화 상태를 지속적으로 모니터링합니다.

이처럼 MirrorMaker2는 단순한 데이터 복제를 넘어 Consumer 소비 위치 동기화 및 클러스터 상태 모니터링까지 지원하여 복제 및 마이그레이션 시 데이터 무결성과 서비스 연속성을 보장합니다.

MirrorMaker2 동작 방식

그러면 MirrorMaker2가 실제로 어떻게 클러스터 간의 복제와 Offset 동기화를 수행하는지 Kafka Connect 기반 위에서 동작하는 세 가지 핵심 Connector의 동작 방식에 대해 살펴보겠습니다.

📥 MirrorSourceConnector : 실시간 데이터 복제

MirrorSourceConnnector는 MM2의 핵심으로 Source Kafka 클러스터의 Topic 데이터를 Target Kafka 클러스터로 실시간 스트리밍 복제하는 역할을 담당합니다.

단순히 메시지를 복제하는 것뿐만 아니라 복제 과정에서 Source Kafka 클러스터의 오프셋과 Target 클러스터의 오프셋 간의 매핑 정보를 생성하여 Source Kafka의 offset-syncs Topic에 기록합니다.

이 오프셋 매핑 정보는 Consumer가 클러스터를 전환할 때 정확한 소비 위치를 보장하기 위한 기반이 됩니다.

🔗 MirrorCheckpointConnector : Consumer Offset 동기화

MirrorCheckpointConnector는 Consumer Group의 Offset 동기화를 담당합니다.

이 Connector는 Source Kafka에 연결된 Consumer Group이 어디까지 메시지를 소비했는지를 주기적으로 확인합니다. 그리고 앞서 MirrorSourceConnector가 기록한 오프셋 매핑 정보를 활용하여 이 Source Offset 위치를 Target Kafka 기준으로 계산합니다.

이렇게 계산된 Offset은 Target Kafka의 checkpoints Topic에 기록됩니다.

따라서 애플리케이션의 Consumer가 Source Kafka에서 Target Kafka로 엔드포인트를 전환할 때, 이 checkpoints Topic의 정보를 기반으로 동일한 위치에서 소비를 중단없이 재개할 수 있도록 보장하게 됩니다.

📈 MirrorHeartbeatConnector : 클러스터 상태 모니터링

MirrorHeartbeatConnector는 두 클러스터 환경의 운영 안정성을 높이는 역할을 합니다.

이 Connector는 주기적으로 heartbeat Topic에 메시지를 기록함으로써 Source-Target 클러스터 간의 연결 상태와 동기화 상태를 지속적으로 모니터링합니다.

이러한 세 개의 Connector 동작 기반으로 도메인 Kafka에서 공통 Kafka로의 전환 과정에서 데이터 일관성과 Consumer Offset 유지라는 핵심 요구사항을 충족시키며 서비스 영향 최소화 요구사항을 만족할 수 있었습니다.

이제 이 MirrorMaker2를 활용한 구체적인 전환 과정을 단계별로 살펴보겠습니다.

3. MirrorMaker2 기반 전환 과정

공통 Kafka 전환은 Source → Target 단방향 복제 구조(One-way Mirroring)기반으로 두 클러스터를 실시간으로 동기화해두고 그 위에서 Producer-Consumer 연결 전환 절차를 점진적으로 전환하는 방식으로 진행했습니다.

단방향 복제 구조에서의 주의 사항으로는 Producer, Consumer 전환 순서인데요.

만약 Producer가 Consumer보다 먼저 Target으로 전환되면 Source Kafka에는 이후 신규 메시지가 들어오지 않기 때문에 여전히 Source Kafka에 연결된 Consumer는 데이터를 처리하지 못해 메시지 불일치, 지연, 누락이 발생할 수 있습니다.

따라서 전환 시 소비 흐름을 기준으로 전환 순서를 설계하여 전환 과정은 다음과 같은 5단계로 진행했습니다.

⓵ Source → Target 단방향 실시간 동기화 구성

⓶ Consumer 우선 전환

⓷ Consumer 안정화 후 Producer 전환

⓸ Source Kafka 트래픽 확인후 Mirroring 중지

⓹ Source Kafka 종료 후 자원 회수

이와 같은 MirrorMaker2 기반의 점진적 전환 방식으로 도메인 Kafka의 데이터 일관성을 유지하면서 Consumer와 Producer를 안전하게 전환할 수 있었습니다.

4. 전환 결과

이러한 공통 Kafka 전환의 결과로 기존 도메인별로 분리 운영되던 총 8개의 Kafka 클러스터를 공통 Kafka 클러스터에 집중화할 수 있었습니다.

이 통합을 통해 아키텍처, 비용, 운영 효율성 측면에서 다음과 같은 효과를 얻게 되었습니다.

🏗️ 아키텍처 및 개발 측면

분산 환경을 통합하고 표준화하여 개발의 생산성과 시스템의 안정성을 확보했습니다.

💰 비용 및 운영 표준 측면

클러스터 분산 운영으로 인한 중복 자원 및 관리 포인트를 단일화하여 비용 절감 및 운영 표준이 적용되었습니다.

이러한 전환 결과를 통해 기존 8개 도메인 클러스터를 하나의 중앙 공통 플랫폼으로 성공적으로 통합하였으며, 전환 이후에도 공통 Kafka에는 수백 개의 신규 토픽 증가와 트래픽 급증, 특히 트래픽 성수기 시즌에도 성능 저하나 장애 없이 안정적으로 데이터를 처리하며 중앙 데이터 운영 플랫폼으로 역할을 공고히 하고 있습니다.

5. 마무리

이번 공통 Kafka 전환 프로젝트는 단순한 인프라 통합이 아닌, 도메인별로 분리된 8개의 운영 환경을 단일화하는 과정으로 긴 시간 동안 여러 고민과 기술적 시행착오가 있었지만 MirrorMaker2 기반의 점진적 무중단 전환 전략을 적용하여 서비스 영향 없이 안정적으로 공통 Kafka 통합을 달성했습니다.

특히 다양한 팀이 사용하던 플랫폼인 만큼 부담도 있었지만 여러 팀의 적극적인 협조 덕분에 큰 이슈없이 마무리할 수 있었습니다. 전환 과정에서 일정 조율 및 테스트와 전환 작업에 적극적으로 참여해 주신 모든 개발팀 리더분들과 개발자분들께 이 글을 빌려 감사의 말씀을 전합니다.

전환 이후에는 모든 도메인 서비스가 공통 Kafka 기반으로 운영되는 만큼 단순한 안정화 수준을 넘어 운영 효율성과 확장성까지 고려한 고도화가 필요합니다.

이에 따라 현재 클러스터 확장, 리밸런싱 자동화, 모니터링 체계 개선 작업 등이 예정되어 있으며 이를 통해 장기적인 운영 안정성과 서비스 품질을 지속적으로 강화해나갈 계획입니다.

긴 글 읽어주셔서 감사합니다.