네이버/Apache Kafka

3 개의 포스트

naver원문

비용, 성능, 안정성을 목표로 한 지능형 로그 파이프라인 도입 (새 탭에서 열림)

네이버의 통합 데이터 플랫폼 AIDA 내 로그 수집 시스템인 'Logiss'는 대규모 로그 파이프라인을 운영하며 겪었던 무중단 배포의 한계, 리소스 낭비, 로그 중요도 미분류 문제를 해결하기 위해 지능형 파이프라인을 도입했습니다. 핵심은 Storm의 멀티 토폴로지 구성을 통한 블루-그린 배포 구현과 실시간 트래픽 상태에 따라 처리 속도를 동적으로 조절하는 지능형 제어 알고리즘의 적용입니다. 이를 통해 서비스 중단 없는 배포는 물론, 인프라 비용을 약 40% 절감하고 장애 시 핵심 로그를 우선 처리하는 안정성까지 확보하며 성능과 비용의 최적점을 찾아냈습니다. **멀티 토폴로지와 블루-그린 배포를 통한 무중단 운영** * 기존 Traffic-Controller는 단일 토폴로지 구조로 인해 배포 시마다 데이터 처리가 3~8분간 중단되는 문제가 있었으나, 이를 해결하기 위해 멀티 토폴로지 기반의 블루-그린 배포 방식을 도입했습니다. * Storm 2.x의 `assign` 방식 대신 Kafka의 컨슈머 그룹 관리 기능을 활용하는 `subscribe` 방식으로 내부 로직을 커스텀 변경하여, 여러 토폴로지가 동일 파티션을 중복 소비하지 않도록 개선했습니다. * 이를 통해 트래픽이 몰리는 낮 시간대에도 중단 없이 안전하게 신규 기능을 배포하고 점진적인 트래픽 전환이 가능해졌습니다. **지능형 트래픽 제어를 통한 리소스 최적화** * 낮과 밤의 트래픽 차이가 5배 이상 발생하는 환경에서 피크 타임 기준으로 장비를 고정 할당하던 비효율을 제거하기 위해 '지능형 속도 제어' 알고리즘을 도입했습니다. * Kafka의 랙(lag) 발생량과 백엔드 시스템(OpenSearch 등)의 CPU 부하 상태를 실시간으로 감시하여, 시스템이 여유로울 때는 로그 처리 속도를 자동으로 높여 적체를 빠르게 해소합니다. * 유동적인 속도 조절 덕분에 기존 대비 투입 장비 리소스를 약 40% 절감하는 성과를 거두었으며, 갑작스러운 트래픽 유입에도 유연하게 대응할 수 있게 되었습니다. **로그 중요도 기반의 우선순위 처리** * 모든 로그를 동일한 속도로 처리하던 방식에서 벗어나, 비상 상황 발생 시 서비스 핵심 로그가 먼저 처리될 수 있도록 우선순위(High, Medium, Low) 개념을 도입했습니다. * 트래픽 지연이 발생하면 중요도가 낮은 로그의 처리 속도는 제한하고, 사업 및 서비스 운영에 필수적인 핵심 로그는 지연 없이 전송되도록 파이프라인 가용성을 확보했습니다. **저장소별 차등 샘플링을 통한 비용 절감** * 실시간 검색을 위한 OpenSearch와 장기 보관을 위한 랜딩 존(Landing Zone)에 데이터를 전송할 때, 각 저장소의 목적에 맞게 샘플링 비율을 다르게 설정할 수 있는 기능을 구현했습니다. * 모든 데이터를 무조건 100% 저장하는 대신, 분석 목적에 따라 일부 샘플링만으로 충분한 로그는 저장량을 줄여 인덱싱 부하를 낮추고 스토리지 비용을 효율적으로 관리할 수 있게 되었습니다. 대규모 로그 파이프라인 운영에서 비용 효율과 안정성은 상충하기 쉬운 가치이지만, 시스템의 상태를 실시간으로 파악하고 제어하는 '지능형' 로직을 통해 두 마리 토끼를 모두 잡을 수 있습니다. 특히 스트리밍 처리 프레임워크의 제약 사항을 직접 커스텀하여 비즈니스 요구사항에 맞춘 최적화 사례는 유사한 데이터 플랫폼을 운영하는 기술진에게 실무적인 통찰을 제공합니다.

naver원문

네이버 TV (새 탭에서 열림)

Apache Kafka의 차세대 소비자 그룹 프로토콜(Consumer Group Protocol v2)은 기존 v1 프로토콜이 가진 리밸런싱 성능의 한계와 복잡성을 근본적으로 해결하기 위해 도입되었습니다. 새로운 프로토콜은 리밸런싱 로직의 주체를 클라이언트에서 서버(Broker)로 옮겨 전체적인 시스템 안정성을 높였으며, 대규모 클러스터 운영 시 발생하던 중단 시간을 획기적으로 단축했습니다. 이 글은 네이버의 실무 경험을 바탕으로 v2의 주요 특징과 성능 개선 사항, 그리고 안정적인 마이그레이션 전략을 제시합니다. **기존 Consumer Group Protocol v1의 문제점** * **Stop-the-world 리밸런싱:** 리밸런싱이 발생하면 모든 컨슈머가 데이터 처리를 멈추고 파티션을 재할당받아야 하므로 일시적인 처리 지연이 불가피했습니다. * **클라이언트 측의 과도한 부담:** 리밸런싱 로직이 컨슈머 클라이언트에 포함되어 있어, 클라이언트 수가 늘어날수록 통신량과 계산 복잡도가 급증하는 구조적 한계가 있었습니다. * **디버깅의 어려움:** 리밸런싱 과정이 복잡하고 클라이언트별로 상태가 달라 문제 발생 시 원인 파악과 모니터링이 까다로웠습니다. **Consumer Group Protocol v2의 핵심 특징과 장점** * **서버 중심 리밸런싱:** 그룹 코디네이터(Broker)가 파티션 할당 로직을 직접 수행하여 클라이언트의 계산 부하를 줄이고 전체 프로세스를 단순화했습니다. * **점진적 협력 리밸런싱:** 모든 컨슈머를 멈추지 않고, 변경이 필요한 파티션만 점진적으로 재할당하여 서비스 가용성을 극대화했습니다. * **하트비트 메커니즘 개선:** 하트비트 응답 내에 리밸런싱 명령을 포함시켜 별도의 JoinGroup/SyncGroup 절차 없이도 빠른 상태 동기화가 가능해졌습니다. **성능 향상 및 운영 효율화** * **확장성 강화:** 수천 개의 파티션과 수백 명의 컨슈머가 참여하는 대규모 그룹에서도 리밸런싱 시간을 일관되게 유지합니다. * **불필요한 리밸런싱 감소:** 컨슈머의 일시적인 네트워크 순단이나 짧은 지연에 대해 보다 유연하게 대응하여 불필요한 그룹 재편성을 방지합니다. * **전용 툴 지원:** 새로운 프로토콜에 최적화된 모니터링 툴과 API를 통해 소비자 그룹의 상태를 더 정밀하게 확인하고 관리할 수 있습니다. **성공적인 마이그레이션 및 설정 가이드** * **호환성 확인:** Kafka 브로커와 클라이언트 버전을 확인하여 v2 프로토콜(KIP-848) 지원 여부를 먼저 점검해야 합니다. * **단계적 도입:** `group.protocol` 설정을 통해 기존 v1과 새로운 v2를 선택적으로 적용할 수 있으며, 개발 환경에서 충분한 검증 후 운영 환경에 반영하는 것이 권장됩니다. * **클라이언트 업데이트:** v2의 이점을 온전히 누리기 위해서는 브로커뿐만 아니라 컨슈머 클라이언트 라이브러리 역시 최신 버전으로 업그레이드해야 합니다. 대규모 트래픽을 처리하며 리밸런싱으로 인한 지연 시간에 민감한 서비스라면 Kafka 3.x 후반대 버전부터 도입된 Consumer Group Protocol v2로의 전환을 적극적으로 검토해야 합니다. 특히 컨슈머 그룹의 규모가 크거나 빈번한 배포가 일어나는 환경일수록 v2 도입을 통한 운영 안정성 향상 효과가 더욱 뚜렷하게 나타날 것입니다.

naver원문

6개월 만에 연간 수십조를 처리하는 DB CDC 복제 도구 무중단/무장애 교체하기 (새 탭에서 열림)

네이버페이는 차세대 아키텍처 개편 프로젝트인 'Plasma'의 최종 단계로, 연간 수십조 원의 거래 데이터를 처리하는 DB CDC 복제 도구인 'ergate'를 성공적으로 개발하여 무중단 교체했습니다. 기존의 복제 도구(mig-data)가 가진 유지보수의 어려움과 스키마 변경 시의 제약 사항을 해결하기 위해 Apache Flink와 Spring Framework를 조합한 새로운 구조를 도입했으며, 이를 통해 확장성과 성능을 동시에 확보했습니다. 결과적으로 백엔드 개발자가 직접 운영 가능한 내재화된 시스템을 구축하고, 대규모 트래픽 환경에서도 1초 이내의 복제 지연 시간과 강력한 데이터 정합성을 보장하게 되었습니다. ### 레거시 복제 도구의 한계와 교체 배경 * **유지보수 및 내재화 필요성:** 기존 도구인 `mig-data`는 DB 코어 개발 경험이 있는 인원이 순수 Java로 작성하여 일반 백엔드 개발자가 유지보수하거나 기능을 확장하기에 진입 장벽이 높았습니다. * **엄격한 복제 제약:** 양방향 복제를 지원하기 위해 설계된 로직 탓에 단일 레코드의 복제 실패가 전체 복제 지연으로 이어졌으며, 데이터 무결성 확인을 위한 복잡한 제약이 존재했습니다. * **스키마 변경의 경직성:** 반드시 Target DB에 칼럼을 먼저 추가해야 하는 순서 의존성이 있어, 작업 순서가 어긋날 경우 복제가 중단되는 장애가 빈번했습니다. * **복구 프로세스의 부재:** 장애 발생 시 복구를 수행할 수 있는 인원과 방법이 제한적이어서 운영 효율성이 낮았습니다. ### Apache Flink와 Spring을 결합한 기술 아키텍처 * **프레임워크 선정:** 저지연·대용량 처리에 최적화된 **Apache Flink(Java 17)**를 복제 및 검증 엔진으로 채택하고, 복잡한 비즈니스 로직과 복구 프로세스는 익숙한 **Spring Framework(Kotlin)**로 이원화하여 구현했습니다. * **Kubernetes 세션 모드 활용:** 12개에 달하는 복제 및 검증 Job을 효율적으로 관리하기 위해 세션 모드를 선택했습니다. 이를 통해 하나의 Job Manager UI에서 모든 상태를 모니터링하고 배포 시간을 단축했습니다. * **Kafka 기반 비동기 처리:** nBase-T의 binlog를 읽어 Kafka로 발행하는 `nbase-cdc`를 소스로 활용하여 데이터 유실 없는 파이프라인을 구축했습니다. ### 데이터 정합성을 위한 검증 및 복구 시스템 * **지연 컨슈밍 검증(Verifier):** 복제 토픽을 2분 정도 지연하여 읽어 들이는 방식으로 Target DB에 데이터가 반영될 시간을 확보한 뒤 정합성을 체크합니다. * **2단계 검증 로직:** 1차 검증 실패 시, 실시간 변경으로 인한 오탐인지 확인하기 위해 Source DB를 직접 재조회하여 Target과 비교하는 보완 로직을 수행합니다. * **자동화된 복구 흐름:** 일시적인 오류는 5분 후 자동으로 복구하는 '순단 자동 복구'와 배치 기반의 '장애 자동 복구', 그리고 관리자 UI를 통한 '수동 복구' 체계를 갖추어 데이터 불일치 제로를 지향합니다. ### DDL 독립성 및 성능 개선 결과 * **스키마 캐싱 전략:** `SqlParameterSource`와 캐싱된 쿼리를 이용해 Source와 Target의 칼럼 추가 순서에 상관없이 복제가 가능하도록 개선했습니다. Target에 없는 칼럼은 무시하고, 있는 칼럼만 선별적으로 반영하여 운영 편의성을 극대화했습니다. * **성능 최적화:** 기존 대비 10배 이상의 QPS를 처리할 수 있는 구조를 설계했으며, CDC 이벤트 발행 후 최종 복제 완료까지 1초 이내의 지연 시간을 달성했습니다. * **모니터링 강화:** 복제 주체(ergate_yn)와 Source 커밋 시간(rpc_time)을 전용 칼럼으로 추가하여 데이터의 이력을 추적할 수 있는 가시성을 확보했습니다. 성공적인 DB 복제 도구 전환을 위해서는 단순히 성능이 좋은 엔진을 선택하는 것을 넘어, **운영 주체인 개발자가 익숙한 기술 스택을 적재적소에 배치**하는 것이 중요합니다. 스트림 처리는 Flink에 맡기고 복잡한 복구 로직은 Spring으로 분리한 ergate의 사례처럼, 도구의 장점을 극대화하면서도 유지보수성을 놓치지 않는 아키텍처 설계가 대규모 금융 플랫폼의 안정성을 뒷받침합니다.