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#ApacheFlink
#Backend

두 개의 플링크 오토스케일러 이야기

두 개의 플링크 오토스케일러 이야기
01

Summary

넷플릭스는 어떻게 3만 개의 플링크 작업을 오토스케일링하여 연간 110만 달러를 아꼈을까?

자체 빌드에서 오픈소스 Flink Autoscaler와 Temporal의 결합으로 진화한 실전 마이그레이션 기술기

이 글은 대규모 실시간 스트림 처리를 안정적으로 수행하기 위해 넷플릭스가 겪은 두 가지 플링크 오토스케일러의 진화 여정을 다룹니다. 기존 외부 관찰식 메트릭 시스템의 한계를 극복하기 위해 작업 내부 상태를 정확히 진단하는 Apache Flink Autoscaler를 도입하고, 이를 Temporal 워크플로우 엔진과 결합하여 대규모 인프라에서 격리성과 안정성을 확보한 실전 노하우를 공유합니다.

  • 01자체 개발(Build) 기술의 유지보수 비용을 줄이고 검증된 오픈소스(Buy)를 도입해 성공적으로 이식한 엔지니어링 사례 제시
  • 02작업 내부에서 각 연산자의 실제 성능 한계를 역추적하는 '실질 처리 비율(TPR)' 공식 적용
  • 03단일 루프 병목 문제를 해결하기 위해 Flink 작업별로 Temporal 워크플로우를 배치하여 장애 전파 범위를 원천 격리
  • 04대규모 서브태스크(최대 3,000개) 처리를 위해 JobManager의 메트릭 조회를 캐싱 및 서버 단 필터링으로 최적화
  • 05급격한 리스케일링 진동을 막기 위해 목표 자원 사용률을 0.45로 낮춰 스케일 아웃 안정성 대폭 개선

+RECOMMENDATION

대규모 Apache Flink 파이프라인을 구축 중이거나 트래픽 변동이 잦은 대형 클라우드 데이터 파이프라인의 비용 최적화 및 오토스케일링 설계를 고민하는 데이터 플랫폼 엔지니어에게 적극 추천합니다.

The Problem

넷플릭스는 30,000개 이상의 Flink 작업을 운영하면서 대형 상태 기반(stateful) DAG 및 다중 연산자 작업의 복잡한 스케일링을 수동으로 관리해야 하는 비효율성을 안고 있었습니다. 기존에 자체 개발했던 외부 메트릭 기반 오토스케일러는 컨테이너 수준의 거친 정보만 분석할 수 있어 각 연산자의 개별 부하와 병목을 세밀하게 파악하기 어려운 한계가 있었습니다.

The Solution

넷플릭스는 작업 내부의 실제 처리량(TPR)을 분석하는 오픈소스 'Apache Flink Autoscaler' 핵심 라이브러리를 도입하고, 이를 자사 플랫폼 환경에 맞게 Spring Boot와 Temporal 워크플로우 기반 아키텍처로 통합했습니다. 대규모 스케일 처리를 위해 Flink JobManager의 메트릭 캐싱 및 필터링 성능을 개선하고, 포워드 체이닝 유지 및 싱크 백프레셔 감지 등의 플랫폼 특화 기능을 기여 및 커스텀 구현했습니다.

The Result

새로운 오픈소스 기반 오토스케일러 도입을 통해 넷플릭스의 클라이언트 텔레메트리 및 로깅 팀은 연간 Flink 컴퓨팅 비용을 58%(약 110만 달러) 절감하는 성과를 거두었습니다. 개별 Flink 작업별로 오토스케일러의 평가 단위를 격리하여 평가 루프의 장애 전파 문제를 방지했으며, 최대 3,000개의 서브태스크를 가진 대형 작업도 무리 없이 자동으로 스케일링할 수 있게 되었습니다.

Trade-off

너무 공격적인 다운스케일링은 일시적인 트래픽 변동 시 자원 부족으로 인한 재지연 및 스케일링 루프를 반복 유발할 수 있어, 넷플릭스는 효율성을 소폭 양보하고 목표 사용률(Target Utilization)을 커뮤니티 권장값인 0.7 대신 0.45로 보수적으로 설정했습니다. 또한 현재 스케일링에 따른 병목의 핵심은 스케일러의 알고리즘 계산 속도가 아니라 Flink 엔진 자체의 중단, 상태 복구 및 재시작 시간에 종속된다는 단점이 존재합니다.

03

Key Concepts

Concept · 01

True Processing Rate (TPR)

각 데이터 처리 연산자가 백프레셔(Backpressure)나 대기 상황이 없이 전력을 다해 작동할 때 처리할 수 있는 최대 이론적 처리량입니다. 관찰된 실시간 처리량을 바쁘게 일한 시간의 비율(busy fraction)로 나누어 계산합니다.

  • 연산자 그래프 전체를 순회하면서 전체 클러스터 단위가 아닌 병목 연산자 위주로 정밀한 필수 병렬도를 계산하는 데 기초가 됩니다.
Concept · 02

Temporal Workflow Engine

분산 시스템에서 복잡하고 오래 실행되는 비즈니스 프로세스나 비동기 태스크를 안전한 상태 트래킹 기반으로 실행 및 조율해주는 워크플로우 오케스트레이션 엔진입니다.

  • 넷플릭스의 Flink Autoscaler는 작업당 하나의 독립적 Temporal 워크플로우를 매핑해 실행함으로써 하나의 작업 불량이 전체 스케일러 평가를 지연시키지 않도록 격리합니다.
Concept · 03

Disaggregated State (상태 분리 아키텍처)

스트림 처리 엔진에서 대용량 상태(State) 정보를 로컬 디스크가 아닌 고성능 원격 분산 스토리지에 유지하고 처리하는 Flink 2.0의 진화된 상태 관리 프레임워크입니다.

  • 작업의 스케일 인/아웃 리스케일링 과정에서 로컬 디스크로 무거운 상태 데이터를 읽고 써야 하는 Flink의 고질적인 재시작 지연 병목을 크게 완화할 해결책으로 넷플릭스가 실험을 계획하고 있습니다.
Continue reading · same source

NetflixMore from Netflix

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

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

    gRPCGraph DatabaseDistributed Systems
    3주 전
  • 분석을 위한 디바이스 사양 모델링

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

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

    vLLMTriton Inference ServerLLM Serving
    1개월 전

Related reads#ApacheFlink

Explore #ApacheFlink
토스

Apache Flink + RocksDB 튜닝으로 광고 Frequency Capping 실시간 집계를 일주일까지 확장하기

#ApacheFlink4개월 전
라인·Apache Iceberg

Hive에서 Iceberg로: 데이터 반영 속도 12배 향상의 비밀

#ApacheFlink4개월 전

Source

Netflix
Netflix
Engineering Blog

Published · August 21, 2026

Topics

Apache FlinkAutoscalingStream ProcessingTemporalDistributed Systems