Airbnb identity graph 를 통합 knowledge graph 인프라로 확장하기

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

핵심 포인트

그래프는 70억 노드·110억 엣지에 하루 500만 엣지씩 늘어, 써드파티 솔루션의 쓰기 성능과 P95/P99 꼬리 지연이 한계에 닿았다.
온라인 확장성·표현력·인프라 적합성·오픈소스 확장성을 기준으로 JanusGraph(Gremlin)+DynamoDB+OpenSearch 를 택했다.
JanusGraph 의 스토리지 분리 설계로 DynamoDB 의 안정성을 쓰면서 그래프 로직을 독립적으로 개발했다.
트랜잭션·병렬 쿼리·관찰성을 엔진에서, path/side-effect 스텝을 클라이언트에서 최적화했다.
부하 테스트에서 쓰기 QPS 를 기존의 10배까지 확장하고 주기적 인스턴스 재부팅도 없앴다.

상세 정리

규모·진화: identity graph 는 관계형 DB+KV 스토어에서 2021년 써드파티 SaaS 그래프 DB, 2024년 내부 플랫폼으로 진화했고 70억 노드·110억 엣지에 하루 500만 엣지가 더해진다.
문제: 하루 500만 엣지 쓰기 성능 저하, 4~8 hop 다단계 쿼리, P95/P99 꼬리 지연, 느린 쿼리로 인한 리소스 고갈이 핵심 과제였다.
선정 기준: 온라인 쿼리 확장성, 표현력 있는 스키마·쿼리 언어, Airbnb 인프라 적합성, 확장 가능한 오픈소스 코드 네 가지로 스택을 골랐다.
스택: Apache TinkerPop 기반 JanusGraph 에 Gremlin 쿼리, 스토리지 백엔드 DynamoDB, 인덱싱 OpenSearch 를 결합했다.
스토리지 분리: JanusGraph 의 플러그인형 백엔드 설계로 DynamoDB 안정성을 활용하면서 그래프 로직을 독립적으로 진화시킬 수 있게 했다.
엔진 최적화: 기본 JanusGraph 락이 과중해 DynamoDB 조건부 쓰기·트랜잭션 API 로 무결성을 지키며 오버헤드를 줄였고, getMultiSlices 를 개선해 고팬아웃 쿼리를 병렬 페치했으며, 분산 추적을 통합해 오픈소스의 관찰성 격차를 메웠다.
클라이언트 최적화: 비배치로 폴백되던 Path/SimplePath 스텝을 비순환을 보장하는 조건부 쿼리로 대체하고, side-effect 스텝을 고쳐 비배치 서브스텝과 계산량을 줄였다.
마이그레이션: 같은 Gremlin 쿼리도 플래닝 차이로 성능 편차가 나, 내부·써드파티 솔루션을 병렬 운영하며 섀도우 트래픽으로 검증한 뒤 단계적으로 전환했다.
결과: 내부 솔루션이 모든 그래프 쿼리 패턴에서 기존 벤더를 앞섰고, 읽기 API 지연과 P99 꼬리 지연이 개선됐으며, 주기적 재부팅이 사라지고 쓰기 QPS 를 10배까지 확장했다.
확장 활용: 부정 탐지, 인벤토리 지식 그래프, 데이터 계보 같은 추가 사용 사례도 지원하게 됐다.

왜 읽나대규모 그래프를 써드파티에서 자체 운영으로 옮기려는 데이터 플랫폼 엔지니어에게, JanusGraph 백엔드 선택과 엔진·클라이언트 최적화의 실전 레퍼런스.

Airbnb Engineering 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청

Airbnb identity graph 를 통합 knowledge graph 인프라로 확장하기

이 글과 비슷한

분석가가 직접 만든 마케팅 자동화 시스템 — 오디언스 빌더 제작기

모든 Vercel 빌드를 지탱하는 데이터베이스 마이그레이션 이야기

DynamoDB 핫 파티션을 해결하는 3가지 방법 (3): 조회를 인덱스 테이블로 옮기기