트래픽 셰이핑이 Kubernetes 스케일링 전략에서 빠진 이유

Author: Thomas Mathew (opens in a new tab) Date: March 12, 2026

2019년, Netflix는 회원들이 콘텐츠를 재생할 수 없게 된 장애를 경험했습니다. 동영상 재생, UI 애니메이션, 분석, A/B 테스트 로깅 등 모든 요청이 과부하된 동일 인프라를 놓고 경쟁했습니다. 해결책은 더 많은 용량이 아니었습니다. 바로 우선순위 기반 부하 차단이었습니다. 낮은 우선순위의 트래픽(로깅, 분석, UI 개선)을 자동으로 차단하면서 핵심 경험인 동영상 재생을 유지하는 시스템이었습니다. 이를 배포한 지 며칠 후, 유사한 사고가 발생했습니다. 하지만 이번에는 회원들이 전혀 눈치채지 못했습니다. (opens in a new tab)

Netflix만의 이야기가 아닙니다. Google, Uber, LinkedIn, Shopify, Agoda 모두 프로덕션에서 우선순위 기반 트래픽 셰이핑을 운영하고 있습니다. 이는 대규모에서 검증된 표준 신뢰성 패턴이 되었습니다. 하지만 Kubernetes 생태계에서 대부분의 팀은 아직 이를 갖추지 못하고 있습니다.

오토스케일러는 용량을 처리합니다. 트래픽 셰이핑은 우선순위를 처리합니다. 두 가지 모두 없다면, 불가능한 선택에 직면하게 됩니다. 안전을 위해 과잉 프로비저닝(리소스의 30-50% 낭비)하거나, 급증 시 성능 저하를 감수하는 것입니다.

검증된 패턴: 업계 선두 기업들의 방법

우선순위 기반 부하 차단은 새로운 아이디어가 아닙니다. 초당 수백만 건의 요청을 처리하는 기업들이 사용하는 검증된 신뢰성 패턴입니다. 이 기업들의 공통점은: 모든 트래픽이 동등하게 만들어지지 않았으며, 과부하 시 동등하게 취급하는 것이 잘못된 기본값이라는 것입니다.

Netflix: 점진적 우선순위 스코어링

Netflix는 모든 요청에 0(최고)에서 100(최저)까지의 우선순위 점수 (opens in a new tab)를 부여합니다. 시스템 부하가 증가함에 따라 가장 낮은 우선순위 트래픽부터 점진적으로 차단이 확장됩니다. 35% 과부하 시, 95점 이상의 요청만 차단됩니다. 80% 과부하 시, 임계값은 약 50으로 낮아집니다. 동영상 재생 요청은 0에 가까우며, 절대 차단되지 않습니다. 이 방식은 게이트웨이 수준(Zuul)에서 서비스 수준으로 진화하여, 각 서비스가 자체 우선순위 결정을 제어할 수 있게 되었습니다.

Google: 요청 중요도 전파

Google의 SRE 관행은 모든 요청에 "핵심 사용자 대면"에서 "비핵심 백그라운드"까지의 중요도 수준 (opens in a new tab)을 표시합니다. 중요도는 RPC 시스템을 통해 자동으로 전파됩니다. 요청 A가 서비스 B와 C를 호출하면, 두 서비스 모두 A의 우선순위를 상속받습니다. 서비스가 과부하되면, 가장 낮은 중요도부터 먼저 차단 (opens in a new tab)합니다. Google은 또한 부하 하에서 우아한 성능 저하를 적용합니다. 검색이 전체 인덱스를 조회하는 대신 캐시된 결과를 반환하여, 완전히 실패하는 대신 낮은 품질로 사용자 경험을 보존합니다.

Uber: 동적 부하 차단 (Cinnamon)

Uber는 QALM (QoS-Aware Load Management) (opens in a new tab)을 구축했습니다. 요청을 계층으로 순위를 매기고 P99 지연 지표를 사용하여 동시성 제한을 동적으로 조정하는 프레임워크입니다. Cinnamon 부하 차단기가 활성화되면, 지연 민감 작업이 영향받기 전에 낮은 우선순위 트래픽이 차단됩니다. 과부하 시 결과: 처리량 약 80% 증가, 중요 작업의 P99 지연 약 70% 감소.

LinkedIn: Hodor - 세 가지 트래픽 계층

LinkedIn의 Hodor 시스템 (opens in a new tab)은 모든 트래픽을 세 가지 계층으로 분류합니다: 저하 불가능 (회원 대면 요청은 절대 차단 불가), 저하 가능 (낮은 품질로 제공 가능), 선택적 (오프라인/니어라인 시스템은 사용자 영향 없이 차단 가능). 과부하 감지기는 각 프로세스 내에서 실행되며, 모든 인바운드 요청을 이러한 계층에 대해 조회합니다.

공통 패턴

구현 방식은 다르지만, 모든 기업이 동일한 원칙으로 수렴합니다:

1. 비즈니스 우선순위에 따라 요청을 분류: 모든 트래픽이 동등하게 중요하지 않습니다
2. 가장 낮은 우선순위부터 점진적으로 차단: 모든 비용을 치르더라도 핵심 경로를 보호합니다
3. 실시간 신호 사용: 동시성, 지연, 에러율, 리소스 압박
4. 응답 자동화: 트래픽 급증 시 사람이 대응하기엔 너무 느립니다

Kubernetes의 격차

업계 합의에도 불구하고, 대부분의 Kubernetes 클러스터는 우선순위 기반 트래픽 셰이핑 없이 운영됩니다. 팀들은 이 문제를 위해 설계되지 않은 도구에 의존합니다:

속도 제한은 비즈니스 컨텍스트에 무관심합니다. 초당 요청이 무엇인지 상관없이 차단합니다. 속도 제한기는 결제 제출과 프리페치 호출을 동일하게 취급합니다. 이것이 바로 Netflix, Google, Uber가 우선순위 인식을 추가하여 해결한 문제입니다.

서킷 브레이커는 이진법적입니다. 서비스가 비정상일 때 작동하여 모든 트래픽을 차단합니다. 점진적인 응답이 없습니다. 서킷 브레이커는 "분석 트래픽은 차단하되 결제 흐름은 유지"라고 말할 수 없습니다. 이것이 바로 LinkedIn의 Hodor가 세 가지 계층 모델로 하는 것입니다.

EnvoyFilter YAML은 정적이고 수동입니다. Istio의 EnvoyFilter는 맞춤형 트래픽 규칙을 작성할 수 있게 하지만, 실시간 워크로드 압박에 대한 인식 없이 정적 구성입니다. Uber의 Cinnamon은 실시간 P99 지연을 사용하여 임계값을 동적으로 조정합니다. 정적 YAML은 그렇게 할 수 없습니다.

격차는 지식이 아니라 구현에 있습니다. Netflix 스타일의 부하 차단기를 구축하려면 심층적인 인프라 엔지니어링이 필요합니다. Wave Flow는 이 검증된 패턴을 배포 가능한 솔루션으로 모든 Kubernetes 클러스터에 제공합니다.

Wave Flow: 검증된 패턴, Kubernetes에 바로 적용 가능

Wave Flow는 Netflix, Google, Uber가 사용하는 동일한 우선순위 기반 부하 차단 패턴을 구현하지만, 기존 서비스 메시 프록시(Istio, Envoy, Kong, NGINX)에 직접 통합되는 배포 가능한 WebAssembly(WASM) 모듈로 제공됩니다. 맞춤형 인프라 없이. ~0.1ms의 결정 오버헤드.

모든 인바운드 요청을 대규모에서 검증된 계층별 접근 방식을 모델로 한 네 가지 우선순위 계층으로 분류합니다:

요청은 HTTP 헤더, URL 경로 접두사, HTTP 메서드로 분류됩니다. 이는 Google이 사용하는 동일한 분류 차원(호스트명, URL 경로, 사용자 ID)입니다. 매칭되지 않은 트래픽은 기본적으로 BULK가 되어, 중요한 트랜잭션이 항상 먼저 보호됩니다.

실제 동작 방식

플래시 세일 중인 이커머스 플랫폼을 생각해보세요. Shopify가 광범위하게 작성한 시나리오 (opens in a new tab)로, 트래픽이 정상의 100배까지 급증할 수 있습니다:

• /checkout/* 및 /payment/* 경로 → CRITICAL (절대 차단 안 함)
• /cart/* 및 X-User-Tier: premium 헤더 → IMPORTANT (95% 이상에서만 차단)
• /products/* 및 /search → MODERATE (80% 이상에서 차단)
• /recommendations, /analytics → BULK (60% 이상에서 차단)

CPU 사용률이 65%에 도달하면, Wave Flow는 추천 및 분석 호출 차단을 시작합니다. Netflix가 로깅 및 A/B 테스트 트래픽을 먼저 차단하는 방식과 유사합니다. 압박이 85%로 올라가면, 상품 탐색도 제한되지만 결제는 전체 용량으로 계속 흐릅니다. 오토스케일러의 새 파드가 준비될 때까지, 전환 기간 내내 핵심 수익이 보호됩니다.

세 가지 배포 모드

Wave Flow는 기존 인프라와 통합됩니다. 서비스 메시 교체 없이:

1. 인그레스 게이트웨이 모드: 클러스터로 들어오는 모든 트래픽을 보호합니다. Istio Ingress Gateway, Kong, NGINX, Envoy Gateway, APISIX와 작동합니다.
2. 사이드카 모드: 세밀한 제어를 위한 서비스별 트래픽 셰이핑. Netflix의 게이트웨이 수준에서 서비스 수준 부하 차단으로의 진화와 유사합니다.
3. 앰비언트 메시 모드: Istio 앰비언트 메시(1.18+)를 사용한 사이드카 없는 배포. 서비스별 제어와 공유 프록시 효율성을 결합합니다.

팀에 미치는 의미

플랫폼 엔지니어링 팀을 위해

Netflix, Google, LinkedIn은 모두 내부 플랫폼에 맞춤형 부하 차단을 구축했습니다. Wave Flow는 맞춤형 엔지니어링 없이 플랫폼에 동일한 기능을 제공합니다. 플랫폼 계약의 일부가 됩니다. 모든 개발 팀이 사용하는 표준화된 4계층 트래픽 우선순위 모델. 한 번 정의하고 어디서나 배포합니다.

SRE / 신뢰성 팀을 위해

새벽 3시, 페이지가 울립니다. Wave Flow가 이미 실행 중이면, 사용률이 올라가면서 BULK 및 MODERATE 트래픽이 자동으로 조절됩니다. Netflix의 Zuul 게이트웨이가 2020년 사고 중 낮은 우선순위 트래픽을 자동으로 차단한 것과 같은 방식입니다. 여러분의 역할은 "압박 속에서 긴급 속도 제한 적용"에서 "자동화가 작동하는지 확인"으로 바뀝니다. 우아한 성능 저하가 연쇄 실패를 대체합니다.

엔지니어링 리더십을 위해

이커머스 다운타임 비용이 평균 분당 $14,056 (opens in a new tab)이고 대기업은 평균 분당 $23,750에 달하는 상황에서, 트래픽 급증 시 수익 핵심 트랜잭션을 보호하는 것은 직접적인 재무적 영향을 미칩니다. Wave Flow는 트래픽이 용량을 초과하는 순간에 수익을 창출하는 요청이 통과할 수 있도록 보장합니다.

시작하기

Wave Flow는 기존 Istio 또는 Envoy 인프라에 WASM 모듈로 배포됩니다. 서비스 메시 교체 없이, 추가 사이드카 없이, 맞춤형 코드 없이.

실용적인 롤아웃 경로:

1. 분류: 핵심 서비스를 식별하고 우선순위 계층을 할당합니다. Netflix와 LinkedIn이 우선순위 스코어링 시스템을 정의할 때 수행한 동일한 작업입니다.
2. 배포: 하나의 클러스터에 Wave Flow 정책을 적용합니다. 정상 트래픽 하에서 1-2주간 셰이핑 동작을 모니터링합니다.
3. 확장: 일관된 우선순위 정책으로 나머지 클러스터에 롤아웃합니다.

우선순위 기반 부하 차단은 Netflix, Google, Uber, LinkedIn, Shopify에서 검증된 패턴입니다. 차이점은 그 기업들이 맞춤형 시스템을 구축하는 데 수년을 보냈다는 것입니다. Wave Flow는 동일한 패턴을 배포 가능하고 구성 가능한 솔루션으로 Kubernetes 클러스터에 제공합니다.

오토스케일링은 용량을 처리합니다. 트래픽 셰이핑은 우선순위를 처리합니다. 함께, 어느 하나만으로는 해결할 수 없는 격차를 해소합니다.

Kubernetes 트래픽 관리를 다음 단계로

Kubernetes 스택에 우선순위 기반 트래픽 인텔리전스를 추가할 준비가 되셨나요?

탐색:

• Wave Flow — Kubernetes를 위한 우선순위 기반 트래픽 셰이핑
• 문의하기 — Wave Flow를 직접 확인해보세요

Wave Autoscale은 CNCF 실버 멤버이자 AWS EKS Service Ready Partner인 STCLab이 개발합니다.