AI
당근의 AWS 기반 피처 플랫폼 구축 여정, Part 1: 구축 배경과 피처 서빙
두줄요약
당근은 추천 시스템 고도화를 위해 AWS 기반 피처 플랫폼을 설계하고, 다단계 캐시와 일관된 스키마로 피처 서빙을 구성했습니다. 캐시 미스, 정합성, 관통 문제를 완화하며 대규모 트래픽을 안정적으로 처리하는 구조를 소개했습니다.
문제 상황
- 추천 시스템 도입 후 개인화 피드의 성과가 커지면서, 다양한 피처를 중앙에서 빠르게 관리·서빙할 필요성 증가
- 초기 구조는 중고거래 서버 내부 라이브러리 의존, 하드코딩된 피처 코드, 일관성 없는 저장소 사용으로 확장성과 신뢰성에 한계
구조와 흐름
- 피처 플랫폼을 피처 서빙, 스트림 수집, 배치 수집의 3축으로 분리하고, 1부에서는 서빙 구조를 중심으로 설명
- 서빙 계층은 Server, Remote Cache, Database, On-demand Feature Server로 구성하고, EKS·ElastiCache·DynamoDB를 활용
- 피처그룹 스펙과 partition key/sort key 설계로 다양한 타입의 피처를 일관된 스키마로 저장
선택 이유
- 높은 카디널리티와 낮은 지연시간 요구를 맞추기 위해 Local cache, Remote cache, Database의 다단계 캐시 전략 채택
- 캐시 미스, 정합성, 캐시 관통 문제를 줄이기 위해 PEE, Soft TTL/Hard TTL 분리, Write Through, Jitter, Negative Caching 적용
성능/운영 포인트
- 대규모 트래픽과 피처 개수 증가를 고려해 초기부터 높은 확장성 목표를 설정
- 캐시 히트율, Negative Cache 비율, DynamoDB 핫 파티션 여부를 모니터링하며 운영 안정성 확보
- 대용량 피처와 임베딩 증가에 대응한 Embedded Database, TTL 최적화, 캐시 정책 고도화 과제 검토