DevLog

엔지니어링 블로그를 한 곳에서 탐색하고, 최근 발행 흐름을 빠르게 파악할 수 있는 서비스 입니다.

Quick Links

  • Latest Feed
  • Engineering Directory

Support

  • 소개
  • 개인정보처리방침

Contribute

  • 원하는 블로그 추가 (준비 중)
  • Feedback

© 2026 DevLog Inc. All rights reserved.

본 사이트는 공개 RSS 피드를 통해 콘텐츠를 수집하며, 모든 콘텐츠의 저작권은 원저작자에게 있습니다.

Back to Feed
KOEN
Read Original

Contents

Continue Reading

  • More from Netflix
  • Related reads#gRPC
#Backend

넷플릭스가 실시간 분산 그래프를 구축한 방법과 이유: 3부 — gRPC 실행 API를 통한 그래프 쿼리

넷플릭스가 실시간 분산 그래프를 구축한 방법과 이유: 3부 — gRPC 실행 API를 통한 그래프 쿼리
01

Summary

넷플릭스는 어떻게 수십억 개의 에지를 가진 그래프를 0.1초 만에 검색할까?

gRPC와 비동기 너비 우선 탐색으로 완성한 초저지연 분산 그래프 조회 엔진 설계기

이 아티클은 넷플릭스가 실시간 분산 그래프(RDG) 상에서 수많은 다중 홉 쿼리를 100ms 미만으로 처리하기 위해 설계한 서빙 레이어 구조를 소개합니다. 네트워크 오버헤드를 유발하는 깊이 우선 탐색 대신 비동기 너비 우선 탐색을 선택하고, 캐싱 및 데이터 스트리밍 기법을 조화롭게 결합한 실전 아키처 가이드를 제공합니다.

  • 01깊이 우선 대신 너비 우선 탐색(BFS)을 선택하여 분산 환경에서의 네트워크 왕복 횟수를 최소화하고 병렬 배칭을 실현
  • 02Thread-per-request 모델을 탈피하고, 단 16~24개의 전용 스레드 풀로 수천 개의 비동기 I/O 요청을 조율하는 고성능 아키텍처 구현
  • 03대규모 연결 노드를 한 번에 로드하는 대신, 인접 리스트를 100개 단위의 스트림으로 나누어 처리하고 필터링을 조기 적용해 메모리 과부하 방지
  • 04전체 데이터를 캐싱하는 대신 휘발성이 낮고 접근 빈도가 높은 노드만 EVCache로 선택적 캐싱하여 70~80%의 높은 히트율 달성
  • 05클라이언트가 필요로 하는 외부 메타데이터만 선택적으로 인리치먼트(Enrichment)하되, 외부 서비스 장애 시에도 그래프 데이터를 우선 반환하는 Fail-open 구조 설계

+RECOMMENDATION

대규모 분산 그래프 데이터나 복잡하게 얽힌 관계형 데이터를 초저지연으로 조회해야 하는 백엔드 아키텍트와 분산 시스템 엔지니어에게 적극 추천합니다.

The Problem

넷플릭스는 대규모 실시간 분산 그래프(RDG)를 구축했으나, 대용량 보안 조회부터 탐색적 개인화 추적에 이르는 다양한 접근 패턴을 100ms 미만의 지연 시간 내에 처리해야 하는 조회 계층 설계의 복잡성에 직면했습니다. 특히 순차적인 다중 홉(hop) 조회 시 발생하는 네트워크 오버헤드와 광범위한 팬아웃(fan-out) 처리 문제가 있었습니다.

The Solution

너비 우선 탐색(Breadth-First Traversal) 방식을 채택하여 각 단계를 병렬화했고, 블로킹 I/O를 방지하기 위해 비동기식 구성(Asynchronous Composition) 기반의 전용 스레드 풀을 도입했습니다. 또한 인접 리스트(Adjacency Lists)를 스트림 형태로 처리하여 대규모 팬아웃 시 데이터 오버페칭을 방지하고 EVCache를 사용해 빈번히 조회되는 정적 데이터를 선택적으로 캐싱했습니다.

The Result

이와 같은 구조를 통해 2-홉 이상의 다중 홉 그래프 조회를 100ms 미만의 지연 시간 내에 완벽하게 처리할 수 있게 되었습니다. 또한 수천 개의 동시 쿼리를 소수의 스레드 풀(16~24개 스레드)만으로 지연 없이 안전하게 조율할 수 있었으며 선택적 캐싱을 통해 70~80%의 높은 히트율을 달성했습니다.

Trade-off

너비 우선 탐색의 특성상 그래프의 각 레벨 데이터를 한 번에 메모리에 유지해야 하므로 메모리 사용량이 급증할 수 있어, 각 홉마다 에지 타입별 제한(Limits)을 두어 메모리 부하를 제어해야 했습니다. 또한 강한 일관성 대신 최종 일관성(Eventual Consistency)을 타협안으로 채택하여 성능을 최적화했습니다.

03

Key Concepts

Concept · 01

너비 우선 탐색 (Breadth-First Traversal)

그래프를 탐색할 때 한 경로를 끝까지 쫓아가는 깊이 우선 방식과 달리, 현재 노드와 인접한 모든 노드를 레벨 단위로 먼저 확장하며 탐색하는 방법입니다.

  • 다중 홉 조회 시 순차적인 네트워크 호출로 인한 오버헤드를 줄이기 위해 채택되었습니다.
  • 사용자 계정의 모든 프로필을 먼저 가져온 후, 이들의 시청 이력을 병렬로 일괄 조회하는 배칭 구조에 활용되었습니다.
Concept · 02

인접 리스트 스트리밍 (Adjacency List Streaming)

노드 간의 연결 관계(에지)를 저장하는 인접 리스트를 메모리에 한 번에 올리는 대신, 일정한 배치 크기로 스트리밍하며 읽어 들이는 방식입니다.

  • 특정 프로필의 시청 이력처럼 팬아웃이 큰 노드 데이터를 조회할 때 메모리 급증을 방지하기 위해 사용됩니다.
  • 100개 단위의 배치로 데이터를 스트리밍하며 조건에 맞지 않는 데이터는 조기에 필터링하여 버릴 수 있도록 제어합니다.
Concept · 03

비동기 구성 (Asynchronous Composition)

I/O 작업이 완료될 때까지 실행 스레드를 블로킹하지 않고, 작업 완료 이벤트가 오면 다음 단계를 이어서 실행하도록 작업을 논리적으로 체이닝하는 기법입니다.

  • 넷플릭스 RDG는 단 16~24개의 스레드만으로 구성된 전용 풀을 이용해 수천 건의 동시 쿼리를 지연 없이 스케줄링합니다.
  • 스토리지 조회 및 외부 서비스 인리치먼트와 같은 I/O 대기 시간 동안 스레드가 다른 작업을 계속 처리할 수 있게 보장합니다.
Continue reading · same source

NetflixMore from Netflix

View all posts from Netflix
  • MAPS: 넷플릭스의 대규모 멀티모달 에셋 개인화

    CLIPMediaFMRecommendation Systems
    1일 전
  • 두 개의 플링크 오토스케일러 이야기

    Apache FlinkAutoscalingStream Processing
    1주 전
  • 분석을 위한 디바이스 사양 모델링

    Data ModelingFeature ManagementAnalytics
    4주 전
  • GenRec: 넷플릭스의 LLM 네이티브 추천 시스템을 향하여

    LLMRecommendation SystemContext Engineering
    1개월 전
  • 넷플릭스의 자체 LLM 서빙 플랫폼 구축기

    vLLMTriton Inference ServerLLM Serving
    1개월 전

Related reads#gRPC

Explore #gRPC
채널 톡·Istio

Istio 3-4편: 507 status code와 istiod disconnected 탐지

#gRPC1개월 전

Source

Netflix
Netflix
Engineering Blog

Published · August 7, 2026

Topics

gRPCGraph DatabaseDistributed SystemsAsynchronous I/OEVCache