ビデオホスティングはストレージを大量に必要とするビジネスです。フル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 つの重要な問いに答えることに焦点を当てました。 GIR に保存されているビデオファイルの中に、依然として GET や Retrieval のアクティビティが高いものが多すぎないか？ もしそうであれば、それらを効果的に特定して対処するにはどうすればよいか？ 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; JSON その結果、ほんの数時間で、多くのビデオファイルに何千回もアクセスされたことがわかりました。これは予想をはるかに超える頻度です。 さらなる分析により、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 を達成できます。

G-gen の助田です。当記事では、 Network Connectivity Center を使い、異なるプロジェクトの VPC ネットワーク同士を接続する手順を解説します。 はじめに Network Connectivity Center とは 検証シナリオ ハイブリッドスポーク使用時の注意点 設定手順 事前準備 プロジェクト A: NCC ハブの作成とスポークの接続 プロジェクト B: スポークの作成と接続リクエストの送信 プロジェクト A: 接続リクエストの承認 疎通確認 ルートテーブルの確認 PING による疎通テスト はじめに Network Connectivity Center とは Network Connectivity Center （以下、NCC）は、Google Cloud 上の VPC ネットワークやオンプレミスネットワーク等を、ハブアンドスポークモデルで一元管理するためのネットワーク接続管理サービスです。複数の VPC ネットワークを統合管理し、推移的ルーティングや拠点間接続を実現できます。 NCC の基本的な仕様や詳細な説明については、以下の記事をご参照ください。 blog.g-gen.co.jp 検証シナリオ 当記事では、ハブを管理するプロジェクト A と、そこへ接続するスポークを持つプロジェクト B の構成を検証します。 具体的には、プロジェクト A に作成する NCC ハブ（ ncc-hub-central ）に対して、自プロジェクトの VPC ネットワーク（ vpc-a ）と、別プロジェクトであるプロジェクト B の VPC ネットワーク（ vpc-b ）を、それぞれスポークとして接続します。これにより、異なるプロジェクトに存在する VPC ネットワーク間で経路情報を交換し、 相互通信が可能な状態 を実現します。 構成図は、以下の通りです。 構成図 リソース定義は以下の通りです。 項目 プロジェクト A（ハブ管理） プロジェクト B（スポーク接続） プロジェクト ID project-a-hub project-b-spoke VPC ネットワーク名 vpc-a vpc-b サブネット subnet-a（ 10.0.0.0/24 ） subnet-b（ 172.16.0.0/24 ） リージョン asia-northeast1 asia-northeast1 NCC ハブ名 ncc-hub-central - スポーク名 spoke-a spoke-b ハイブリッドスポーク使用時の注意点 当記事ではプロジェクトを跨いだ VPC スポーク の接続手順を紹介しますが、プロジェクト間接続において、ハイブリッドスポーク（Cloud VPN、Cloud Interconnect、ルーター アプライアンス）は、 ハブと同じプロジェクト内に存在する必要 があります。 例えば、外部ネットワーク（オンプレミスや他クラウド等）との接続用リソースをスポーク側のプロジェクト（今回の例ではプロジェクト B）に配置し、プロジェクト A のハブへ接続することはできません。ハイブリッド接続を行う場合は、 ハブ側のプロジェクトへリソースを集約しなければならない という設計上の制約に留意が必要です。 参考 : ハイブリッドスポーク 設定手順 事前準備 プロジェクトを跨いだネットワーク構成とする場合、各プロジェクトでの作業内容に応じて適切な IAM 権限の付与が必要です。今回は以下の作業を実施するため、それぞれのプロジェクトで権限を設定します。 当記事の作業では、プロジェクト A において、ハブの作成や別プロジェクトからの接続承認、および自プロジェクトの VPC ネットワークのスポーク化を行います。この作業のためにハブの作成者が必要な権限は以下のとおりです。 リソース ロール プロジェクト A ・ハブ アンド スポーク管理者（ roles/networkconnectivity.hubAdmin ） ・スポーク管理者（ roles/networkconnectivity.spokeAdmin ） ・Compute ネットワーク管理者（ roles/compute.networkAdmin ） 一方のプロジェクト B では、スポークを作成し、プロジェクト A のハブに対して接続リクエストを送信します。この作業のためにスポークの作成者が必要な権限は以下のとおりです。 リソース ロール プロジェクト A ・グループ ユーザー（ roles/networkconnectivity.groupUser ） プロジェクト B ・スポーク管理者（ roles/networkconnectivity.spokeAdmin ） ・Compute ネットワーク管理者（ roles/compute.networkAdmin ） 上記では、プロジェクト A と B にそれぞれ別の管理者がいる前提で必要な権限を分けて記載しましたが、両方のプロジェクトに対して同じ管理者が操作をしても構いません。 参考 : ハブとスポークを操作する 参考 : 別のプロジェクトでスポークを提案する プロジェクト A: NCC ハブの作成とスポークの接続 まずはネットワークの中心となるハブを作成し、プロジェクト A 自身の VPC ネットワークを接続します。 NCC ハブのトポロジを選択します。今回は相互通信を行うため、 メッシュ トポロジ を選択します。 ハブ -トポロジ選択- ハブ名を入力し、作成ボタンを押下します。（スポークの追加は後ほど行います） ハブ -構成- 続いて、スポークを作成します。先ほど作成したハブに、 vpc-a をスポーク spoke-a として接続します。 スポークA -接続先のハブ設定- スポークA -編集- 同一プロジェクト内のスポーク接続では特別な承認ステップは発生せず、作成直後にスポークのステータスが Active となります。 スポークA -作成完了後- プロジェクト B: スポークの作成と接続リクエストの送信 次に、プロジェクト B でスポークを作成し、別プロジェクトにある NCC ハブへ接続します。 接続するハブのロケーションを指定します。別のプロジェクトにあるハブへ接続するため、 「別のプロジェクト内」 を選択し、ハブが存在する プロジェクト ID と ハブ名 を指定して、次のステップを押下します。 スポークB -接続先のハブ設定- vpc-b をスポーク spoke-b として作成します。 スポークB -編集- 作成完了後、スポークのステータスが 「確認待ち（Pending）」 となることを確認します。 スポークB -承認待ち- この時点では経路情報の交換は行われておらず、VPC ネットワーク間での通信はできません。 プロジェクト A: 接続リクエストの承認 プロジェクト間のスポーク接続においては、ハブ管理者が リクエストを承認する ことでハブへの接続が有効化されます。 プロジェクト A のハブ詳細画面から、ステータスが [確認待ち] のスポークを選択します。 リクエスト内容を確認後、 [スポークを承認] を押下し、接続を承認します。 スポークB -承認実行- 承認後、ステータスが Active となります。 スポークB -承認済- 疎通確認 ルートテーブルの確認 接続完了後、NCC ハブおよび各 VPC ネットワークのルートテーブルを参照し、以下の通りルートが追加されていることを確認します。 NCC ハブのルートテーブル スポーク A（ 10.0.0.0/24 ）およびスポーク B（ 172.16.0.0/24 ）のサブネットルートが学習されていることを確認します。 NCC ハブのルートテーブル VPC ネットワーク A のルートテーブル ネクストホップを NCC ハブとする 172.16.0.0/24 へのルートが自動追加されていることを確認します。 VPC-A ルートテーブル VPC ネットワーク B のルートテーブル 同様に 10.0.0.0/24 へのルートが追加されていることを確認します。 VPC-B ルートテーブル PING による疎通テスト 検証用に作成した各 VPC ネットワーク内の VM 間で、プライベート IP アドレスによる疎通を確認しました。 # VPC ネットワーク B の VM から、VPC ネットワーク A のVM（10.0.0.2）へ ping 実行 ping 10 . 0 . 0 . 2 -c 4 PING 10 . 0 . 0 . 2 ( 10 . 0 . 0 . 2 ) 56 ( 84 ) bytes of data. 64 bytes from 10 . 0 . 0 .2: icmp_seq = 1 ttl = 64 time = 1 . 23 ms 64 bytes from 10 . 0 . 0 .2: icmp_seq = 2 ttl = 64 time = 0 . 456 ms 64 bytes from 10 . 0 . 0 .2: icmp_seq = 3 ttl = 64 time = 0 . 421 ms 64 bytes from 10 . 0 . 0 .2: icmp_seq = 4 ttl = 64 time = 0 . 443 ms --- 10 . 0 . 0 . 2 ping statistics --- 4 packets transmitted, 4 received, 0 % packet loss, time 3004ms rtt min/avg/max/mdev = 0 . 421 / 0 . 637 / 1 . 230 / 0 . 342 ms NCC ハブを介して、プロジェクトを跨いだ通信が正常に行われていることが確認できました。 助田 真輝 (記事一覧) クラウドソリューション部所属。2024年11月、G-genにジョイン。クラウドインフラ設計、特にネットワークとセキュリティ分野に強い関心を持ち、関連技術の探求に日々取り組む。

はじめに こんにちは、奈良先端科学技術大学院大学 修士 1 年 の 東迎健太郎 です。 2025年 ...