コンテンツの主権を守るため（？）、高機能画像CDNからAWS自前対応に乗り換えた話

2024年11月15日（金）、Media JAWSでの発表資料です。高機能画像CDNサービスからコンテンツ内容への（軽い）注意を受けたことをきっかけに、メディア企業としての自主性を担保する目的で、必要な機能だけを自前で実装し、AWSからの配信に乗り換えた経緯と方法論をご紹介しています。

Transcript

1. コンテンツの主権を守るため（？）、 高機能画像CDNからAWS自前対応に 乗り換えた話 長尾 洋一郎 Yoichiro Nagao 株式会社講談社 IT戦略企画室 テクノロジーラボ部長 KODANSHAtech合同会社 ゼネラルマネージャー 小島 貴之 Takayuki Kojima KODANSHAtech合同会社 エンジニアリングマネージャー
2. ABOUT US 長尾 洋一郎 Yoichiro Nagao 株式会社講談社 IT戦略企画室 テクノロジーラボ部長 KODANSHAtech合同会社 ゼネラルマネージャー 小島 貴之 Takayuki Kojima KODANSHAtech合同会社 エンジニアリングマネージャー
3. KODANSHAtechとは ウェブメディアのいち編集部からはじまった 「草の根」組織を、2020年に法人化。 「フリーランスエンジニア的な自由度の高い 働き方」＋「日本企業的な社会的セーフティ ネット」のいいとこ取りを目指している。 好きな日程で働ける、基本フルリモート勤務、 複業・兼業原則可、など、結構、攻めている。 よろしければサイトも⇨
4. 今日の話題: FRIDAYと「techチーム」 FRIDAYは、1984年11月創刊の「写真週刊誌」。 いわゆる「スクープ」について、主に写真を通じて世に問う雑誌。 ガラケー向けに作られた古いサイトしかなかったこのメディアで 完全内製化を成し遂げたことが、チームが草の根から会社公式の ものになっていく大きな原動力となった。 媒体としては現在でもスクープを狙いつづけているが、同時に 近年は「グラビア」の媒体としての位置付けが色濃くなっている。 ともかくも、 写真を大切にしていきたいメディアである ということで、引きつづいてお聞きいただければ。 ⇦40周年になりました。
5. 発表内容 • 今年の7月〜最近まで進めていたプロジェクトのご紹介 • FRIDAYのメディアコンテンツ（画像・動画）の配信を 外部の SaaS から AWS を使った自前の配信システムに切り替 えた
6. 開発の経緯① • これまで SaaS の画像・動画配信の仕組みを利用していた • 今回 FRIDAY で規約上配信しないでほしいと言われるコンテン ツがあった • 当然ですが日本の法律上問題ないものを配信しているわけで、 我々から見ると問題ない内容 （週刊誌に載っているような内容） • 最終的にそのコンテンツは配信することができた
7. 開発の経緯② • すぐにコンテンツ配信ができなくなることはなさそうだが、 SaaS 側の判断で配信できるコンテンツの有無が決まってしま うのはメディアを運営していくにあたって今後リスクになると 考えた • 大きな問題になる前に別の配信手段を持ちたいと考えプロジェ クトがスタート
8. AWS を選択した理由 • 一つは単純に我々が管理しているシステムの多くはインフラに AWS を採用しているという点 • もう1点は、これまでの仕組みでは、一度 S3 にアップロードし てから SaaS 側にアップロードする構成としていたので、元 データが S3 にある状態だった • そのまま元データを再利用できると移行がしやすかった
9. 機能要件
10. 機能要件① - 画像＆動画共通 • CDN の機能 • ユーザごとに有効期限を設定して配信 • サブスクリプション型のサービスのため
11. 機能要件② - 画像 • 画像変換機能 • 入力ファイルは jpeg / png • 1枚の元画像から複数のサイズへの変換 • 画像の切り抜き • 複数フォーマットでの出力 (jpeg / webp) • ぼかし画像の生成 • 画像の複合 • 顔検出 • 人物にズームしたサムネイルの生成
12. 機能要件③ - 動画 • 入力ファイルは mp4 • HLS 形式への変換 • サンプル動画の生成（動画の一部抽出＋ぼかしをかける） • → 今回は見送り • 動画からサムネイル画像の生成
13. 事前調査による AWS での実現性の確認 • CDN → CloudFront • ユーザごとに有効期限を設定 → 署名付き URL or Cookie • 画像変換 → Lambda • AWS のサイトでも紹介されている Sharp を使うことを検討 • https://aws.amazon.com/jp/solutions/implementations/serverless-image- handler/ • 顔検出 → Rekognition • 動画変換 → Elemental MediaConvert
14. システム詳細（画像）
15. システム詳細（画像） • Lambda 関数を2つ作成 • コンテンツの配信 + 画像変換 • 画像削除時のキャッシュ削除
16. システム構成（画像変換＋配信）
17. 画像 発生した問題と解消方法 工夫した点
18. 画像 - 発生した問題①-1 - Rekognition のエラー • 5MB 以上の画像を Rekognition に投げるとエラーになる • 大きい画像のテストで発覚 • 上限が5MB なのは仕様 • https://docs.aws.amazon.com/ja_jp/rekognition/latest/dg/limits.ht ml • ファイルサイズではなく、バッファに展開した後のサイズが 5MB を超えるとエラーとなる（pixel 数に依存する） • 運用上、5MB 以上のファイルもアップロードされることがあ るので対策が必要
19. 画像 - 発生した問題①-2 - Rekognition のエラー 対策 • 5MB 以下に収まるまで画像を縮小してから渡すことで解決 • Rekognition の顔検出で返却される座標は [0,1] の範囲で返る ので、仮に画像を 1/2 などに縮小したとしても結果は変わらな かったので対応しやすかった • 縮小すると精度は落ちるが、そもそも大きい画像なので、実際 には縮小しても検出結果は変わらなかった
20. 画像 - 発生した問題②-1 - Lambda がメモリ不足でエラー • Lambda の設定は 1GB • Lambda は短期間にアクセスすると実行環境が再利用されるこ とがある • https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/lambda- runtime-environment.html • 通常は問題ないが Sharp はデフォルトで内部的にキャッシュを 持っていて、連続して呼ぶと使用メモリが積み上がりエラーに なっていた • 例）9500x6000 pixel の場合 • 展開後のバッファサイズは 170 MB 程度 • 1回の変換で 700-800 MB ほど使う
21. 画像 - 発生した問題② -2 - Lambda がメモリ不足でエラー 対策 • sharp.cache の無効化 • これで安定した • 大きい画像はそもそもかなりメモリを使うので 1GB → 1.5 GB に変更 • メモリを 1536MB (1.5倍) にすると、1ms あたりのコストも 1.5倍になるが、実行速度は半分以下になり、コストはむしろ減 少するので効率の良い設定 • https://repost.aws/ja/knowledge-center/lambda-memory- compute-cost
22. システム詳細（動画）
23. システム詳細（動画） • Lambda 関数を3つ作成 • MediaConvert のジョブ生成 • MediaConvert 完了通知 • ファイル削除時のキャッシュ削除
24. システム構成（動画変換）
25. 動画 発生した問題と解消方法 工夫した点
26. 動画 - 発生した問題①-1 - 署名付きURLによる配信 • 動画もサブスクユーザのみが再生できるので署名付きURL また は Cookie による制御を検討 • ただし、生成されるプレイリスト(.m3u8)は解像度ごと の .m3u8 を含み、さらに各 .m3u8 の中に .ts 形式のファイル リストが含まれる • このそれぞれのパスを署名付きにする必要がある
27. 動画 - 発生した問題①-2 - 署名付きURLによる配信 • 例）.m3u8 ファイル #EXTM3U #EXT-X-VERSION:3 … #EXT-X-STREAM-INF:BANDWIDTH=358380,AVERAGE-BANDWIDTH=… video_480x270.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=562812,AVERAGE-BANDWIDTH=… video_640x360p.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=899700,AVERAGE-BANDWIDTH=… video_960x540p.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=1593970,AVERAGE-BANDWIDTH=… video_1280x720p.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=3129959,AVERAGE-BANDWIDTH=… video_1920x1080p.m3u8
28. 動画 - 発生した問題①-3 - 署名付きURLによる配信 • 例）video_1920x1080p.m3u8 #EXTM3U #EXT-X-VERSION:3 ... #EXTINF:3, video_1280x720p/00000/video_1280x720p_00001.ts #EXTINF:3, video_1280x720p/00000/video_1280x720p_00002.ts #EXTINF:3, video_1280x720p/00000/video_1280x720p_00003.ts #EXTINF:3, video_1280x720p/00000/video_1280x720p_00004.ts #EXT-X-ENDLIST
29. 動画 - 発生した問題①-4 - 署名付きURLによる配信 • 複数のパスにまたがるので最初は署名付き Cookie を検討 • ただ、別ドメインの扱いや、フロントエンドのどこで Cookie 発行するかなど気を付けるポイントがいくつかありそうだった • その後、ドキュメントを読み込んだところ、カスタムポリシー を使用すると URL にワイルドカードを使えることが分かった ので、この方法を検証 • https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/Dev eloperGuide/private-content-creating-signed-url-custom- policy.html#private-content-custom-policy-statement-values
30. 動画 - 発生した問題①-5 - 署名付きURLによる配信 • ワイルドカードを使うと以下のようにURLを指定して、生成し た署名を、指定したパス以下全てに利用できる • 例） • https://example.com/video1/* で署名 • https://example.com/video1/video_1280x720p.m3u8?<signature> の形でアクセスできる
31. 動画 - 発生した問題①-6 - 署名付きURLによる配信 • 共通の署名で特定のパス以下にアクセスできるようになったが、 フロントエンドで再生する際に、すべてのパスに署名をつけら れるかを確認 • フロントエンド (Next.js) では動画の再生に hls.js と react- player の2つのライブラリが使われていたが、どちらも署名を 付与することが可能だった
32. 動画 - 発生した問題①-7 - 署名付きURLによる配信 • 例）hls.js const videoSrc = "https://example.com/video1/video.m3u8"; const hls = new Hls({ xhrSetup: function (xhr, url) { const query = "<SIGNATURE>"; xhr.open("GET", url + query, true); }, }); hls.loadSource(videoSrc); hls.attachMedia(video);
33. 動画 - 発生した問題①-8 - 署名付きURLによる配信 • 例）react-player <ReactPlayer url="https://example.com/video1/video.m3u8" config={{ file: { hlsOptions: { xhrSetup: function (xhr: XMLHttpRequest, url: string) { const query = "<SIGNATURE>"; xhr.open("GET", url + query, true); }, }, }, }} />
34. 動画 - 発生した問題①-9 - 署名付きURLによる配信 • 動的に署名をつける形で実際に動画も再生できたのでこの方法 で進めていた • しかし、後々になって問題があることが発覚..（後述）
35. 動画 - 発生した問題②-1 - iPhone で再生できない • iPhone で再生できない問題が発覚 • 前述の署名を付与する方法は Media Source Extensions API を 利用している • https://developer.mozilla.org/ja/docs/Web/API/Media_Source_Exte nsions_API
36. 動画 - 発生した問題②-2 - iPhone で再生できない • Media Source は iOS Safari では利用できなかった （iPad OS は利用可能） • https://caniuse.com/mediasource
37. 動画 - 発生した問題②-3 - iPhone で再生できない 対策 • 最終的に Lambda から .m3u8 ファイルを返す際に、含まれる 各パスを署名付きに変換して返すことで解決 • ワイルドカードの署名をここで活かすことができた • ユーザごとに結果が変わるので CloudFront のキャッシュはし ない形にした
38. まとめ • 色々問題はあったが、最終的に AWS を使って メディアを配信をする仕組みを構築することができた • あらためて実データや実機でのテスト大事だと再認識させられ るプロジェクトだった • メディア企業として独自の配信基盤を持てるようになったこと は大きい
39. THANK YOU!
40. おまけ
41. MediaConvert のオプション調整-1 • 最初、オプション調整などせずに実行したところ、解像度を上 げると SaaS よりも出力ファイルサイズが大きくなる傾向に あった - 元ファイル SaaS MediaConvert 1920x1080 326 MB - 67.9 MB 1280x720 28 MB 17.04 MB 27.7 MB 960x540 21 MB 12.18 MB 20.6 MB 640x360 15 MB 10.27 MB 9.1 MB 480x270 12 MB 7.89 MB 6.6 MB
42. MediaConvert のオプション調整-2 ファイルサイズの増加は配信コストに影響するので、チューニン グを実施 • 帯域幅削減フィルター(PRO) • 軽微だが全体的にサイズを減らすことができた • 変換時のコストは上がる初回のみなので許容 • QVBR 品質レベルの調整 • あまり下げるとクオリティに影響がある • 今回は 7 に下げた
43. MediaConvert のオプション調整-3 • 品質チューニングレベル(PRO) • マルチパスにするとわずかにサイズが減った（ビットレートによる） • 一方変換時間は 1.4〜1.5 倍に伸びるが、SaaS と比較すると同程度 の時間だった
44. MediaConvert のオプション調整-4 • 以下のパターンで検証 • パターン1 : 帯域幅削減フィルター(PRO) ON • パターン2 : QVBR 品質レベル=7に統一 • パターン3 : 品質チューニングレベル=マルチパス(PRO) • パターン4 : 1〜3 全て有効 - 元ファイル SaaS 既存の設定 パターン1 パターン2 パターン3 パターン4 1920x1080 326M - 67.9 MB 64.4 MB 34.2 MB 67.5 MB 33.1 MB 1280x720 28M 17.04 MB 27.7 MB 26.6 MB 19.2 MB 27.6 MB 18.5 MB 960x540 21M 12.18 MB 20.6 MB 19.7 MB 14.7 MB 20.6 MB 14.1 MB 640x360 15M 10.27 MB 9.1 MB 8.8 MB 9.1 MB 9.0 MB 8.7 MB 480x270 12M 7.89 MB 6.6 MB 6.5 MB 6.6 MB 6.6 MB 6.4 MB
45. 画像のキャッシュ① • 1枚の元画像から複数のサイズを生成する • Rekognition の結果は変わらないのに毎回実行するのは非効率 • 変換コストは 1画像 = 0.001USD (0.15円) 対策 • 顔検出の結果を Redis にキャッシュすることにした • 時間短縮 (300-400ms) & コスト削減となった
46. 画像のキャッシュ② • Sharp で強くぼかしをかきえた時の処理が遅い • 数sec かかる • 元画像が png だととくに遅い • 結果的に Lambda の実行時間も伸びる 対策 • Sharp の実装で改善 + 変換結果を S3 にキャッシュ
47. 署名付き URL の生成が遅い問題-1 • 署名付き URL を生成するのに 1URL に対して約 1ms かかって いた • 1ms は早いのだが、今回大量に画像を一覧表示しているページ があり、かつ1画像に対して8パターンのサイズを生成していた • 具体的には約300画像あり、 x8倍で 2400ms かかってしまった • SaaS のときにも似たような処理があったが、その際は 1URL = 0.06ms 程度だったので問題にはなっていなかった。
48. 署名付き URL の生成が遅い問題-2 対策 • そもそも表示数や生成サイズのパターンが多いことは改善した いが、すぐに手を入れづらい部分だったため、今回は生成結果 をインメモリにキャッシュすることで回避 • デメリットはある • デプロイするとキャッシュが消える • オートスケールした時にキャッシュヒット率が下がる