CDN事業者破産による緊急移管対応とEMの意思決定・学び

AWS, CloudFront, マネジメント

はじめに

システム開発推進部第2Gの曽利田です。
株式会社レコチョクでエンジニアリングマネージャーをしています。
Switch2の抽選結果メールが届くたび、「また落選か…」と肩を落とす日々が続いています。
ちなみに、CDN移管対応をしていたのは、Switch2の当選を夢見始めるよりも約6ヶ月も前のこと。
Switch2はまだ手に入りませんが、CDNの安定配信はしっかり手に入れました！
※つい最近のことですが、半年経って時限爆弾的問題が発生したので上記取り消します。。。詳細は別途

ということで、

要約

2024年末、突如として約1ヶ月後のサービス終了を告げられたCDNからの移行プロジェクト。
30万件以上の動画ファイルを対象に、年末年始を返上して技術検証から実装、リリースまでを完遂した取り組みを紹介します。

背景

2024年9月頃、弊社で利用していたCDN事業者がChapter 11（米連邦破産法第11条）を申請し、裁判所管理下で再建を進める状況となりました。

当初は「すぐにサービスが停止することはない」との見解でしたが、今後の安定性を懸念し、CDN移行の検討を開始しました。

CDNの利用形態は大きく以下に分類されます：

  • 一般的なキャッシュ機能＋URL保護
  • 音楽配信・動画配信における特殊な配信機能（on-the-fly（リアルタイム）変換）

特に音楽・動画配信では、以下のような特殊処理をCDN上で行っていました：

  • 音楽再生（PCブラウザ）：m4a形式の音源をon-the-flyでm3u8へ変換し、HLS形式で配信
  • DRM付き動画再生（アプリ/PCブラウザ）：mp4動画をon-the-flyでDRM付与、ライセンス認証もCDN側でラップして対応

緊急対応の必要性

2024年12月初旬、事業者より 2025年1月16日でのCDNサービス終了 が発表され、急遽移管の準備を本格化させることとなりました。

移行対象と対応方針

以下の3機能について、AWSを中心とした自前対応にて移行を実施：

対象機能 対応内容
CDNの基本機能（キャッシュ＋URL保護） CloudFront への移行
音楽配信のon-the-fly HLS変換 AWS MediaConvert を使用
DRM付き動画の配信 AWS MediaPackage + SPEKE 対応DRM事業者と連携

以降、3部に分けて記載していきます。

第1部：DRM付き動画の配信 AWS MediaPackage + SPEKE 対応DRM事業者と連携

※本記事

第2部：音楽配信のon-the-fly HLS変換 AWS MediaConvert

https://techblog.recochoku.jp/11925

第3部：AWS MediaPackage のその後の対応について

https://techblog.recochoku.jp/11945

まずは「DRM付き動画の配信（AWS MediaPackage + SPEKE対応DRM事業者連携）」について、詳細を解説します。

最初に、移行前と同様に、on-the-fly変換機能を有するCDN事業者・サービス提供会社を探しましたが、日本国内では見つからず、代替候補の中で AWS MediaServicesによる自前構成 が最も機能面・サポート面で優れていたため、採用を決定しました。

旧CDNでのDRM再生フロー

旧CDNでのDRM再生フローは以下の通りでした。CDN上でon-the-fly変換とDRM事業者連携を行い、簡潔な構成でDRM保護された動画配信を実現していました。

drm_diagram.png

AWS構成での実現概要

spekev2-mediapackage002-1024x437.png

使用サービス

  • MediaPackage：配信用のエンコーダ＋パッケージャ
  • CloudFront：エッジ配信
  • SPEKE：DRMライセンス連携プロトコル
    → SPEKE対応のDRM事業者を選定する必要あり

参考: SPEKEとは

ポイント：複数のDRM事業社にヒアリングをしましたが、最終的な決め手は、サポート対応の速さでした。
A社：サポートはメールなので、とのこと。緊急時でも同じ
B社：すぐにでもSlackで対応可能なので、緊急時でも対応可能
　→ サポート対応の速さを最重視し、B社を選定しました。

実装ステップ

MediaPackage構築

AWSコンソールからPackaging Group、Packaging Configuration、Assetを登録するのですが、構成は以下の図のイメージになります。
               +----------------------+
               |   Packaging Group    |
               +----------+-----------+
                          |
         +----------------+----------------+
         |                                 |
+--------------+                 +----------------+
| Packaging    |                 | Packaging      |
| Config (HLS) |                 | Config (DASH)  |
+--------------+                 +----------------+
         ↑                                 ↑
         |                                 |
         +---------------+----------------+
                         |
                   +-----+-----+
                   |   Asset   |
                   +-----------+

  1. Packaging Groupの作成
    packaging_group.png
    ※最大Packaging Group数:10

  2. Packaging Configurationの作成
    packaging_group_detail.png

    • Apple HLS（iOS用）
    • DASH-ISO（Android/PC用）
  3. Assetの作成
    assets.png

    • 事前に作成したPackaging Group（最大10のうち1つ）を指定してAssetを作成
    • 1Packaging Groupあたりの最大Asset数:10000
    • smil ファイルに動画情報を記載し登録

      <br /><br /><br />   <video src="xxx.mp4" />
       
       
       

      ※smilファイルとは…
      SMIL（Synchronized Multimedia Integration Language）は、音声・動画・テキスト・画像などのメディアを同期させて再生するためのXMLベースの記述言語です。
      動画配信などにおいて、複数のメディアファイル（例：音声・映像・字幕）を組み合わせて再生する制御を行う際に使用されます。

    Assetとして登録するsmilファイルは、SMIL3.0の仕様に従っていればOK
    https://www.w3.org/TR/SMIL3/

  4. 再生URLの保存
    Asset登録後にMediaPackageから発行される再生URLをDBに保存。
    アプリ・PC側は再生時にこのURLを参照してストリームを取得する構成。

まとめると、

  1. Packaging Groupの作成
  2. Packaging Configurationの作成
    はAWSコンソールで事前に実施し、
  3. Assetの作成
  4. 再生URLの保存
    をバッチ処理で自動化することで動画再生が可能となりました。

問題と対処

  • Asset登録数の制限
  • 動画ファイルが別AWSアカウントにある問題
    • smilファイルと動画が同一AWSアカウントのS3に配置されていないといけない（製品仕様とのこと）
      • 動画をコピーするバッチを追加実装
    • smilファイルに指定する動画のパスが相対パスだと正しく動作しない
      • smilファイルと同じ階層に動画を配置

CloudFront構成

CloudFrontを導入する目的

MediaPackageだけでも配信は可能ですが、以下の理由からCloudFrontを前段に配置しました。

  • エッジキャッシュによるパフォーマンス向上
  • トラフィックコストの最適化
  • アクセス制御とセキュリティ強化

URL構造への対応

Packaging Group(3種類) x Packaging Configuration(2種類)ごとに再生URLのパスが異なるので、それぞれのパスに対してCloudFrontのBehaviorを設定する必要があります。

URLは、
‘out/v1//pkg-config-guid/‘
という形式で一般化できるので、上記のBehaviorを設定します。
※pkg-config-guid は、Packaging ConfigurationのGUIDなのですが、値を取得するには、実際にURLを発行して取得するしかないようです。

cloudfront_behavior.png

※参考
https://aws.amazon.com/jp/blogs/media/metfc-managing-content-delivery-across-multiple-aws-elemental-mediapackage-origins/

cache_behavior.png

リリースに向けて

ここまでを実質12月中旬〜下旬にかけて、開発メンバー総動員で対応にあたりました。
そして12月末のタイミングで、対応方針の選択に迫られます。

  • イニシャルデータ（すでに納品済みの動画）のみ対応し、ランニングデータ（リリース後に納品される動画）は事後対応とする（※対応完了までは再生できないため、お客様影響あり）
  • 正月休み返上でランニングデータも対応（別途バッチ開発が必要）し、お客様影響をなくす

のどちらかを判断する必要があり、会社としては、後者でいく！という判断がくだされました。
普段当該案件に関わっていないメンバー含め、10人以上のメンバーが正月休みを返上して対応にあたりましたが、全員前向きに対応してもらい、本当に頼もしかったです。

事業会社として、やれることはやるべきだという判断でした。
今回の経験を通じて、より積極的に「お客様影響を最小化する選択肢」を自信を持って提案し、迅速な意思決定をリードする重要性を再認識しました。今後も、現場の声を丁寧に拾い上げつつ、最適な判断を下せるEMでありたいと考えています。

最終構成の概要

AWSアカウント 主な役割
アカウント1（旧動画Origin） 動画アップロード元、コピー元
アカウント2（MediaPackage運用） MediaPackage構成、Asset登録、CloudFront配信

再生

DRM事業者とのやり取りが発生しますが、ここは割愛します。
一般的なDRMライセンス認証の流れになります。

まとめ

今回のCDN移管対応を通じて、

  • 障害リスクを最小化するための迅速な意思決定
  • お客様影響を最小化するためのリーダーシップ
  • サポート体制の重要性
  • AWSサービスの制限や運用上の工夫

エンジニアリングマネージャーとして、こうした多くの学びを得ました。
今後も「信頼される技術選定」と「お客様視点のリーダーシップ」を大切にし、現場の声や変化に柔軟に対応しながら、より良いエンジニア組織づくりに取り組んでいきます。

AWS, CloudFront, マネジメント