楽曲ストリーミング配信のCDN移行を行った時のアーキテクチャについて

ツール導入前の課題

弊社では音楽配信サービスを提供しており、HLS（HTTP Live Streaming）を用いた楽曲のストリーミング配信を行っています。

これまで利用していた CDN 事業者から、サービス終了の通知を受けたことをきっかけに、約1か月という短期間で新たな CDN の選定・導入を行う必要がありました。

他の CDN 事業者も調査しましたが、日本国内で同様の要件を満たせるサービスを見つけることができませんでした。

その中で、AWS の CloudFront + Lambda@Edge + MediaConvert + S3 を組み合わせることで、既存の配信フローを再現できそうだという結論に至り、自前で実装する方針を採用しました。

どのような状態を目指していたか

今まで使用していたCDNでは以下のフローでHLS配信を行っていました。

1. ユーザーが CDN に楽曲をリクエスト
2. CDN がキャッシュを確認し、キャッシュがあればそのまま返却
3. キャッシュがない場合は、楽曲取得API へリクエストを送信し m4a 形式の楽曲を取得
4. CDN が m4a を HLS (m3u8 + TS) に変換
5. HLS 変換後の m3u8 + TS をユーザーへ返却
6. CDN が変換済みの HLS ファイルをキャッシュ

新しい構成においても、この配信フローを維持しつつ、HLS 変換を適切に処理できる仕組みを構築することを目標としていました。

改善したかった課題はどれくらい解決されたか

• 配信停止を発生させることなく CDN の切り替えを完了
• 既存アプリケーションの大きな改修を行わずに移行
• 事前 HLS 変換の導入により、初回再生時の待ち時間を解消

といった形で、主要な課題はほぼ解決でき、配信品質やユーザー体験を大きく損なうことなく、切り替えを完了できました。

全体の処理フローとしては、CloudFront から Lambda@Edge をトリガーし、Lambda@Edge 側で S3 内の HLS ファイルを確認、存在しない場合は MediaConvert を利用して m4a を HLS に変換し、S3 に配置するという構成です。

構築自体は大きな問題なく進みましたが、MediaConvert を利用した HLS 変換の処理時間とコストが大きな課題となりました。

具体的な課題は以下の通りです。

1. 初回アクセス時の HLS 変換による再生遅延

初回の楽曲再生時には、S3 バケットに HLS 変換済みファイル（m3u8 + AAC）が存在しません。

そのため、初回アクセス時のみ MediaConvert による HLS 変換処理が発生します。

この変換処理には、楽曲の長さに関わらず 10秒前後かかり、その間、ユーザーは再生を開始できません。

すべての楽曲で初回再生時に待ち時間が発生することになり、ユーザー体験を大きく損なう可能性がありました。

2. 変換中の再生が成立しない

課題1の回避策として、MediaConvert の設定で「変換中のデータを順次返却し、先行再生できないか」を検証しました。

しかし、アプリケーション側でシークバーを操作すると、変換が完了していない区間は再生できないという挙動が発生し、実用に耐えないことが分かりました。

結果として、HLS 変換が完全に完了するまで再生を開始できない構成となりました。

3. MediaConvert のコスト

初回再生時の遅延を解消するため、イニシャル楽曲分は事前に HLS ファイルを生成しておく方針を検討しました。

しかし、配信楽曲数が多いため、すべてを MediaConvert で変換すると コストが大幅に増加することが判明しました。

課題の解決策

この課題を解決するため、リリース前に主要楽曲の HLS ファイルを事前生成する方針に切り替えました。

EC2 インスタンスに ffmpeg をインストールした変換環境を構築し、複数台を並行稼働させて数日間かけて事前変換を完了させました。

この対応により、

• ユーザーの初回再生時でも待ち時間なく再生を開始できるように改善
• MediaConvert を大量実行する場合と比較してコストを大幅に削減

という結果を得ることができました。

なお、事前変換していない楽曲については、初回アクセス時に MediaConvert による変換が発生する構成としています。