netflix·2026년 7월 31일·3분 읽기큐레이션 요약

분석을 위한 디바이스 기능 모델링

넷플릭스는 다양한 기기의 하드웨어·플랫폼 차이로 인해 기능 지원 여부가 달라지므로, 기기별 역량을 정교하게 모델링해야 한다고 설명합니다. 이를 위해 최신 기기 상태를 저장하는 누적 테이블과 최근 28일간의 활성 기기 분포를 집계하는 히스토그램 테이블을 구축했습니다. 이 데이터는 4K, 공간 음향, 클라우드 게임, 최신 UI 등의 기능 도달 범위를 분석하고 기기별 기능 활성화 여부를 안전하게 결정하는 데 활용됩니다. ## 기기 역량 모델링의 필요성 - 넷플릭스는 4K 스트리밍, 몰입형 오디오, 라이브 스트리밍, 클라우드 게임 등 다양한 기능을 제공합니다. - 기기마다 다음과 같은 하드웨어 및 플랫폼 제약이 존재합니다. - RAM 용량 - CPU 코어 수 - 화면 해상도와 외부 디스플레이 지원 - 비디오·오디오 프로필 - 운영체제 및 플랫폼 기능 지원 여부 - 따라서 모든 기기에 동일한 기능을 활성화하면 성능 저하나 사용자 경험 악화가 발생할 수 있습니다. - 기기 역량 데이터를 바탕으로 기능 지원 가능 여부를 세밀하게 판단하면 기능 확산의 병목을 찾고 출시 속도를 높일 수 있습니다. ## 최신 상태를 저장하는 누적 테이블 - 누적 테이블은 각 기기 모델의 최신 역량 상태를 저장하도록 설계되었습니다. - 기기별로 다음과 같은 정보를 기록할 수 있습니다. - 화면 너비와 높이 - 지원되는 비디오 프로필 - 서라운드 사운드 지원 여부 - RAM 크기 - 기타 하드웨어 및 플랫폼 기능 - 예시 데이터는 한 기기가 1280×720 해상도와 `playready`, `hevc` 비디오 프로필을 지원함을 나타냅니다. ```json { "Screen Height": ["720"], "Screen Width": ["1280"], "Video Profiles": ["playready", "hevc"] } ``` - 최신 상태 중심으로 데이터를 관리하기 때문에 분석 및 리포팅 시스템에서 현재 기기 환경을 효율적으로 조회할 수 있습니다. ## 최근 활성 기기 분포를 보여주는 히스토그램 테이블 - 집계 분석에는 최근 28일 동안 활성 상태였던 기기 수를 기록하는 히스토그램 테이블을 사용합니다. - 데이터는 다음 기준으로 세분화됩니다. - 기기 모델 - 소프트웨어 버전 - 특정 기능 또는 역량 지원 여부 - 전체 활성 기기 중 특정 역량을 지원하는 기기의 비율을 계산할 수 있습니다. - 예를 들어 스트리밍 스틱에 연결된 외부 디스플레이 역량을 분석할 때 다음과 같이 확인할 수 있습니다. - 전체 기기의 100%가 HD용 `playready` 프로필 지원 - 전체 기기의 20%만 UHD용 `hevc` 프로필 지원 - 단순히 “기기 모델이 기능을 지원한다”는 정보가 아니라, 실제 사용 중인 기기 집단에서 해당 기능이 어느 정도 보급되어 있는지 파악할 수 있다는 점이 중요합니다. ## 기능 플래그와 분석 제품의 결합 - 기기 역량 데이터는 내부 시스템의 기능 플래그와 통합됩니다. - 이를 통해 특정 기기 모델이나 소프트웨어 버전에만 기능을 활성화하는 세밀한 제어가 가능합니다. - 분석 제품은 다음 기능의 도달 범위를 파악하는 데 활용됩니다. - 4K Ultra HD - Netflix Spatial Audio - 클라우드 게임 - 최신 사용자 인터페이스 - 실제 기기 지원률과 성능 데이터를 기반으로 기능을 활성화하므로 안정성과 성능을 함께 고려할 수 있습니다. ## 기대 효과 - 기능이 지원되지 않는 기기에 잘못 배포되는 문제를 줄일 수 있습니다. - 특정 기기나 소프트웨어 버전에서 발생하는 기능 확산의 병목을 식별할 수 있습니다. - 기능 출시 전 지원 가능한 사용자 규모를 예측할 수 있습니다. - 전 세계의 다양한 기기 생태계에 맞춰 기능을 점진적이고 안전하게 확장할 수 있습니다. 실무적으로는 기기별 최신 상태와 실제 활성 기기 분포를 분리해 관리하고, 이를 기능 플래그와 연결하는 방식이 효과적입니다. 특히 기능 지원 여부뿐 아니라 실제 사용자 기기 중 지원 기기의 비율까지 함께 분석해야 기능 출시 범위와 우선순위를 정확하게 결정할 수 있습니다.

원문 읽기(새 탭에서 열림)

data-modelingvideo-streamingcloud-gamingfeature-flags+2

netflix·2026년 7월 30일·5분 읽기큐레이션 요약

GenRec: 넷플릭스에서 LLM 네이티브 추천을 향하여

Netflix의 GenRec은 사용자 이력과 콘텐츠 메타데이터를 자연어로 표현하고, Netflix에 맞게 후처리 학습한 LLM을 추천 랭커로 활용하는 시스템이다. 기존의 대규모 수작업 피처와 특화 아키텍처 의존도를 줄이면서도, 카탈로그 인식 점수 헤드와 보상 신호를 통해 개인화·장기 사용자 가치·비즈니스 제약을 반영한다. 대규모 A/B 테스트에서 기존 랭커보다 단기 및 장기 지표를 유의미하게 개선했으며, 더 적은 라벨 데이터와 입력 신호만으로도 경쟁력 있는 성능을 보였다. ## 기존 추천 시스템의 복잡성과 LLM의 가능성 - Netflix의 기존 모델은 사용자·아이템·상호작용에 대한 수천 개의 수작업 피처를 사용한다. - 시퀀스 모델링, 피처 상호작용, 멀티태스크 학습 등 다양한 특화 구조가 콘텐츠 유형과 제품 화면별로 구축되어 있다. - 새로운 콘텐츠 유형이나 추천 화면을 추가하려면 피처 설계, 모델 구조, 인프라, 실험을 함께 변경해야 한다. - LLM은 사용자 이력과 아이템 정보를 텍스트로 통합하고, 자연어 기반의 의미 관계와 추천 조건을 표현할 수 있다. - 하지만 일반 LLM은 인기 콘텐츠 편향, 카탈로그에 없는 아이템 생성, 비즈니스 제약 무시, 부족한 개인화 등의 문제가 있다. ## GenRec의 추천 문제 정의 - 사용자 \(u\), 컨텍스트 \(\tau\), 시간 \(t\), 상호작용 이력 \(H\)를 입력으로 받아 Netflix 전체 카탈로그 \(C\)의 순위 \(\pi\)를 생성한다. - 컨텍스트에는 기기, 화면, 지역, 시간 등이 포함된다. - 후보군이 주어지면 Top-K 순위를 만들고, 후보군이 없으면 전체 카탈로그를 대상으로 순위를 계산한다. - 단순 클릭이나 재생 수가 아니라 만족도와 유지율을 대변하는 장기적 회원 효용을 최적화한다. ## 2단계 학습 구조 ### Netflix 맞춤형 기반 LLM - 오픈소스 LLM을 Netflix의 독점 데이터로 적응시킨다. - Netflix 콘텐츠 이해, 회원 행동과 선호 패턴, 일반적인 언어 이해 능력을 학습한다. - 여러 애플리케이션이 공유하는 Netflix 인식 기반 모델로 사용된다. - 콘텐츠 변화에 맞춰 자주 갱신하기보다는 비교적 드물게 업데이트된다. ### GenRec 후처리 학습 - 기반 LLM을 추천 순위화와 제어에 특화된 모델로 전환한다. - 랭킹 데이터와 복수의 보상 신호를 사용한다. - 새로운 콘텐츠와 변화하는 취향을 반영하기 위해 더 자주 갱신한다. - Netflix의 LLM 서빙 비용과 지연시간을 고려해 최적화한다. ## 상호작용 로그를 대화 데이터로 변환 - Netflix의 조회, 재생 시간, 좋아요·싫어요, 찜하기, 중단 등 방대한 이벤트를 추천 대화 형식으로 변환한다. - 사용자 메시지에는 다음 정보가 포함된다. - 현재 화면과 기기 같은 컨텍스트 - 사용자 프로필과 과거 이력 - 아이템 메타데이터 - “다음에 시청하거나 좋아요를 누를 콘텐츠를 추천하라”와 같은 과제 - 어시스턴트 메시지에는 실제 회원 행동이 기록된다. - 어떤 콘텐츠를 재생했는지 - 얼마나 오래 시청했는지 - 어떤 피드백을 남겼는지 - 학습 시에는 언어 모델링과 추천 랭킹을 함께 지원하지만, 추론 시에는 답변 텍스트를 생성하지 않는다. - 실제 서비스에서는 verbalized context를 입력하고, 별도의 카탈로그 인식 점수 헤드로 콘텐츠를 정렬한다. ## 피처 엔지니어링에서 컨텍스트 엔지니어링으로 - 기존 추천 시스템이 밀집 벡터와 수작업 피처를 중심으로 한다면, GenRec은 이력과 상황을 자연어로 변환해 LLM의 의미 공간에 입력한다. - 모델이 아이템 간 관계, 반복 시청, 변화하는 관심사 같은 고차원 패턴을 직접 학습하도록 한다. - 모든 상호작용을 그대로 입력하면 토큰 한도와 비용 문제가 발생하므로, 컨텍스트를 선별하고 압축한다. - 긴 재생이나 긍정 피드백처럼 신호가 강한 이벤트는 자세히 유지 - 짧은 재생이나 빠른 탐색처럼 신호가 약한 이벤트는 제거 - 폭주 시청처럼 반복적인 행동은 요약 - 신작이나 콜드스타트 아이템은 필요한 경우 더 자세히 설명 - 제한된 토큰 예산 안에서 최근성과 신호 강도가 높은 이력을 우선한다. - 프롬프트의 공통 접두사를 늘려 prefix caching을 활용하고, 서빙 비용을 낮춘다. - 결과적으로 모델 개발의 초점이 개별 피처 제작에서 정보 밀도 높은 입력 문맥 설계로 이동한다. ## 랭킹·언어·보상 신호를 결합한 학습 ### 카탈로그 인식 랭킹 목표 - 충분히 긴 재생이나 강한 명시적 피드백처럼 가치가 높은 참여를 긍정 샘플로 사용한다. - 임계값과 노이즈 제거 로직으로 부정확한 행동 신호를 정제한다. - 전체 카탈로그 또는 후보군에 대한 cross-entropy 손실을 사용해 긍정 아이템의 점수를 높인다. - 자유로운 텍스트 생성이 아니라 실제 Netflix 카탈로그 안에서 점수를 계산하므로, 존재하지 않는 콘텐츠를 추천하는 문제를 줄인다. ### 언어 모델링 목표 - 입력과 출력의 텍스트에 대해 언어 모델링 목표를 유지한다. - 자연어로 표현된 사용자 이력과 콘텐츠 메타데이터를 이해하는 능력을 보존한다. - 향후 추천 이유나 설명 생성과 같은 텍스트 기반 기능으로 확장할 가능성도 유지한다. ### 보상 기반 정렬 - 단기 클릭이나 재생만 최적화하지 않고 장기적인 회원 만족도를 반영한다. - 영화, 시리즈, 게임, 라이브, 팟캐스트 등 콘텐츠 유형 간 균형 같은 비즈니스 요구사항을 고려한다. - 여러 보상 신호를 보상 가중 손실에 반영해 랭킹 결과가 Netflix의 장기 목표와 맞도록 조정한다. ## 서빙 효율성과 성능 - GenRec은 Netflix의 LLM 서빙 스택에서 prefill-only 방식으로 실행된다. - 추론 시 토큰을 생성하지 않고 입력을 처리해 아이템별 점수를 계산하므로 생성형 LLM보다 비용 효율적이다. - 기존의 성숙한 프로덕션 랭커와 비교한 대규모 A/B 테스트에서 단기 및 장기 온라인 지표를 모두 통계적으로 개선했다. - Phase 2 학습에 필요한 라벨 데이터와 입력 신호도 기존 시스템의 일부만 사용했다. 실무적으로는 LLM을 추천 시스템에 도입할 때 모든 로그를 무작정 텍스트화하기보다, 카탈로그 제약을 보장하는 점수 헤드, 장기 보상 설계, 토큰 예산 관리, 캐싱 전략을 함께 설계하는 것이 중요하다. GenRec의 사례는 추천 모델의 성능뿐 아니라 피처 유지보수 비용과 새로운 추천 시나리오의 확장성까지 고려할 때 LLM 기반 구조가 유효할 수 있음을 보여준다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델자연어 처리recommendation-systemsreinforcement-learning+2

netflix·2026년 7월 17일·5분 읽기큐레이션 요약

넷플릭스의 사내 LLM 서빙

Netflix는 LLM을 별도 ML 시스템이 아니라 기존 JVM 기반 서빙 플랫폼과 GPU 추론 백엔드 안에서 운영한다. 엔진으로는 vLLM을 선택하고, Triton·OpenAI 호환 API·통합 배포 제어 plane을 결합해 연구에서 운영까지의 전환 비용을 낮췄다. 다만 운영 환경에서는 엔진 버전 불일치, 커스텀 모델 처리, JSON 제약 누락, 모델 버전과 입력 스키마 변경 간 조정 문제가 주요 리스크로 드러났다. ## Netflix의 통합 추론 아키텍처 - 통합 JVM 서빙 시스템이 라우팅, A/B 테스트, 후보 생성, feature 조회, 추론, 후처리, 로깅을 end-to-end로 처리한다. - 실시간 요청과 캐시된 배치 경로를 모두 지원한다. - 호출 방식은 다음 두 가지다. - 기존 서빙 시스템을 통한 gRPC - 최신 LLM 애플리케이션을 위한 직접 HTTP - 소형 CPU 모델은 원격 호출 비용을 피하기 위해 서빙 프로세스 내부에서 실행한다. - 대형 GPU 모델은 Model Scoring Service(MSS)로 추론을 위임한다. - MSS는 XGBoost, TensorFlow, PyTorch, LLM을 동일한 인터페이스로 제공하며, 내부 GPU 실행은 NVIDIA Triton Inference Server가 담당한다. - Java 기반 control plane은 모델 배포, 버전 관리, 상태 점검, 자동 확장, 멀티리전 롤아웃과 무중단 업그레이드를 관리한다. ## vLLM을 표준 추론 엔진으로 선택 Netflix는 원래 Triton과 통합된 TensorRT-LLM을 사용했지만, 2025년경 워크로드 변화에 맞춰 재평가했다. - 임베딩 생성, prefill-only 추론, autoregressive decoding, 복잡한 제약 로직이 필요한 커스텀 모델까지 지원해야 했다. - vLLM을 선택한 이유: - 별도의 다단계 컴파일 없이 커스텀 모델 아키텍처 로딩 가능 - 커스텀 디코딩 로직을 위한 확장 지점 제공 - 컴파일 중심 엔진보다 장애와 중간 상태를 디버깅하기 쉬움 - 연구자들이 이미 익숙하게 사용해 연구-운영 전환 비용이 낮음 - 전문화된 엔진과 오픈소스 엔진 간 성능 격차가 줄어든 점도 선택에 영향을 주었다. ## Triton과 vLLM의 패키징 방식 Triton에서 vLLM 모델을 패키징하는 방식은 유지보수성과 프론트엔드 변경의 결합도에 큰 영향을 준다. - **Python backend** - 패키징 시 입력·출력 tensor 스펙을 직접 정의한다. - 프론트엔드의 요청 생성 방식이 바뀌면 패키징 코드도 함께 수정해야 한다. - 변경이 맞물리지 않으면 런타임 요청이 실패한다. - 전처리, 후처리, 앙상블, 커스텀 토크나이징 등 비표준 로직이 필요한 모델에는 적합하다. - **vLLM backend** - 모델 가중치와 tokenizer 경로를 담은 JSON 설정만 제공한다. - Triton이 배포 시점에 I/O tensor 스펙을 동적으로 생성한다. - 모델 아티팩트와 프론트엔드를 독립적으로 발전시킬 수 있어 기본 선택으로 적합하다. ### 운영에서 드러난 패키징 문제 - Triton의 vLLM backend는 특정 vLLM API에 맞춰 컴파일된다. - 예를 들어 Triton 25.09가 vLLM 0.11.2에서 제거된 `vllm.engine.metrics`를 import하면 backend 자체가 로드되지 않는다. - 따라서 서비스 이미지 생성 시 Triton과 vLLM 호환 버전을 고정해야 한다. - 모델 작성자가 패키징 단계에서 vLLM 버전을 임의로 덮어쓰지 못하도록 제한할 필요가 있다. - 표준 HuggingFace 모델이 아닌 커스텀 실행 흐름은 여전히 Python backend를 사용해야 한다. ## OpenAI 호환 HTTP API Netflix는 LLM을 기존 모델과 다른 “특수 모델”로 취급하지 않기 위해 모든 모델을 동일한 gRPC 호출 체계로 제공한다. - 기존 클라이언트 라이브러리, 상태 점검, 배포 파이프라인을 LLM에도 재사용한다. - 동시에 생태계 표준이 된 OpenAI 호환 API를 추가 HTTP 프론트엔드로 제공한다. - 호스팅 모델에서 자체 파인튜닝 모델로 전환할 때 API를 그대로 유지할 수 있다. - 이에 따라 품질, 지연시간, 비용, 데이터 프라이버시를 이유로 자체 호스팅을 선택해도 애플리케이션 코드 변경이 거의 없다. ## Triton 프론트엔드와 JSON 출력 제약 구현에는 NVIDIA의 Triton OpenAI 호환 프론트엔드를 활용했다. - 내장 Triton 서버가 실행된다. - `TritonLLMEngine`이 HTTP 요청 스키마를 Triton 추론 요청으로 변환한다. - FastAPI를 통해 응답을 제공한다. - KServe HTTP/gRPC 프론트엔드도 활성화해 Java control plane이 동일한 Triton 인스턴스에 gRPC로 접근할 수 있다. - 운영 중 `response_format`이 스키마에서는 허용되지만 vLLM까지 전달되지 않는 문제가 발견됐다. - 그 결과 JSON 응답을 요청해도 guided decoding이 적용되지 않아 잘못된 JSON이 반환될 수 있었다. - Netflix는 프론트엔드를 git subtree로 가져와 `response_format`을 vLLM의 guided decoding 파라미터로 변환하도록 직접 패치했다. ## 무중단 배포와 스키마 변경 문제 GPU 모델은 CPU 서비스보다 기동 시간이 길고, 모델 버전 사이에 I/O 스키마가 달라질 수 있어 배포 시 추가 조정이 필요하다. ### Red-Black 배포 - 새 버전을 기존 버전과 동시에 실행한다. - 새 인스턴스가 health check를 통과하면 트래픽을 단계적으로 이동한다. - 새 버전이 확장되는 속도만큼 기존 버전을 축소한다. - 중간 단계에서 실패하면 원자적으로 롤백한다. - 모델 인터페이스가 안정적인 경우 적합하다. - 하지만 입력 tensor 차원 추가처럼 I/O 스키마가 바뀌면 문제가 생긴다. - upstream 소비자는 새 모델이 완전히 배포되기 전까지 설정을 바꿀 수 없다. - 마이그레이션 중 새 모델에 이전 형식 요청이 전달된다. - 결과적으로 요청이 실패한다. 제공된 글은 Red-Black 방식의 한계와 `Versioned` 배포 전략을 설명하기 시작한 지점에서 끝나므로, Versioned 전략의 구체적인 동작과 장단점은 확인할 수 없다. 실무적으로는 vLLM을 표준 경로로 삼되, Triton·vLLM 버전을 강하게 고정하고 Python backend라는 예외 경로를 유지하는 것이 현실적이다. 또한 OpenAI 호환 API를 도입할 때는 스키마가 실제 추론 엔진의 제약 기능까지 전달되는지 검증하고, 모델 배포와 입력 스키마 변경을 독립적으로 조정할 수 있는 버전 관리 전략을 마련해야 한다.

원문 읽기(새 탭에서 열림)

grpcvllmgpu-inferencefastapi+4

netflix·2026년 7월 14일·4분 읽기큐레이션 요약

대규모 서비스 토폴로지 구축: 아키텍처, 도전 과제, 그리고 얻은 교훈

넷플릭스는 장애 대응과 변경 영향 분석을 위해 실시간 서비스 의존성 지도를 구축했으며, 이를 위해 배치가 아닌 스트리밍 중심 아키텍처를 선택했다. 시스템은 eBPF 네트워크 흐름, IPC 메트릭, 분산 추적 데이터를 물리적으로 분리된 계층에 저장하고, 필요할 때 통합해 제공한다. 대규모 트래픽에서도 안정적으로 동작하기 위해 백프레셔와 분산 집계 파이프라인을 적용했으며, 약간의 지연을 허용하는 대신 데이터 손실과 시스템 장애를 방지했다. ## 실시간 서비스 토폴로지가 필요한 이유 - 기존의 시간별·일별 배치 방식은 데이터가 생성될 때 이미 오래된 상태가 된다. - 장애 대응 시 한 시간 전의 의존성 지도는 현재의 장애 원인과 영향 범위를 정확히 보여주기 어렵다. - 실시간 변경 검증과 장애 분석을 위해 지속적인 데이터 수집과 갱신이 필요하다. - 넷플릭스의 시스템은 일반적으로 수십 분 이내에 토폴로지 정보를 갱신하는 것을 목표로 한다. ## 스트리밍 중심 아키텍처 - 여러 리전의 Kafka 스트림에서 네트워크 흐름 데이터를 지속적으로 수집한다. - IPC 메트릭은 Server-Sent Events(SSE) 형태로 전달하고, 반응형 파이프라인에서 처리한다. - 배치 처리처럼 완전한 스냅샷을 기다리지 않고, 데이터가 도착하는 즉시 토폴로지를 갱신한다. - 대규모 트래픽을 처리하면서도 처리 지연이 누적되지 않도록 스트리밍 처리와 부하 제어를 함께 설계했다. ## 백프레셔를 통한 안정적인 부하 제어 - 단순한 무제한 큐는 트래픽이 급증할 때 메모리를 고갈시키고 인스턴스 장애를 일으킬 수 있다. - 버퍼가 가득 찼을 때 데이터를 버리는 방식은 연결 정보가 사라져 토폴로지가 불완전해진다. - 배치 방식은 데이터를 보존할 수 있지만, 장애가 끝난 뒤에야 결과를 확인하게 될 수 있다. - 백프레셔는 하위 단계의 처리 속도에 맞춰 상위 단계가 자동으로 속도를 줄이는 방식이다. - 그래프 데이터베이스가 느려지면 Stage 2가 Stage 1에 감속을 요청한다. - 감속 신호는 Kafka 소비자까지 전파된다. - Kafka에 데이터가 남아 있으므로 처리 능력이 회복된 뒤 이어서 처리할 수 있다. - GC 일시정지, 외부 저장소 지연, 트래픽 급증 상황에서도 시스템이 중단되거나 데이터를 대량으로 버리지 않고 점진적으로 느려진다. - 실시간성이 몇 초 또는 몇 분 늦어지는 대신, 시간 단위로 오래된 데이터나 누락된 토폴로지를 피할 수 있다. - 반응형 스트림은 전통적인 동기식 처리보다 이해하고 운영하기 어렵지만, 넷플릭스 규모에서는 안정성을 위한 필수 요소로 평가된다. ## 데이터 소스별 물리적 토폴로지 계층 넷플릭스는 서로 다른 특성을 가진 데이터를 하나의 저장소에 억지로 통합하지 않고, 세 개의 계층으로 분리했다. - **네트워크 계층** - eBPF 기반 네트워크 흐름 로그를 그래프 데이터베이스에 저장한다. - 서비스 간 연결을 폭넓게 포착하지만 애플리케이션 수준의 상세한 맥락은 부족하다. - **IPC 계층** - 애플리케이션 메트릭을 별도의 그래프 데이터베이스에 저장한다. - 엔드포인트 정보가 풍부하지만 계측된 서비스만 포함한다. - **트레이싱 계층** - 분산 추적 데이터를 Parquet 기반 컬럼형 저장소에 저장한다. - 실제 요청 경로를 보여주지만 샘플링으로 인해 전체 트래픽을 대표하지 않을 수 있다. - 각 계층을 물리적으로 분리하면 처리량, 쿼리 패턴, 데이터 발전 주기에 맞춰 독립적으로 최적화할 수 있다. - 쿼리 시에는 필요한 저장소에 병렬 질의한 뒤 결과를 병합해 통합된 서비스 뷰를 제공한다. ## 네트워크 중간 장비를 해결하는 분산 집계 파이프라인 네트워크 흐름 로그는 실제 서비스 의존성이 아니라 개별 네트워크 홉만 보여주는 문제가 있다. - 실제 경로가 `App A → 로드 밸런서 → App B`라면 흐름 로그에는 두 개의 별도 연결로 기록된다. - 이 데이터를 그대로 시각화하면 서비스 대신 로드 밸런서, NAT 게이트웨이, API 게이트웨이, 프록시 같은 인프라 컴포넌트가 중심에 나타난다. - 따라서 여러 홉을 분석해 논리적인 `App A → App B` 의존성으로 재구성해야 한다. - 이를 위해 네트워크 계층 수집은 세 단계의 분산 집계 파이프라인으로 구성된다. ### Stage 1: 초기 집계 - 네 개 리전의 Kafka에서 흐름 로그를 소비한다. - 잘못된 흐름 로그를 필터링한다. - 5분 단위 시간 창으로 데이터를 묶는다. - 각 시간 창마다 초기 집계 객체를 생성한다. - 일관성 해싱을 사용해 집계 대상을 분산한다. - 생성된 집계 결과를 SSE를 통해 Stage 2로 스트리밍한다. - 이 단계에서는 중간 장비가 포함된 네트워크 홉을 식별하지만, 최종적인 서비스 간 연결은 아직 확정하지 않는다. ## 대규모 분산 시스템에서 얻은 설계 교훈 - 실시간 처리는 단순히 빠르게 처리하는 문제가 아니라, 느려지는 상황에서도 시스템을 무너지지 않게 만드는 문제다. - 데이터 손실보다 일시적인 지연을 선택하는 것이 서비스 토폴로지와 장애 분석에는 더 적합할 수 있다. - 서로 다른 데이터의 특성이 뚜렷하다면 저장소와 처리 계층을 분리하고, 조회 시 통합하는 편이 확장성과 독립적인 최적화에 유리하다. - 로컬 환경에서 정상 동작하는 구현도 운영 환경에서는 Kafka 지연, 메모리 부족, 트래픽 편중, GC 비용 등으로 쉽게 한계에 도달할 수 있다. - 따라서 대규모 시스템은 초기 설계뿐 아니라 부하 상황에서의 관찰, 병목 측정, 단계별 최적화 방법론이 중요하다. 실용적으로는 스트리밍 파이프라인을 구축할 때 무제한 버퍼나 무조건적인 데이터 삭제보다 백프레셔를 우선 고려하는 것이 좋다. 또한 서로 다른 품질과 용도를 가진 데이터 소스를 하나의 모델로 통합하기보다, 각 소스에 맞는 저장 계층을 유지하고 조회 단계에서 결합하는 방식이 운영 유연성을 높인다.

원문 읽기(새 탭에서 열림)

Apache Kafkaebpfgraph-databasedistributed-tracing+4

netflix·2026년 6월 29일·4분 읽기큐레이션 요약

GenPage: 넷플릭스의 엔드투엔드 생성형 홈페이지 구축을 향해

Netflix의 **GenPage**는 기존의 다단계 추천 파이프라인 대신, 하나의 생성형 Transformer가 사용자·요청 맥락을 입력으로 받아 홈페이지 전체를 한 번에 생성하는 방식이다. 행(row), 콘텐츠(entity), 배치(layout)를 함께 생성하므로 페이지 전체의 사용자 만족도와 콘텐츠 간 상호작용을 최적화할 수 있다. 실제 A/B 테스트에서 기존 운영 시스템보다 핵심 참여 지표를 유의미하게 개선했고, 전체 서빙 지연 시간도 20% 줄였다. ## 홈페이지 전체를 생성하는 GenPage - 기존 Netflix 홈페이지는 다음 요소를 별도 단계에서 처리했다. - 어떤 추천 행을 노출할지 결정 - 각 행 안의 콘텐츠 후보 생성 및 랭킹 - 행과 콘텐츠의 최종 배치 - GenPage는 사용자 이력과 요청 맥락을 프롬프트처럼 사용하고, 홈페이지 전체를 자기회귀적으로 생성한다. - 일반적인 생성형 추천기가 평평한 콘텐츠 목록만 생성하는 것과 달리, GenPage는 다음을 함께 생성한다. - 추천 행 - 각 행의 콘텐츠 - 페이지 내 배치 순서와 구조 ## 다단계 추천 시스템에서 엔드투엔드 모델로 - 하나의 Transformer가 원시 입력 신호에서 최종 페이지를 만들기 때문에 여러 모델 간 목표 불일치를 줄일 수 있다. - 후보 생성, 행 랭킹, 콘텐츠 랭킹 등 여러 모델을 유지·운영해야 하는 부담이 감소한다. - 기존의 복잡한 특성 공학(feature engineering)을 줄이고, 데이터·연산량·모델 규모를 늘려 성능을 개선하기 쉬운 구조를 제공한다. - 새로운 콘텐츠 유형이나 UI를 도입할 때 아키텍처를 크게 바꾸지 않고 확장할 수 있다. - 라이브 이벤트 - 게임 - 팟캐스트 - 개인화된 UI 컴포넌트 - 콘텐츠별 개인화 아트워크 ## 페이지 단위 최적화와 강화학습 - 기존 시스템은 주로 개별 콘텐츠나 행의 클릭·시청 가능성을 최적화한다. - GenPage는 페이지 전체를 생성하므로 행과 콘텐츠 사이의 상호작용을 페이지 보상으로 학습할 수 있다. - 예를 들어 상단의 ‘Continue Watching’ 행은 즉각적인 만족도를 높일 수 있지만, 사용자가 다른 행을 탐색하는 양은 줄일 수 있다. - 강화학습(RL)을 적용하면 다음과 같은 전체 페이지 수준의 효과를 고려할 수 있다. - 콘텐츠 다양성 - 여러 행의 탐색성과 시청 유도력 간 균형 - 사용자 만족도와 페이지 탐색량의 trade-off - 흥미롭게도 오프라인 평가에서는 다양성을 직접 보상 목표에 포함하지 않았음에도 RL 후처리 학습 이후 홈페이지 다양성이 증가했다. ## 홈페이지 데이터를 토큰 시퀀스로 표현 - 각 학습 샘플은 홈페이지 노출 한 번을 나타내며 다음 세 요소로 구성된다. - **Context**: 사용자 행동 이력, 프로필 속성, 요청 맥락 - **Page**: 실제 노출된 추천 행과 콘텐츠, 레이아웃 순서 - **Feedback**: 재생, 좋아요, 이탈 등 사용자 반응 - Context와 Page는 모델 입력·출력으로 토큰화한다. - Feedback은 직접 생성하는 대상이 아니라 내부 보상 시스템을 통해 학습 신호로 변환한다. - 결과적으로 모델은 일반 텍스트가 아닌, 구조화된 홈페이지 표현을 생성한다. ## 도메인 특화 토크나이저 - 일반적인 LLM용 텍스트 토크나이저 대신 Netflix 추천 도메인에 맞춘 전용 토크나이저를 사용한다. - 예를 들어 “사용자가 30일 전에 특정 작품을 50분 시청했다”는 이벤트를 다음과 같이 압축할 수 있다. - 엔터티 ID - 행동 유형 - 시간 구간 - 시청 지속시간 구간 - 일반 GPT 계열 토크나이저로 16개 토큰이 필요한 정보를 4개 토큰으로 표현할 수 있어 시퀀스 길이와 추론 비용을 줄인다. - 행과 콘텐츠가 특정 토큰과 직접 대응하므로 제품·비즈니스 규칙을 적용하기도 쉽다. - 생성 결과에 허용되지 않는 콘텐츠나 구조가 포함되지 않도록 제어할 수 있다는 점도 장점이다. ## 사용자 맥락 토큰 - 사용자 행동 이력은 다음 메타데이터를 포함한 행동 시퀀스로 표현한다. - 행동 유형 - 콘텐츠 ID - 발생 시점 - 행동 지속시간 - 명시적 신호와 암묵적 신호를 모두 포함한다. - 명시적 신호: 재생, ‘My List’ 추가, 좋아요 - 암묵적 신호: 예고편 시청, 상세 페이지 방문 - 사용자 프로필에는 언어, 프로필 유형 등을 넣는다. - 요청 맥락에는 시간대, 요일, 사용 기기 등의 정보를 포함한다. - 전체 노출 이력처럼 지나치게 긴 데이터는 요약해서 사용한다. - 이 요약 과정은 모델이 원시 데이터를 완전히 직접 학습하는 대신 사람이 설계한 프롬프트 엔지니어링을 일부 남긴다는 한계가 있다. - 장기적으로는 긴 이력을 엔드투엔드 방식으로 압축하는 것이 중요한 연구 과제다. ## 운영 환경의 주요 과제 - 홈페이지를 실시간 생성해야 하므로 서빙 지연 시간이 핵심 제약이다. - 계속 변화하는 콘텐츠 카탈로그에서 신규 콘텐츠의 콜드 스타트 문제를 해결해야 한다. - 사용자의 관심사와 문화적 트렌드 변화에 맞춰 모델을 지속적으로 최신화해야 한다. - 생성 결과에도 콘텐츠 정책, 제품 요구사항, 비즈니스 규칙을 적용해야 한다. - Netflix는 이러한 제약을 고려하면서도 운영 환경에 GenPage를 적용했다. ## 실험 및 운영 결과 - 성숙하고 최적화된 기존 다단계 추천 시스템과 비교한 온라인 A/B 테스트에서: - 출시 판단에 사용하는 핵심 사용자 참여 지표가 통계적으로 유의미하게 향상됐다. - 전체 엔드투엔드 서빙 지연 시간이 20% 감소했다. - 오프라인 분석에서는 모델 규모를 키우는 것보다 프롬프트에 더 풍부한 정보를 넣는 것이 현재 조건에서 더 큰 효과를 보였다. - 강화학습은 명시적으로 다양성을 최적화하지 않았음에도 페이지 다양성을 높였다. GenPage는 홈페이지를 개별 콘텐츠의 집합이 아니라 하나의 최적화 대상인 페이지로 다룬다는 점에서 의미가 있다. 다만 실시간 지연, 신규 콘텐츠, 최신성, 생성 결과 제어가 핵심 과제이므로, 실제 도입 시에는 도메인 특화 토큰화와 강력한 규칙 검증 계층을 함께 설계하는 것이 현실적인 접근이다.

원문 읽기(새 탭에서 열림)

생성형 AItransformerreinforcement-learningpersonalization+2

netflix·2026년 6월 23일·5분 읽기큐레이션 요약

더욱 정교하게 제어할 수 있는 AI 영상 편집을 향해: 넷플릭스의 초기 연구 탐색

넷플릭스는 AI가 영상 전체를 무분별하게 재생성하지 않고, 창작자가 지정한 부분만 정밀하게 수정해야 전문적인 영상 편집에 활용될 수 있다고 주장합니다. 이를 위해 편집 영역만 별도 레이어로 생성하는 Vera와, 객체를 제거한 뒤 물리적으로 자연스러운 장면을 복원하는 VOID를 제안했습니다. 두 연구의 목표는 원본 영상의 정체성·연기·배경을 보존하면서도 복잡한 편집 작업을 자동화해 창작자의 통제력을 높이는 것입니다. ## 전문 영상 편집에서 AI가 겪는 문제 - 기존 생성형 비디오 편집 모델은 수정 대상뿐 아니라 영상 전체의 픽셀을 다시 생성하는 경우가 많습니다. - 그 결과 다음과 같은 의도하지 않은 변화가 발생할 수 있습니다. - 인물의 얼굴이나 정체성 변화 - 배우의 연기와 동작 변형 - 배경, 소품, 장면의 세부 정보 훼손 - 객체 제거 모델은 대상 객체를 지우는 데 집중한 나머지, 객체가 장면의 물리적 상호작용에 미친 영향을 복원하지 못할 수 있습니다. - 그림자, 반사, 가려진 배경, 움직임의 연속성이 깨지면 객체를 제거한 결과가 부자연스럽게 보입니다. ## Vera: 편집 영역만 생성하는 레이어드 비디오 확산 모델 - Vera는 원본 영상 전체를 재생성하지 않고 다음 두 가지를 별도로 생성합니다. - **편집 레이어**: 새로 추가하거나 변경할 시각적 요소 - **알파 매트**: 편집 레이어가 적용될 영역을 나타내는 grayscale 마스크 - 생성된 레이어를 원본 영상과 합성하므로, 편집 영역 바깥의 원본 픽셀은 그대로 유지됩니다. - 텍스트 지시를 기반으로 다음과 같은 작업을 지원합니다. - 객체 추가 - 배경 변경 - 복잡한 장면의 시각적 요소 수정 - 이 방식은 원본 인물의 정체성, 연기, 카메라에 포착된 세부 사항을 보존하는 데 유리합니다. ## Vera의 학습 데이터 구축 - 기존 공개 데이터셋에는 깨끗한 입력 영상, 알파 매트, 편집 레이어, 합성 결과를 함께 제공하는 고품질 레이어드 데이터가 부족했습니다. - 넷플릭스는 오픈소스 영상, 자동 처리, 사람의 품질 검수를 결합해 총 **48만 6천 프레임**, 해상도 **832×480** 규모의 데이터셋을 구축했습니다. - 데이터는 세 단계로 구성됩니다. - **합성 영상** - 고품질 전경 알파 매트를 다양한 자동 생성 배경에 합성 - 객체 추가와 배경 변경을 위한 알파 매트 학습에 활용 - **현실적인 단일 객체 영상** - 분할, 매팅, 배경 인페인팅 또는 생성 과정을 적용 - 사람의 품질 검수를 거쳐 다양한 장면과 카메라 움직임을 확보 - **효과가 포함된 다중 객체 영상** - 개별 객체와 함께 그림자·반사 같은 시각 효과도 분리 - 복잡하고 동적인 장면에서의 합성 성능을 개선 ## Vera의 MoT 모델 구조 - Vera가 생성해야 하는 출력은 서로 다른 특성을 가집니다. - 편집 레이어 - 알파 매트 레이어 - 자연스러운 합성 영상 레이어 - 하나의 공유 아키텍처만 사용하면 데이터 효율이 떨어질 수 있어, Vera는 **Mixture-of-Transformers(MoT)** 구조를 사용합니다. - 하나의 DiT 대신 출력별로 세 개의 DiT를 둡니다. - 각 분기는 독립적인 QKV projection과 FFN 가중치를 유지합니다. - 세 분기의 토큰을 결합한 뒤 joint self-attention을 적용해 서로 간의 상호작용을 가능하게 합니다. - 각 분기는 전문성을 유지하면서 다른 레이어의 정보도 활용합니다. - 세 DiT는 동일한 사전 학습 T2V 모델에서 초기화됩니다. - 추가 입력 처리 방식은 다음과 같습니다. - 원본 영상 토큰은 합성 레이어 토큰에 더해집니다. - 선택적 마스크 영상 토큰은 노이즈가 포함된 알파 토큰에 더해집니다. - 모든 레이어는 동일한 RoPE를 공유하며, 알파·합성 토큰에는 레이어를 구분하도록 0으로 초기화된 학습 임베딩을 추가합니다. ## Vera의 평가와 결과 - 평가용 벤치마크는 다음으로 구성되었습니다. - 객체 추가 72개 - 배경 변경 69개 - 느리고 빠른 움직임, 다양한 카메라 움직임, 단일·다중 객체, 단순·복잡한 장면을 포함합니다. - 성능은 세 기준으로 평가했습니다. - **콘텐츠 보존**: 편집 대상 바깥 영역이 변하지 않았는지 픽셀 및 지각적 유사도로 측정 - **지시문 준수**: 텍스트 프롬프트를 얼마나 정확히 실행했는지 평가 - **영상 품질**: 시간적 일관성과 프레임별 공간 품질 측정 - Vera-1.3B와 Vera-14B는 기존 기준 모델보다 콘텐츠 보존 성능에서 크게 우수했습니다. - 동시에 가장 강력한 기존 모델들과 비슷한 수준의 영상 품질과 지시문 준수 성능을 유지했습니다. ## VOID: 물리적으로 자연스러운 객체 제거 - VOID는 영상에서 객체와 객체가 장면에 미친 상호작용을 함께 제거하는 비디오 인페인팅 모델입니다. - 단순히 객체 영역을 지우는 것이 아니라 다음 요소까지 장면에 맞게 복원하는 것을 목표로 합니다. - 객체 뒤에 가려져 있던 배경 - 객체가 만든 그림자와 반사 - 주변 물체와의 물리적 상호작용 - 시간에 따른 움직임과 장면 연속성 - 따라서 결과 영상은 객체가 처음부터 존재하지 않았던 것처럼 보이도록 설계됩니다. ## 창작자 통제력을 중심에 둔 연구 방향 - 넷플릭스는 AI가 창작자의 의도를 대체하기보다 창작 선택을 확장해야 한다는 원칙을 강조합니다. - 영상 편집 도구는 무엇을 바꿀지뿐 아니라 무엇을 절대 바꾸지 않을지도 통제할 수 있어야 합니다. - Vera는 변경 범위를 레이어 단위로 제한하고, VOID는 제거 후 장면의 물리적 일관성까지 고려함으로써 전문 편집 환경에 필요한 예측 가능성과 보존성을 높이려는 접근입니다. - 연구진은 두 모델의 알고리즘과 실험 결과를 논문으로 공개해 후속 연구와 발전을 촉진하려 합니다. 실무적으로는 영상 전체를 재생성하는 방식보다, 편집 영역·보존 영역·합성 결과를 분리하는 구조가 원본 훼손을 줄이고 편집 결과를 더 쉽게 검수할 수 있습니다. 특히 객체 제거 작업에서는 시각적 삭제뿐 아니라 그림자, 반사, 가려진 배경, 시간적 움직임까지 함께 처리해야 자연스러운 결과를 얻을 수 있습니다.

원문 읽기(새 탭에서 열림)

생성형 AItransformercomputer-visiondiffusion-models+4

netflix·2026년 6월 22일·4분 읽기큐레이션 요약

넷플릭스는 Kueue로 배치 컴퓨팅을 어떻게 간소화했는가

Netflix는 기존 자체 배치 시스템인 CMB의 큐잉·스케줄링 기능을 Kubernetes 기반 오픈소스인 Kueue로 대체해 배치 컴퓨팅을 단순화했다. Kueue는 Titus의 기존 스케줄러를 유지하면서 멀티테넌트 용량 관리, 우선순위 큐, 선점, 공정 공유 등을 제공해 기능 확장과 Kubernetes 네이티브 전환을 지원했다. Netflix는 사용자 API와 경험을 그대로 유지한 채 수백만 개의 배치 작업을 이전했으며, 현재 Kueue를 프로덕션에서 완전히 운영하고 있다. ## CMB와 Titus의 기존 구조 - CMB(Compute Managed Batch)는 완료까지 실행되는 배치 작업을 제출·관리하는 Netflix의 관리형 서비스였다. - 작업은 테넌트 계층 구조에 따라 관리되며, 우선순위와 큐 순서에 따라 실행됐다. - Titus는 실제 작업 실행 플랫폼으로, 여러 Kubernetes 클러스터 또는 셀에 걸친 작업 배치와 용량 예약을 담당했다. - CMB는 단일 Titus 엔드포인트를 통해 클러스터 토폴로지를 직접 알지 않고도 작업과 용량 예약을 관리할 수 있었다. ## 테넌트 계층과 용량 관리 - **Internal Tenant** - 조직이나 애플리케이션 구조를 표현하기 위한 중간 노드다. - 직접 작업을 수용하지 않으며, 하위에 internal tenant나 leaf tenant를 둘 수 있다. - **Leaf Tenant** - 실제 작업을 제출할 수 있는 최종 테넌트다. - 큐를 가지며 하위 테넌트를 둘 수 없다. - **Reserved Capacity** - 내부 테넌트에서는 하위 트리 전체가 용량을 공정하게 공유한다. - 리프 테넌트에서는 특정 용량을 독점적으로 예약해 다른 테넌트가 해당 자원을 예약하지 못하도록 한다. - **Shared Capacity** - 모든 테넌트가 사용할 수 있는 전역 버스트 용량이다. - 기존 CMB에서는 작업이 승인된 뒤에는 선점되지 않았으므로, 이후 수요가 바뀌어도 작업이 끝까지 실행됐다. ## Kueue를 선택한 이유 - Kueue는 kube-scheduler를 대체하지 않으므로 Titus의 기존 스케줄링 프로파일과 통합할 수 있다. - YuniKorn이나 Volcano처럼 스케줄러 자체를 교체하면 작업 배치가 분산되어 효율이 저하될 수 있었다. - Kubernetes 생태계에서 빠르게 발전하고 있으며 채택 흐름도 강했다. - 서로 다른 하드웨어를 사용하는 환경에서 멀티테넌트 쿼터를 관리할 수 있다. - `v1.Pod`, `batch/v1.Job`뿐 아니라 RayJob, RayCluster 같은 고수준 리소스도 지원한다. - CMB에서 구현하기 어려웠던 기능을 기본 제공한다. - 선점(preemption) - 전체 작업 단위의 원자적 스케줄링(all-or-nothing scheduling) - 토폴로지 인지 스케줄링(topology-aware scheduling) ## Netflix Batch로의 마이그레이션 - 마이그레이션 프로젝트의 목표는 다음과 같았다. - CMB 사용자가 별도 작업을 하지 않아도 되는 투명한 이전 - 컨테이너 실행률과 전체 최대 처리량 유지 - CMB의 큐잉·스케줄링 로직을 Kueue로 대체 - 새로운 구조에서는 Kueue가 활성화된 Titus 셀에서 Kueue가 큐잉과 스케줄링을 담당한다. - Titus federation은 Netflix가 만든 Kueue router를 통해 작업을 적절한 Kueue 셀로 전달한다. - 운영자는 UI에서 테넌트의 마이그레이션 버튼을 누르는 것만으로 전환할 수 있으며, 문제가 발생하면 쉽게 롤백할 수 있었다. ## CMB 개념을 Kueue 리소스로 변환 - 기존 internal tenant는 Kueue의 **Cohort**로 변환됐다. - 기존 leaf tenant는 **ClusterQueue와 LocalQueue** 조합으로 변환됐다. - 테넌트의 용량 설정은 Kueue의 다음 개념으로 매핑됐다. - Resource Flavor - Nominal Quota - 이 구조를 통해 기존의 테넌트 계층과 용량 정책을 유지하면서 실제 큐 관리는 Kueue에 위임했다. ## 마이그레이션 과정에서 얻은 교훈 - 기존 API를 유지하고 내부 구현부터 교체하면 고객 경험을 바꾸지 않고 위험을 단계적으로 줄일 수 있다. - 가장 복잡한 사용 사례를 마지막으로 미루지 않는 것이 중요했다. - Netflix는 가장 크고 복잡한 고객을 초기에 이전했다. - 이를 통해 다른 고객의 이전 가능성을 검증했고, 실제 프로덕션 마이그레이션은 4주 만에 완료됐다. - 기본 설정만으로는 Netflix의 처리량을 감당할 수 없었다. - Kueue의 QPS, burst, `groupKindConcurrency` 값을 기본값보다 크게 조정해야 했다. - Titus와 유사한 개발 환경에서 부하 테스트를 일찍 수행해 성능 위험을 사전에 확인했다. ## 현재 운영 상태와 향후 방향 - Kueue는 Netflix 프로덕션에 완전히 배포되어 수백만 개의 배치 작업을 관리하고 있다. - Netflix는 더 많은 Titus 배치 작업을 Kueue 기반의 관리형 환경으로 편입할 계획이다. - 예약 용량 활용률을 높이기 위해 공정 공유와 선점 기능도 프로덕션 수준으로 확장했다. - 이러한 경험은 Kubernetes 네이티브 학습·트레이닝 인프라를 구축하는 다른 내부 팀의 작업 큐와 스케줄링 설정에도 활용되고 있다. Netflix의 사례는 기존 사용자 인터페이스와 실행 플랫폼을 유지하면서 큐잉 계층만 검증된 Kubernetes 구성 요소로 교체한 점이 핵심이다. 대규모 시스템에서는 한 번에 모든 것을 재작성하기보다 API 호환성, 단계적 전환, 조기 부하 테스트, 손쉬운 롤백을 함께 설계하는 접근이 실용적이다.

원문 읽기(새 탭에서 열림)

쿠버네티스container-orchestrationmulti-tenancykueue+4

netflix·2026년 6월 19일·4분 읽기큐레이션 요약

데이터 카나리아: 넷플릭스는 카탈로그 메타데이터를 어떻게 검증하는가

넷플릭스는 코드 변경이 없어도 카탈로그 데이터 자체가 손상되면 수백만 명의 재생 경험이 즉시 영향을 받을 수 있다는 점을 확인했다. 이에 실제 운영 트래픽으로 새 데이터 버전을 검증하는 데이터 카나리 시스템을 구축했고, 10분 이내에 문제를 감지해 배포를 차단한다. 핵심은 최종 변환 결과를 별도 카나리 클러스터에서 검증하고, 실제 재생 시도량을 기준으로 이상 여부를 빠르게 판단하는 것이다. ## 카탈로그 메타데이터 손상으로 발생한 장애 - 넷플릭스의 카탈로그 메타데이터는 타이틀, artwork, 제공 지역, 재생 가능 여부 등을 정의한다. - 과거 장애 대응 과정에서 실행된 수동 완화 조치가 데이터 피드를 비워 버렸고, 일부 타이틀의 메타데이터가 손상됐다. - 코드나 설정 변경이 없었기 때문에 기존 코드 카나리 배포는 문제를 감지하지 못했다. - 손상된 메타데이터로 manifest 생성이 실패하면서 카탈로그 서비스와 재생 기능에 장애가 발생했다. - 각 upstream 데이터 소스에는 검증 로직이 있었지만, 여러 입력을 변환한 최종 출력 상태의 오류까지는 잡지 못했다. ## 데이터 배포에 필요한 새로운 검증 방식 - 카탈로그 데이터는 여러 입력 피드를 지속적으로 변환하고 짧은 주기로 배포하는 고속 데이터 파이프라인이다. - 기존 카나리 분석 도구는 통계적 신뢰도를 확보하는 데 30~60분이 필요해 데이터 배포 주기와 맞지 않았다. - 입력 데이터가 정상이어도 변환 이후의 최종 상태에서 문제가 발생할 수 있으므로, 실제 클라이언트가 소비하는 출력물을 검증해야 했다. - shadow traffic은 카탈로그 서비스 요청만 재현할 뿐, 여러 서비스가 연동되는 전체 재생 과정을 검증할 수 없었다. - 운영 트래픽을 사용하되, 문제가 발생하면 고객 영향 범위를 즉시 제한할 수 있어야 했다. ## 전용 데이터 카나리 오케스트레이터 - 별도의 카나리 전용 클러스터와 오케스트레이터를 구축해 데이터 검증과 일반 서비스 운영을 분리했다. - **Baseline 클러스터** - 현재 운영 중인 최신 카탈로그 버전을 지속적으로 제공한다. - **Canary 클러스터** - 새 카탈로그 버전을 받아 검증한다. - **오케스트레이터** - baseline과 canary 클러스터의 상태 및 버전 동기화를 확인한다. - 조건이 충족되면 카오스 실험을 시작한다. - 실험 결과를 REST endpoint로 transformer 서비스에 전달한다. - 이 REST 기반의 일반화된 연동 지점 덕분에 다른 데이터 소스도 transformer 코드를 수정하지 않고 유사한 검증 패턴을 적용할 수 있다. ## 카오스 플랫폼을 활용한 실시간 검증 - 10분 이내 검증을 위해 기존 카오스 플랫폼을 확장하고, 실험 임계값을 데이터 카나리 목적에 맞게 조정했다. - 클라이언트 유형별로 트래픽 패턴과 downstream 의존성이 다르므로 주요 tenant마다 별도 실험을 수행했다. - 특히 playback 요청을 처리하는 tenant의 트래픽이 오류를 가장 빠르게 발견했다. - **Sticky canary** - 세션 affinity를 사용해 한 사용자의 트래픽이 실험 중 baseline 또는 canary 중 한쪽에만 계속 연결되도록 한다. - 두 데이터 버전의 결과가 섞이는 것을 막아 공정한 비교가 가능하다. - 기술 지표보다 실제 사용자 행동에 가까운 **Starts Per Second(SPS)** 를 핵심 지표로 사용했다. - 메타데이터 오류는 카탈로그 서비스의 latency나 error rate를 높이지 않고도 재생 시도 자체를 감소시킬 수 있기 때문이다. - 통계 수집이 끝날 때까지 기다리지 않고, 실시간으로 지표를 스트리밍하며 회귀가 감지되는 즉시 실험을 중단한다. - 이는 통계적 확실성을 일부 줄이는 대신, 짧은 배포 주기 안에 문제를 차단하는 속도를 우선한 설계다. ## 운영 환경을 고려한 예외 처리 - 오케스트레이터가 재배포 중 재시작되더라도 진행 중인 카오스 실험을 찾아 계속 polling하도록 했다. - 여러 오케스트레이터 인스턴스가 동시에 실행될 수 있으므로 leader election과 중복 실행 방지 장치를 적용했다. - 한 버전 공지에 대해 실험이 한 번만 실행되도록 보장했다. - 클라이언트별 데이터 소비 주기가 다르기 때문에 baseline과 canary의 버전 상태를 추적하고, 두 클러스터가 올바르게 정렬된 경우에만 실험을 시작한다. ## 의도적인 장애 주입으로 검증 - 시스템의 효과를 확인하기 위해 실제로 카탈로그 데이터를 의도적으로 손상시키는 통제된 실험을 수행했다. - 고관심 타이틀을 denylist에 넣는 등 실제 장애와 유사한 데이터 손상 상황을 재현했다. - 이러한 실패 주입 실험을 통해 실제 재생 트래픽과 SPS 지표가 회귀를 감지하고, 잘못된 데이터 버전이 회원에게 확산되기 전에 중단되는지 검증했다. 데이터 파이프라인도 코드 배포와 마찬가지로 최종 산출물 기준의 카나리 검증이 필요하다. 특히 사용자 영향이 직접 반영되는 지표를 선택하고, 운영 트래픽을 격리된 환경에서 비교하며, 이상 징후가 나타나는 즉시 중단하는 구조가 고속 데이터 배포에 효과적이다.

원문 읽기(새 탭에서 열림)

rest-apidata-pipelineschaos-engineeringdata-canary+3

netflix·2026년 6월 19일·4분 읽기큐레이션 요약

데이터 프로젝트: 넷플릭스 규모로 데이터 자산 관리

Netflix는 수백만 개의 테이블과 수만 개의 워크로드를 개별 자산·사용자 단위로 관리하면서 권한 변경과 워크플로 장애가 반복되는 문제를 겪었다. Data Projects는 관련 자산을 프로젝트로 묶고, 사람과 무관하게 유지되는 프로젝트 전용 신원(identity)을 부여해 권한과 실행 주체의 관리 단위를 상향한다. 이를 통해 조직 개편이나 담당자 변경에도 권한과 데이터 워크플로가 안정적으로 유지되도록 한다. ## 개별 자산 중심 권한 관리의 한계 - 기존에는 모든 테이블에 개별 ACL을 설정해야 했다. - 조직 개편이나 팀 통합 때 수백 개 테이블의 권한을 하나씩 수정해야 했다. - 대규모 권한 변경 요청이 지원팀에 집중됐다. - 관리 부담을 피하기 위해 테이블을 전사 공개하는 사례가 생겨 ACL의 의미가 약화됐다. - Data Projects는 여러 테이블과 워크로드를 하나의 프로젝트로 묶어 프로젝트 단위로 권한을 관리한다. ## 사람에게 종속된 워크로드 신원의 문제 - Maestro 워크플로, Spark 파이프라인, 데이터 이동 작업은 실행 시 신원이 필요했다. - 기존에는 워크플로 작성자의 사용자 계정으로 실행하는 경우가 많았다. - 담당자가 팀을 옮기거나 퇴사하면 계정 권한이 바뀌어 워크플로가 실패했다. - 다른 사람의 계정으로 교체해도 권한이 완전히 같지 않아 새로운 권한 오류가 연쇄적으로 발생했다. - 수만 개의 예약 워크로드를 운영하는 Netflix에서는 이러한 방식이 지속 가능하지 않았다. ## Data Projects의 기본 구조 - Data Project는 관련 데이터 자산을 묶어 관리·조회하는 논리적 컨테이너다. - 포함할 수 있는 자산에는 테이블, 워크플로, 시크릿 등이 있다. - 동시에 사람과 독립적으로 유지되는 합성(synthetic)·지속적(durable) 신원 역할을 한다. - 500개 테이블의 ACL을 각각 관리하는 대신, 하나의 프로젝트에 대한 권한을 관리한다. - 초기 목적은 접근 제어와 실행 신원 통합이지만, 향후 다른 데이터 플랫폼 관리 기능으로 확장될 수 있다. ## 프로젝트 기반 역할과 권한 - 프로젝트 소유 팀이 프로젝트의 grant를 관리한다. - 사용자, 그룹, 애플리케이션, CI 작업 등 다양한 주체를 grant로 추가할 수 있다. - 각 grant에는 프로젝트 내 작업 범위를 결정하는 역할이 부여된다. - 예를 들어: - `Contributor`: 프로젝트 자산에 대한 읽기·쓰기 권한 - `Viewer`: 읽기 전용 권한 - 팀원이 합류하거나 떠날 때 개별 자산 ACL 수백 개를 수정하지 않고 프로젝트 grant 하나만 변경하면 된다. ## Netflix 애플리케이션 ID와 AWS IAM 역할 - 모든 Data Project에는 Netflix 애플리케이션 신원이 provision된다. - 필요하면 AWS IAM 역할도 함께 제공된다. - Netflix 신원은 Maestro 같은 비동기 워크로드의 실행 주체가 된다. - AWS IAM 역할은 Amazon EMR의 Spark 작업 등 AWS 특화 작업에 사용된다. - IAM 역할은 암호학적으로 안전한 방식으로 프로젝트의 Netflix 신원으로 교환될 수 있다. - 권한이 충분한 프로젝트 구성원은 로컬 노트북이나 노트북 환경에서 프로젝트 신원을 가정해 실제 예약 작업과 동일한 권한으로 테스트·디버깅할 수 있다. ## ‘Gravity’를 통한 자산 자동 귀속 - 프로젝트 신원으로 실행된 워크로드가 새 자산을 만들면 해당 자산이 자동으로 프로젝트에 포함된다. - 예를 들어 Maestro 워크플로가 테이블 세 개를 생성하면 이 테이블들이 자동으로 프로젝트의 자산이 된다. - 생성 자산을 나중에 찾아 프로젝트에 수동 등록할 필요가 없다. - 프로젝트가 해당 워크로드가 만든 자산의 중심이 되어 관리 범위와 권한 적용이 자연스럽게 확장된다. ## Maestro와 신뢰된 워크로드 실행 - Maestro는 ETL, 데이터 이동, 머신러닝 학습 등 배치 분석 작업을 담당하는 Netflix의 핵심 오케스트레이터다. - 예약 작업은 원래 사용자가 실행 시점에 উপস্থিত하지 않아도 되므로, Maestro는 Trusted Workload Manager(TWM)로 지정됐다. - TWM은 관리하는 워크로드를 대신해 새로운 신원 토큰을 발급할 권한을 가진다. - 하나의 워크플로 실행은 데이터 웨어하우스 테이블 ACL, Netflix 리소스 정책, AWS IAM 정책을 모두 통과해야 할 수 있다. - 따라서 실행 신원이 불안정하면 전체 데이터 파이프라인이 실패한다. ## 프로젝트 기반 지속 가능한 신원 - 기존의 `maestro OBO alice@netflix.com` 방식은 Maestro와 개인 사용자의 권한을 결합했지만, 사용자 생명주기에 종속됐다. - Data Projects는 이를 팀이 소유하는 Netflix 애플리케이션 신원으로 대체한다. - 프로젝트 신원은 담당자의 휴가, 부서 이동, 퇴사와 무관하게 유지된다. - Maestro는 워크플로 실행 전 호출자가 해당 프로젝트를 사용할 권한이 있는지 검증한다. - 실행 중 생성된 테이블은 gravity를 통해 프로젝트에 자동 귀속되고 프로젝트 권한을 물려받는다. - 시크릿도 프로젝트 정책 범위에서 관리되므로 담당자 변경으로 자격 증명이 고립되지 않는다. - 결과적으로 권한 관리가 중앙화되고, 워크플로 실행이 안정적이며, 감사 가능성도 높아진다. 대규모 데이터 플랫폼에서는 개별 테이블과 사용자에 권한을 계속 부여하기보다, 팀·서비스·워크로드를 대표하는 프로젝트 단위의 소유권과 지속 가능한 실행 신원을 도입하는 것이 효과적이다. 특히 예약 작업과 조직 변화가 많은 환경에서는 프로젝트 단위 권한, 자동 자산 귀속, 사람과 분리된 서비스 신원을 함께 설계하는 것이 권장된다.

원문 읽기(새 탭에서 열림)

apache-sparkaccess-controlidentity-managementaws-iam+4

netflix·2026년 6월 19일·4분 읽기큐레이션 요약

콘텐츠 출시의 위험 예측: 데이터 기반 인사이트가 출시 계획을 혁신하는 방법

넷플릭스는 콘텐츠 출시 준비 과정에서 수작업으로 입력된 미디어 전달 일정이 자주 부정확하거나 누락된다는 문제를 발견했습니다. 이에 제작 진행 데이터와 메타데이터를 활용한 머신러닝 모델로 Locked Cut과 최종 IMF 전달까지 남은 일수를 예측하고, 출시 지연 위험을 줄이려 합니다. 백테스트 결과 예측 일정은 수작업 일정에 비해 정확도와 제공 범위가 높았으며, 출시 직전 일정 오차와 출시 지연 사이의 상관관계도 완화했습니다. ## 콘텐츠 출시 준비와 일정 리스크 - 넷플릭스 콘텐츠는 개발, 프리프로덕션, 제작, 후반작업, 출시 준비 단계를 거쳐 공개됩니다. - 후반작업이 끝나면 최종 오디오·비디오 파일인 IMF가 전달되고, 이를 기반으로 다음 작업이 진행됩니다. - 아트워크와 예고편 제작 - 자막 생성 - 관람등급 지정 - 품질관리(QC) - 일부 작업은 최종본이 아닌 Locked Cut으로 미리 시작할 수 있습니다. - 다만 Locked Cut 이후 IMF가 크게 변경되면 추가 conformance 작업이 필요합니다. - IMF를 기다리면 일정이 압축될 수 있고, Locked Cut으로 일찍 시작하면 수정 비용이 발생하는 트레이드오프가 존재합니다. ## 수작업 일정의 한계 - 콘텐츠 파트너가 제작 일정에 Locked Cut과 IMF의 예상 전달일을 수동으로 입력합니다. - 실제 제작은 일정 변경, 인력·장비 충돌, 예기치 못한 문제 등으로 지속적으로 변동됩니다. - 그 결과 다음 문제가 발생합니다. - 일부 콘텐츠에는 예상 전달일 자체가 없음 - 기존 예상일이 실제 전달일과 크게 다름 - 출시 준비팀이 언제 작업을 시작해야 할지 판단하기 어려움 - 넷플릭스는 축적된 제작 데이터를 활용해 일정 누락을 보완하고 예상일의 정확도를 높이려 했습니다. ## 일정 오차와 출시 지연의 관계 - 일정 부정확성을 측정하기 위해 **Accumulated Error Days(AED)**라는 지표를 만들었습니다. - AED는 예상 전달일과 실제 전달일 사이의 편차를 시간에 따라 누적한 값으로, 두 일정 곡선 사이의 면적에 해당합니다. - 출시 지연이 발생한 콘텐츠는 지연이 없는 콘텐츠보다 평균 AED가 유의미하게 높았습니다. - 특히 전달일에 가까운 마지막 기간의 AED가 출시 지연과 더 강한 상관관계를 보였습니다. - 따라서 장기적인 평균 오차뿐 아니라 출시 직전 일정이 얼마나 정확한지가 출시 리스크 관리에 중요합니다. ## 머신러닝 기반 전달일 예측 - 예측 모델은 부스티드 트리 회귀 모델로, 진행 중인 제작물에 대해 IMF 또는 Locked Cut 전달까지 남은 일수를 예측합니다. - 다음과 같은 데이터를 입력값으로 활용합니다. - 제작 진행 상황과 관련된 운영 신호 - 콘텐츠 및 타이틀 메타데이터 - 계절성 신호 - 제작 과정의 매일 업데이트된 스냅샷 데이터를 사용해, 각 날짜 시점의 제작 상태를 모델링합니다. - 이 방식의 장점은 다음과 같습니다. - 새로운 정보가 들어올 때마다 최신 예측 생성 - 제작 단계가 달라도 적용 가능한 유연한 모델 구축 - 시간에 따라 변하는 동적 특성 반영 - 수작업 일정이 없는 콘텐츠에도 항상 예측일 제공 ## 종합적인 모델 평가 지표 - 실제 전달일과 비교해 예측일의 정확도를 평가하기 위해 여러 지표를 사용했습니다. - 평균·중앙값 절대 오차(MAE 등) - 평균·중앙값 오차를 통한 과대·과소 예측 편향 - 오차 표준편차를 통한 예측 분포의 변동성 - 전달일까지 일정 기간 이상 차이 나는 큰 오차의 비율 - 수작업 일정은 전달일까지 남은 기간별로 일정이 존재하는 콘텐츠의 비율인 coverage도 측정했습니다. - 예측 모델은 항상 날짜를 제공하도록 설계되어 수작업 일정의 공백을 보완할 수 있습니다. ## 수작업 일정 대비 개선 효과 - 백테스트에서 예측 일정은 대부분의 전달 시점과 평가 지표에서 수작업 일정보다 우수했습니다. - IMF와 Locked Cut 모두에서 평균 절대 오차가 크게 감소했습니다. - 큰 오차나 이상치도 수작업 일정에서 예측 일정으로 전환했을 때 줄어들었습니다. - 예측 모델은 단순히 최종 시점의 정확도를 높이는 것뿐 아니라 더 일찍 유용한 신호를 제공합니다. - Locked Cut 전달 6개월 전부터 예측일이 수작업 일정보다 정확했던 콘텐츠 비율은 76%였습니다. - 예측 일정의 MAE는 6.1주였으며, 수작업 일정이 같은 수준에 도달하려면 전달 11주 전까지 기다려야 했습니다. - AED를 6개월 또는 더 짧은 기간에 걸쳐 계산했을 때도 예측 IMF·Locked Cut 일정이 수작업 일정 대비 AED를 낮췄습니다. - 이러한 효과는 여러 구매 조직과 콘텐츠 유형, 즉 시리즈와 단편 콘텐츠 전반에서 대체로 나타났습니다. ## 기존 업무 흐름에 예측 일정 적용 - 전달 예상일은 이미 관련 팀의 업무 과정에 포함되어 있기 때문에, 예측 날짜를 도입해도 기존 프로세스를 전면 개편할 필요가 없습니다. - 다만 수작업 일정과 예측 일정이 동시에 존재하면 어느 쪽을 더 신뢰할지 판단해야 합니다. - 예측 일정이 평균적으로 더 정확하더라도 모든 상황에서 수작업 일정을 능가하는 것은 아니므로, 두 일정의 신뢰도를 비교하고 상황별로 선택하는 운영 체계가 필요합니다. - 제공된 글은 이 문제를 해결하기 위한 후속 방식 설명 중간에서 끝나 있어, 최종 의사결정 규칙이나 운영 정책은 확인할 수 없습니다. 실무적으로는 예측일을 기존 일정의 대체재라기보다, 누락된 일정을 보완하고 위험 신호를 조기에 제공하는 계층으로 도입하는 것이 적절합니다. 특히 출시 직전 AED와 일정 오차를 지속적으로 모니터링하면 출시 지연 가능성이 높은 콘텐츠에 우선 대응할 수 있습니다.

원문 읽기(새 탭에서 열림)

머신러닝predictive-modelinganalytics-engineeringtime-series-forecasting+3

netflix·2026년 6월 19일·4분 읽기큐레이션 요약

넷플릭스에서 카산드라 데이터 이동의 진화

넷플릭스는 하루 약 1,200건, 약 3PB의 Cassandra 데이터를 Iceberg로 옮기던 기존 Casspactor를 확장 가능한 계층형 엔진으로 교체했다. 기존 시스템은 여러 메타데이터 서비스에 의존하고 대규모 파티션과 다양한 Cassandra 데이터 모델을 제대로 처리하지 못해 안정성·비용·확장성 문제가 발생했다. 새 구조는 S3 백업을 단일 진실 공급원으로 사용하고, Spark DataFrame과 커넥터 팩토리를 기반으로 각 데이터 모델에 최적화된 커넥터를 구축한다. ## Casspactor의 역할과 한계 - Casspactor는 Cassandra의 SSTable과 메타데이터를 S3 백업에서 읽어 Iceberg 테이블로 변환했다. - 하루 약 1,200건의 데이터 이동과 약 3PB 규모의 전송을 처리하며 핵심 업무를 지원했다. - Cassandra 노드의 사이드카 프로세스가 SSTable과 메타데이터를 S3에 업로드하고, 작업 실행 시 엔진이 필요한 백업 구조를 구성했다. - 이후 SSTable을 다운로드하고 mutation compaction과 변환을 수행한 뒤 Iceberg에 기록했다. - 그러나 단일 커넥터로 설계되어 Key Value, Time Series, Graph 등 여러 데이터 추상화에 공통 기반을 제공하기 어려웠다. ## 분산된 메타데이터 의존성 문제 - Casspactor는 백업의 존재 여부, 완전성, 포함 데이터를 여러 독립 시스템의 메타데이터를 조합해 판단했다. - 각 시스템의 갱신 주기와 정확도, 장애 방식이 달라 실제 백업 상태와 Casspactor의 인식이 불일치할 수 있었다. - 메타데이터가 실제 백업과 어긋나면 오래되거나 잘못된 데이터를 조용히 읽는 문제가 발생했다. - Cassandra 클러스터 유지보수 중 비동기 스냅샷이 만들어졌고, 한 리전에 있는 모든 노드가 같은 시각에 스냅샷을 생성해야 한다는 제약도 있었다. - 노드 하나가 교체되면 리전 전체의 데이터 이동이 실패할 수 있었다. - 새 구조에서는 백업 파일 자체의 메타데이터를 직접 읽어 S3를 백업 존재 여부와 완전성을 판단하는 단일 진실 공급원으로 사용한다. ## 모든 커넥터가 물려받은 제약 - **대규모 파티션 처리 실패** - Key Value와 Time Series에서 흔한 넓은 파티션을 처리하지 못했다. - 일부 작업은 메모리 부족으로 종료됐다. - **데이터 모델 인식 부족** - 원시 Cassandra 테이블만 이동했기 때문에 Key Value 등의 커넥터가 별도의 후처리로 데이터 모델을 복원해야 했다. - 이로 인해 처리 비용과 복잡성, 장애 가능성이 증가했다. - **중간 테이블 증가** - Casspactor는 최종 결과 전에 중간 Iceberg 테이블을 생성했다. - Key Value 커넥터는 추가 중간 테이블과 스냅샷 테이블까지 필요했다. - 상위 데이터 추상화가 추가될수록 중간 저장 공간과 비용이 누적됐다. - **Time Travel 불가** - 여러 서비스를 조합해 백업 단위를 구성했기 때문에 클러스터 토폴로지나 Keyspace 스키마가 변경된 뒤 과거 백업을 복원하기 어려웠다. - **모놀리식 구조** - Casspactor는 재사용 가능한 엔진이 아니라 하나의 커넥터였다. - 데이터 모델별 목적형 커넥터를 공통 기반 위에 구축할 수 없었다. ## 새로운 계층형 아키텍처 - 새 구조는 Apache Cassandra Analytics, 넷플릭스의 Move Data 프레임워크, 내부 백업 표현 방식과 S3 클라이언트를 결합한다. - 가장 아래 계층인 Cassandra Analytics Wrapper가 S3 백업에서 원시 데이터를 읽는다. - 읽은 결과는 표준 Spark DataFrame으로 변환된다. - 상위 계층의 Connector Factory는 Java UDF와 변환 로직을 통해 데이터 추상화별 커넥터를 생성한다. - Key Value나 Time Series 커넥터는 일반적인 DataFrame을 입력으로 받아 자체 데이터 모델에 맞게 처리한다. - 핵심 읽기 엔진의 개선 사항은 모든 커넥터에 적용되고, 각 커넥터는 변환 로직에 집중할 수 있다. ## Spark 기반 처리와 운영 개선 - mutation compaction과 데이터 처리를 Spark Executor 수준으로 이동했다. - 대규모 또는 편향된 파티션을 과도한 셔플 없이 처리해 메모리 부족 문제를 줄였다. - Cassandra 백업에서 바로 Spark DataFrame을 생성하므로 중간 Iceberg 테이블이 필요하지 않다. - 중간 저장 비용과 다단계 파이프라인의 운영 복잡성이 감소한다. - 소스 테이블의 특성에 따라 작업 리소스를 자동 조정하는 auto-sizing 기능을 제공한다. - 엔지니어가 작업별 리소스를 수동으로 조정하지 않아도 성능과 비용을 최적화할 수 있다. - S3의 백업 메타데이터를 직접 사용해 여러 외부 서비스에 대한 의존성을 제거하고 안정성을 높였다. ## 실용적인 결론 대규모 Cassandra 데이터 이동 시스템은 백업 메타데이터를 여러 서비스에서 조합하기보다 실제 저장소를 단일 진실 공급원으로 삼는 편이 안정적이다. 또한 원시 데이터 추출 엔진과 데이터 모델별 변환 커넥터를 분리하면, 공통 성능 개선을 재사용하면서도 Key Value·Time Series 같은 각 도메인에 최적화된 처리를 구현할 수 있다.

원문 읽기(새 탭에서 열림)

amazon-s3apache-sparkapache-icebergapache-cassandra+3

netflix·2026년 6월 19일·4분 읽기큐레이션 요약

개인화된 알림 시스템을 위한 빠른 사고와 느린 사고

Netflix의 개인화 알림 시스템은 장기적인 메시징 전략을 세우는 느린 정책(Slow Policy)과, 실제 발송 시점에 최적의 콘텐츠를 선택하는 빠른 정책(Fast Policy)으로 분리된다. 느린 정책은 회원별 주간 채널 빈도와 발송 페이싱을 결정하고, 빠른 정책은 해당 범위 안에서 즉각적인 관련성과 참여 가능성이 가장 높은 메시지를 선택한다. 이를 통해 단기 참여율뿐 아니라 알림 피로도와 채널 구독 해지 위험까지 함께 관리한다. ## 기존 단일 정책 방식의 한계 - 기존 시스템은 단일 알림이 단기간에 유발하는 인과적 효과를 예측해 발송 여부를 결정했다. - 즉시 시청, 클릭, 앱 방문 같은 단기 지표 최적화에는 효과적이지만, 다음과 같은 장기 영향을 반영하기 어려웠다. - 반복 발송으로 인한 알림 피로도 증가 - 몇 주에 걸쳐 나타나는 참여도 하락 - 이메일·푸시 수신 거부 가능성 증가 - 지속적인 콘텐츠 시청 습관과 회원 만족도 변화 - 발송 여부와 콘텐츠 순위를 하나의 판단으로 처리했기 때문에, 회원별 주간 발송 빈도는 명시적인 정책이 아니라 일별 의사결정의 부산물이었다. - 전체 발송량은 모델 점수 임계값으로 조절했지만, 임계값을 바꾸면 발송 빈도뿐 아니라 선택되는 메시지의 품질과 분포도 함께 변했다. - 결과적으로 회원마다 다른 참여 패턴에 맞춰 발송 빈도와 콘텐츠 선택을 독립적으로 개인화하기 어려웠다. ## 느린 정책과 빠른 정책의 계층 구조 - **느린 정책(Slow Policy)** - 주간 등 일정한 긴 시간 범위에서 회원별 메시지 계획을 수립한다. - 채널별 목표 빈도와 시간에 따른 발송 페이싱을 결정한다. - 장기 참여 패턴과 회원의 메시지 반응을 바탕으로 전략적 결정을 내린다. - **빠른 정책(Fast Policy)** - 실제 발송 기회가 발생할 때마다 작동한다. - 느린 정책이 정한 빈도와 페이싱 범위 안에서 가장 관련성 높은 메시지를 선택한다. - 특정 시점의 콘텐츠 적합성과 단기 참여 가능성을 최적화한다. - 푸시와 이메일 빈도를 독립적으로 조합한 이산적 행동 공간을 사용하며, 약 100개 수준의 채널별 페이싱 조합을 표현할 수 있다. ## 장기 효용 함수와 메시지 비용 느린 정책은 회원별 효용 함수를 최대화하는 행동을 선택한다. > U(member, action) = Σ wₖ · Rewardₖ(member, action) − Cost(action) - **긍정적 신호** - 회원이 알림을 통해 콘텐츠나 기능의 가치를 발견할 가능성 - 알림 이후의 시청, 클릭, 플랫폼 참여 가능성 - **부정적 신호** - 메시지 피로도 증가 가능성 - 특정 채널의 수신 거부 또는 이탈 가능성 - 부정적 피드백은 실제 데이터에서 매우 희소하기 때문에, 이를 모델링하는 것만으로는 충분하지 않다. - 부정적 비용이 거의 없다고 예측되면 모델이 “가능한 한 많이 발송”하는 정책으로 치우칠 수 있다. - 이를 방지하기 위해 모든 발송에 공통으로 적용되는 **보편적 메시지 비용(universal message cost)** 을 추가한다. - 이 비용은 보상 함수를 오목하고 안정적으로 만들어 과도한 발송 정책을 억제한다. - 비용의 크기는 온라인 실험과 오프라인 평가 지표를 함께 사용해 경험적으로 조정한다. ## 빈도와 시간 배분을 분리한 페이싱 - 느린 정책은 평균 발송 빈도뿐 아니라 일주일 동안 메시지를 어떻게 분산할지도 결정할 수 있다. - 가장 단순한 방식은 균등 무작위 페이싱이다. - 목표 빈도를 발송 기회별 확률로 변환한다. - 각 기회마다 확률에 따라 발송 여부를 무작위로 결정한다. - 개별 발송 시점은 달라질 수 있지만 장기적으로는 목표 발송률을 유지한다. - 향후에는 다음과 같은 비균등 페이싱도 적용할 수 있다. - 요일별 발송 패턴 - 회원의 최근 활동 여부에 따른 발송 - 콘텐츠 출시 시점에 맞춘 집중 발송 - 특정 이벤트나 캠페인에 맞춘 일시적 발송 증가 ## 두 정책 간의 비동기 통신 - 느린 정책과 빠른 정책은 저지연 feature store를 통해 연결된다. - **Planner** - 회원별 최적 페이싱 계획을 계산한다. - 계산된 전략적 의도를 feature store에 저장한다. - **Executor** - 매일 알림 발송 기회가 생기면 저장된 계획을 feature로 읽는다. - 해당 계획을 제약 조건으로 사용해 실제 발송 여부와 메시지를 결정한다. - 이 구조에서는 장기 계획 계산과 실시간 메시지 선택을 비동기적으로 분리할 수 있어, 각 정책이 서로 다른 시간 규모의 문제에 집중할 수 있다. ## 실용적인 결론 개인화 알림 시스템에서는 “무엇을 보낼 것인가”와 “얼마나 자주 보낼 것인가”를 하나의 모델에 맡기기보다 분리하는 것이 효과적이다. 장기 효용과 메시지 피로도를 반영하는 계획 계층을 먼저 만들고, 실시간 선택 계층이 그 계획 안에서 콘텐츠를 고르게 하면 단기 성과와 장기적인 회원 경험을 함께 최적화할 수 있다.

원문 읽기(새 탭에서 열림)

reinforcement-learningfeature-storepersonalizationnotification-systems+3

netflix·2026년 6월 19일·4분 읽기큐레이션 요약

인과 추론을 위한 인간 증강 에이전틱 워크플로우

소프트웨어 에이전트가 관찰자료의 인과효과를 분석하더라도, 결과를 자동으로 신뢰해서는 안 된다. 이 글은 인간이 분석 계획과 가정을 제시하고, 에이전트가 분석·진단을 수행하며, 별도의 비평 에이전트가 결함과 신뢰도를 검토하는 인간 증강형 OCI(관찰적 인과추론) 워크플로를 소개한다. 핵심은 정답이 없는 관찰연구에서 분석 산출물을 투명하게 남기고 사람이 재현·감사할 수 있도록 하는 것이다. ## 관찰적 인과추론에서 에이전트 감독이 필요한 이유 - 에이전트는 데이터 조회, 회귀분석, 결과 보고를 자동화할 수 있지만, 숨은 교란이나 표본 선택 편향을 놓칠 수 있다. - 예를 들어 인기 Netflix 프로그램 시청자와 장기 회원 유지율을 비교할 때, 열성 팬을 일반 시청자처럼 취급하면 잘못된 인과효과가 나온다. - OCI는 도메인 지식과 가정에 대한 판단이 필요하므로, 반복적인 분석 작업은 자동화하되 질문 설정과 가정 검토는 사람이 담당해야 한다. - 저자들은 OCI 에이전트를 오픈소스로 공개하고, ACIC 2016 데이터셋 평가에서 단일 실행 방식보다 여러 데이터 생성 과정에서 우수한 성능을 보였다고 설명한다. ## 타깃 실험을 모방하는 분석 철학 - 실제로 수행하기 어렵거나 불가능한 이상적 A/B 테스트를 먼저 상상하고, 그 실험을 관찰자료로 얼마나 충실히 모방할 수 있는지 검토한다. - 이 사고방식은 처리(treatment), 결과(outcome), 분석 시점, 통제해야 할 사전 공변량을 명확히 하는 데 도움을 준다. - 특히 “비교 가능한 처리군과 통제군을 만들 수 있는가”와 “처리 배정이 관측된 공변량으로 충분히 설명되는가”가 중요하다. - 워크플로는 기본적으로 비관측 교란이 없다는 가정(unconfoundedness) 아래 설계되었지만, 평행추세를 사용하는 패널 분석 등 다른 OCI 방법에도 원칙을 확장할 수 있다. ## 네 가지 설계 진단 - **공변량 균형** - 가중치 적용 후 처리군과 통제군의 사전 공변량 표준화 평균 차이(Standardized Mean Difference)가 0.2 미만이어야 한다. - **겹침(Overlap)** - 처리받을 확률인 성향점수(propensity score)가 0.1~0.9 범위에 있어야 한다. - 특정 집단에서 처리 확률이 거의 0 또는 1이면 두 집단을 공정하게 비교하기 어렵다. - **플라시보 결과** - 처리 이전에 측정된 변수에 유의한 처리효과가 나타나지 않아야 한다. - 사전 결과에 효과가 나타나면 기존 집단 차이나 분석 설계 오류를 의심해야 한다. - **숨은 교란 민감도** - 관측되지 않은 변수가 처리와 결과를 동시에 설명한다고 가정했을 때 결론이 얼마나 흔들리는지 평가한다. - 효과의 크기뿐 아니라 결과가 어떤 수준의 숨은 교란에 견디는지도 함께 보고한다. ## Actor–Critic 구조와 역할 분담 - **Principal(인간 사용자)** - 분석 목적과 맥락을 담은 초기 계획을 작성한다. - 주요 위협 요인과 통제해야 할 교란변수를 제시한다. - 사용할 수 있는 도구, 데이터 모델, 데이터셋을 지정한다. - 실행된 노트북과 비평 보고서를 검토한다. - **Actor(분석 에이전트)** - 인간의 계획을 구체적인 데이터 분석 명세로 정제한다. - 허용된 도구만 사용해 분석한다. - 계획, 명세, 코드, 도표, 노트북 등 사람이 읽고 기계적으로도 점검할 수 있는 산출물을 만든다. - 네 가지 설계 진단을 수행하고, 진단 실패 시 어떤 보정 조치를 취했는지 기록한다. - **Critic(비평 에이전트)** - 계획에서 빠진 교란변수나 맹점을 찾는다. - 계획·분석 명세·실제 실행 결과가 일치하는지 확인한다. - 진단 결과를 바탕으로 결과의 신뢰도 수준을 제시한다. - 성향점수 절단(trimmed propensity score) 등으로 인해 추정 대상이 ATE(평균처리효과)와 어떻게 달라졌는지 설명한다. - 실행된 분석을 이상적인 무작위대조시험(RCT)과 비교한다. - 권장 RCT나 장려(encouragement) 실험 등 최소 하나의 대안적 측정 전략을 제안한다. ## 정답 대신 과정 감사를 활용하는 평가 - 실제 관찰자료에는 참된 인과효과라는 명확한 ground truth가 없으므로, 출력값만 정답과 비교하는 방식에는 한계가 있다. - 따라서 에이전트는 분석 계획, 명세, 시각화, 실행 노트북, 보고서 같은 중간 산출물을 남긴다. - 인간 사용자는 이 자료를 직접 읽거나 다운로드해 다시 실행하면서 각 분석 단계와 가정을 감사할 수 있다. - 보고서는 버전 관리하고 실행된 노트북은 파일 저장소에 업로드해 재현성을 높인다. - Netflix의 검증된 비에이전트 OCI 도구는 이 과정을 지원하며, 인과효과 추정에는 이중강건 학습(doubly robust learning)을 사용한다. ## 실용적인 결론 에이전트에게 인과분석 전체를 맡기기보다, 인간이 질문·가정·데이터 사용 범위를 정하고 에이전트가 반복 계산과 진단을 수행하도록 역할을 분리하는 것이 안전하다. 특히 공변량 균형, 겹침, 플라시보, 민감도 분석 결과와 재실행 가능한 노트북을 함께 검토해야 하며, 관찰연구의 결론을 이상적인 RCT와 비교해 신뢰도와 한계를 명시하는 것이 바람직하다.

원문 읽기(새 탭에서 열림)

causal-inferenceagentic-workflowobservational-causal-inferencedoubly-robust-learning+3

netflix·2026년 6월 3일·4분 읽기큐레이션 요약

시계열 워크로드를 위한 동적 재파티셔닝

Netflix의 TimeSeries Abstraction은 Cassandra를 이용해 페타바이트 규모의 시계열 데이터를 밀리초 단위로 처리하지만, 시간이 지날수록 커지는 광범위한 파티션이 지연시간과 타임아웃을 유발했다. 기존의 테이블 단위 재파티셔닝은 전체 데이터가 비슷한 문제를 보일 때는 효과적이지만, 일부 ID만 비정상적으로 커지는 경우에는 적합하지 않았다. 이를 해결하기 위해 Netflix는 읽기 경로에서 넓은 파티션을 감지하고, 해당 TimeSeries ID 단위로 비동기 분할한 뒤 읽기 요청을 자동으로 재라우팅하는 동적 파티셔닝 시스템을 구축했다. ## Cassandra와 넓은 파티션의 문제 - Cassandra는 높은 처리량, 낮은 지연시간, 비용 효율성, 운영 성숙도를 이유로 Netflix의 시계열 저장소로 사용된다. - 그러나 이벤트가 시간에 따라 누적되면 하나의 파티션이 지나치게 커질 수 있다. - 일반적인 읽기 지연은 수 밀리초 수준이지만, 넓은 파티션에서는 특히 데이터 끝부분에서 지연시간이 수 초까지 증가한다. - 이로 인해 요청 타임아웃, 높은 CPU 사용률, 가비지 컬렉션 일시정지, 스레드 큐 대기 등이 발생할 수 있다. - 단순히 Cassandra 클러스터를 확장하는 방식은 비용 문제를 해결하지 못하므로 데이터 배치 자체를 개선해야 한다. ## 기존 TimeSeries 파티셔닝 전략 - 데이터를 일정한 시간 단위의 개별 Time Slice로 나누어 파티션 크기를 제한한다. - 시간 기준으로 데이터를 효율적으로 조회하거나 삭제할 수 있으며, 대량의 tombstone을 처리해야 하는 부담도 줄어든다. - 데이터셋 생성 시 사용자가 예상 트래픽과 이벤트 특성을 입력한다. - 프로비저닝 파이프라인은 해당 입력을 바탕으로 Monte Carlo 시뮬레이션을 수행해 인프라와 파티션 설정을 결정한다. ## 사전 설정 방식의 한계 - 초기 단계에서는 실제 운영 트래픽을 정확히 예측하기 어렵다. - 시간이 지나면서 트래픽 패턴, 클라이언트 동작, 제품 요구사항이 변할 수 있다. - 일부 TimeSeries ID만 다른 ID보다 훨씬 많은 이벤트를 받는 데이터 이상치가 존재할 수 있다. - Time Slice마다 다른 파티션 전략을 적용할 수 있지만, 수천 개 데이터셋의 설정을 사람이 직접 조정하는 것은 지속 가능하지 않다. - 따라서 파티션 상태를 관찰하고 자동으로 조정하는 시스템이 필요하다. ## Time Slice 단위 재파티셔닝 - Cassandra의 `nodetool tablehistograms` 등 introspection API를 활용해 파티션 크기 분포를 관찰한다. - 너무 작은 파티션이 많은 과도한 분할(over-partitioning)과 지나치게 큰 파티션을 모두 탐지할 수 있다. - 예를 들어 파티션 크기가 10KB보다 작으면 읽기 증폭과 스레드 큐잉이 커질 수 있다. - 백그라운드 워커가 애플리케이션에 연결된 Time Slice의 파티션 히스토그램을 감시한다. - 파티션 크기가 설정된 목표 밀도에 미달하면 조정 계수를 계산하고, 이후 생성될 Time Slice의 `time_bucket` 간격을 변경한다. - 목표 파티션 크기는 워크로드에 따라 보통 2MiB~10MiB로 설정된다. - 이 방식은 읽기 지연시간과 타임아웃을 줄이는 데 효과가 있었지만, 테이블 전체가 비슷한 문제를 보일 때만 적합하다. - 특정 ID 몇 개만 넓은 경우에는 전체 테이블의 파티션 전략을 바꾸는 것이 불필요하거나 효과적이지 않다. ## 일부 ID만 문제가 될 때의 대응 - **아무것도 하지 않기** - 애플리케이션의 전체 지표에 영향이 없다면 문제를 감수하는 것이 합리적일 수 있다. - **부분 결과 반환** - 요청이 설정된 지연시간 SLO를 넘으면 진행 중인 요청을 중단한다. - 그때까지 수집한 데이터만 반환해, 전체 결과보다 빠른 응답을 우선하는 클라이언트에 적합하다. - **문제 ID 차단** - 테스트나 스팸 데이터처럼 시스템을 불안정하게 만드는 ID를 차단한다. - 다만 정상적이고 중요한 ID가 큰 경우에는 데이터 전체를 처리해야 하므로 이 방법을 사용할 수 없다. ## ID별 동적 파티셔닝 - 동적 파티셔닝은 테이블 전체가 아니라 특정 TimeSeries ID의 넓은 파티션만 자동으로 분할한다. - 비동기 파이프라인은 다음 세 단계로 구성된다. - **감지:** 읽기 경로에서 특정 파티션의 읽기 바이트 수를 추적하고, 임계치를 넘으면 넓은 파티션으로 판단한다. - **계획 및 분할:** 적절한 크기가 되도록 파티션 분할 작업을 계획하고 비동기적으로 실행한다. - **읽기 제공:** 분할이 완료되면 기존 요청 경로를 투명하게 새 파티션으로 재라우팅한다. - 읽기 작업 중 파티션에서 읽은 바이트가 설정된 한도를 초과하면 Kafka로 감지 이벤트를 발행한다. - 이벤트에는 데이터가 속한 Time Slice 테이블, 문제가 된 `time_series_id`, 기존 `time_bucket`, `event_bucket`, 해당 파티션의 쓰기 종료 여부(`immutable`), 버전 등의 정보가 포함된다. - 이 구조를 통해 정상적인 ID에는 영향을 주지 않으면서, 데이터량이 큰 특정 ID만 선택적으로 재구성할 수 있다. ## 실용적인 결론 - 데이터 전체의 분포가 바뀌었다면 Time Slice 단위 자동 재파티셔닝을 적용하는 것이 효율적이다. - 일부 ID만 비대해지는 경우에는 ID별 동적 파티셔닝이 더 적합하다. - 읽기량, 파티션 크기, 지연시간 SLO를 지속적으로 관찰하고 자동화된 감지·분할·재라우팅 체계를 마련하는 것이 핵심이다.

원문 읽기(새 탭에서 열림)

데이터베이스 설계Apache Kafkatime-series-databaseapache-cassandra+1

netflix·2026년 5월 29일·5분 읽기큐레이션 요약

넷플릭스의 고처리량 그래프 추상화: 1부

넷플릭스의 Graph Abstraction은 분석 중심의 OLAP가 아니라, 밀리초 수준의 지연 시간과 초당 수백만 건의 처리량이 필요한 OLTP 그래프 서비스를 위해 설계됐다. 이 시스템은 약 650TB 규모의 그래프 데이터를 초당 약 1,000만 건의 연산으로 처리하며, KV·TimeSeries·EVCache 등 기존 데이터 추상화를 조합해 실시간성과 비용 효율을 확보한다. 강한 타입의 스키마와 사전 정의된 관계를 활용해 데이터 품질, 쿼리 계획, 탐색 중복 제거를 개선하는 것이 핵심이다. ## OLAP와 OLTP 그래프의 차이 - **OLAP 그래프** - 대규모 그래프를 대상으로 개방형·알고리즘 중심의 분석을 수행한다. - RDF/SPARQL, Property Graph/Gremlin·openCypher, SQL 등을 사용한다. - 낮은 지연 시간이나 높은 처리량보다 심층 분석과 유연성이 중요하다. - **OLTP 그래프** - 초당 수백만 건의 연산과 밀리초 단위의 탐색 응답을 요구한다. - 높은 성능을 위해 최종적 일관성(eventual consistency)을 허용할 수 있다. - 시작 노드 지정, 최대 탐색 깊이 제한 등 쿼리 복잡도 제약을 둔다. - 스트리밍 처리나 사용자 경험과 직접 연결되므로 높은 글로벌 가용성이 필요하다. - Netflix Graph Abstraction은 이러한 OLTP 요구를 대상으로 만들어졌다. ## 넷플릭스의 주요 활용 사례 - **Real-Time Distributed Graph(RDG)** - 넷플릭스 생태계의 엔터티와 상호작용 사이의 동적 관계를 표현한다. - 기존 RDG 구현이 Graph Abstraction에 통합됐다. - **Social Graph** - Netflix Gaming 내부의 소셜 연결을 모델링한다. - 사용자 참여도 향상에 활용된다. - **Service Topology** - 넷플릭스 내부 서비스 간 관계를 나타낸다. - 실시간 및 과거 데이터를 분석해 장애 발생 시 근본 원인 분석을 지원한다. ## 기존 데이터 추상화 위에 구축한 아키텍처 - 저장소와 캐시를 새로 개발하지 않고 Netflix Online Datastore 생태계의 추상화를 활용한다. - **KV Abstraction** - 노드와 엣지의 최신 상태를 저장한다. - 모든 실시간 그래프 쿼리를 위한 인덱스로 사용된다. - **TimeSeries Abstraction** - 선택적으로 연결할 수 있다. - 시간에 따른 그래프 변화와 과거 상태를 조회할 수 있다. - **EVCache** - 밀리초 단위의 낮은 지연 시간을 달성하기 위한 캐시 계층이다. - 더 특화된 캐시 계층도 실험 중이다. - **Data Gateway Control Plane** - 그래프 스키마를 관리한다. - KV와 TS 데이터셋의 생성, 삭제, 구성 및 프로비저닝을 자동화한다. ## 강한 타입의 Property Graph 모델 - 그래프는 여러 타입의 노드와 엣지로 구성된다. - 노드와 엣지는 각각 속성(properties)을 가질 수 있다. - 속성 타입을 강하게 지정해 다음을 보장한다. - 필터링을 효율적으로 수행한다. - 데이터 내보내기(export)의 일관성을 유지한다. - 잘못된 형식의 데이터 입력을 방지한다. - 엣지는 의미에 따라 다음 중 하나로 정의된다. - **단방향 엣지**: 한 방향으로만 탐색한다. - **양방향 엣지**: 양쪽 방향의 관계를 표현한다. ## 네임스페이스와 물리적 격리 - 그래프 데이터는 **네임스페이스(namespace)**라는 독립 단위로 분리된다. - 각 네임스페이스는 Control Plane 설정에 따라 특정 물리 저장 계층과 연결된다. - 전용 하드웨어 또는 공유 하드웨어에 배포할 수 있다. - 프로비저닝 자동화는 다음 요구사항을 바탕으로 비용 효율적인 하드웨어 구성을 결정한다. - 목표 처리량 - 허용 지연 시간 - 데이터셋 크기 - 워크로드의 중요도 ## 명시적 그래프 스키마와 엣지 매핑 - 각 네임스페이스에는 명시적인 그래프 스키마가 연결된다. - 스키마는 다음을 정의한다. - 노드 타입과 엣지 타입 - 허용되는 속성과 타입 - 노드 간 허용 관계 - 엣지 방향 - 관계는 **엣지 매핑(edge mapping)**의 집합으로 표현된다. - 출발 노드 타입 - 엣지 타입 - 도착 노드 타입 - 단방향 또는 양방향 여부 - 예를 들어 `account -owns-> profile`은 단방향이고, `profile -linked_to- device`는 양방향으로 설정할 수 있다. - 엣지별 속성 스키마를 통해 `registration_time`은 TIMESTAMP, `status`는 STRING처럼 허용된 속성명과 타입을 지정한다. ## 스키마를 활용한 최적화 Graph Abstraction 서버는 시작 시 스키마를 읽어 가능한 관계를 나타내는 인메모리 메타데이터 그래프를 구축한다. - **데이터 품질 보장** - 스키마와 맞지 않는 노드, 엣지, 속성의 쓰기를 거부한다. - 데이터 내보내기 결과의 일관성을 높인다. - **쿼리 계획 수립** - 사용자 요청을 처리할 수 있는 탐색 경로를 빠르게 구성한다. - **엣지 중복 제거** - 같은 노드 타입 사이의 양방향 엣지를 탐색할 때 중복 경로 처리를 줄인다. - **불가능한 경로 제거** - 스키마상 존재할 수 없는 관계를 탐색 대상에서 제외한다. - 필터 조건이나 속성 타입이 맞지 않는 경로도 제거한다. - 서버는 Control Plane을 주기적으로 조회해 변경된 스키마를 반영한다. - 향후에는 엣지 카디널리티를 이용해 쿼리 fanout을 줄이고, 타입 안전한 데이터 접근 계층과 스키마 인식형 Gremlin 유사 API를 제공할 계획이다. ## KV 기반 실시간 인덱스 - 각 네임스페이스는 기본 저장 계층의 하나의 테이블과 연결된다. - 테이블은 고유 ID를 기준으로 레코드를 분할한다. - 하나의 레코드에는 정렬된 여러 key-value 항목이 저장된다. - 결과적으로 네임스페이스는 유연한 접근 패턴을 지원하는 **정렬된 맵들의 맵(map of sorted maps)** 구조를 갖는다. - 노드와 엣지의 모든 실시간 그래프 인덱스는 KV를 기반으로 저장된다. ## 멱등성과 Last-Write-Wins - 동일한 ID와 키에 대한 쓰기는 멱등적으로 처리된다. - 따라서 요청을 여러 번 재시도하거나 request hedging을 수행해도 안전하다. - 멱등성 토큰에는 타임스탬프가 포함된다. - KV는 이 타임스탬프를 이용해 저장 계층에서 **Last-Write-Wins(LWW)** 규칙을 적용한다. - 네트워크 지연이나 일시적 장애가 발생해도 재시도 가능한 쓰기 모델을 제공한다. 실시간·고처리량 그래프 시스템을 구축할 때는 범용 그래프 데이터베이스 하나에 모든 요구를 맡기기보다, 최신 상태 저장소·이력 저장소·캐시·스키마 관리 계층을 목적에 맞게 조합하는 방식이 효과적이다. 특히 강한 스키마와 제한된 탐색 모델을 도입하면 데이터 품질을 높이면서 쿼리 경로와 비용을 사전에 최적화할 수 있다.

원문 읽기(새 탭에서 열림)

graph-databaseeventual-consistencysparqlproperty-graph+3