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 백엔드 선택과 엔진·클라이언트 최적화의 실전 레퍼런스.
Pinterest Engineering·
