apache-kafka

5 개의 포스트

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

네이버의 통합 데이터 플랫폼 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% 저장하는 대신, 분석 목적에 따라 일부 샘플링만으로 충분한 로그는 저장량을 줄여 인덱싱 부하를 낮추고 스토리지 비용을 효율적으로 관리할 수 있게 되었습니다. 대규모 로그 파이프라인 운영에서 비용 효율과 안정성은 상충하기 쉬운 가치이지만, 시스템의 상태를 실시간으로 파악하고 제어하는 '지능형' 로직을 통해 두 마리 토끼를 모두 잡을 수 있습니다. 특히 스트리밍 처리 프레임워크의 제약 사항을 직접 커스텀하여 비즈니스 요구사항에 맞춘 최적화 사례는 유사한 데이터 플랫폼을 운영하는 기술진에게 실무적인 통찰을 제공합니다.

고객은 절대 기다려주지 않는다: 빠른 데이터 서빙으로 고객 만족도를 수직 상승 시키는 법 (새 탭에서 열림)

토스페이먼츠는 가파른 성장세에 따른 데이터 조회 부하를 해결하기 위해 CQRS 아키텍처를 도입하고 Apache Druid를 중심으로 한 데이터 서빙 환경을 구축했습니다. 초기에는 Elasticsearch와 Druid를 결합하여 대규모 시계열 데이터의 실시간 집계와 검색 성능을 확보했으며, 이를 통해 비용 효율성과 시스템 안정성을 동시에 달성했습니다. 현재는 Druid의 조인 제약과 멱등성 문제를 해결하기 위해 StarRocks를 도입하며, 도메인 간 결합이 자유로운 통합 원장 시스템으로 진화하고 있습니다. ### CQRS와 Apache Druid 도입 배경 * **MSA 전환과 DB 분리:** 서비스 규모가 커지며 모놀리식에서 MSA로 전환했으나, DB가 분산되면서 도메인 간 조인이나 통합 조회가 어려워지는 문제가 발생했습니다. * **명령과 조회의 분리:** 읽기 전용 저장소로 Apache Druid를 선택하여 원장 DB(MySQL)의 부하를 줄이고, 수십억 건의 데이터를 저지연으로 조회하는 CQRS 구조를 설계했습니다. * **Druid의 기술적 이점:** 시계열 데이터 최적화, SQL 지원을 통한 낮은 러닝 커브, 모든 컬럼의 비트맵 인덱스(Bitmap Index)화, 그리고 클라우드 네이티브 구조를 통한 비용 효율성을 고려했습니다. ### 데이터 가공 및 메시지 발행 방식 * **CDC 대신 메시지 발행 선택:** 데이터팀이 도메인 로직을 직접 소유해야 하는 CDC 방식 대신, 각 도메인 팀에서 완성된 데이터를 발행하는 방식을 채택하여 시스템 의존성을 Kafka로 단순화했습니다. * **역정규화 테이블 구성:** 복잡한 수단별 원장 데이터를 조회 친화적인 역정규화 테이블로 변환하여 적재했으며, JSON 필드 단위까지 비트맵 인덱스가 생성되어 효율적인 질의가 가능해졌습니다. ### AWS 환경에서의 비용 및 성능 최적화 * **컴퓨팅과 스토리지 분리:** 고가의 네트워크 스토리지(EBS) 대신 S3를 영구 저장소로 활용하고, 쿼리 수행 시에는 로컬 SSD를 사용하여 성능을 9배 이상 향상했습니다. * **스팟 인스턴스 활용:** 데이터가 S3에 안전하게 보관되는 특성을 이용해 개발/테스트 환경에서 스팟 인스턴스를 적극적으로 사용하여 월 5,000만 원 이상의 클라우드 비용을 절감했습니다. * **고가용성 확보:** 네트워크 스토리지 의존성을 제거함으로써 가용 영역(AZ) 간 분산 배치가 유연해져 시스템의 안정성을 높였습니다. ### Druid 운영의 기술적 도전과 극복 * **파편화 및 멱등성 문제:** 데이터가 시점별로 분산되는 파편화 현상을 해결하기 위해 60초 주기 탐지 프로세스와 자동 컴팩션(Compaction)을 도입했습니다. * **Rollup을 통한 성능 극대화:** 동일 차원의 데이터를 자동 집계하여 저장하는 Rollup 기능을 적용해, 수십 초 걸리던 집계 쿼리 응답 속도를 0.5~1초 내외로 99% 이상 개선했습니다. * **ES 하이브리드 아키텍처:** 단일 ID 기반의 고속 검색은 Elasticsearch가 담당하고, 필터링된 결과의 대규모 집계는 Druid가 처리하도록 역할을 분담해 검색 성능을 안정화했습니다. ### StarRocks 도입을 통한 통합 원장 구축 * **조인 및 멱등성 한계 극복:** Druid의 제한적인 조인 기능과 멱등성 처리의 어려움을 해결하기 위해 StarRocks를 새롭게 도입했습니다. * **도메인 간 데이터 결합:** 결제부터 매입, 정산까지 이르는 전체 라이프사이클을 한눈에 볼 수 있는 통합 원장을 구현하여 비즈니스 요구사항에 유연하게 대응하고 있습니다. **결론적으로** 대규모 트래픽 환경에서는 단순한 DB 분리를 넘어 검색(ES), 시계열 집계(Druid), 그리고 복잡한 조인과 멱등성 보장(StarRocks)이라는 각 도구의 장점을 살린 하이브리드 아키텍처 설계가 필수적입니다. 특히 스토리지와 컴퓨팅을 분리한 구조는 비용 절감뿐만 아니라 운영의 유연성을 확보하는 핵심 전략이 됩니다.

[DAN25] 기술세션 영상이 모두 공개되었습니다. (새 탭에서 열림)

팀네이버의 컨퍼런스 DAN25에서 발표된 35개의 기술 세션 영상이 모두 공개되었으며, 그중 오프라인 현장에서 가장 큰 호응을 얻었던 5가지 핵심 세션의 상세 내용이 공유되었습니다. 이번 컨퍼런스는 AI 에이전트, 소버린 AI, AX 전략 등 네이버의 미래 비전과 실제 서비스 적용 사례를 중심으로 사용자 경험의 혁신 과정을 다루고 있습니다. 대규모 트래픽 처리부터 LLM의 서비스 최적화까지, 네이버의 기술적 고민과 해결책을 담은 실전 노하우를 온라인을 통해 확인할 수 있습니다. **LLM 기반 사용자 메모리 구축 및 실시간 반영** * 사용자의 파편화된 서비스 이용 기록을 '간접적인 대화'로 간주하여 개인화된 메모리를 구축하는 '네이버 PersonA' 프로젝트를 소개합니다. * 대규모 언어모델(LLM)의 추론 능력을 활용해 사용자에게 적절한 시점에 의미 있는 제안을 전달하는 시스템을 구현했습니다. * 실시간 로그를 대규모 사용자 환경에 안정적으로 반영하기 위한 기술적 대안과 AI 에이전트로 진화하기 위한 단계별 로드맵을 다룹니다. **랭킹 기반 플레이스 트렌드 분석 시스템** * 실시간 사용자 데이터를 분석하여 '지금 뜨는 장소'를 포착하기 위해 '급등'과 '지속'의 균형을 맞춘 랭킹 알고리즘을 적용했습니다. * 단순한 인기 순위를 넘어 텍스트 마이닝과 LLM을 결합하여 특정 장소가 주목받는 구체적인 이유를 키워드로 추출하는 과정을 공유합니다. **검색 서비스 특화 LLM 및 AI 브리핑** * 수십억 건의 질문과 답을 처리하는 검색 환경에 최적화하기 위해 범용 LLM 대신 검색 로그 기반의 특화 모델을 개발한 사례입니다. * 다양한 데이터 조합 실험과 최적화 레시피를 통해 범용 성능을 유지하면서도 검색 맞춤 기능을 강화한 기술적 노하우를 설명합니다. * 신뢰성을 높이는 'AuthGR' 기술과 전통적 검색 과정을 통합해 제시하는 'AI briefing'을 통해 검색 품질 개선 방향을 제시합니다. **추천-CRM 통합 모델과 실시간 개인화 UX** * 네이버 웹툰/시리즈 환경에서 관리 복잡성을 줄이기 위해 개별적으로 운영되던 추천 모델과 CRM 모델을 하나의 통합 프레임워크로 설계했습니다. * 배치(Batch) 기반 시스템에서 API 기반 실시간 추론 아키텍처로 전환하여 모델 간 일관성을 확보하고 사용자 경험을 고도화했습니다. **초대규모 로그 파이프라인 'Logiss' 운영 전략** * 초당 수백만 건, 하루 수백억 건에 달하는 전사 로그를 처리하기 위해 Storm과 Kafka 기반의 멀티 토폴로지를 적용하여 무중단 배포 환경을 구축했습니다. * 지능형 파이프라인을 도입해 피크 시간대의 트래픽을 분산시키고, 장애 발생 시 로그 우선순위에 따른 차등 처리로 시스템 안정성을 확보했습니다. * 샘플링 기능을 활용한 저장소 효율화 등 비용과 성능, 안정성을 동시에 잡은 대규모 데이터 인프라 관리 기법을 공유합니다. 네이버의 최신 기술 트렌드와 대규모 시스템 운영 노하우를 깊이 있게 이해하고 싶다면, DAN25 홈페이지나 네이버 TV 채널에 공개된 세션 풀 영상을 참고하시길 권장합니다. 특히 LLM을 실제 서비스 아키텍처에 어떻게 녹여낼지 고민하는 개발자나 데이터 엔지니어에게 실질적인 기술적 영감을 제공할 것입니다.

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의 사례처럼, 도구의 장점을 극대화하면서도 유지보수성을 놓치지 않는 아키텍처 설계가 대규모 금융 플랫폼의 안정성을 뒷받침합니다.

DDD를 Merchant 시스템 구축에 활용한 사례를 소개합니다 (새 탭에서 열림)

기존의 음식 배달 중심 시스템에서 벗어나 소매 상품 판매에 최적화된 새로운 Merchant 시스템을 구축하기 위해 도메인 주도 설계(DDD)를 도입했습니다. 이번 프로젝트는 DDD가 단순히 코드 구현 기술이 아니라, 도메인의 역할과 책임을 명확히 정의하고 이를 바탕으로 조직 구조와 협업 방식을 설계하는 방법론임을 보여줍니다. 클린 아키텍처와 비동기 이벤트 기반의 모듈 구성을 통해 시스템의 확장성을 확보하고, 글로벌 팀 간의 원활한 협업 체계를 마련하며 성공적으로 시스템을 론칭했습니다. **소매 플랫폼으로의 전환과 도메인 정의** * 기존 시스템의 '음식점 기반 소매 판매' 한계를 극복하기 위해 독립적인 Merchant 시스템을 설계했습니다. * Merchant 시스템은 점포, 상품, 재고 등의 정보를 제공하고, 실제 판매는 '소비자 플랫폼'에서 담당하는 구조로 역할을 분리했습니다. * 핵심 도메인을 점포(shop), 상품(item), 카테고리(category), 재고(inventory), 주문(order)의 다섯 가지로 정의하여 복잡도를 낮추었습니다. **클린 아키텍처를 활용한 시스템 설계** * 도메인 엔티티가 외부 환경의 변화에 영향을 받지 않도록 클린 아키텍처를 채택했습니다. * 모든 팀원이 쉽게 이해하고 따를 수 있는 명확한 계층 구조를 통해 유지보수 편의성을 높였습니다. * 의존성 방향을 내부(도메인)로만 허용하여 비즈니스 로직의 순수성을 유지했습니다. **비동기 기반의 모듈 및 통신 구조** * 시스템을 외부 요청을 받는 'API' 모듈과 비즈니스 로직을 처리하는 '엔진' 모듈로 분리하여 가용성을 높였습니다. * gRPC를 통한 API 제공과 Apache Kafka 기반의 내부 통신을 결합했으며, Decaton 라이브러리를 사용해 파티션 대비 높은 처리량을 확보했습니다. * 플랫폼 특성을 고려하여 즉각적인 응답보다는 최종 일관성(Eventual Consistency)과 빠른 API 응답 능력에 초점을 맞춘 비동기 구조를 설계했습니다. **글로벌 협업과 조직의 일치(Conway's Law)** * 한국 팀은 핵심 도메인(Core)을, 일본 팀은 현지 시스템 연계(Link, BFF)를 담당하도록 조직을 구성해 콘웨이의 법칙을 실천했습니다. * 의사결정 과정과 논의 배경을 기록하는 ADR(Architectural Decision Record)을 활용해 조직 간의 공감대를 형성하고 불필요한 재논의를 방지했습니다. * 추상화된 연계 계층을 통해 새로운 소비자 플랫폼이 추가되더라도 핵심 도메인의 변화는 최소화되는 유연한 구조를 만들었습니다. 성공적인 DDD 적용을 위해서는 헥사고날 아키텍처와 같은 기술적인 구현에만 매몰되지 않는 것이 중요합니다. 도메인의 역할과 책임을 먼저 명확히 정의하고, 그 경계에 맞춰 팀 조직과 소통 구조를 설계할 때 진정한 설계의 이점을 얻을 수 있습니다. 시스템의 아키텍처가 조직의 소통 구조를 반영한다는 점을 인지하고, 기술과 조직 관리의 균형을 맞추는 접근이 권장됩니다.