Pinterest / apache-spark

Drastically Reducing Out-of-Memory Errors in Apache Spark at Pinterest (새 탭에서 열림)

Pinterest는 대규모 Spark 환경에서 빈번하게 발생하는 OOM(Out-of-Memory) 오류를 해결하기 위해 'Auto Memory Retries' 기능을 도입했습니다. 이 시스템은 태스크 수준에서 리소스 요구량을 동적으로 판단하고, 실패 시 더 큰 메모리 프로필을 가진 실행기(Executor)에서 태스크를 재시도하도록 자동화합니다. 이를 통해 수동 튜닝의 번거로움을 줄이고 자원 효율성을 높여 전체적인 작업 실패율과 운영 비용을 획기적으로 낮추는 성과를 거두었습니다. ### 기존 Spark 리소스 관리의 한계와 문제점 * Pinterest의 Spark 클러스터는 하드웨어 대비 높은 메모리 요구량으로 인해 OOM 오류가 잦았으며, 전체 작업 실패 원인의 약 4.6%가 메모리 부족에서 기인했습니다. * 사용자가 모든 스테이지와 태스크의 메모리 요구량을 정확히 예측하여 수동으로 설정하는 것은 매우 어렵고 시간이 많이 소요되는 작업입니다. * 데이터 스큐(Skew) 현상으로 인해 같은 스테이지 내에서도 특정 태스크만 과도한 메모리를 사용하는 경우가 많아, 모든 태스크를 최대치에 맞춰 설정하면 심각한 자원 낭비가 발생합니다. * 제품 팀의 우선순위 문제로 인해 비용 절감을 위한 수동 최적화가 지속적으로 이루어지기 어려운 구조적 한계가 있었습니다. ### Auto Memory Retries의 단계별 대응 전략 * **CPU 할당량 증설을 통한 메모리 확보 (1단계):** 실행기에 1개 이상의 코어가 있는 경우, OOM 발생 시 첫 번째 재시도에서 태스크당 CPU 할당량(`spark.task.cpus`)을 두 배로 늘립니다. 이를 통해 실행기 내 동시 실행 태스크 수를 줄여 개별 태스크가 사용할 수 있는 공유 메모리 공간을 즉각적으로 확보합니다. * **물리적으로 큰 실행기 투입 (2단계):** CPU 조절만으로 해결되지 않거나 단일 태스크가 이미 실행기 전체 메모리를 사용 중인 경우, 물리적으로 더 큰 메모리를 가진 새로운 실행기를 동적으로 런칭합니다. * **하이브리드 확장 프로필 적용:** 기본 설정의 2배, 3배, 4배 크기의 리소스 프로필을 미리 등록하고 단계별로 순차 적용합니다. Apache Gluten을 사용하는 워크로드의 경우 Off-heap 메모리도 함께 증설하여 가속화된 연산을 지원합니다. ### 시스템 구현 및 Spark 엔진 확장 * **태스크 수준의 리소스 프로필:** 기존 Spark의 고정된 리소스 할당 방식에서 벗어나, `Task` 객체에 개별 리소스 프로필 ID(`taskRpId`)를 저장할 수 있도록 확장하여 동일한 TaskSet 내에서도 태스크마다 사양을 다르게 가질 수 있게 구현했습니다. * **스케줄링 로직 최적화:** `TaskSetManager`는 OOM 감지 시 즉시 상위 프로필을 할당하며, `TaskSchedulerImpl`은 증설된 CPU 속성을 가진 태스크를 기존 실행기에서 우선 실행할 수 있게 하여 리소스 재사용 속도를 높였습니다. * **동적 리소스 할당:** `ExecutorAllocationManager`가 상위 프로필을 필요로 하는 대기 태스크를 실시간으로 추적하고, 물리적으로 큰 실행기가 필요한 시점에 맞춰 Kubernetes 등에 자원을 요청합니다. * **사용자 경험 개선:** 사용자가 어떤 태스크가 더 많은 자원을 사용했는지 쉽게 파악할 수 있도록 Spark UI의 태스크 목록에 리소스 프로필 ID를 표시하는 기능을 추가했습니다. 효율적인 Spark 운영을 위해서는 모든 작업을 최대 메모리 요구량에 맞추기보다, 상위 90%(P90) 수준의 일반적인 설정으로 실행하고 예외적인 태스크만 'Auto Memory Retries'로 구제하는 탄력적 전략이 권장됩니다. 이는 데이터 스큐가 심한 대규모 파이프라인에서 운영 안정성을 확보함과 동시에 인프라 비용을 최적화할 수 있는 강력한 해법이 될 것입니다.

Next Generation DB Ingestion at Pinterest (새 탭에서 열림)

Pinterest는 기존의 파편화된 배치 기반 DB 적재 시스템을 개선하기 위해 Iceberg와 CDC(Change Data Capture) 기술을 결합한 통합 프레임워크를 구축했습니다. 이 시스템은 데이터 지연 시간을 24시간 이상에서 수 분 단위로 단축하고, 변경된 데이터만 처리하는 방식으로 인프라 비용을 획기적으로 절감했습니다. 이를 통해 분석, 머신러닝, 규정 준수 등 현대적인 데이터 요구사항에 기민하게 대응할 수 있는 고성능 데이터 생태계를 마련했습니다. ### 통합 CDC 프레임워크의 계층 구조 * **CDC 레이어**: Debezium 및 TiCDC를 활용해 MySQL, TiDB, KVStore의 변경 사항을 1초 미만의 지연 시간으로 포착하여 Kafka에 기록합니다. * **스트리밍 레이어**: Flink 작업이 Kafka의 이벤트를 실시간으로 처리하여 S3에 위치한 'CDC Iceberg 테이블'에 추가 전용(Append-only) 방식으로 저장합니다. * **배치 레이어**: Spark 작업이 주기적으로(15~60분) CDC 테이블의 최신 변경 사항을 읽어 `Merge Into` 구문을 통해 최종 'Base Iceberg 테이블'에 업서트(Upsert)를 수행합니다. * **부트스트랩 및 유지보수**: 초기 데이터 로드를 위한 전용 파이프라인과 소형 파일 압축(Compaction) 및 스냅샷 만료 관리를 위한 유지보수 작업을 포함합니다. ### CDC 테이블과 베이스 테이블의 이원화 관리 * **CDC 테이블**: 모든 변경 이력을 담은 시계열 원장으로, 5분 미만의 지연 시간을 유지하며 원천 데이터의 변경 로그를 보존합니다. * **베이스 테이블**: 온라인 DB의 현재 상태를 그대로 반영하는 스냅샷 테이블입니다. CDC 테이블로부터 최신 레코드를 추출하여 정합성을 맞춥니다. * **동기화 로직**: `ROW_NUMBER()` 함수를 활용해 기본 키(PK)별로 가장 최신 업데이트(최근 타임스탬프 및 GTID 기준)를 식별한 후, 삭제 유형은 제거하고 나머지는 업데이트 또는 삽입합니다. ### 성능 및 비용 최적화 전략 * **Merge-on-Read (MOR) 방식 채택**: Copy-on-Write(COW) 방식은 업데이트 시 대규모 파일을 다시 작성해야 하므로 스토리지와 계산 비용이 높습니다. Pinterest는 비용 효율성을 극대화하기 위해 MOR 방식을 표준 전략으로 선택했습니다. * **기본 키 해시 버킷팅(Bucketing)**: 베이스 테이블을 PK의 해시값(예: `bucket(100, id)`)으로 파티셔닝하여 Spark가 업서트 작업을 병렬로 효율적으로 처리할 수 있도록 설계했습니다. * **증분 처리 효율성**: 매일 전체 테이블을 덤프하던 방식에서 변경된 데이터(통상 5% 미만)만 처리하는 방식으로 전환하여 연산 리소스 낭비를 차단했습니다. 방대한 양의 데이터베이스를 데이터 레이크로 통합할 때는 Iceberg의 `Merge Into` 기능을 활용한 증분 업데이트가 필수적입니다. 특히 읽기 성능과 쓰기 비용 사이의 균형을 위해 MOR 전략을 사용하고, 쓰기 병목을 해소하기 위해 기본 키 기반의 버킷팅을 적용하는 것이 실무적으로 매우 효과적인 접근임을 보여줍니다.

PinLanding: Turn Billions of Products into Instant Shopping Collections with Multimodal AI (새 탭에서 열림)

Pinterest의 'PinLanding'은 수십억 개의 제품 데이터를 멀티모달 AI를 통해 정교한 쇼핑 컬렉션으로 자동 변환하는 프로덕션 파이프라인입니다. 기존의 수동 큐레이션이나 단순 검색 기록 기반 방식에서 벗어나, 제품의 이미지와 텍스트를 직접 분석하여 사용자의 복잡하고 긴 꼬리형(Long-tail) 검색 의도에 맞는 컬렉션을 생성합니다. 이 시스템은 비전-언어 모델(VLM)을 통한 속성 추출과 CLIP 스타일의 효율적인 임베딩 모델을 결합하여 대규모 데이터셋에서도 정밀도와 확장성을 동시에 확보했습니다. **사용자 쇼핑 의도와 데이터 신호의 특성화** * 사용자의 검색 기록, 자동 완성 상호작용, 필터 사용 패턴을 분석하여 쇼핑 의도의 분포를 파악합니다. * '검은색 칵테일 드레스'와 같은 정형화된 주요 쿼리(Head)뿐만 아니라, '이탈리아 여름 휴가 때 입을 옷'과 같은 서술형 및 대화형 쿼리에 대응하는 것을 목표로 합니다. * 색상, 상황, 스타일, 핏 등 20개 카테고리에 걸친 속성 차원을 정의하여, 수요는 높지만 기존 검색 결과가 부족한 영역을 식별합니다. **VLM과 LLM-as-Judge를 활용한 쇼핑 토픽 정제** * 제품의 이미지와 메타데이터를 비전-언어 모델(VLM)에 입력하여 정규화된 키-값 쌍 형태의 속성을 생성합니다. * 초기 VLM 출력의 너무 구체적이거나 중복된 속성(예: 'boho'와 'bohemian')을 해결하기 위해 빈도 기반 필터링과 임베딩 기반 클러스터링을 수행합니다. * 최종적으로 'LLM-as-judge' 단계를 거쳐 추출된 속성들이 실제 쇼핑 의도와 일치하는지, 의미적으로 일관성이 있는지 평가하여 고품질의 쇼핑 토픽 사전을 구축합니다. **CLIP 스타일 모델을 통한 대규모 속성 할당** * 모든 제품에 VLM을 직접 적용하는 것은 비용이 과다하므로, 이미지-텍스트를 정렬하는 CLIP 스타일의 듀얼 인코더 모델을 별도로 학습시킵니다. * 제품 인코더와 속성 구절 인코더를 통해 각각의 임베딩을 생성하고, 두 벡터 간의 유사도가 임계치를 넘을 때 속성을 할당합니다. * 이 방식은 VLM 대비 연산 비용을 획기적으로 낮추면서도, 제품별 속성 밀도를 높여 더욱 일관된 제품-속성 그래프를 형성합니다. **Ray 및 Spark 기반의 효율적인 배치 추론 및 피드 구축** * 수백만 개의 핀(Pin)과 토픽을 처리하기 위해 Ray 프레임워크를 사용하여 GPU와 CPU 리소스를 독립적으로 확장하며 스트리밍 방식으로 추론을 수행합니다. * CLIP 기반 분류기는 8개의 NVIDIA A100 GPU에서 약 12시간 만에 학습 및 추론을 완료하며, 회당 비용을 약 500달러 수준으로 절감했습니다. * 최종 피드 구성은 Apache Spark를 활용하여 제품과 쇼핑 토픽 간의 속성 유사도를 계산하고, 가중치 기반 스코어링을 통해 관련성 높은 제품들을 컬렉션으로 묶어냅니다. PinLanding 시스템은 AI가 단순한 키워드 매칭을 넘어 제품의 시각적, 맥락적 의미를 깊이 있게 이해할 수 있음을 보여줍니다. 대규모 이커머스 환경에서 사용자에게 개인화되고 탐색 가능한 쇼핑 경험을 제공하려는 기업은 VLM을 통한 '지식 추출'과 CLIP 스타일 모델을 통한 '효율적 확산' 전략을 참고할 가치가 있습니다.