[reinvent 2024] Netflix의 클라우드 급격한 부하 처리 방법

들어가며

Netflix처럼 전 세계적으로 수많은 사용자를 가진 서비스가 갑작스러운 트래픽 급증을 어떻게 처리하는지 항상 궁금했습니다. 특히, AWS를 기반으로 한 대규모 시스템 운영 경험이 부족한 저에게, 이번 세션은 실질적인 기술적 통찰을 얻을 좋은 기회라고 생각했습니다.

Netflix의 트래픽 급증 관리 – 예측과 사전 대응의 중요성

Netflix는 전 세계 6억 명 이상의 시청자를 보유한 서비스로, 다양한 시간대와 지역에서 사용자들이 콘텐츠를 소비합니다. 일반적으로 Netflix의 트래픽은 하루 중 특정 시간대에 피크를 이루며, 비교적 예측 가능한 패턴을 따릅니다.

그러나 특정 이벤트나 상황에서는 이와 같은 패턴을 뛰어넘는 갑작스러운 트래픽 급증(sudden traffic spike)이 발생합니다. 예를 들어, 인기 타이틀의 신규 시즌이 공개되거나, 글로벌 스포츠 이벤트가 종료된 직후, 또는 다른 스트리밍 서비스의 장애로 인해 대규모 사용자가 몰리는 경우입니다.

Netflix의 페일오버 과정은 두 단계로 나뉩니다: Evacuation(리전 트래픽 비우기)와 Restore(트래픽 복원)입니다.

1. Evacuation
   • 트래픽이 문제가 발생한 리전에서 다른 리전으로 이동되며, 이동된 리전에는 기존 대비 최대 2배의 트래픽이 유입됩니다.
   • 이 과정은 1분 이내에 완료되며, 긴 꼬리 요청(long-tail traffic)은 최대 5분까지 걸릴 수 있습니다.
   • “Intelligent steering(지능형 분산)”을 통해 급증을 완화합니다.
     
     
2. Restore
   • 문제가 해결된 리전에 트래픽을 다시 복구할 때는 최대 100배 트래픽이 들어올 수 있습니다.
   • 복구 과정은 5~10분에 걸쳐 점진적으로 이루어지며, 트래픽 급증으로 인한 시스템 과부하를 방지합니다.

Netflix는 이러한 트래픽 급증을 처리하기 위해 예측 기반 사전 스케일링(Predictive Pre-Scaling)을 활용하여 각 리전의 리소스를 미리 확장하거나, 트래픽 셰이커(Traffic Shaker)를 통해 트래픽을 균등하게 분산합니다.

Netflix는 트래픽 급증 상황에서 서비스의 안정성을 보장하기 위해 예측 기반 사전 스케일링(Predictive Pre-Scaling)을 활용합니다. 위 이미지에서 보이듯, Netflix는 예상되는 트래픽 패턴에 맞춰 사전에 리소스를 확장하고, 필요 시 빠르게 줄이는 방법을 통해 효율적인 자원 관리를 실현하고 있습니다.

사전 스케일링의 핵심 단계

1. Prescale(사전 스케일링):
   
   Netflix는 트래픽이 증가할 것으로 예상되는 시점에 앞서 서비스 인스턴스를 미리 확장합니다.
   
   예를 들어, 인기 드라마의 신규 시즌이 오후 7시에 공개될 예정이라면, 오후 6시부터 인스턴스를 늘려 예상 부하를 수용할 준비를 합니다. 이를 통해 트래픽 급증이 발생하더라도 시스템 과부하 없이 원활한 사용자 경험을 제공합니다.
   
   
2. Spike(트래픽 급증):
   
   트래픽이 예상대로 급증하면, 이미 확장된 리소스가 부하를 안정적으로 처리합니다.
   
   이 과정은 AWS의 오토스케일링 기능을 보완하며, 급증으로 인해 새롭게 리소스를 프로비저닝(provisioning)하는 시간 지연을 최소화합니다.
   
   
3. Downscale(스케일 축소):
   
   트래픽이 줄어드는 시점에서는, 확장했던 인스턴스를 점진적으로 줄여 불필요한 리소스 비용을 절감합니다.
   오토스케일링 메커니즘은 이 축소 과정에서도 원활한 트래픽 처리를 유지하도록 설계되어 있습니다.

실시간 대응 – 빠른 감지와 확장

Netflix는 급격한 트래픽 급증 상황에서 실시간으로 대응하기 위해 AWS 오토스케일링을 최적화한 시스템을 운영합니다. 위 이미지에서 오토스케일링(Auto Scaling)을 통한 급격한 요청량 증가를 어떻게 처리하는지를 보여주고 있으나, 몇가지 문제점을 확인할 수 있습니다. 

Netflix는 단기간 내에 60,000 RPS(Requests Per Second)의 급격한 트래픽 증가를 겪을때, 트래픽 증가를 감지하는 데 약 4분, 감지 후 새로운 인스턴스를 추가로 프로비저닝(provisioning)하고 부팅하는 데 약 6분이 소요되며 이로 인해 초기에 확장된 인스턴스가 충분하지 않아, 추가적인 확장이 필요하여 이러한 과정이 반복적으로 일어나는 비효율이 나타나게 됩니다.

이로 인해 전체 스케일링 시간은 20분 이상 걸리며, 사용자가 성능 저하를 경험할 위험이 높아졌습니다.

이러한 문제를 해결하고 갑작스러운 트래픽 급증에 신속히 대응하기 위해 복구 시간(Time-to-Recovery)을 구성하는 주요 단계를 분석하고 최적화하는 데 주력합니다. 위 이미지는 복구 시간의 구성 요소와 각 단계에서 발생하는 작업을 시각적으로 보여줍니다. 이를 통해 Netflix는 복구 시간을 최소화하고 서비스 중단을 방지합니다.

복구 시간은 다음 다섯 가지 주요 단계로 나뉩니다:

1. 감지(Detection):
   • Scaling Alarm Triggers: 트래픽 급증이 발생했음을 감지하고 확장을 시작하기 위한 경보가 트리거됩니다.
     
     
2. 제어 플레인(Control Plane):
   • Hardware Online: AWS의 제어 플레인에서 필요한 하드웨어 인스턴스를 온라인으로 프로비저닝.
     
     
3. 시스템 시작(System Startup):
   • Kernel and Base SystemD Units Started: 커널 및 기본 시스템 구성 요소가 초기화됩니다.
     
     
4. 애플리케이션 시작(Application Startup):
   • Microservices Started: 마이크로서비스가 시작되고 로드 밸런서에 연결됩니다.
     
     
5. 트래픽 유입(Traffic):
   • 확장된 리소스가 트래픽을 수용하기 시작하고, 안정적인 서비스가 복구됩니다.

AWS CloudWatch의 기본 모니터링 주기는 5분 해상도로, 급격한 트래픽 변화를 실시간으로 반영하지 못했습니다. 따라서 Netflix는 기존 CPU 기반의 표준 메트릭(Standard Metrics) 대신, RPS(Requests Per Second)와 같은 사용자 트래픽 중심의 커스텀 메트릭(Custom Metrics)을 활용하여 더 빠르고 정확하게 트래픽 급증을 감지합니다.

우리는 이러한 방식을 고해상도 감지(Higher Resolution Metrics)이라고 부르고, 복구시간(Time-to-Recovery)을 구성하는 주요 요인을 분석하고 최적화했습니다. 이를 통해 Netflix는 5초 해상도로 데이터를 수집하고 분석하여, 급격한 트래픽 증가를 더 빠르게 감지할 수 있게되어 감지 부분에서 기존 대비 3배 빠르게 개선되었습니다.

추가적으로 EC2 인스턴스의 부팅시간을 단축시키기 위해서 systemd-analyze를 활용하여 서비스 시작 순서를 분석하였습니다. 시스템 서비스는 순차적으로 시작되며, 하나의 서비스가 완료되어야 다음 서비스가 시작되기 때문에 서비스 간 의존성이 복잡할 경우 부팅 시간이 길어지는 원인이 됩니다. 이를 해결하기 위해서 systemd-analyze blame 명령을 통해 각 서비스의 시작 시간을 측정하여 의존성이 없는 서비스는 병렬로 실행되도록 설정 변경하였습니다.

또한 애플리케이션 시작 시간에서 많은 병목이 발생하고 있다는 것을 확인할 수 있었습니다. p90(상위 10%)의 부팅 시간이 무려 18분에 달하는 서비스가 발견되었으며, 이는 전체 스케일링의 속도를 방해하는 주요 요소였습니다. 이러한 원인은 특정 서비스의 과도한 의존성 설정, 최적화되지 않은 초기화 로직, 시스템 및 네트워크 병목 현상으로 인해 발생하고 있었습니다.

Netflix는 p90 이상에 속하는 서비스의 부팅 시간을 집중적으로 분석하여 서비스의 의존성, 초기화 로직, 네트워크 연결 상태를 면밀히 조사하였고 이를 통해 불필요한 초기화 작업 제거 또는 지연 실행 방식 도입하며, 모든 서비스가 특정 부팅 시간 목표를 충족하도록 요구할 수 있는 SLA를 도입하였습니다.

이러한 최적화 작업으로 인해 갑작스러운 트래픽 요청이 발생하더라도 신속하게 감지하고 빠른 오토스케일링(Auto Scaling) 확장으로 인해 3분안에 모든 서비스가 안정적으로 처리될 수 있게 되었습니다.

우선순위 로드 샤딩과 회복력 강화

Netflix는 트래픽 급증 상황에서도 서비스의 안정성을 유지하기 위해 우선순위 로드 샤딩(Prioritized Load Shedding)과 시스템 회복력 강화(Resilience Enhancement) 전략을 채택했습니다. 이 접근법은 한정된 자원을 가장 중요한 요청에 우선적으로 할당하고, 시스템 전체가 과부하로 인해 실패하는 상황을 방지하는 데 중점을 둡니다.

로드 셰딩은 시스템이 과부하 상태에 놓였을 때 일부 요청을 거부하거나 지연 처리하여 전체 시스템의 안정성을 유지하는 기법입니다.

다만 기존 로드 셰딩의 경우 요청 간 우선순위를 설정하지 않고 일괄적으로 거부하는 방식은 중요한 요청까지 차단할 위험이 있으며, 모든 요청을 동일하게 처리하다 보면 시스템이 과부하 상태로 진입하여 혼잡 실패(Congestive Failure)를 초래할 가능성이 높습니다.

이러한 문제를 해결하기 위해서 우선순위 로드 샤딩(Prioritized Load Shedding)를 사용하게 되었습니다.

우선순위 로드 셰딩은 대규모 트래픽 급증 상황에서 시스템 안정성을 유지하기 위해 Netflix가 도입한 핵심 기술입니다. 이는 한정된 시스템 자원을 가장 중요한 요청에 우선적으로 할당하고, 중요하지 않은 요청은 선택적으로 차단함으로써 혼잡 실패(Congestive Failure)를 방지하는 데 중점을 둡니다. 이 기법은 클라우드 기반 서비스가 안정적인 사용자 경험을 유지하면서도 효율적으로 리소스를 사용할 수 있도록 설계되었습니다.

Netflix는 요청을 중요도에 따라 세 가지로 분류합니다. 이 우선순위는 시스템 리소스가 제한된 상황에서도 핵심 기능이 유지될 수 있도록 설계되었습니다.

1. Critical Requests (필수 요청):
   • 동영상 스트리밍 시작, 유지 등 핵심 서비스에 필수적인 요청.
   • 사용자가 즉각적인 영향을 받는 요청으로, 처리 우선순위가 가장 높습니다.
     
     
2. Degraded Requests (일반 요청):
   • 사용자 경험을 개선 하지만, 서비스의 핵심 기능에 필수적이지 않은 요청.
   • 필요 시 차단 가능하며, 우선순위는 Critical Requests보다 낮습니다.
     
     
3. Best-Effort Requests (최소 우선순위 요청):
   • 디바이스의 사전 로드, 백그라운드 작업 등 시스템 성능에 큰 영향을 미치지 않는 요청.
   • 시스템 부하가 높아질 경우 가장 먼저 차단됩니다.

Netflix의 우선순위 로드 셰딩은 시스템 부하 상태를 실시간으로 모니터링하여, 중요도가 낮은 요청을 차단함으로써 리소스를 확보하는 방식으로 작동합니다.

• 정상 상태:
  • 모든 요청이 성공적으로 처리됩니다. 이 단계에서는 로드 셰딩이 활성화되지 않습니다.
    
    
• 성공 버퍼 진입:
  • 시스템 부하가 증가함에 따라 중요도가 낮은 요청(Best-Effort Requests)이 점진적으로 차단됩니다.
  • 이를 통해 핵심 요청을 위한 리소스를 확보합니다.
    
    
• 실패 버퍼 진입:
  • 부하가 성공 버퍼를 넘어 실패 버퍼로 진입하면, 일부 일반 요청(Degraded Requests)도 차단됩니다.
  • 이 단계에서는 Critical Requests가 우선적으로 처리됩니다.
    
    
• 혼잡 실패 방지:
  • 시스템 부하가 실패 버퍼를 초과하지 않도록 우선순위 로드 셰딩이 지속적으로 작동하며, 시스템 전체가 멈추는 상황을 방지합니다.

Netflix는 전 세계적으로 대규모 트래픽을 안정적으로 처리하기 위해 다양한 전략을 활용합니다. 그중에서도 Fallback과 Cross-Region Shifting은 시스템 안정성과 성능 유지를 위해 중요한 역할을 합니다. 이 두 가지 기법은 과부하나 특정 백엔드의 장애 상황에서도 사용자 요청을 효과적으로 처리하고, 서비스의 연속성을 보장하기 위해 설계되었습니다.

Netflix는 Zuul이라는 API Gateway를 통해 모든 요청을 관리합니다. Zuul은 각 요청에 우선순위 값을 할당하여 중요도를 판단하고, 이를 기반으로 적절한 백엔드 서비스로 요청을 라우팅합니다. 예를 들어, 우선순위가 높은 요청은 동영상 재생과 같은 핵심 서비스에 해당하며, 중간 우선순위 요청은 사용자 환경 데이터를 로드하는 작업에, 우선순위가 낮은 요청은 배경 데이터를 처리하는 작업에 사용됩니다. 이러한 구조는 중요한 작업이 우선적으로 처리될 수 있도록 하며, 시스템 리소스를 효율적으로 활용할 수 있게 합니다.

Fallback은 특정 백엔드 서비스가 과부하 상태에 있거나 장애가 발생한 경우, 이를 해결하기 위해 작동합니다. 시스템은 먼저 과부하 상태를 감지합니다. 예를 들어, Backend A가 CPU 사용량 초과나 요청 실패율 증가와 같은 과부하 징후를 보일 때, Zuul은 이를 즉시 감지합니다. 이후, 과부하 상태에서는 우선순위가 낮은 요청(Prio=17, Prio=3)을 차단하여 우선순위가 높은 요청(Prio=2)이 성공적으로 처리될 수 있도록 리소스를 확보합니다. 만약 Backend A를 사용할 수 없는 경우, 시스템은 자동으로 동일한 데이터를 제공할 수 있는 Backend B로 요청을 전환합니다. 이 과정은 장애 상황에서도 중요한 서비스가 지속적으로 제공될 수 있도록 보장합니다.

Netflix는 글로벌 서비스 운영을 위해 AWS의 다수의 리전을 활용하며, 각 리전은 활성-활성(Active-Active) 상태를 유지합니다. Cross-Region Shifting은 과부하 상태에서 다른 리전으로 요청을 이동시키는 전략으로, 글로벌 아키텍처의 핵심 요소 중 하나입니다.

이 전략은 특정 리전(예: us-east-2)이 과부하 상태에 놓였을 때, 다른 리전(예: us-east-1)으로 요청을 전환하여 문제를 해결합니다. 전환된 요청은 우선순위가 낮아질 수 있으며(Prio=17 → Prio=99), 이는 다른 리전의 성능 저하를 방지하는 역할을 합니다. 또한, Netflix는 Cassandra 데이터베이스를 활용하여 전 세계 리전 간 데이터를 실시간으로 동기화합니다. 이로 인해 요청이 다른 리전으로 이동하더라도 동일한 데이터를 액세스할 수 있어 사용자 경험에 차질이 없습니다.

결론

Netflix의 클라우드 트래픽 관리 전략은 단순한 확장이 아니라, 예측과 대응을 조화롭게 설계한 점에서 큰 인사이트를 주었습니다. 이번 세션에서는 Netflix가 AWS의 다양한 도구를 활용해 서비스 안정성을 유지하는 방식을 자세히 이해할 수 있었습니다. 특히, 예측 기반 사전 스케일링과 빠른 오토스케일링, 그리고 우선순위 로드 셰딩의 조합은 대규모 트래픽 급증 상황에서도 안정적인 서비스 운영을 가능하게 한다는 점이 인상적이었습니다.

가장 큰 배움은 사전 대응(Proactive Approach)과 실시간 대응(Reactive Approach)의 균형입니다. Netflix는 트래픽 증가를 미리 예측하고 준비하는 동시에, 급증 상황이 발생하면 빠르게 감지하고 필요한 리소스를 신속히 확장합니다. 이러한 접근은 단순히 문제를 해결하는 것을 넘어, 시스템 전반의 회복력(resilience)을 강화하는 데 초점이 맞춰져 있음을 보여줍니다.

또한, 우선순위 로드 샤딩(Prioritized Load Shedding)은 모든 요청이 동일하지 않다는 점을 고려한 전략으로, 서비스의 핵심 기능을 보호하면서도 덜 중요한 요청을 효율적으로 관리하는 방법을 제시합니다. 이는 단순히 리소스를 더 추가하는 것 이상의 효과적인 트래픽 관리 방법을 탐구하는 데 중요한 시사점을 제공합니다.결론적으로, Netflix의 사례는 단순히 대규모 서비스 운영의 성공 사례를 넘어서, 모든 규모의 시스템 설계에 유용한 교훈을 제공합니다. 끊임없는 테스트와 반복적인 개선이 회복력 있는 시스템의 핵심이라는 메시지를 가슴 깊이 새기며, 이를 실무에 적용해 나갈 계획입니다.