elasticsearch

비디오 검색을 위한 멀티모달 인텔리전스 구현 (새 탭에서 열림)

넷플릭스는 방대한 분량의 원본 영상 데이터에서 창작자가 원하는 특정 순간을 신속하게 찾아낼 수 있도록 여러 전문 AI 모델을 결합한 멀티모달(Multimodal) 검색 시스템을 구축했습니다. 이 시스템은 캐릭터, 환경, 대화 등 서로 다른 모델이 생성한 파편화된 신호들을 하나의 통합된 시간축으로 동기화하여 고차원의 문맥 이해와 실시간 검색을 동시에 실현합니다. 결과적으로 수십억 개의 데이터 포인트 속에서도 창작자의 의도에 부합하는 장면을 지연 시간 없이 정확하게 찾아내는 기술적 해결책을 제시합니다. **비디오 검색의 기술적 복잡성과 한계** * **타임라인 통합의 어려움:** 각 모델은 비디오를 서로 다른 간격으로 분석하여 텍스트 레이블이나 벡터 임베딩 등 상이한 형태의 메타데이터를 생성하므로, 이를 하나의 연대기적 지도로 정렬하는 데 막대한 계산 비용이 발생합니다. * **데이터 규모의 폭발:** 2,000시간 분량의 아카이브는 약 2억 1,600만 프레임에 달하며, 이를 여러 모델로 처리할 경우 수십억 개의 레이블과 벡터 데이터가 생성되어 전통적인 데이터베이스로는 처리가 불가능합니다. * **중복 제거와 하이브리드 스코어링:** 시각적으로 유사한 수천 개의 후보 중 최적의 클립을 제안하기 위해, 단순한 수학적 유사도를 넘어 상징적 텍스트 매칭과 의미론적 벡터 검색을 결합한 정교한 랭킹 엔진이 필요합니다. * **제로 프릭션(Zero-Friction) 검색:** 창작 흐름을 방해하지 않기 위해 수십억 개의 레코드를 탐색하면서도 초 단위 미만의 응답 속도를 유지해야 하는 물리적 제약이 존재합니다. **데이터 수집 및 융합 파이프라인 (Ingestion & Fusion)** * **트랜잭션 영속화 (Transactional Persistence):** 고가용성 파이프라인을 통해 수집된 모델의 원본 주석(Annotation)을 Apache Cassandra에 저장합니다. 이 단계에서는 데이터 무결성과 빠른 쓰기 처리량을 최우선으로 하여 모든 모델 출력을 안전하게 확보합니다. * **오프라인 데이터 융합 (Offline Data Fusion):** Apache Kafka를 통해 비동기적으로 실행되며, 파편화된 모델 데이터를 1초 단위의 '시간 버킷(Temporal Buckets)'으로 정규화합니다. 예를 들어 '조이'라는 캐릭터와 '주방'이라는 배경이 겹치는 구간을 하나의 통합 레코드로 병합하여 복합적인 쿼리가 가능하도록 만듭니다. * **실시간 검색 인덱싱:** 융합된 데이터를 Elasticsearch에 인덱싱합니다. 이때 자산 ID와 시간 버킷을 조합한 복합 키(Composite Key)를 사용하여 업서트(Upsert) 방식으로 데이터를 갱신함으로써 데이터 중복을 방지하고 단일 진실 공급원(Single Source of Truth)을 유지합니다. **효율적인 멀티모달 시스템을 위한 제언** 대규모 영상 자산을 관리하는 시스템에서는 원본 데이터를 실시간으로 검색하는 대신, 데이터를 수집-융합-인덱싱 단계로 분리(Decoupling)하여 처리하는 구조가 필수적입니다. 특히 서로 다른 AI 모델의 출력을 공통된 시간 단위(Time Bucketing)로 정규화하여 저장함으로써, 복잡한 다차원 검색 시 발생하는 계산 부하를 오프라인에서 미리 해결하고 사용자에게는 즉각적인 검색 경험을 제공할 수 있습니다.

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

토스페이먼츠는 가파른 성장세에 따른 데이터 조회 부하를 해결하기 위해 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)이라는 각 도구의 장점을 살린 하이브리드 아키텍처 설계가 필수적입니다. 특히 스토리지와 컴퓨팅을 분리한 구조는 비용 절감뿐만 아니라 운영의 유연성을 확보하는 핵심 전략이 됩니다.

당근 검색 엔진, 쿠버네티스로 쉽게 운영하기 2편 — 데이터 노드 웜업 적용 (새 탭에서 열림)

당근 검색 플랫폼팀은 쿠버네티스(ECK) 환경에서 Elasticsearch 클러스터를 운영하며, 롤링 리스타트 시 발생하는 레이턴시 급증 문제를 해결하기 위해 '데이터 노드 웜업(Warmup)' 시스템을 구축했습니다. 단순히 Pod가 실행되는 것을 넘어 샤드 복구와 캐시 예열이 완료된 후에만 다음 노드를 재시작하도록 제어함으로써, 피크 타임에도 서비스 영향 없이 안정적인 배포가 가능해졌습니다. 이를 통해 운영자의 모니터링 부담을 제거하고 언제든 안심하고 배포할 수 있는 환경을 마련했습니다. **롤링 리스타트와 콜드 캐시의 위험성** * Elasticsearch는 페이지 캐시, 쿼리 캐시 등 다양한 메모리 캐시에 크게 의존하므로, 재시작 직후 캐시가 비어 있는 '콜드 캐시' 상태에서는 성능이 급격히 저하됩니다. * 쿠버네티스의 기본 롤링 업데이트는 Pod의 준비 상태(Ready)만 확인하고 다음 노드를 재시작하기 때문에, 준비되지 않은 노드에 트래픽이 몰리며 전체 검색 레이턴시가 수 초까지 치솟는 장애가 발생할 수 있습니다. * 노드 한 대가 내려간 동안 남은 노드들이 모든 부하를 감당해야 하며, 복제본(Replica) 샤드가 없는 상태에서 다른 노드에 문제가 생기면 클러스터가 'Red' 상태로 변해 가용성이 무너질 위험이 큽니다. **안전한 배포를 위한 단계별 웜업 전략** * 목표는 배포 중에도 P99 레이턴시를 평소 수준으로 유지하고, 클러스터 상태가 'Yellow'에서 다시 'Green'이 된 것을 확인한 후 다음 단계로 넘어가는 것입니다. * 이를 위해 노드 재시작 후 세 가지 단계를 거칩니다: 1) 데이터 노드가 클러스터에 정상 합류할 때까지 대기, 2) 할당된 샤드들의 데이터 복구(Recovery) 완료 확인, 3) 실제 검색 쿼리를 미리 실행하여 캐시를 채우는 과정입니다. * 특히 샤드 복구가 완료되지 않은 상태에서 웜업을 시작하면 데이터가 없는 상태에서 쿼리를 날리는 꼴이 되므로, 반드시 인덱싱 상태를 모니터링하는 로직이 포함되어야 합니다. **사이드카 패턴 기반의 웜업 시스템 구현** * Elasticsearch 컨테이너와 함께 실행되는 별도의 `warmup-sidecar`를 도입하여 노드의 상태를 정밀하게 추적합니다. * 사이드카는 API를 통해 해당 노드의 샤드들이 모두 'Started' 상태인지 확인하고, 실제 운영 환경에서 발생하는 검색 트래픽(Traffic Replay)을 신규 노드에 미리 쏘아주어 메모리에 데이터를 올립니다. * 이 모든 과정이 완료되어야만 쿠버네티스의 Readiness Probe를 통과하게 설계하여, ECK 오퍼레이터가 노드 웜업이 끝날 때까지 다음 Pod의 재시작을 자동으로 대기하도록 제어했습니다. 대규모 트래픽을 처리하는 상태 기반(Stateful) 시스템에서는 인프라 수준의 단순한 헬스체크만으로는 부족하며, 애플리케이션 내부의 데이터 준비 상태를 고려한 정교한 배포 전략이 필수적입니다. 데이터 노드 웜업 도입으로 배포 시간은 기존보다 길어졌지만, 시간에 구애받지 않고 24시간 언제든 안전하게 시스템을 업데이트할 수 있는 운영 안정성을 확보하게 되었습니다.

100년 가는 프론트엔드 코드, SDK (새 탭에서 열림)

토스페이먼츠는 결제 연동의 복잡성을 해결하기 위해 SDK를 제공하고 있으며, 최근 V1의 한계를 극복하고 안정성과 확장성을 극대화한 V2 SDK를 구축했습니다. 가맹점의 다양한 런타임 환경과 예측 불가능한 요구사항에 대응하기 위해 단순한 기능 구현을 넘어 체계적인 아키텍처와 모니터링 시스템을 도입했습니다. 결과적으로 개발자에게는 쉬운 연동 경험을, 비즈니스에는 견고한 신뢰성을 제공하는 결제 생태계를 완성했습니다. **SDK 개발의 특수성과 V1의 한계** * **환경의 의존성:** SDK는 가맹점의 코드 내에서 실행되므로, 가맹점의 호출 빈도나 네트워크 상태에 직접적인 영향을 받습니다. 일례로 사용량 분석을 위해 추가한 로그 코드가 특정 가맹점의 잦은 호출과 맞물려 네트워크 병목 현상을 일으키고 서비스 전체를 다운시키는 사례가 발생했습니다. * **런타임 예측 불가능성:** 가맹점에서 잘못된 데이터 타입(예: String 대신 Number)을 전달할 경우 `startsWith` 같은 표준 메서드에서 에러가 발생하는 등, 일반적인 프론트엔드 개발보다 훨씬 방어적인 코딩이 요구됩니다. * **커뮤니케이션의 접점:** SDK는 단순히 API를 호출하는 도구가 아니라 가맹점 개발자와 만나는 기술적 창구이며, 가맹점의 수많은 커스텀 요구사항을 수용해야 하는 복잡성을 안고 있습니다. **안정성 확보를 위한 테스트와 모니터링** * **촘촘한 테스트 체계:** 로직 검증을 위한 300개 이상의 단위 테스트와 다양한 유즈케이스를 반영한 500개 이상의 E2E 통합 테스트를 통해 코드 수준의 안정성을 확보했습니다. * **Global Trace ID:** 프론트엔드부터 백엔드까지 결제 전 과정을 하나의 식별자로 추적하는 체계를 도입하여, 장애 발생 시 시스템 레이어 전체를 쉽게 파악할 수 있도록 했습니다. * **모니터링 CLI:** 배포 전후의 결제 성공률을 가맹점 및 런타임 환경(OS, 브라우저, 웹뷰 등)별로 비교 분석하는 자체 도구를 개발했습니다. 이를 통해 특정 환경에서 발생하는 결제 중단 현상을 실시간으로 탐지하고 즉각 대응합니다. **확장성을 위한 레이어드 아키텍처** * **조립 가능한 구조:** 특정 가맹점만을 위한 예외 처리가 `if`문으로 산재되어 코드 복잡도가 올라가는 문제를 해결하기 위해, 기능을 레고 블록처럼 독립적으로 구성했습니다. * **3계층 분리:** "변경의 원인"을 기준으로 코드의 경계를 명확히 나누어 관리합니다. * **Public Interface Layer:** 가맹점과 약속한 인터페이스를 검증하고 도메인 언어로 번역하는 역할 * **Domain Layer:** 핵심 비즈니스 로직과 결제 정책을 담당하는 중심부 * **External Service Layer:** 서버 API나 Web API 등 외부 의존성과의 통신을 담당하는 계층 * **관심사 격리:** 이러한 계층화를 통해 가맹점별 커스텀 요구사항이 추가되더라도 기존의 핵심 로직에 영향을 주지 않고 특정 블록만 교체하거나 확장할 수 있는 유연성을 확보했습니다. 성공적인 SDK 개발을 위해서는 단순히 편리한 기능을 제공하는 것을 넘어, 타사의 코드 환경에서도 견고하게 동작할 수 있는 방어적인 설계와 문제 발생 시 즉시 원인을 파악할 수 있는 관측성(Observability) 확보가 필수적입니다. 가맹점별 특이 케이스를 코드 전반에 흩뿌리기보다는, 명확한 레이어 구분을 통해 비즈니스 로직과 커스텀 로직을 분리하는 설계 원칙을 권장합니다.

복제의 재정의: 저지연 멀티테넌트 데이터 복제 플랫폼 구축기 (새 탭에서 열림)

데이터독(Datadog)은 모놀리식 포스트그레스(Postgres) 데이터베이스의 확장성 한계와 수동 데이터 파이프라인의 복잡성을 해결하기 위해 자동화된 관리형 데이터 복제 플랫폼을 구축했습니다. 이 플랫폼은 체계적인 변경 데이터 캡처(CDC)와 비동기 복제 방식을 통해 데이터 일관성을 유지하면서도 시스템 성능을 비약적으로 향상시켰습니다. 결과적으로 엔지니어링 팀은 인프라 관리의 부담에서 벗어나 안정적이고 낮은 지연 시간으로 대규모 데이터를 다양한 서비스 간에 자유롭게 이동시킬 수 있게 되었습니다. **포스트그레스의 확장성 한계와 데이터 재건축** * 서비스 초기에는 포스트그레스의 ACID 보장과 편의성이 유용했으나, 데이터량이 증가하면서 복잡한 조인 및 집계 쿼리의 응답 시간이 수 밀리초에서 수 초 단위로 급격히 악화되었습니다. * 특정 조직의 메트릭 요약 페이지에서 수십만 개의 행을 조인할 때 P90 지연 시간이 7초에 달했으며, 인덱스 팽창(Bloat)과 VACUUM 작업 부하로 인한 I/O 병목 현상이 발생했습니다. * OLTP 부하와 검색/필터링 부하를 분리하기 위해, 복제 과정에서 데이터를 비정규화(Denormalization)하여 전용 검색 플랫폼으로 전송하는 아키텍처로 전환했습니다. * 이러한 최적화를 통해 페이지 로드 시간을 최대 97% 단축(30초 → 1초)하고, 복제 지연 시간을 500ms 수준으로 유지하는 성과를 거두었습니다. **Temporal을 활용한 복제 파이프라인 프로비저닝 자동화** * Debezium, Kafka, Elasticsearch 등 다양한 기술 스택이 결합된 복제 파이프라인을 수동으로 구축하는 과정은 운영상 큰 부담이 되었습니다. * 포스트그레스의 `wal_level` 설정, 논리적 복제 슬롯 생성, 사용자 권한 관리, Kafka 토픽 매핑 등 반복적이고 오류가 잦은 단계를 Temporal 워크플로우를 통해 모듈화했습니다. * WAL(Write-Ahead Log) 보존 문제를 해결하기 위한 하트비트 테이블 설정부터 싱크 커넥터 배포까지의 모든 과정을 오케스트레이션하여 운영 탄력성을 높였습니다. * 자동화된 플랫폼 덕분에 개발자들은 인프라 설정 대신 혁신에 집중할 수 있게 되었으며, 멀티 테넌트 환경에서도 일관된 파이프라인 관리가 가능해졌습니다. **성능과 확장성을 위한 비동기 복제 전략** * 강한 일관성을 보장하는 동기 복제 대신, 대규모 고처리량 환경에 적합한 비동기 복제 방식을 채택했습니다. * 동기 복제는 네트워크 지연이나 복제본의 응답 상태가 기본 시스템의 성능에 직접적인 영향을 주지만, 비동기 방식은 애플리케이션의 쓰기 성능을 네트워크 지연으로부터 격리합니다. * 장애 발생 시 미세한 데이터 지연이 발생할 수 있는 트레이드오프가 있으나, 이는 확장성과 가용성을 우선시하는 데이터독의 분산 환경에 더 적합한 선택이었습니다. **결론 및 권장사항** 대규모 시스템에서 데이터베이스의 성능 저하를 방지하려면 OLTP와 읽기 전용 검색 워크로드를 분리하는 것이 필수적입니다. 이때 발생하는 복잡한 데이터 이동 문제는 Temporal과 같은 워크플로우 엔진으로 자동화하여 운영 비용을 낮추고, 비동기 복제 모델을 통해 시스템의 전체적인 처리량과 가용성을 확보하는 전략이 권장됩니다.

디스코드가 수조 개의 (새 탭에서 열림)

디스코드(Discord)는 수십억 개의 메시지를 효율적으로 검색하기 위해 엘라스틱서치(Elasticsearch)를 기반으로 한 고성능 검색 인프라를 구축했습니다. 초기 설계는 길드(서버)나 DM 단위로 데이터를 샤딩하여 쿼리 속도를 높이고 운영 관리를 용이하게 하는 데 집중했으며, 리소스를 절약하기 위해 지연 인덱싱(Lazy Indexing) 방식을 채택했습니다. 하지만 서비스가 급격히 성장함에 따라 초기 설계의 효율성보다는 대규모 확장성 측면에서 구조적인 한계가 나타나기 시작했습니다. **엘라스틱서치 기반의 샤딩 및 저장 구조** - 데이터의 논리적 네임스페이스인 인덱스를 두 개의 엘라스틱서치 클러스터에 분산 배치하여 관리했습니다. - 모든 메시지는 길드(Guild) 또는 DM ID를 기준으로 샤딩되어, 특정 그룹의 메시지가 동일한 인덱스에 저장되도록 설계했습니다. - 이러한 샤딩 전략은 관련 데이터를 한데 모아 쿼리 실행 속도를 최적화하고, 클러스터 규모를 제어 가능한 수준으로 유지하는 데 기여했습니다. **메시지 큐와 대량 인덱싱 처리** - 모든 사용자가 검색 기능을 사용하는 것이 아니라는 점에 착안하여, 메시지를 즉시 처리하지 않고 필요할 때 인덱싱하는 '지연 인덱싱' 방식을 도입했습니다. - 메시지 큐를 구축하여 워커(Worker)들이 메시지 덩어리(Chunks)를 가져와 처리할 수 있도록 시스템을 구성했습니다. - 엘라스틱서치의 벌크 인덱싱(Bulk-indexing) 기능을 활용하여 대량의 메시지를 한 번에 처리함으로써 인덱싱 효율을 극대화했습니다. 초기 설계 단계에서 데이터 응집도와 리소스 효율성을 고려한 샤딩 및 인덱싱 전략은 시스템의 성능과 비용 효율성을 잡는 데 효과적입니다. 그러나 서비스의 성장에 따라 기존 아키텍처에서 발생하는 병목 현상을 미리 예측하고, 성능 저하가 시작되는 시점에 맞추어 인프라 고도화를 준비하는 과정이 필수적입니다.