넷플릭스는 왜 AWS 장애 때도 멈추지 않았을까? 아키텍처 완전 해부
넷플릭스는 AWS에서 대규모 장애가 나도 거의 멈추지 않는 서비스로 자주 거론됩니다. 수많은 이용자가 동시에 접속해도 끊김 없이 스트리밍이 되는 이유는 단순히 "서버를 많이 써서"가 아니라, 처음부터 장애를 전제로 설계된 클라우드 아키텍처 덕분입니다.
이 글에서는 넷플릭스의 전체 시스템 디자인을 한 번에 훑어보면서, 실제 AWS 리전 장애가 발생했을 때도 서비스가 살아남는 핵심 비밀까지 함께 정리해 보겠습니다. 개발자든, 클라우드 엔지니어든, 그냥 넷플릭스를 좋아하는 유저든, "서비스를 이렇게까지 탄탄하게 만들 수 있구나"를 느끼실 거예요.
넷플릭스 아키텍처 한눈에 보기: 끊김 없는 스트리밍의 비밀
넷플릭스를 켜고 재생 버튼을 누르는 그 짧은 순간 동안, 수십 개의 시스템이 동시에 움직입니다. 사용자의 기기 종류, 위치, 네트워크 상태에 따라 최적의 경로로 트래픽이 흘러가고, 추천과 결제, 프로필, 자막, 화질 선택 등이 모두 백그라운드에서 조용히 돌아갑니다.
이 모든 것을 가능하게 하는 핵심 키워드는 세 가지입니다. 바로 마이크로서비스, 클라우드 네이티브 인프라, 그리고 데이터 기반 운영입니다.
각 기능이 작은 서비스 단위로 쪼개져 있어서 일부가 망가져도 전체가 멈추지 않고, AWS를 적극 활용하면서도 특정 리전이나 특정 서비스 하나에 과도하게 의존하지 않도록 설계했습니다. 그리고 매일 쌓이는 방대한 로그와 이벤트를 분석해, 추천 품질뿐 아니라 안정성과 장애 대응 전략까지 계속 개선합니다.
사용자 요청 여정 1: ELB와 Zuul이 받쳐주는 첫 관문
넷플릭스를 실행하고 "재생"을 누르면 가장 먼저 사용자의 요청은 AWS의 ELB(Elastic Load Balancer)를 거칩니다. ELB는 들어오는 트래픽을 여러 서버로 나눠 보내 서버 한 대가 과부하로 쓰러지지 않게 막아주는 문지기 역할을 합니다.
ELB 뒤에서는 넷플릭스의 API 게이트웨이인 Zuul이 실제 "교통 정리"를 담당합니다. Zuul은 요청이 유효한지 확인하고, 누구인지 인증하고, 어떤 마이크로서비스로 보낼지 결정합니다. 또한 응답을 되돌려줄 때는 형식을 다듬어 각 기기에서 잘 보이도록 가공까지 합니다.
그 아래에는 Netty라는 비동기 네트워크 프레임워크가 깔려 있어, 동시에 엄청난 수의 HTTP 요청을 처리할 수 있습니다. 즉, "사용자가 버튼을 눌렀다"는 단순한 동작 뒤에, 고성능 네트워크 스택과 API 게이트웨이가 촘촘히 붙어 있는 구조인 셈입니다.
마이크로서비스 구조: 한 부분이 망가져도 전체는 돈다
넷플릭스 시스템 설계에서 가장 중요한 축은 마이크로서비스 아키텍처입니다. 추천, 검색, 결제, 계정, 콘텐츠 메타데이터 등 각 기능이 독립적인 서비스로 나뉘어 있어서, 하나가 문제가 생겨도 다른 서비스는 최대한 영향 없이 동작합니다.
이 구조를 안전하게 유지해 주는 대표 도구가 Hystrix 같은 서킷 브레이커입니다. 어떤 마이크로서비스가 느려지거나 응답을 하지 않으면, 서킷 브레이커가 회로를 끊어 "여기 더 이상 기대하지 말자"라고 판단하고 우회하거나 기본 응답으로 대체합니다. 이 덕분에 작은 장애가 도미노처럼 전 시스템으로 번지는 것을 막을 수 있습니다.
마이크로서비스 간 통신은 보안과 효율성을 고려해 별도 클라이언트를 통해 관리됩니다. 결국 넷플릭스의 설계 철학은 명확합니다. "절대 하나의 거대한 서비스에 목숨을 걸지 말 것."
데이터베이스와 캐시 전략: 속도와 안정성을 동시에 잡는 방법
수억 명 단위의 이용자 데이터를 다루려면, 저장소 설계부터 다릅니다. 넷플릭스는 한 가지 데이터베이스로 모두 해결하려 하지 않고, 목적에 맞게 여러 기술을 조합합니다.
사용자의 활동 기록과 콘텐츠 메타데이터처럼 규모가 크고 분산 저장이 필요한 데이터는 Cassandra 같은 NoSQL DB에 쌓습니다. 반면 결제 정보나 구독 같은 구조화된 데이터는 여전히 MySQL 같은 관계형 데이터베이스에 보관합니다.
그리고 이 모든 것 위에 넷플릭스가 자체 개발한 EVCache가 올라가 있습니다. Memcached 기반의 캐시 시스템으로, 자주 조회되는 데이터를 메모리에서 바로 꺼낼 수 있게 해 지연 시간을 크게 줄여 줍니다. 이 조합 덕분에 "데이터는 엄청 많은데 속도도 빠른" 다소 욕심 많은 요구사항을 만족시키는 것이죠.
배포와 인프라 탄탄하게 만드는 비밀: Chaos Monkey와 Titus
넷플릭스는 AWS 위에 올라가 있지만, 단순히 "인스턴스 여러 개 띄워두는 수준"이 아닙니다. 장애를 견딜 수 있는 구조를 시험하고, 자동화된 배포와 스케일링을 위해 자체적인 도구들을 사용합니다.
가장 유명한 것이 바로 Chaos Monkey입니다. 프로덕션 서버를 일부러 랜덤하게 죽여 보면서 시스템이 정말로 자동 복구되는지, 장애가 발생했을 때 서비스가 어느 정도까지 견디는지를 실전처럼 테스트합니다. 이런 문화 덕분에 실제 AWS 장애가 나도 "처음 겪는 일"이 아니라, 이미 여러 번 리허설한 상황이 되는 셈입니다.
또한 컨테이너 기반 배포를 위해 Titus라는 플랫폼을 사용합니다. Titus는 마이크로서비스를 컨테이너로 올리고, 자동으로 배포하고, 모니터링하고, 필요하면 스케일 아웃까지 도와주는 관리 도구입니다. 이 조합이 넷플릭스를 진짜 클라우드 네이티브 서비스로 만들어 줍니다.
Open Connect: 넷플릭스만의 CDN이 AWS를 넘어서는 순간
흥미로운 사실 하나. 우리가 영상을 재생할 때, 실제 비디오 스트림은 대부분 AWS에서 직접 나오지 않습니다.
넷플릭스는 Open Connect라는 자체 CDN(콘텐츠 전송 네트워크)을 구축해, 전 세계 ISP(통신사) 네트워크 가까이에 캐시 서버를 배치했습니다. 인기 있는 콘텐츠는 이 Open Connect 서버들에 미리 저장되어, 사용자와 물리적으로 가장 가까운 곳에서 전달됩니다.
이렇게 되면 장점이 많습니다. 지연 시간은 줄어들고, 4K 같은 초고화질 스트리밍도 지장 없이 나오며, 트래픽이 AWS 리전에 몰리지 않아 클라우드 인프라에 장애가 나도 이미 캐시된 콘텐츠는 계속 잘 재생됩니다. 넷플릭스가 스스로 스트리밍 품질과 비용, 안정성을 모두 통제할 수 있는 강력한 무기입니다.
영상 업로드와 인코딩 파이프라인: 한 번 올려 전 세계 기기에 맞추는 법
새로운 영화나 드라마가 넷플릭스에 들어오는 과정도 매우 체계적입니다. 원본 영상이 들어오면 우선 큐에 쌓이고, 여기서부터 대규모 병렬 인코딩 파이프라인이 시작됩니다.
트랜스코더는 영상을 여러 해상도와 코덱, 다양한 기기 환경에 맞는 여러 버전으로 변환합니다. 4K TV, 태블릿, 스마트폰, 저속 네트워크까지 모두 고려한 최적화 작업이 자동으로 진행됩니다.
변환이 끝난 파일은 S3 같은 클라우드 스토리지에 저장되고, 품질 검증을 통과한 뒤 최종적으로 Open Connect에 배포됩니다. 여러 워커가 동시에 비동기 처리로 인코딩을 수행하기 때문에, 방대한 양의 신규 콘텐츠도 빠르게 전 세계에 뿌릴 수 있습니다.
데이터 파이프라인과 분석: 추천뿐 아니라 안정성까지 좌우한다
넷플릭스는 하루에도 수많은 로그와 이벤트를 수집합니다. 우리가 어떤 콘텐츠를 보았는지, 재생이 어디서 끊겼는지, 앱 에러는 언제 났는지, 스트림 품질은 어땠는지 등 모든 것이 데이터로 남습니다.
수집된 데이터는 S3 같은 저장소에 쌓이고, EMR, Kafka, Samza, Spark 같은 빅데이터/스트리밍 처리 도구를 통해 가공됩니다. Elasticsearch는 실시간 로그 분석에, Spark는 추천 알고리즘 개선과 트렌드 분석, 장애 패턴 탐지 등에 활용됩니다.
이 분석 결과는 단순히 "이런 콘텐츠 좋아하시겠죠?" 수준을 넘어서, 어떤 리전이 이상 행동을 보이는지, 어느 서비스가 평소보다 느린지, 장애 징후가 없는지 감지하는 데도 쓰입니다. 즉, 데이터 분석은 넷플릭스의 비즈니스 성과와 시스템 안정성을 동시에 책임지는 중추 역할을 합니다.
넷플릭스가 AWS 대규모 장애에서도 살아남는 진짜 이유
이제 핵심 질문으로 돌아가 보겠습니다. "왜 AWS에 큰 장애가 났는데도 넷플릭스는 거의 멀쩡했을까?"
첫 번째 이유는 멀티 리전 액티브-액티브 구조입니다. 넷플릭스는 여러 AWS 리전에서 동시에 서비스를 운영하고, 데이터도 지속적으로 복제합니다. 하나의 리전에 장애가 나면 그 리전을 과감히 "비우고(evacuate)" 트래픽을 건강한 리전으로 옮겨버립니다.
두 번째는 자동화된 빠른 페일오버 시스템입니다. 넷플릭스는 단순 서버 지표가 아니라, 초당 스트림 시작 수 같은 비즈니스 지표를 리전별로 실시간 모니터링합니다. 어떤 리전의 지표가 평소와 다르게 떨어지면 자동으로 다른 리전의 용량을 급히 늘리고, DNS를 변경해 문제 있는 리전을 우회합니다. 평균 6~7분 안에 리전 수준의 페일오버를 끝낼 수 있을 정도로 훈련되어 있습니다.
세 번째는 AWS "컨트롤 플레인" 의존성을 최소화한 설계입니다. 스트리밍 중에는 IAM, 컨테이너 레지스트리, 일부 내부 관리 서비스에 실시간 의존하지 않도록, 자격 증명과 컨테이너 이미지, 설정값 등을 미리 캐싱해 둡니다. AWS 내부 서비스에 문제가 생겨도 이미 떠 있는 워크로드와 스트리밍에는 영향이 덜 가도록 한 것이죠.
여기에 평소부터 Chaos Monkey 같은 도구로 장애를 연습하고, Open Connect로 스트리밍 트래픽 상당 부분을 AWS 밖으로 빼놓은 덕분에, 실제 AWS 장애 시에도 시청자는 큰 불편을 느끼지 않는 경우가 많습니다.
DNS로 트래픽을 우회하는 방법: 리전을 통째로 "피하는" 기술
리전 장애가 발생했을 때, 마지막으로 큰 역할을 하는 것이 DNS입니다. 넷플릭스는 권한 DNS와 지리 기반 라우팅(geo-DNS)을 이용해, 사용자의 위치와 리전 상태를 기반으로 어디로 접속시킬지를 제어합니다.
문제가 생긴 리전에 대해 DNS 레코드를 다른 건강한 리전으로 변경하면, TTL이 만료되는 시간(보통 몇 분) 동안 서서히 트래픽이 새로운 리전으로 옮겨갑니다. 이 과정에서 이미 준비된 "섀도 클러스터"가 바로 트래픽을 받아줄 수 있도록 대기하고 있습니다.
일부 클라이언트는 DNS 캐시 때문에 잠시 동안 기존 리전에 붙으려고 하지만, 이마저도 예외 처리와 백업 경로를 통해 최대한 오래 버티거나 빠르게 우회하게 설계되어 있습니다. DNS 변경이 자동화 파이프라인에 통합되어 있기 때문에, 사람의 손으로 콘솔을 클릭할 필요 없이 몇 분 안에 전 세계 트래픽 경로를 바꿀 수 있는 것이죠.
시사점: 우리 서비스에 넷플릭스式 안정성을 어떻게 적용할까?
넷플릭스의 시스템 디자인과 AWS 장애 대응 전략을 보면, "운이 좋아서 안 멈춘 서비스"가 아니라 "처음부터 멈추지 않도록 설계된 서비스"라는 사실이 분명해집니다.
여기서 우리가 배울 수 있는 현실적인 포인트를 몇 가지로 정리해 보면 이렇습니다. 모든 서비스를 마이크로서비스로 쪼개야 한다는 뜻은 아니지만,
단일 리전, 단일 인스턴스, 단일 DB에 모든 걸 걸지 말 것
장애를 가정하고 서킷 브레이커, 타임아웃, 캐시 등을 적극적으로 활용할 것
가능한 한 자동화된 모니터링과 페일오버를 준비할 것
평소에 "장애 연습"을 해보고, 문서가 아닌 실제로 복구가 되는지 검증할 것
중요한 것은 기술 스택보다는 태도와 문화입니다. "언젠가는 장애가 난다"는 사실을 받아들이고, 그때도 사용자가 서비스를 쓸 수 있도록 미리 준비하는 것, 그것이 넷플릭스가 AWS 장애 속에서도 버틸 수 있었던 핵심입니다.
당장 멀티 리전 구축이나 자체 CDN까지는 어렵더라도, 작은 서비스부터 "장애 내성(resiliency)"을 설계에 녹여 보는 건 어떨까요? 오늘 넷플릭스 이야기가 여러분 서비스의 다음 아키텍처를 고민하는 데 좋은 힌트가 되길 바랍니다.
이 노트는 요약·비평·학습 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.