데이터 카나리아: 넷플릭스는 카탈로그 메타데이터를 어떻게 검증하는가

넷플릭스는 코드 변경이 없어도 카탈로그 데이터 자체가 손상되면 수백만 명의 재생 경험이 즉시 영향을 받을 수 있다는 점을 확인했다. 이에 실제 운영 트래픽으로 새 데이터 버전을 검증하는 데이터 카나리 시스템을 구축했고, 10분 이내에 문제를 감지해 배포를 차단한다. 핵심은 최종 변환 결과를 별도 카나리 클러스터에서 검증하고, 실제 재생 시도량을 기준으로 이상 여부를 빠르게 판단하는 것이다.

카탈로그 메타데이터 손상으로 발생한 장애

• 넷플릭스의 카탈로그 메타데이터는 타이틀, artwork, 제공 지역, 재생 가능 여부 등을 정의한다.
• 과거 장애 대응 과정에서 실행된 수동 완화 조치가 데이터 피드를 비워 버렸고, 일부 타이틀의 메타데이터가 손상됐다.
• 코드나 설정 변경이 없었기 때문에 기존 코드 카나리 배포는 문제를 감지하지 못했다.
• 손상된 메타데이터로 manifest 생성이 실패하면서 카탈로그 서비스와 재생 기능에 장애가 발생했다.
• 각 upstream 데이터 소스에는 검증 로직이 있었지만, 여러 입력을 변환한 최종 출력 상태의 오류까지는 잡지 못했다.

데이터 배포에 필요한 새로운 검증 방식

• 카탈로그 데이터는 여러 입력 피드를 지속적으로 변환하고 짧은 주기로 배포하는 고속 데이터 파이프라인이다.
• 기존 카나리 분석 도구는 통계적 신뢰도를 확보하는 데 30~60분이 필요해 데이터 배포 주기와 맞지 않았다.
• 입력 데이터가 정상이어도 변환 이후의 최종 상태에서 문제가 발생할 수 있으므로, 실제 클라이언트가 소비하는 출력물을 검증해야 했다.
• shadow traffic은 카탈로그 서비스 요청만 재현할 뿐, 여러 서비스가 연동되는 전체 재생 과정을 검증할 수 없었다.
• 운영 트래픽을 사용하되, 문제가 발생하면 고객 영향 범위를 즉시 제한할 수 있어야 했다.

전용 데이터 카나리 오케스트레이터

• 별도의 카나리 전용 클러스터와 오케스트레이터를 구축해 데이터 검증과 일반 서비스 운영을 분리했다.
• Baseline 클러스터
  • 현재 운영 중인 최신 카탈로그 버전을 지속적으로 제공한다.
• Canary 클러스터
  • 새 카탈로그 버전을 받아 검증한다.
• 오케스트레이터
  • baseline과 canary 클러스터의 상태 및 버전 동기화를 확인한다.
  • 조건이 충족되면 카오스 실험을 시작한다.
  • 실험 결과를 REST endpoint로 transformer 서비스에 전달한다.
• 이 REST 기반의 일반화된 연동 지점 덕분에 다른 데이터 소스도 transformer 코드를 수정하지 않고 유사한 검증 패턴을 적용할 수 있다.

카오스 플랫폼을 활용한 실시간 검증

• 10분 이내 검증을 위해 기존 카오스 플랫폼을 확장하고, 실험 임계값을 데이터 카나리 목적에 맞게 조정했다.
• 클라이언트 유형별로 트래픽 패턴과 downstream 의존성이 다르므로 주요 tenant마다 별도 실험을 수행했다.
• 특히 playback 요청을 처리하는 tenant의 트래픽이 오류를 가장 빠르게 발견했다.
• Sticky canary
  • 세션 affinity를 사용해 한 사용자의 트래픽이 실험 중 baseline 또는 canary 중 한쪽에만 계속 연결되도록 한다.
  • 두 데이터 버전의 결과가 섞이는 것을 막아 공정한 비교가 가능하다.
• 기술 지표보다 실제 사용자 행동에 가까운 Starts Per Second(SPS) 를 핵심 지표로 사용했다.
  • 메타데이터 오류는 카탈로그 서비스의 latency나 error rate를 높이지 않고도 재생 시도 자체를 감소시킬 수 있기 때문이다.
• 통계 수집이 끝날 때까지 기다리지 않고, 실시간으로 지표를 스트리밍하며 회귀가 감지되는 즉시 실험을 중단한다.
• 이는 통계적 확실성을 일부 줄이는 대신, 짧은 배포 주기 안에 문제를 차단하는 속도를 우선한 설계다.

운영 환경을 고려한 예외 처리

• 오케스트레이터가 재배포 중 재시작되더라도 진행 중인 카오스 실험을 찾아 계속 polling하도록 했다.
• 여러 오케스트레이터 인스턴스가 동시에 실행될 수 있으므로 leader election과 중복 실행 방지 장치를 적용했다.
• 한 버전 공지에 대해 실험이 한 번만 실행되도록 보장했다.
• 클라이언트별 데이터 소비 주기가 다르기 때문에 baseline과 canary의 버전 상태를 추적하고, 두 클러스터가 올바르게 정렬된 경우에만 실험을 시작한다.

의도적인 장애 주입으로 검증

• 시스템의 효과를 확인하기 위해 실제로 카탈로그 데이터를 의도적으로 손상시키는 통제된 실험을 수행했다.
• 고관심 타이틀을 denylist에 넣는 등 실제 장애와 유사한 데이터 손상 상황을 재현했다.
• 이러한 실패 주입 실험을 통해 실제 재생 트래픽과 SPS 지표가 회귀를 감지하고, 잘못된 데이터 버전이 회원에게 확산되기 전에 중단되는지 검증했다.

데이터 파이프라인도 코드 배포와 마찬가지로 최종 산출물 기준의 카나리 검증이 필요하다. 특히 사용자 영향이 직접 반영되는 지표를 선택하고, 운영 트래픽을 격리된 환경에서 비교하며, 이상 징후가 나타나는 즉시 중단하는 구조가 고속 데이터 배포에 효과적이다.