ペタバイト規模のコスト最適化：あるビデオホスティングプラットフォームが S3 コストを 70% 削減した方法

ビデオホスティングはストレージを大量に必要とするビジネスです。フルHD 1080p 解像度の映画を約 100 万本扱う中程度の事業者でも、約 10 ペタバイト（PB）のストレージが必要になります。Amazon Simple Storage Service は、スケーラビリティ、パフォーマンス、そしてコスト効率の面で長年の実績があります。とはいえ、継続的な FinOps プラクティスを適用することで、コスト効率を高め、クラウドのコストモデルから得られるビジネス価値を最大化することができます。

このブログでは、ビデオホスティングのお客様が Amazon S3 のコストを 70% 削減するのに AWS がどのように役立ったかを説明しています。その成果は、AWS のネイティブツールを活用して何百万もの動画ファイルのライフサイクルを理解し、その後、Just-in-Timeの動画ホスティングプラットフォームのアーキテクチャを微調整することで達成されました。

AWS Cost and Usage Reports を使用して問題の規模を特定する

ビジネスの成長に伴い、お客様は Amazon S3 のコストが着実に増加していることに気づきました。S3 コストはインフラ総コストの 40% を占めていました。コストの全体像を把握するには、通常、AWS Cost Explorer から始めるのが最適です。ただし、Amazon S3 のコストは、ストレージクラスやアクセスパターンなど、さまざまな要因の影響を受ける可能性があるため、AWS Cost and Usage Reports（CUR）を使用してより詳細な分析を行う必要があります。
AWS ブログ「Analyze Amazon S3 storage costs using AWS Cost and Usage Reports, Amazon S3 Inventory, and Amazon Athena」で説明されているアプローチに従い、AWS は Amazon S3 の総コストを次のグラフのように 4 つの主要な構成要素に詳しく分類しました。

図1: AWS Cost and Usage Reports のデータから生成されたS3のコスト内訳

お客様は、S3 Standard、S3 Standard Infrequent Access、S3 Glacier Instant Retrieval（GIR）の 3 つの Amazon S3 ストレージクラスを使用していました。一見したところ、S3 のコストの大部分（88％）は GIR によるものでした。具体的には、GET API（33.7％）と Retrieval（28.6％）のコストは、一般的な使用パターンと比較して異常に高いようです（注：Glacier Instant Retrieval クラスの場合、S3 GET と Retrieval のコストは S3 オブジェクトにアクセスするたびに発生します）。

S3 GIR は「ほとんどアクセスされないが、ミリ秒単位で取得する必要がある長期にわたるデータ」を対象としているため、大量の取得操作は、意図したアーキテクチャ設計とプラットフォームの実際のアクセスパターンとの間に不一致があることを示していました。

アーキテクチャと潜在的な問題を理解する

お客様のワークロードは、世界中の企業顧客向けのセールスおよびマーケティングビデオをホストする SaaS プラットフォームです。ほとんどの動画は少人数の視聴者が視聴することを想定していたため、お客様は Just-in-Time Processing（JITP）アーキテクチャを採用しました。このアプローチにより、要求された場合にのみビデオセグメントを特定の形式にトランスコードし、同じビデオの複数のレンディション（訳注：同一のオリジナル動画を異なる解像度、ビットレート、フォーマット、コーデックなどに変換したバリエーションのこと）を保存する必要がなくなるため、ストレージコストを削減できます。

図2：Just-in-Time Processing（JITP）アーキテクチャ

コストをさらに最適化するために、お客様は、動画ファイルが 30 日経過してアクセスされる可能性が少なくなった時点で、自動的に S3 GIR ストレージクラスに移行する Amazon S3 ライフサイクル設定（これにはいくらかのコストがかかりますが、MB サイズのオブジェクトではごくわずかです）を実装しました。これらのファイルが休止状態のままである限り、S3 GIR は S3 Standard と比較してストレージコストを最大 80% 削減できるという考えでした。

ただし、GIR に保存されているファイルに予期せずアクセスされた場合、Retrieval と GET リクエストの追加料金が発生します（Amazon S3 の料金ページに詳述されています）。1TB のビデオデータを GIR に保存するには 1 か月あたり約 4 ドル（S3 Standard では 21 ドル）かかりますが、同じデータを GIR から一度取得した場合、Retrieval と GET のコストは合計で約 30 ドルになり、意図した節約額はすぐに相殺されます。

図3：S3 GIR 内のファイルを取得したときのコストへの影響

その結果、コスト最適化の取り組みは、次の 2 つの重要な問いに答えることに焦点を当てました。

1. GIR に保存されているビデオファイルの中に、依然として GET や Retrieval のアクティビティが高いものが多すぎないか？
2. もしそうであれば、それらを効果的に特定して対処するにはどうすればよいか？

S3 Access Logging は、膨大なデータの中から問題のファイルを特定するのに役立ちます

GET リクエストと Retrieval リクエストの出所を定量化するために、お客様はバケットに対して行われたすべてのリクエストの詳細な記録を提供する Amazon S3 Access Logging に目を向けました。一度有効にすると、S3 は設定したターゲットバケットにログファイルを自動的に書き込みます。

S3 アクセスログを分析する最良の方法は、Amazon Athena でクエリを実行することです。Amazon S3 のドキュメントの手順に従って、ログデータを表すデータベースとテーブルを作成できます。

たとえば、次の SQL クエリは、データベースとテーブルの名前が s3_access_logs_dbとmybucket_logs であると仮定して、最もアクセス数の多い S3 オブジェクトの上位 10 件を返します。

SELECT 
  COUNT(*) AS access_count,
  key AS file_name
FROM 
  s3_access_logs_db.mybucket_logs
WHERE 
  operation = 'REST.GET.OBJECT'
  AND httpstatus = '200'
GROUP BY 
  key
ORDER BY 
  access_count DESC
LIMIT 10;

その結果、ほんの数時間で、多くのビデオファイルに何千回もアクセスされたことがわかりました。これは予想をはるかに超える頻度です。

さらなる分析により、GIR 層のすべての GET および Retrieval アクティビティのほぼ半分を、全体のごく一部（約 0.1%）、主にサイズの大きいファイルが占めていることが確認されました。これらのファイルについては、S3 Glacier Instant Retrieval（GIR）に保存することは、コストの観点からは非効率的でした。チームはそれらを S3 Intelligent-Tiering に移行することを評価しました。コストモデリングでは、Intelligent-Tiering では取り出し料金がかからず、GET API のコストが GIR と比べて 25 分の 1 であるため、大幅な節約が可能であることが示されました。たとえば、次の上位 3 つのアクセスファイルでは、90% 以上の節約が可能です。

これらの洞察をもとに、チームは最もアクティブな 60,000 のオブジェクト（合計 1,000 万本の動画の約 0.6%）にフラグを付け、S3 Intelligent-Tiering に再分類しました。この変更は意図したとおりに機能し、GIR の Retrieval と GET のコストを 50% 削減しました。

頻繁にアクセスされるファイルを S3 Intelligent-Tiering に再分類するとすぐに節約できましたが、すべての動画が同じアクセスパターンに従うわけではないことも浮き彫りになりました。この洞察は、複数の S3 ストレージクラスを戦略的に使用することにより、より包括的な最適化への道を開きました。

複数のS3ストレージクラスを活用してアーキテクチャを最適化する

Just-in-Time のパッケージ環境では、生涯にわたるストレージコストはアクセスパターン、つまり各ビデオがそのライフサイクル全体でどれくらいの頻度で視聴されるかに大きく依存します。

チームがこれらのロングテール（訳注：ここでの「ロングテール」とは、アクセス頻度の分布において、超高頻度アクセスのファイル群を除いた後も、依然として相対的に高いアクセスが続いているファイル群を指す）の「頻繁にアクセスされる」ファイルを分析したところ、これらは主に明確な特徴を持つマーケティングビデオであることがわかりました。

• より高い解像度（1080p または 4K）とより長い尺のため、約 100 倍のサイズがある
• 視聴される可能性が約 100 倍高い
• 全オブジェクトの 10% だが、月間 31 億件の GET リクエストの約 99％ を占めている

コストを最適化するには、これらのトラフィックの多い動画はアップロード時に S3 Intelligent-Tiering に保存し、残りの動画は引き続き S3 Standard を使用し、30 日間のライフサイクルポリシーで S3 Glacier Instant Retrieval（GIR） に移行する必要があります。

幸いなことに、この改善を実装するのに必要なのは数行のコードだけでした。デプロイされると、GET リクエストの量は GIR から Intelligent-Tiering に徐々にシフトし、S3 全体のコストは着実に下がりました。

図4：S3 Intelligent-Tiering を採用した後の GET リクエスト（GIRクラス）は減少傾向

ストレージクラスを最適化した後、次の問いは簡単でした。S3 GET リクエストの総数を減らして、さらにコストを削減できるでしょうか？

Just-in-Time pipeline の残りの部分をチューニングする

それに答えるために、チームは Just-in-Time（JIT）ビデオ処理パイプラインの他の部分、特にコンテンツ配信レイヤー（Amazon CloudFront）と Nginxベースのパッケージングレイヤーを調べました。

指針となるアイデアは簡単でした：

• CDN レイヤー：CloudFront のキャッシュミスを減らし、Nginxベースのパッケージングレイヤーへフォールバックされるリクエストを減らす
• パッケージ層：各ビデオセグメントを構築するのに必要なフェッチの数を最小限に抑える

図5：GET リクエストコストの概算

CloudFront と Nginxのレイヤーを分析したところ、最適化の機会が実際に見つかりました。

• CloudFront の最適化：Amazon CloudWatch のメトリクスを分析したところ、CloudFront のグローバルキャッシュヒット率はわずか 65％ で、特定の地域では 40％ に低下していました。
  特にパフォーマンスの低い地域に焦点を当てて CloudFront ディストリビューション構成を調整したところ、ヒット率は約 90％ に増加しました。この改善だけでも、S3 GET と Retrieval リクエストを約 50% 削減しました。
• Nginxベースのパッケージングレイヤーの最適化: CloudFront でキャッシュミスが発生するたびに、システムはマニフェストファイルと複数の 6 秒間のセグメントファイルを再生成しました。レイヤーはこれらのファイルをローカルにキャッシュしなかったため、必要なデータを取得するために複数の S3 GET 範囲リクエストを発行しました。
  S3 GET リクエストのバイト範囲サイズを 256 KB から 2 MB に増やすことで、チームは平均セグメントの構築に必要な GET の数を 7.05 から 1.04 に減らし、全体で 85% 削減しました。

これらのパイプラインの最適化により、S3 GET リクエストが 90％ 削減され、それに比例して取得とリクエストのコストが下がり、コスト最適化の最終段階が完了しました。

結果のまとめと重要なポイント

チームは、AWS Cost and Usage Reports と Amazon S3 Access Logging から得た洞察をもとに、お客様が Amazon S3 の6 桁の年間請求額を約 70% 削減できるように支援しました。これらの節約は、CloudFront キャッシュのチューニング、ロングテールコンテンツへの S3 Intelligent-Tiering の活用、効率向上のための S3 GET 範囲サイズの調整など、ワークロードアーキテクチャを最適化することによって達成されました。

クラウドネイティブ（「クラウドで生まれた」）企業は、オンデマンドのクラウド価格設定と柔軟なスケーリングにより、並外れた俊敏性を享受しています。これらのビジネスが急速に成長するにつれて、持続可能な事業拡大にはコストの最適化が重要になります。AWS は、何百万ものお客様との協力から、最も効果的なコスト最適化は、多くの場合、アーキテクチャのチューニング、つまり効率的に拡張し、必要な場合にのみリソースを使用するシステムを設計することにあることを学びました。

自社のコスト要因を理解するには、まず AWS のネイティブコスト管理ツールを使って可視化してください。より包括的なサポートが必要な場合は、AWS Cloud Financial Management チームに依頼して、ワークロードに合わせたコスト最適化戦略を策定することもできます。

翻訳はテクニカルアカウントマネージャーの加須屋 悠己が担当しました。原文はこちらです。

Cedric Hu

シニア・ソリューション・アーキテクトとして、セドリック・フーは ISV と提携してクラウドの複雑さを乗り越えています。彼は、厳格なコスト管理を維持しながら、スケーラブルで革新的なソリューションを構築することを専門としています。これにより、お客様は技術的卓越性を損なうことなく最大の ROI を達成できます。