분산디비지만 노출은 하고싶어 - mongo로 노출 전용 DB 만들기 - 이태원_NEDAY 23.07
엔지니어링데이 2025 네이버 · YouTube
AI 핵심 요약
상품과 카탈로그 데이터가 늘면서 정규화된 테이블을 여러 번 조인하는 방식은 지연과 장애를 일으켰고, 분산 PostgreSQL에서도 조인 비용이 부담이 됐다. 이를 해결하기 위해 PostgreSQL CDC를 Kafka로 전달하고, 컨버터·프로세서·라이터를 거쳐 노출에 맞게 가공한 데이터를 MongoDB에 적재하는 전용 DB를 만들었다. 변경량을 줄이는 필터링과 중복 제거, 원본 DB 재조회, 줄기 테이블을 이용한 노출 제어를 적용했으며, 전체 데이터는 Spark로 새 컬렉션에 재생성해 API를 전환하도록 구성했다. 발표에서 공유한 운영 결과로는 API 응답 목표를 유지했고 전체 데이터 생성에는 시간대에 따라 약 2시간 반에서 4시간이 걸렸으며, 데이터 순서와 CDC·복제 지연을 고려한 설계가 중요하다는 점을 강조했다.
- CDC 메시지는 행 단위 변경을 전달하므로, 순서나 연관 데이터가 중요한 경우 원본 DB를 다시 조회해 전체 상태를 구성할 수 있다.
- 변경량이 많을 때는 노출에 쓰이지 않는 필드를 제외하고, 배치 안에서 같은 상품의 중복 변경을 합쳐 처리량을 줄인다.
- MongoDB 문서에 자주 바뀌는 공통 이름을 중복 저장하는 대신 ID만 두고 CDC 기반 캐시에서 값을 조회하면 대량 갱신을 피할 수 있다.
- 상품 테이블을 기준이 되는 줄기 데이터로 삼아, 줄기가 없는 하위 데이터는 노출하지 않도록 하면 테이블별 처리 속도 차이로 인한 불완전 노출을 막을 수 있다.
- 전체 데이터 재생성은 새 컬렉션에 진행하고 API를 전환해, 운영 중인 데이터와 복구 작업을 분리한다.
소개
네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY(7월)에서 발표되었던 세션을 공개합니다. ----- 쇼핑검색서비스개발BE 팀의 이태원입니다. 네이쇼핑의 카탈로그, 상품 API 개발을 담당하고 있습니다. 이번 발표를 통해서 노출을 위해 고군분투했던 제 경험을 공유하고, 관련 기술에 관심 있는 분들과 함께 이야기 나누어보고 싶습니다! 이번 프로젝트에 사용한 kafka, mongoDb, postgreSql, redis 등 다양한 프레임워크에 관심을 갖게 되었습니다. [노출DB란?] - 쇼핑의 메인DB는 citus를 활용한 postgreSql로 분산DB입니다. - 이를 노출에 알맞은 형태로 가공해 새로운 DB를 만든 것이 노출DB입니다. - postgreSql의 CDC 데이터를 받아서, kafka를 통해 데이터를 재가공, mongo에 적재하는 프로젝트입니다 [목차] 노출DB란? - 탄생 배경 - 전체 구조 난관 - 변경량 - 정규화 - 새 상...
비슷한 학습 자료
컨퍼런스 NDC
NDC 2018 [Spark, Flintrock, Airflow 로 구현하는 탄력적이고 유연한 데이터 분산 처리 자동화 인프라 구축] 세션 공유드립니다. 상세 내용은 NDC Replay 홈페이지를 참고 부탁드려요. 😊 1. 발표자 성함 : 박주홍 2. 발표자 소개 : 데브시스터즈에서 데이터 분석 및 인프라 팀장을 맡고 있습니다. 쿠키런 For Kakao 서버를 개발하고 라인 쿠키런의 글로벌 서버 구현을 총괄하였으며, 데이터 분석을 위한 Hadoop 기반의 인프라 구축을 진행했습니다. 카이스트와 서울대에서 데이터 분석 연구를 진행했고 Line Developer Day 에서 글로벌 게임 서버 구축, CHI Conference 에서 게임 데이터 분석 발표를 하였습니다. 이번에는 게임 데이터 분석을 위한 데이터 분산 처리 자동화 인프라 구축에 대해 발표하고자 합니다. 게임을 사랑하고 좋아하며, 데이터를 통해 게임을 보다 더 잘 이해하고 재미있게 만들고 싶습니다. 데이터 분석과 인프라...
데이터베이스 데브옵스 · 인프라
컨퍼런스 당근 밋업
MongoDB On Kubernetes | 2024 당근 테크 밋업
컨퍼런스 if kakao
StateDB pruning & Migration / if(kakao)2022
컨퍼런스 if kakao
블록체인의 스토리지는 모든 데이터의 정합성 체크를 위해 모든 데이터를 누적해 저장합니다. 지속해서 증가하는 데이터로 인해 로컬 스토리지 데이터는 계속 증가하고, 이에 따라 데이터 액세스 속도는 지속적으로 느려지게 됩니다. 블록체인에서 과거 데이터가 중요하긴 하지만 노드별 역할에 따라 현재 데이터만 필요한 경우도 있고, 과거 데이터가 필요하더라도 최근 데이터만큼 빠른 속도로 액세스 되지 않아도 괜찮은 노드도 존재합니다. 이러한 특성을 이용해서 클레이튼은 과거 데이터를 지우거나 분산 스토리지로 마이그레이션 하는 로직을 만들어 스토리지 활용을 최적화하는 블록체인 스토리지 관리 모듈을 개발 중입니다. 본 세션에서는 이에 대한 이야기를 하고자 합니다. #BlockchainStorage 크러스트유니버스에서 블록체인의 스토리지를 개발하고 있는 이든입니다. 카카오톡의 분산스토리지를 개발했고, 최근에 클레이튼에서 사용하는 블록체인용 스토리지의 최적화와 분산시스템으로의 확장을 고민하고 있습...
데이터베이스 블록체인
컨퍼런스 DAN 2025
[팀네이버 컨퍼런스 DAN25] 실시간 vs 배치, 함께 굴리는 데이터 파이프라인 - 확장성과 정합성을 잡은 대규모 데이터 플랫폼 운영기 본 발표는 AdVoost Shopping 광고 상품에서 쇼핑 상품을 연동하는 데이터 파이프라인을 구축한 경험을 다룹니다. 다양한 플랫폼 제약과 서비스 요구사항 속에서 실시간 처리와 배치 처리의 균형, 상품 메타데이터와 광고 메타데이터의 동시 연동이라는 과제를 해결한 과정을 공유합니다. MongoDB CDC, Kafka Streams, Iceberg, 자체 영속성 레이어 등을 활용하여 구현한 방법을 소개하고, 선형성·확장성·성능 관점에서의 트레이드오프, 그리고 실시간·배치 처리 방식을 선택한 기준에 대해 공유합니다. 목차 1. AdVoost Shopping 에서의 도전과제 - AdVoost Shopping 에서의 저희의 역할, 주어진 요구 사항, 그리고 도출한 도전과제를 설명합니다. 2. 아키텍처 - 도전과제를 통...
데이터베이스 데브옵스 · 인프라
컨퍼런스 엔지니어링데이 2025
Iceberg Low-Latency Queries with Materialized Views (feat. 실시간 거래 리포트)
컨퍼런스 엔지니어링데이 2025
네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2025 에서 발표되었던 세션을 공개합니다. [발표 내용] - 본 영상에서는 “실시간 거래 리포트를 어떻게 하면 사용자가 원하는 다양한 조건으로 빠르게 조회할 수 있을까?” 라는 질문에서 출발한 기술적 여정을 다룹니다. - 단순히 데이터를 쌓고 조회하는 단계를 넘어, 거래 데이터의 최신성과 응답 속도, 그리고 확장성을 동시에 확보하기 위한 여러 시도를 공유합니다. [발표 대상] - 데이터 플랫폼 엔지니어 / 데이터 아키텍트 – 대용량 실시간 데이터 처리 및 저지연 설계에 관심 있는 분 - 분석 플랫폼 운영자 / BI 개발자 – 다차원 필터 조회 속도 및 Freshness 향상 전략을 찾고 있는 분 - Spark, Iceberg, StarRocks 활용자 – 실제 조합 운영 사례를 통해 운영 팁을 얻고자 하는 분 [목차] 0. 소개 (Introduction) 1. 문제 정의 (Problem Definition)...
데이터베이스 데브옵스 · 인프라
컨퍼런스 엔지니어링데이 2025
늘어가는 조회트래픽 Elasticsearch로 분산시키기
컨퍼런스 엔지니어링데이 2025
네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2025(5월)에서 발표되었던 세션을 공개합니다. [발표 내용] 점점 늘어가던 플레이스 조회트래픽을 메인DB로부터 Elasticsearch(Opensearch)로 분산한 경험을 공유합니다. (#Elasticsearch #Opensearch #트래픽 분산 #CQRS #slow query #feature toggle #feature flag #자동 fallback) [강의 대상] * 트래픽 분산 및 Elasticsearch(Opensearch)에 관심이 있으신 분들 * 난이도 : 하~중하 (트래픽 분산경험 / ES 운용경험이 없으신 주니어 개발자분들도 이해하시기 좋은 정도) [목차] * 조회 DB 도입 배경 - 기존 리뷰조회 flow - 호출량이 점점 늘어가던 플랫폼, 증가하는 조회필터 / 정렬조건 - DB 인덱스 추가의 한계 - 조회용 DB를 도입한다면? * Elasticsearch를 조회DB로...
백엔드 데이터베이스