latency-optimization

데이터 사이언티스트로서 영향력을 (새 탭에서 열림)

피그마(Figma)는 데이터 규모가 급격히 팽창함에 따라 기존 배치 기반 파이프라인의 한계를 극복하기 위해 CDC(Change Data Capture) 및 스트리밍 아키텍처로의 대대적인 전환을 단행했습니다. Apache Iceberg와 Kafka, Debezium을 결합한 새로운 파이프라인을 통해 데이터 지연 시간을 수일에서 수분 단위로 단축했으며, 수백 개의 데이터베이스 샤드로부터 발생하는 대규모 데이터를 안정적으로 처리할 수 있는 기반을 마련했습니다. 이 글은 급성장하는 서비스에서 데이터 일관성과 실시간성을 동시에 확보하기 위한 피그마 엔지니어링 팀의 여정과 기술적 결정을 다룹니다. ### 기존 배치 파이프라인의 한계와 병목 현상 * 초기 피그마는 Embulk를 이용해 수백 개의 RDS 샤드에서 데이터를 추출하여 S3에 저장하고 이를 Snowflake로 로드하는 배치 방식을 사용했으나, 데이터 양이 늘어남에 따라 지연 시간이 며칠씩 발생했습니다. * 소스 데이터베이스에 직접 쿼리를 날려 데이터를 추출하는 방식은 운영 중인 DB에 과도한 부하를 주었으며, 이를 피하기 위해 읽기 전용 복제본(Read Replica)을 사용함에도 불구하고 스케일 아웃의 한계에 직면했습니다. * 스키마 변경이 발생할 때마다 파이프라인이 수동 개입 없이는 중단되거나 데이터 정합성이 깨지는 등 운영상의 복잡도가 임계치를 넘어서는 문제가 있었습니다. ### CDC 및 Kafka 기반의 실시간 스트리밍 도입 * 데이터베이스의 바이너리 로그(Binlog)를 읽어 변경 사항을 즉시 캡처하는 CDC 방식을 도입하여 원본 DB에 가하는 부하를 최소화했습니다. * Debezium 커넥터를 AWS MSK(Managed Streaming for Kafka)와 연결해 수백 개의 샤드에서 발생하는 변경 이벤트를 중앙 Kafka 클러스터로 실시간 수집하는 구조를 설계했습니다. * Confluent Schema Registry를 활용해 Avro 포맷으로 데이터를 직렬화함으로써, 업스트림의 스키마 변경이 다운스트림 파이프라인에 안전하고 자동화된 방식으로 전파되도록 구현했습니다. ### Apache Iceberg를 활용한 데이터 레이크 현대화 * S3에 저장되는 데이터를 관리하기 위해 오픈 소스 테이블 포맷인 Apache Iceberg를 도입하여 대규모 데이터셋에 대한 ACID 트랜잭션과 시간 여행(Time Travel) 기능을 확보했습니다. * 기존의 단순 파일 저장 방식과 달리 Iceberg는 메타데이터를 효율적으로 관리하므로, Snowflake와 같은 데이터 웨어하우스에서 쿼리 시 불필요한 파일을 스캔하지 않아도 되어 성능과 비용을 최적화했습니다. * Kafka Connect의 Iceberg 싱크를 사용하여 스트리밍 데이터를 즉시 Iceberg 테이블로 기록함으로써 데이터 신선도를 극대화했습니다. ### 시스템 전환의 성과와 운영 효율화 * 새로운 아키텍처 도입 후 데이터 가용 지연 시간이 수일에서 5분 이내로 줄어들었으며, 분석가와 엔지니어들이 거의 실시간에 가까운 인사이트를 얻을 수 있게 되었습니다. * 데이터 파이프라인의 가시성을 높이기 위해 사용자 정의 모니터링 대시보드와 알림 시스템을 구축하여, 특정 샤드나 커넥터에서 발생하는 문제를 즉각적으로 파악하고 대응할 수 있는 환경을 만들었습니다. * 인프라의 확장성이 크게 개선되어 향후 데이터베이스 샤드가 추가되거나 트래픽이 급증하더라도 파이프라인의 구조적 변경 없이 유연하게 대응할 수 있는 능력을 갖추게 되었습니다. 서비스 규모가 커짐에 따라 전통적인 배치 방식은 성능과 운영 면에서 한계에 부딪힐 수밖에 없습니다. 피그마의 사례처럼 CDC와 Kafka, 그리고 Iceberg와 같은 현대적인 데이터 스택을 조합하면 데이터 신선도를 획기적으로 높이면서도 시스템의 안정성을 동시에 확보할 수 있습니다. 대규모 샤딩 환경에서 데이터 파이프라인을 고민하는 팀이라면 이벤트 중심의 아키텍처와 스키마 레지스트리를 통한 자동화에 집중할 것을 권장합니다.

투 타워를 넘어서: 차 (새 탭에서 열림)

전통적인 추천 시스템의 표준인 'Two-Tower' 모델은 효율적이지만, 사용자-아이템 간의 복잡한 상호작용 특징(Interaction features)을 반영하지 못하는 구조적 한계가 있습니다. 이를 해결하기 위해 핀터레스트는 범용 신경망 기반의 복잡한 랭킹 모델을 도입하기로 결정하고, 이를 지원하기 위한 GPU 기반의 서빙 스택 재설계를 단행했습니다. 데이터 전송 병목 현상을 해결하고 비즈니스 로직을 모델 내부에 통합함으로써, 초기 4,000ms에 달하던 지연 시간을 실시간 서비스 가능한 수준인 20ms까지 단축하는 데 성공했습니다. ### Two-Tower 모델의 한계와 새로운 도전 * **표현력의 제약:** Two-Tower 구조는 사용자(User)와 아이템(Item)을 각각 독립적인 벡터로 인코딩한 뒤 마지막에 내적(Dot product)만 수행하므로, 네트워크 깊은 곳에서 두 피처가 결합되는 '교차 피처(Cross-features)'나 '타겟 어텐션(Target attention)'을 활용하기 어렵습니다. * **복잡한 모델 도입의 필요성:** 보다 정교한 추천을 위해 피처 간의 직접적인 상호작용을 모델링할 수 있는 일반적인 딥러닝 아키텍처 도입이 필요해졌습니다. * **서빙 인프라의 한계:** 기존 인프라는 단순한 연산(내적 또는 ANN 검색)에 특화되어 있어, 무거운 GPU 추론 단계를 지연 시간 손실 없이 통합하는 것이 핵심 과제였습니다. ### 인벤토리 세분화를 통한 피처 패칭(Feature Fetching) 최적화 * **데이터 전송 병목:** 수만 개의 후보군에 대해 네트워크를 통해 피처를 가져오는 I/O 작업이 모델 추론보다 더 긴 시간을 소모하는 문제가 발생했습니다. * **고가치 인벤토리(Segment 1):** 매출 기여도가 높은 약 100만 개의 문서는 피처를 PyTorch 모델 파일 내의 'Registered Buffer' 형태로 직접 삽입했습니다. 이를 통해 모델 가중치처럼 GPU의 고대역폭 메모리(HBM)에 피처가 상주하게 되어 네트워크 오버헤드를 완전히 제거했습니다. * **롱테일 인벤토리(Segment 2):** 나머지 10억 개 이상의 문서는 고성능 Key-Value 저장소와 인-호스트 캐시를 조합하여 피처를 가져오도록 이원화했습니다. ### 비즈니스 로직의 모델 내부 통합 * **데이터 전송량 최소화:** 기존에는 GPU에서 계산된 수만 개의 점수를 모두 CPU로 보낸 뒤 필터링했으나, 이는 Device-to-Host(D2H) 전송 병목을 야기했습니다. * **로직 내재화:** 유틸리티 계산(pCTR, pCVR, 입찰가 조합 등), 다양성 규칙, Top-K 정렬 등의 비즈니스 로직을 PyTorch 텐서 연산으로 구현하여 모델 내부에 포함시켰습니다. * **병렬 처리 이점:** 복잡한 필터링과 정렬을 GPU의 대규모 병렬 연산으로 처리함으로써 CPU 기반 처리보다 속도를 높였고, 최종 결과값(약 1,000개)만 출력하여 전송 효율을 극대화했습니다. ### GPU 추론 가속화 및 시스템 최적화 * **멀티 스트림 CUDA:** 단일 스트림 방식에서 벗어나 여러 CUDA 스트림을 사용하여 데이터 전송(H2D, D2H)과 연산(Compute)이 서로 겹쳐서 수행(Overlap)되도록 설계했습니다. * **커널 퓨전(Kernel Fusion):** Triton 커널을 사용하여 선형 레이어와 활성화 함수 같은 반복적인 레이어 패턴을 하나로 합침으로써 메모리 대역폭 압박을 완화했습니다. * **수치 형식 최적화:** FP32 대신 BF16(Brain Floating Point 16) 형식을 채택하여 메모리 사용량을 줄이고 연산 속도를 높였습니다. * **워커 정렬:** 호스트 CPU 코어 수에 맞춰 워커 스레드 수를 조정하고 고정(Pinning)하여 컨텍스트 스위칭과 락 경합을 최소화했습니다. 이러한 재설계는 고성능 추천 시스템을 구축할 때 모델 아키텍처뿐만 아니라, 데이터 흐름과 하드웨어 가속기(GPU)의 특성을 고려한 인프라 최적화가 필수적임을 보여줍니다. 특히 대규모 트래픽 환경에서 GPU를 효율적으로 활용하려면 비즈니스 로직을 포함한 전체 서빙 파이프라인을 모델과 밀접하게 통합하는 전략이 유효합니다.