에어비앤비는 어떻게 70억 노드의 지식 그래프를 운영할까? (Feat. JanusGraph + DynamoDB)

들어가며: 왜 지식 그래프인가?

실무에서 '연결'이라는 개념은 생각보다 훨씬 복잡합니다. 사용자 간의 관계, 기기 간의 연결, 계정 간의 연관성 — 이 모든 것을 관계형 데이터베이스로 표현하려면 수많은 조인(Join) 연산이 필요하고, 쿼리 한 번에 수십 초가 걸리는 일이 다반사입니다. 😅

에어비앤비는 바로 이 문제를 해결하기 위해 지식 그래프(Knowledge Graph) 를 도입했습니다. 특히 Trust & Safety(안전 및 신뢰) 도메인에서 사용자 간의 관계를 추적하고, 사기 행위를 탐지하며, 연결된 계정을 식별하는 데 그래프가 핵심 역할을 합니다.

이 글에서는 에어비앤비가 어떻게 70억 개의 노드와 110억 개의 엣지를 가진 아이덴티티 그래프(Identity Graph)를 운영하는지, 그리고 어떤 인프라적 결정을 내렸는지 상세히 살펴보겠습니다. 특히 국내 환경에서 자체 관리형 인프라를 고민하는 분들께 실질적인 인사이트가 될 거예요.

근거자료: 에어비앤비 엔지니어링 블로그 원문

1세대 → 3세대: 아이덴티티 그래프의 진화 과정

에어비앤비의 아이덴티티 그래프는 크게 세 번의 진화를 거쳤습니다.

1세대: RDBMS + KV Store

• 구조: 관계형 DB에 사용자 정보 저장, Redis 같은 KV Store에 JSON 형태의 엣지 리스트 저장
• 문제점: 그래프 밀도(Graph Density)가 증가할수록 확장이 어렵고 비용이 기하급수적으로 증가

2세대: 서드파티 SaaS 그래프 DB (2021년 도입)

• 장점: 수평 확장성 확보
• 단점:
  • 롱테일 지연 시간(Long-tail Latency) 문제 — P95와 P99가 P50 대비 급격히 증가
  • 운영 불안정성 — 주기적인 수동 인스턴스 재부팅 필요
  • 세밀한 접근 제어 및 성능 튜닝 불가
  • 벤더 종속(Vendor Lock-in)

3세대: 자체 관리형 JanusGraph + DynamoDB (현재)

• 특징: 완전한 내부 관리형 플랫폼으로 전환
• 핵심 결정: JanusGraph(오픈소스 분산 그래프 DB) + DynamoDB(스토리지 백엔드) + OpenSearch(인덱싱)

# JanusGraph + DynamoDB 설정 예시 (핵심 개념)
# gremlin-server.yaml 설정 파일

host: 0.0.0.0
port: 8182
scriptEvaluationTimeout: 30000
channelizer: org.apache.tinkerpop.gremlin.server.channel.WsAndHttpChannelizer
graphs: {
  graph: conf/gremlin-server/janusgraph-dynamodb.properties
}

# janusgraph-dynamodb.properties
# 스토리지 백엔드로 DynamoDB 사용
storage.backend=dynamodb
storage.dynamodb.client.credentials.class=com.amazonaws.auth.DefaultAWSCredentialsProviderChain
storage.dynamodb.region=us-west-2
storage.dynamodb.prefix=airbnb_identity_graph

# 인덱스 백엔드로 OpenSearch 사용
index.search.backend=elasticsearch
index.search.hostname=search-cluster.airbnb.internal
index.search.elasticsearch.client-only=true

# 캐싱 설정
cache.db-cache=true
cache.db-cache-clean-wait=20
cache.db-cache-time=180000

실무 팁: JanusGraph의 가장 큰 장점은 스토리지와 컴퓨팅 레이어의 분리입니다. DynamoDB의 확장성과 안정성을 그래프 로직 레이어와 분리함으로써, 각 레이어를 독립적으로 튜닝할 수 있습니다. 국내에서도 DynamoDB 대신 ScyllaDB나 CockroachDB를 백엔드로 사용하는 사례가 늘고 있어요.

핵심 최적화 전략: 롱테일 지연 시간과의 전쟁

에어비앤비가 JanusGraph를 커스터마이징한 핵심 포인트는 세 가지입니다.

1. 트랜잭션 최적화 (Optimized Transactions)

JanusGraph의 기본 잠금(Locking) 메커니즘은 오버헤드가 큽니다. 에어비앤비는 DynamoDB의 조건부 쓰기(Conditional Write)와 트랜잭션 API를 활용해 데이터 무결성을 유지하면서도 오버헤드를 대폭 줄였습니다.

2. 병렬 쿼리 실행 (Parallel Query Execution)

특히 하이 팬아웃(High Fanout) 노드(한 노드에 연결된 엣지가 많은 경우)에서 발생하는 성능 저하를 해결하기 위해 getMultiSlices 인터페이스를 개선했습니다.

# Gremlin 쿼리 최적화 예시
# 비효율적인 Path step 사용 (느림)
g.V().has('user_id', 'U1234')
  .repeat(out('HAS_DEVICE').simplePath())
  .times(3)
  .path()

# 최적화: Path step 제거, 조건부 필터로 대체
# Path step은 JanusGraph에서 배치 처리되지 않아 성능 저하 유발
g.V().has('user_id', 'U1234')
  .repeat(out('HAS_DEVICE').dedup())
  .emit()
  .times(3)
  .dedup()
  .fold()

3. 관측 가능성 확보 (Observability)

오픈소스 버전에서 부족했던 분산 추적(Distributed Tracing)을 내부 포크에 통합했습니다. 이를 통해 각 쿼리의 병목 지점을 정확히 파악할 수 있게 되었습니다.

마이그레이션 결과: 수치로 보는 개선 효과

국내 SI/플랫폼 환경에서의 적용 맥락

• 국내 대형 커머스 플랫폼에서도 유사한 그래프 기반 사기 탐지 시스템을 도입하는 사례가 늘고 있습니다. 특히 쿠팡, 11번가 등에서 Neo4j 대신 JanusGraph를 검토하는 이유는 비용 효율성 때문입니다.
• 주의할 점: JanusGraph는 커뮤니티 버전의 업데이트 주기가 불규칙합니다. 에어비앤비처럼 내부 포크를 관리할 엔지니어링 리소스가 없다면, Managed Neo4j(AuraDB)나 Amazon Neptune을 먼저 검토하는 것이 현실적입니다.

결론: 우리가 배울 수 있는 7가지 교훈

에어비앤비의 사례에서 얻을 수 있는 실전 교훈을 정리해보겠습니다.

1. 벤더 종속은 리스크다: 초기에는 편리하지만, 규모가 커질수록 통제 불능 상태가 됩니다.
2. 스토리지와 컴퓨팅 분리는 신의 한 수: JanusGraph + DynamoDB 조합은 각 레이어를 독립적으로 최적화할 수 있는 유연성을 제공합니다.
3. 롱테일 지연 시간은 '죽음의 곡선'이다: P50만 보지 말고 P95, P99를 함께 모니터링하세요.
4. Gremlin 쿼리는 생각보다 까다롭다: 동일한 쿼리도 엔진에 따라 성능이 천차만별입니다. 반드시 Shadow Traffic 테스트를 하세요.
5. 오픈소스는 '있는 그대로' 쓰면 안 된다: 반드시 내부 요구사항에 맞게 커스터마이징할 각오를 해야 합니다.
6. 관측 가능성은 선택이 아닌 필수: 분산 추적 없이 그래프 DB를 운영하는 것은 맹목 운전과 같습니다.
7. 마이그레이션은 '쿼리 호환성'이 전부가 아니다: 동일한 Gremlin 쿼리도 내부 최적화 전략이 다르면 성능이 완전히 달라집니다.

다음 단계 학습 방향

• 실무에 바로 적용하고 싶다면: JanusGraph 공식 문서에서 'Storage Backend(Backend)' 설정을 먼저 학습하세요.
• 그래프 모델링을 깊이 있게 배우고 싶다면: 'Labeled Property Graph Model'과 'RDF'의 차이를 이해하는 것이 중요합니다.
• 국내 커뮤니티: 국내에서는 JanusGraph 관련 한국어 자료가 부족한 편입니다. 에어비앤비의 아키텍처 결정 과정을 참고하여, 에어비앤비 멀티 프로덕트 데이터 아키텍처 프레임워크와 함께 보시면 더 깊은 이해가 가능합니다.

마지막 조언: 그래프 DB는 은탄환이 아닙니다. '관계'가 핵심인 도메인(사기 탐지, 추천 시스템, 지식 그래프)에 한정해서 도입하고, 단순 CRUD에는 RDBMS를 그대로 사용하는 것이 현명한 선택입니다. 😊