
자체 빌드에서 오픈소스 Flink Autoscaler와 Temporal의 결합으로 진화한 실전 마이그레이션 기술기
이 글은 대규모 실시간 스트림 처리를 안정적으로 수행하기 위해 넷플릭스가 겪은 두 가지 플링크 오토스케일러의 진화 여정을 다룹니다. 기존 외부 관찰식 메트릭 시스템의 한계를 극복하기 위해 작업 내부 상태를 정확히 진단하는 Apache Flink Autoscaler를 도입하고, 이를 Temporal 워크플로우 엔진과 결합하여 대규모 인프라에서 격리성과 안정성을 확보한 실전 노하우를 공유합니다.
대규모 Apache Flink 파이프라인을 구축 중이거나 트래픽 변동이 잦은 대형 클라우드 데이터 파이프라인의 비용 최적화 및 오토스케일링 설계를 고민하는 데이터 플랫폼 엔지니어에게 적극 추천합니다.
넷플릭스는 30,000개 이상의 Flink 작업을 운영하면서 대형 상태 기반(stateful) DAG 및 다중 연산자 작업의 복잡한 스케일링을 수동으로 관리해야 하는 비효율성을 안고 있었습니다. 기존에 자체 개발했던 외부 메트릭 기반 오토스케일러는 컨테이너 수준의 거친 정보만 분석할 수 있어 각 연산자의 개별 부하와 병목을 세밀하게 파악하기 어려운 한계가 있었습니다.
넷플릭스는 작업 내부의 실제 처리량(TPR)을 분석하는 오픈소스 'Apache Flink Autoscaler' 핵심 라이브러리를 도입하고, 이를 자사 플랫폼 환경에 맞게 Spring Boot와 Temporal 워크플로우 기반 아키텍처로 통합했습니다. 대규모 스케일 처리를 위해 Flink JobManager의 메트릭 캐싱 및 필터링 성능을 개선하고, 포워드 체이닝 유지 및 싱크 백프레셔 감지 등의 플랫폼 특화 기능을 기여 및 커스텀 구현했습니다.
새로운 오픈소스 기반 오토스케일러 도입을 통해 넷플릭스의 클라이언트 텔레메트리 및 로깅 팀은 연간 Flink 컴퓨팅 비용을 58%(약 110만 달러) 절감하는 성과를 거두었습니다. 개별 Flink 작업별로 오토스케일러의 평가 단위를 격리하여 평가 루프의 장애 전파 문제를 방지했으며, 최대 3,000개의 서브태스크를 가진 대형 작업도 무리 없이 자동으로 스케일링할 수 있게 되었습니다.
Trade-off
너무 공격적인 다운스케일링은 일시적인 트래픽 변동 시 자원 부족으로 인한 재지연 및 스케일링 루프를 반복 유발할 수 있어, 넷플릭스는 효율성을 소폭 양보하고 목표 사용률(Target Utilization)을 커뮤니티 권장값인 0.7 대신 0.45로 보수적으로 설정했습니다. 또한 현재 스케일링에 따른 병목의 핵심은 스케일러의 알고리즘 계산 속도가 아니라 Flink 엔진 자체의 중단, 상태 복구 및 재시작 시간에 종속된다는 단점이 존재합니다.
각 데이터 처리 연산자가 백프레셔(Backpressure)나 대기 상황이 없이 전력을 다해 작동할 때 처리할 수 있는 최대 이론적 처리량입니다. 관찰된 실시간 처리량을 바쁘게 일한 시간의 비율(busy fraction)로 나누어 계산합니다.
분산 시스템에서 복잡하고 오래 실행되는 비즈니스 프로세스나 비동기 태스크를 안전한 상태 트래킹 기반으로 실행 및 조율해주는 워크플로우 오케스트레이션 엔진입니다.
스트림 처리 엔진에서 대용량 상태(State) 정보를 로컬 디스크가 아닌 고성능 원격 분산 스토리지에 유지하고 처리하는 Flink 2.0의 진화된 상태 관리 프레임워크입니다.




