콘텐츠 수집 및 팟캐스트 동영상 사고 보고서 | Spotify Engineering (새 탭에서 열림)
Spotify의 6월 24일 팟캐스트 영상 게시 지연은 트랜스코딩 용량 부족, 대량 배치 작업, 영상 처리 비용 증가, 자원 스케줄링 버그가 동시에 발생해 큐가 폭증하면서 일어났다. 신규 영상 게시가 수시간 지연됐고, 일부 크리에이터의 재업로드가 부하를 더욱 키웠다. Spotify는 배치 작업 중단, 버그 수정, 처리 용량 증설로 다음 날 새벽 backlog를 해소했으며, 이후 용량 계획·우선순위·모니터링을 전반적으로 개선하고 있다. ## 게시 지연이 발생한 과정 - 신규 팟캐스트의 오디오·비디오는 트랜스코딩과 콘텐츠 분석을 거쳐 Spotify에 게시된다. - 6월 24일 영상 트랜스코딩 인프라가 최대 용량에 도달하면서 신규 영상 게시 큐가 급격히 쌓였다. - 평소 수분 내 게시되던 영상이 수시간 동안 표시되지 않았다. - 업로드가 정상적으로 접수·대기 중이라는 확인이 충분히 제공되지 않아 일부 크리에이터가 에피소드를 재업로드했고, 이로 인해 시스템 부하가 추가됐다. - 신규 에피소드용 중간 우선순위 큐와 기존 에피소드 업데이트용 낮은 우선순위 큐가 모두 영향을 받았다. ## 장애를 키운 네 가지 요인 - **부족한 용량 여유** - 평상시 처리량은 감당할 수 있었지만, 대규모 콘텐츠 제출량 급증을 흡수할 여유 용량이 부족했다. - **기존 콘텐츠 재처리 배치 작업** - 재생 시스템 변경에 맞춰 기존 에피소드를 재처리하는 정기 작업이 신규 콘텐츠와 처리 자원을 경쟁했다. - 배치 작업은 처음에는 정상적으로 보였지만, 제출량 급증과 결합되면서 문제가 됐다. - **영상 품질 개선에 따른 처리 비용 증가** - 더 낮은 비트레이트에서 높은 품질을 제공하도록 변경하면서 에피소드당 처리 시간과 필요한 컴퓨팅 자원이 증가했다. - 용량 계획에 이 증가분이 충분히 반영되지 않았다. - **자원 스케줄링 버그** - 더 강력한 하드웨어로 이전한 뒤 스케줄링 오류가 가용 컴퓨팅 자원을 제대로 활용하지 못하게 했다. - 결과적으로 처리량이 약 10% 감소했다. ## 장애 대응과 복구 일정 - 13:30: 내부 모니터링에서 초기 경고가 발생했지만, 전체 용량 문제로 즉시 인식되지는 않았다. - 15:00: 영상 제출량 급증으로 트랜스코딩 용량이 한계에 접근했다. - 16:35: 용량 확보를 위해 배치 작업을 중단했다. - 17:34: 큐가 임계치를 넘었다는 자동 경고 후 공식 장애 대응을 시작했다. - 19:00: 크리에이터들이 에피소드 미표시 문제를 보고했다. - 20:49: 자원 활용률을 개선하는 소프트웨어 수정 사항을 배포했다. - 6월 25일 00:14: 추가 처리 클러스터를 가동했다. - 01:02: 모든 큐가 비워졌다. - 07:30: 전체 게시 파이프라인이 정상 작동하는 것을 최종 확인했다. ## 모니터링과 대응의 문제점 - 첫 경고가 발생한 뒤 공식 장애 대응이 시작되기까지 약 4시간이 걸렸다. - 엔지니어들은 16:35에 배치 작업을 중단했지만, 문제의 범위가 시스템 전체의 용량 부족이라는 점은 큐가 임계치를 넘은 뒤에야 명확해졌다. - Spotify는 용량 한계에 접근하는 단계에서 더 일찍 경고하도록 모니터링을 개선하고 있다. ## 후속 조치와 신뢰성 개선 - 트랜스코딩 처리 용량을 약 67% 늘려 트래픽 급증과 배치 작업을 위한 여유를 확보했다. - 가용 컴퓨팅 자원을 충분히 활용하지 못하게 하던 스케줄링 버그를 수정했다. - 용량 한계에 가까워질 때 더 빠르게 알림을 보내도록 모니터링을 개선했다. - 정상 상태의 트래픽뿐 아니라 급격한 증가와 장애 복구 상황까지 반영하는 용량 계획을 수립하고 있다. - 크리에이터의 실시간 콘텐츠가 백그라운드 작업보다 우선 처리되도록 게시 시스템의 우선순위 정책을 개선하고 있다. - 예상치 못한 부하를 완화하기 위해 파이프라인 전반에 속도 제한(rate limiting)과 백프레셔(backpressure)를 확대할 계획이다. ## 실용적인 결론 이번 장애는 단일 버그보다 용량 여유 부족, 배치 작업과 실시간 작업의 자원 경쟁, 처리 비용 증가, 모니터링 지연이 복합적으로 작용한 사례다. 대규모 미디어 처리 시스템에서는 평상시 처리량뿐 아니라 급격한 트래픽 증가를 견딜 여유 용량, 작업 우선순위, 조기 경보, 재시도·중복 업로드를 방지하는 명확한 상태 확인이 함께 설계되어야 한다.
