Airbnb Engineering

Airbnb는 2025년 여름 Homes 외에 Experiences·Services 두 상품을 추가하면서 10년 된 데이터 인프라가 "단일 상품" 가정으로 설계됐음을 발견했다. 분석팀은 도메인별 완전 분리 모델과 전사 통합 모델 사이에서 일률적 선택 대신 8가지 기준으로 도메인마다 다르게 결정하는 체계를 구축했다.

Airbnb의 수천 개 서비스 인스턴스에 재배포 없이 매분 설정 변경을 안정적·빠르게 전파해야 하는 문제.

COVID 회복기에 지역별 재오픈 시점이 달라 과거 패턴 기반 수요 예측이 무력화됐다. 유럽·북미 등 백신 공급과 국경 재개 시점이 달라 단일 역사 패턴을 적용할 수 없었다.

Airbnb 가 70억 노드·110억 엣지 규모로 하루 500만 엣지씩 자라는 identity graph 를, 써드파티 SaaS 그래프 DB 에서 JanusGraph+DynamoDB+OpenSearch 기반 내부 플랫폼으로 옮긴 과정을 다룬다. 쓰기 성능·4~8 hop 쿼리의 꼬리 지연·안정성 문제를 엔진과 클라이언트 양쪽 최적화로 풀어 모든 쿼리 패턴에서 기존 벤더를 앞섰다.

조직 전체 GraphQL 스키마를 중앙화하면 API 일관성은 얻지만, 도메인 팀이 빠르게 독립 개발하기 어렵다.

Airbnb의 metrics pipeline이 관측 대상과 같은 Kubernetes·service mesh에 의존해 장애 시 관측성까지 함께 무너질 위험이 있었다.

Airbnb의 장기 실행 업무는 큐와 잡으로 흩어져 idempotency, retry, partial failure 처리를 팀마다 반복 구현해야 했다.

Airbnb의 관측성 백엔드는 초당 5천만 samples와 13억 active time series를 안정적으로 저장하고 조회해야 했다.

Airbnb가 social experience를 확장하면서 사용자의 profile 정보가 다른 맥락에서 연결되어 노출될 위험이 있었다.

StatsD 기반 metrics pipeline을 Prometheus 계열 backend로 옮기려면 전체 지표를 수집하면서 scale, correctness, performance를 보장해야 했다.

COVID 충격으로 Airbnb의 booking date와 trip date 사이 lead-time 분포가 깨져 기존 예측 모델이 구조 변화를 따라가지 못했다.

Airbnb의 vendor-managed observability는 비용과 데이터 제어 한계가 커졌고, 팀별 dashboard와 alert query도 일관성이 낮았다.

여행 사용자가 어디로 갈지 정하지 못한 탐색 단계에서는 목적지 추천이 검색보다 더 중요하다.