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-orchestration쿠버네티스multi-tenancykueue+4

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

불은 꺼지고 시스템은 켜진다: 즉각적인 정전 대비 태세 검증

Meta는 데이터센터의 무경고 전력 상실에 대비하기 위해 **Instantaneous PowerLoss Storm**이라는 새로운 재해 대응 테스트 체계를 도입했다. 기존 시스템에 방어 심층화 전략을 적용하고, 지역 전체의 전원을 실제로 차단하는 단계적 검증을 통해 서비스·데이터·시설의 복원력을 확인했다. 목표는 한 지역 전체의 전력 상실을 개별 장애 도메인 손실만큼 안정적으로 처리하는 것이다. ## 무경고 재해에 대비한 새로운 테스트 패러다임 - 기존의 허리케인, 산불, 전력·네트워크 장애 대응책은 사전 경보가 있을 때 효과적이다. - 그러나 순간적인 전력 상실처럼 전혀 예고되지 않는 재해는 기존 전략만으로 대응하기 어렵다. - Instantaneous PowerLoss Storm은 Meta의 기존 Disaster Readiness(재해 대비) “Storm” 프로그램에 추가된 최종 방어선이다. - 알려진 위험뿐 아니라 새롭게 등장하거나 아직 발견되지 않은 위험까지 검증 대상으로 삼는다. ## 데이터센터 전 계층에 적용한 방어 심층화 - 전력 상실 내성을 데이터센터의 전체 스택에 내장했다. - 기계·전기 설비 - 서버 랙 - 스토리지와 컴퓨트 - Twine 컨테이너 오케스트레이터 - 랙 전원이 끊겨도 배터리와 Power Loss Siren(PLS)을 이용해 메모리 데이터를 보존할 수 있도록 했다. - Twine 서비스 간에는 지역 전체에서 동작하는 비동기 신호 체계인 Unavailability Event(UE)를 구축했다. - 기존 기능은 단일 데이터센터의 장애 도메인에서 검증되어 있었지만, 여러 데이터센터가 연결된 지역 전체 장애에서는 다음 문제가 추가로 발생했다. - 장애 규모가 일반 장애 도메인보다 약 50~60배 큼 - 서비스 복제본 배치 문제 - 수백만 개 서비스의 동시 재시작과 자동 발견 - 전원이 꺼진 지역을 스스로 부팅해야 하는 문제 ## 전체 지역 부팅과 순환 의존성 문제 - Twine의 Scheduler, Allocator, Broker, Zelos 같은 제어 플레인 서비스는 다른 서비스를 시작하기 위한 필수 구성요소다. - 전체 지역이 동시에 부팅될 때 제어 플레인 서비스끼리 서로를 필요로 하는 순환 의존성, 즉 “ouroboros” 문제가 발생할 수 있다. - 이를 해결하기 위해: - 핵심 시작 의존성을 식별했다. - CI/CD에서 Belljar 테스트를 지속적으로 실행해 의존성 문제를 조기에 발견했다. - 예기치 않은 순환 의존성을 끊을 수 있도록 Twine recovery kit을 제공했다. - 이 복구 키트는 Twine 자체를 구동하는 서비스에 대한 “jumpstart” 역할을 한다. - Belljar, Twrko, recovery kit을 함께 사용해 지역 전체 부팅 시 발생할 수 있는 순환 의존성 위험을 줄였다. ## 제어 플레인을 종료시키는 ‘부메랑’ 문제 - UE는 서비스 종료와 복구를 조정하는 신호지만, 이 신호를 생성·전달하는 제어 플레인 자체가 UE에 의해 종료될 수 있었다. - 그러면 일부 서비스가 종료 신호를 받지 못한 채 고아 상태로 남을 수 있다. - 특정 서비스를 UE 전달 대상에서 제외하는 복잡한 방식 대신, 전력 관련 UE를 제어 플레인 서비스가 무시하도록 설계했다. - 단순한 예외 처리로 시스템 복잡도와 유지보수 부담을 낮췄다. ## 신뢰성과 개발 속도 사이의 절충 - 순간 장애에 완벽히 대응하려는 설계는 과도한 엔지니어링이나 정상 운영 중 오탐 위험을 만들 수 있다. - 따라서 반드시 방지해야 할 영향과 감수할 수 있는 영향을 구분했다. - 반드시 방지해야 하는 영향: - 스토리지·데이터베이스 데이터 손실 - 데이터센터 기계·전기 설비의 영구 손상 - 단일 지역을 넘어 지속되는 광범위한 장애 - 허용 가능한 영향: - 일시적인 서비스 오류 - 사전에 정한 한도 내의 랙 장애 - 서비스 라우팅 테이블의 제한된 최신성 저하 - 지역 장애 감지의 일시적인 지연 - 사후 복구가 어렵거나 합리적인 MTTR 내에 완화할 수 없는 문제를 허용 범위 밖으로 정의했다. ## 단계적 검증으로 위험과 폭발 반경 축소 - 전원을 직접 차단하는 테스트는 큰 위험을 동반하므로 점진적인 검증 방식을 택했다. - 검증 단계는 다음과 같다. - 신규·사전 운영 지역에서 의존성 등 독립적인 문제를 먼저 테스트 - 운영 지역을 복제한 shadow 지역에서 실험 - 가장 작고 새로운 운영 지역에서 실제 전력 차단 수행 - 이후 스토리지, AI, 데이터 웨어하우스가 위치한 대규모 운영 지역까지 확대 - 최종 단계의 전력 차단 훈련을 Instantaneous PowerLoss Storm이라고 명명했다. ## 실제 Storm 실행 방식 - 전체 지역에 전력 공급 장애를 주입해 즉시 전원을 차단한다. - 실제 장애처럼 보이도록 테스트 전에 선제적인 보호 조치를 최소화했다. - 현실적인 사고 상황의 MTTR을 반영한 뒤, 영향을 받은 지역을 전역 컨트롤러와 스케줄러에서 격리하는 “drain” 조치를 수행했다. - 반복적인 훈련을 통해 인프라와 엔지니어가 지역 전체 장애를 개별 장애 도메인 장애처럼 처리하도록 개선하고 있다. ## 실용적인 결론 대규모 인프라의 무경고 장애 대비에는 단일 복구 기능보다 시설부터 오케스트레이터까지 이어지는 방어 심층화가 중요하다. 특히 전체 시스템 부팅 시의 순환 의존성과 제어 플레인 보호를 사전에 검증하고, 작은 환경에서 시작해 실제 운영 지역으로 단계적으로 확대하는 방식이 안전성과 개발 속도를 함께 확보하는 현실적인 접근이다.

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

container-orchestrationCI/CD분산 시스템fault-tolerance+3

datadog·2025년 6월 17일원문

수천 개의 워크로드 컨테이너에 빠르고 안정적인 구성 배포를 확장한 방법 (새 탭에서 열림)

데이터독(Datadog)은 초당 수백만 개의 로그를 처리하는 대규모 분산 환경에서 사용자가 설정한 로그 파싱 규칙 등 '컨텍스트 데이터'를 수천 개의 컨테이너에 실시간으로 전파해야 하는 과제에 직면해 있습니다. 단순히 데이터베이스를 조회하거나 짧은 주기의 캐시를 사용하는 방식은 대규모 트래픽 환경에서 DB 부하와 지연 시간 문제를 야기하며, 이를 해결하기 위해 데이터독은 안정성과 확장성을 모두 고려한 독자적인 설정 전파 시스템을 구축했습니다. ### 실시간 설정 전파의 기술적 도전 과제 * **컨텍스트 데이터의 중요성**: 로그 파싱 규칙, 민감 데이터 스캐너 설정, 저장 쿼터 등 사용자별(per-tenant) 설정 데이터는 데이터독 서비스가 고객 데이터를 처리하는 방식의 핵심을 이룹니다. * **낮은 지연 시간 요구**: 사용자가 UI에서 설정을 변경하면 '라이브 테일(Live Tail)'과 같은 실시간 서비스에 즉각 반영되어야 하며, 이는 수천 개의 워크로드 컨테이너가 변경 사항을 거의 동시에 인지해야 함을 의미합니다. * **고도의 신뢰성**: 컨텍스트 데이터는 데이터 처리에 필수적이므로, 이 데이터를 공급하는 시스템은 어떤 장애 상황에서도 견고하게 동작해야 하는 '록 솔리드(rock solid)'한 수준의 안정성이 요구됩니다. ### 단순 접근 방식의 한계 * **온디맨드 조회의 불가능**: 로그가 들어올 때마다 DB에서 설정을 읽어오는 방식은 초당 수십만 건의 읽기 요청을 발생시켜 DB가 감당할 수 없는 수준의 부하를 줍니다. * **로컬 캐싱의 트레이드오프**: 각 컨테이너에 데이터를 캐싱하고 일정 시간마다 갱신하는 방식은 DB 부하를 줄일 수 있지만, 캐시 만료 시간만큼 설정 반영이 늦어져 사용자 경험을 저해합니다. 캐시 기간을 늘릴수록 지연은 심해지고, 줄일수록 DB 부하는 급증하는 딜레마가 발생합니다. ### V1 아키텍처: Kafka 기반 캐시 무효화 * **작동 원리**: 사용자가 설정을 변경하면 DB에 저장된 후 Kafka를 통해 무효화 알림(invalidation message)이 브로드캐스트됩니다. 이를 수신한 모든 워크로드 컨테이너는 해당 테넌트의 데이터만 DB에서 다시 읽어와 캐시를 갱신합니다. * **장점**: 수년간 잘 작동했으며, 평상시 DB 읽기 횟수를 최소화하면서도 설정 변경 시에만 신속하게 업데이트를 수행할 수 있었습니다. * **확장성 한계**: 데이터독의 규모가 커짐에 따라 한 번의 설정 변경이 수천 개의 컨테이너에서 동시에 DB 조회를 일으키는 '천둥 벌거숭이(thundering herd)' 문제를 야기했습니다. 이는 중앙 DB에 막대한 부하를 주며, DB 장애 시 설정 전파가 완전히 중단되는 취약점을 드러냈습니다. 사용자 설정 변경이 실시간으로 반영되어야 하는 대규모 분산 시스템에서는 중앙 집중식 데이터베이스에 직접 의존하는 구조를 탈피해야 합니다. 워크로드 컨테이너가 DB에 직접 접근하여 데이터를 가져오는 대신, 변경 사항을 안정적으로 밀어넣어 주거나 중간에 완충 역할을 하는 계층을 두어 DB 부하를 격리하고 시스템 전체의 복원력을 높이는 설계가 권장됩니다.

container-orchestration데이터베이스 설계datadog옵저버빌리티+4