Spotifyのポッドキャスト4時間障害、原因は「余剰キャパ10%」だった

はじめに：「アップロードしたのに反映されない」

ポッドキャストクリエイターなら一度は経験があるでしょう。エピソードを公開したのに数時間経っても表示されず、リスナーから先に「今回の回、上がってないよ？」と連絡が来る。

2026年6月24日、Spotifyで実際に起きた出来事です。動画ポッドキャストのエピソード公開が数時間遅延し、一部のクリエイターは反映されていないと判断して再アップロードしました。それがさらに負荷を増やしました。システムが「受け付けてキューに入った」ことを通知しなかったからです。これはクリエイターの責任ではなく、プラットフォーム側の責任です。

本記事は単なる障害報告ではなく、メディア処理パイプラインを運用するチームが必ず押さえるべきアーキテクチャの教訓です。根拠資料はSpotifyエンジニアリングブログで確認できます。

障害の4要因：「単一原因」ではなく「重なり」が本質

この障害は単一の原因ではなく、4つの要因が同時に発生した複合的なものです。実務で最も危険なパターンです。

1. ヘッドルーム（余剰キャパシティ）の不足

通常時のトラフィックはスケーリングでカバーできていましたが、大量の新規コンテンツのバーストを受け止める余裕がありませんでした。オートスケーリングがあっても「上限付近」で稼働していれば、急増には弱いのです。

2. バッチ処理との競合

既存エピソードを再処理する定期バッチジョブが動いていました。日中は問題なく見えましたが、新規投稿の急増と重なった瞬間に容量を食いつぶしました。

3. 品質改善がそのままコスト増に

「より良い画質をより低いビットレートで」という改善をデプロイしましたが、エピソードあたりの処理時間と演算量が増加しました。容量計画にこの増加分が反映されていませんでした。

4. スケジューリングバグで10%が遊休

より強力なハードウェアへの移行後、リソーススケジューリングのバグにより利用可能なコンピュートを約10%使えていませんでした。コストは払っているのに性能を引き出せていない状態です。

# 障害再現シミュレーション（概念例）
# 実際のSpotifyコードではなく、容量計画の失敗パターンを示す擬似コードです。

class TranscodingCluster:
    def __init__(self, total_capacity):
        self.total_capacity = total_capacity  # 1秒あたり処理可能なエピソード数
        self.batch_job_load = 0
        self.new_content_load = 0
        self.scheduling_efficiency = 1.0  # バグで0.9まで低下

    def effective_capacity(self):
        # スケジューリングバグを反映：実効容量が減少する
        return self.total_capacity * self.scheduling_efficiency

    def is_overloaded(self):
        total_load = self.batch_job_load + self.new_content_load
        return total_load > self.effective_capacity()

# 障害当時の状況
cluster = TranscodingCluster(total_capacity=100)
cluster.batch_job_load = 30        # バッチジョブが消費する容量
cluster.new_content_load = 75      # 新規動画の急増
cluster.scheduling_efficiency = 0.9  # バグで10%損失

print(cluster.is_overloaded())  # True -> キュー滞留開始

要点はこれです。「平均トラフィック基準で余裕がある」という錯覚が障害を招きます。ピーク＋バッチ＋バグが重なる瞬間こそが本当のリスクです。

タイムラインが示す本当の問題：「4時間の沈黙」

インシデント対応で最も痛いのは技術ではなく検知の遅れでした。

13:30に最初のアラートが上がったのに、正式対応は17:34に始まりました。 約4時間のギャップです。その間、クリエイターはリスナーから先に問題を知らされました。これが本当の失敗です。

再発防止策

• トランスコード容量を約67%増強
• スケジューリングバグの修正
• 容量上限接近時により早くアラートを出すモニタリング改善

この技術の限界と注意点

• 容量増強は根本解決ではありません。 67%増やしてもユーザー急増がそれを上回れば再発します。本当の解はバックプレッシャーと優先度付きキューです。
• オートスケーリングは「余裕」ではなく「反応」です。 スケールアウトにかかる時間の間はキューが溜まります。事前プロビジョニングとバッチスケジューリングの分離が必須です。
• 品質改善のデプロイは必ず容量再計算とセットで。 画質改善のコミット1つが処理時間を増やせば、それが障害の種になります。

まとめ：チームに持ち帰る3つのチェックリスト

1. 「平均」ではなく「ピーク＋バッチ＋障害復旧」で容量を計画する。 定常トラフィックだけを見れば必ず破綻します。
2. リアルタイムのクリエイターコンテンツは常にバッチ処理より優先度を高く。 バックグラウンド再処理が新規公開を妨げてはいけません。
3. モニタリングアラートと対応手順を接続する。 アラートが出ても「これは重大だ」と判断できなければ4時間は無駄に消えます。

次の学習ステップ

• SRE観点： Google SRE Bookの「Handling Overload」章、バックプレッシャーと負荷分散パターン
• アーキテクチャ観点： 優先度付きキューの設計、バッチ／リアルタイムワークロードの分離
• 可観測性観点： キュー深度（queue depth）ベースのSLI設計

国内開発エコシステムでの適用文脈

国内のメディア・コマースプラットフォームでも「アップロードしたのに反映されない」というCSが障害の最初のシグナルになることが多いです。特に大規模プロモーションやライブコマースのタイミングでは新規コンテンツ投稿が急増します。そのときバッチ系の統計・再インデックスジョブが同時に走っていれば、今回とまったく同じパターンが再現されます。バッチジョブのスケジュールをプロモーションカレンダーと分離するだけで、半分は予防できます。

あわせて読みたい

• "データダッシュボードはもう「見せる」ためではなく「意思決定させる」ためのものです" — 障害指標を「意思決定」につなげる可観測性設計
• "ゲームにおけるAIエージェント推論コスト、こうやって削減しましょう NVIDIA IGI SDKコードエージェント実践ガイド" — 演算コスト最適化の観点から見る容量計画