spotify2026년 7월 20일

콘텐츠 수집 및 팟캐스트 동영상 사고 보고서 | 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)를 확대할 계획이다. ## 실용적인 결론 이번 장애는 단일 버그보다 용량 여유 부족, 배치 작업과 실시간 작업의 자원 경쟁, 처리 비용 증가, 모니터링 지연이 복합적으로 작용한 사례다. 대규모 미디어 처리 시스템에서는 평상시 처리량뿐 아니라 급격한 트래픽 증가를 견딜 여유 용량, 작업 우선순위, 조기 경보, 재시도·중복 업로드를 방지하는 명확한 상태 확인이 함께 설계되어야 한다.

content-processingmonitoringincident-responserate-limiting+4

dropbox2026년 7월 20일

범용 콘텐츠 처리 플랫폼 Riviera가 AI와 그 너머를 위해 어떻게 진화했는가 (새 탭에서 열림)

Dropbox의 콘텐츠 처리 플랫폼 Riviera는 파일 미리보기 서비스에서 출발해 Search, Replay, Sign, Dash 등 여러 제품이 공유하는 범용 변환 플랫폼으로 발전했다. 핵심 설계는 파일별·제품별 파이프라인을 따로 만드는 대신, PDF 변환·페이지 이미지 생성·텍스트 추출 같은 작은 변환 작업을 재사용 가능한 플러그인으로 조합하는 것이다. AI 제품의 확산으로 문서와 미디어를 일관된 형태로 준비하는 수요가 커지면서, Dropbox는 Riviera의 기능을 외부 개발자와 설계 파트너에게 API와 Model Context Protocol 도구로 공개했다. ## 미리보기 문제에서 시작된 플랫폼 - Dropbox는 300개가 넘는 파일 형식을 지원하며, 각 형식에서 썸네일, 전체 미리보기, 추출 텍스트, 스트리밍 매니페스트, 메타데이터 등 다양한 결과물을 생성해야 했다. - 파일 형식과 출력물마다 별도 서비스를 만들면 다음 문제가 발생한다. - 동일한 변환 로직이 여러 서비스에 중복됨 - 의존성, 패키지 버전, 설정이 서로 달라짐 - 유지보수와 운영 부담이 커짐 - Riviera는 모든 미리보기를 독립적인 기능으로 보지 않고, 재사용 가능한 작은 변환 단계의 조합으로 정의했다. - 예를 들어 PowerPoint 미리보기는 다음처럼 처리할 수 있다. - PowerPoint를 PDF로 변환 - PDF의 각 페이지를 이미지로 변환 - 생성된 이미지를 Dropbox 화면에서 표시 - PDF를 이미지로 바꾸는 단계는 PDF 자체의 미리보기나 다른 페이지 이미지 생성 작업에도 재사용할 수 있다. ## 조정과 실행을 분리한 아키텍처 - Riviera의 중앙 구성 요소는 변환 요청을 수집하고, 작업을 조합하며, 적절한 백엔드 워커에 분배한다. - 중앙 계층은 다음 기능을 담당한다. - 요청 유효성 검증 - 변환 작업 구성 - 결과 캐싱 - 중복되거나 잘못된 작업 차단 - 각 백엔드 워커는 특정 변환 유형을 담당한다. - 기능별로 독립적인 유지보수와 확장이 가능함 - 특정 변환의 처리량에 맞춰 개별적으로 확장할 수 있음 - 새로운 파일 형식이나 변환 유형을 추가할 때 핵심 인프라를 수정하는 대신 플러그인을 추가하면 된다. - 현재 Riviera는 100개가 넘는 변환 기능을 제공하며, 초당 수십만 건의 변환을 처리한다. - 이 구조 덕분에 핵심 플랫폼은 안정적으로 유지하면서 지원 파일 형식과 제품 기능을 계속 확장할 수 있었다. ## 여러 제품이 공유하는 변환 라이브러리 - Riviera는 처음에는 전담 Previews 팀이 운영하는 내부 서비스였지만, 다른 팀들도 동일한 콘텐츠 처리 문제를 겪고 있다는 사실이 드러났다. - 예를 들어 미리보기용으로 만든 160×160 썸네일은 머신러닝 팀의 이미지 정규화에도 활용할 수 있었다. - 같은 결과물을 여러 소비자가 사용하면 변환을 한 번만 수행하면 됨 - Search 팀은 문서를 검색 인덱싱에 적합한 형태로 준비하기 위해 Riviera를 도입했다. - Sign, DocSend, Replay 같은 제품도 기존 변환 기능을 재사용했다. - 이후 Dropbox는 플러그인 모델을 제품 팀에 개방했다. - Riviera 팀은 핵심 아키텍처를 관리 - 각 제품 팀은 필요한 변환 플러그인을 추가 - 추가된 플러그인은 다른 팀도 사용할 수 있는 공유 자산이 됨 ## Replay가 보여준 플러그인 모델의 효과 - 동영상 리뷰 제품인 Replay는 동영상 트랜스코딩과 조작이라는 복잡한 처리 작업이 필요했다. - Riviera의 미디어 변환 기능을 활용함으로써 Replay 팀은 동영상 처리 인프라를 처음부터 구축하지 않아도 됐다. - 제품 팀이 변환 기능을 요청하면 Riviera가 기존 기능을 노출하거나 새 플러그인을 추가하는 방식이 정착됐다. - 그 결과 기존에는 수개월이 걸릴 수 있었던 기능을 수주 안에 출시할 수 있었고, 새로운 플러그인이 추가될수록 다음 제품의 개발도 빨라졌다. ## Dash와 AI가 만든 새로운 요구 - AI 모델이 문서에 답변하거나 보고서를 요약하려면 먼저 문서가 모델이 처리할 수 있는 일관된 형태로 변환되어야 한다. - 필요한 전처리에는 다음 작업이 포함된다. - 텍스트 추출 - 스캔 문서의 페이지 인식 - 메타데이터 추출 - 다양한 파일 형식의 통일된 표현으로 변환 - 이러한 작업은 본질적으로 AI 모델 자체의 문제가 아니라 콘텐츠 변환 문제이며, Riviera가 기존부터 해결해 온 영역이다. - Dash 팀은 Riviera가 이미 지원하던 수백 가지 파일 형식과 변환 기능을 활용해 별도의 문서 처리 시스템을 새로 만들 필요를 줄였다. - Riviera는 미리보기와 미디어 처리뿐 아니라 검색, 문서 자동화, AI용 콘텐츠 준비에도 적용되는 기반 계층으로 확장됐다. ## 외부 개발자를 위한 공개 - Dropbox는 Riviera에서 축적한 콘텐츠 변환 기능을 API와 Model Context Protocol 도구 형태로 개발자 생태계와 설계 파트너에게 제공하기 시작했다. - 활용 사례로는 다음과 같은 작업이 제시된다. - 콘텐츠 관리 시스템 구축 - 문서 처리 워크플로 자동화 - 파일 검색용 인덱싱 - AI 애플리케이션용 문서 전처리 - 핵심 가치는 제품마다 변환 인프라를 새로 구축하지 않고, 검증된 공통 플랫폼을 이용할 수 있다는 점이다. Riviera의 사례는 대규모 콘텐츠 처리를 제품별 기능이 아니라 재사용 가능한 변환 조합과 플러그인 플랫폼으로 설계해야 한다는 점을 보여준다. 특히 AI 애플리케이션을 만들 때 모델 개발에만 집중하기보다, 다양한 파일을 안정적으로 추출·정규화·변환하는 기반을 먼저 확보하는 것이 실용적인 접근이다.

content-processingaimodel-context-protocoldistributed-systems+3