re:Invent 2024: Amazon CloudFrontのCDN技術と最新機能
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 -Amazon CloudFront: Enhancing web performance one HTTP request at a time (CDN308)
この動画では、Amazon CloudFrontのグローバルCDNアーキテクチャと最新機能について詳しく解説しています。50カ国以上に展開された7,700のPOPを活用し、低レイテンシーでコンテンツを配信する仕組みや、ISPネットワーク内に直接展開されるEmbedded POPの導入により最大20%のFirst Byteレイテンシー改善を実現した事例を紹介しています。また、Warner Bros. DiscoveryのOlympics配信事例では、Origin Shieldの活用によってオンデマンドコンテンツで99%、ライブコンテンツで95%のキャッシュオフロードを達成した実績や、新機能のMedia-Quality Aware Resiliency (MQAR)によるビデオストリーミングの品質向上についても説明しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
CloudFrontが支えるグローバルスケールのコンテンツ配信
皆様、おはようございます。re:Inventへようこそ。私にとって、今年のParisオリンピックの視聴は素晴らしい経験でした。世界中から何百万人もの視聴者が、完璧なリアルタイム視聴体験を期待して視聴していました。しかし、このようなグローバルな規模でどのようにしてそのレベルのパフォーマンスを実現できたのでしょうか？このセッションでは、Amazon CloudFrontがその実現に果たした重要な役割についてお話しします。ライブストリーミング、動的コンテンツ、静的Webサイトのいずれを扱う場合でも、高可用性、セキュリティ、ミリ秒単位のレイテンシーは、今日の世界では譲れない要件となっています。私はSagar Desardaです。Data、Analytics、Gen AI ISVsのTAM組織のリーダーを務めており、Americasのリーダーも兼任しています。一緒に登壇するのは、CloudFrontプロダクトチームを率いるSean Meckleyと、特別ゲストとしてWarner Bros. DiscoveryのVP of EngineeringであるSrini Rajagopalanです。
まず、CloudFrontの概要と、CloudFrontの視点からHTTPリクエストの流れについてご説明します。この流れは、エンドユーザーがHTTPリクエストを行うところから始まります。CloudFront DNSとRoute 53がどのように連携してレイテンシーを最小限に抑え、最寄りのエッジにトラフィックをルーティングするかをご説明します。リクエストがエッジロケーションに到達すると、CloudFrontのキャッシュアーキテクチャと、キャッシュコンテンツを管理するためのポリシーについてお話しします。次に、CloudFront FunctionsとLambda@Edgeがエッジに強力なサーバーレスコンピューティングをもたらす方法についてご説明します。そして、HTTPリクエストがCloudFrontプラットフォームを通過する際、トラフィック状況が変化しても高速性を維持できるよう、リアルタイムでルーティングの判断を行います。リクエストがキャッシュされていない場合は、オリジンへの最適なルートを素早く特定します。Seanが、CloudFrontとオリジンを接続するさまざまな方法について説明します。私は主にWebパフォーマンスの部分に焦点を当て、その後、SriniがCloudFrontでのオリンピックのような大規模メディアイベントの運営に関する知見を共有します。
CloudFrontのアーキテクチャとDNS最適化
Amazon CloudFrontは、グローバルに分散されたCDN（コンテンツデリバリーネットワーク）です。低レイテンシー、高速な転送速度、最適な信頼性でコンテンツを配信するように設計されています。中核となるのは、50カ国以上に展開された7,700のPOPで、エンドユーザーの近くにコンテンツのコピーをキャッシュします。CloudFrontは、各ユーザーのリクエストをAWSのバックボーンネットワークを通じて、最適なコンテンツ配信が可能なエッジロケーションにルーティングすることで、コンテンツの配信を高速化します。これに加えて、CloudFrontが多数のISPとの直接的なピアリングを優先することで、データの移動距離が短縮され、パフォーマンスが向上します。
昨年、私たちは新しいタイプのPOPとして、Embedded POPを導入しました。CloudFront Embedded POPは、AWSネットワーク内に展開される通常のCloudFront POPとは異なり、エンドユーザーのISPネットワーク内に直接展開されます。Embedded POPは、ビデオストリームやゲームのダウンロードなど、大規模なキャッシュ可能なコンテンツを大規模に配信することに特化して構築されています。一方、CloudFront POPは、静的なキャッシュ可能なコンテンツや動的コンテンツなど、さまざまなワークロードの配信に対応するように設計されています。まず標準的なCloudFrontアーキテクチャの概要を説明し、その後これについて詳しくお話しします。
ここからHTTPリクエストの旅が始まります。それはDNSの解決からです。解決が速ければ速いほど、ブラウザはより早くコンテンツの取得を開始できます。エンドユーザーがリクエストを行うと、まずブラウザからエンドユーザーのISP DNSサーバーに向かいます。 このISP DNSは再帰的リゾルバーです。まず.comなどのトップレベルドメイン、次にtntsports.comなどの特定のドメインを見て、ネームサーバーを特定していきます。ネームサーバーが特定されると（この場合はRoute 53）、Route 53はtntsports.comを長いcloudfront.netホスト名に変換することで、そのリクエストをCloudFront DNSに渡します。そこからCloudFront DNSが、コンテンツを提供するための最適なIPを決定します。その後、IPアドレスが返され、下流に送信されてリクエストが完了します。
2019年にCloudFront DNSについて詳しくお話ししましたので、このQRコードの動画をご覧ください。ここでは、私たちのアプローチについて簡単にご説明します。
リクエストのルーティングはDNSレイヤーで行われますが、単純な位置情報マッチングにとどまりません。すべてのネットワークから各CloudFront POPへのパフォーマンスデータを収集し、サーバーの健全性、ネットワーク容量、ネットワーク状態をリアルタイムでモニタリングして、輻輳したルートを回避します。これらの値をすべて考慮し、ISP間でも輻輳を回避しながら、最適なIPを決定しています。
この5年間で、CloudFront DNSにいくつかの改良を加えてきました。まず可用性についてお話しします。CloudFront DNSサーバーはCloudFront CDNへのゲートウェイとして機能し、可用性を確保するための重要な最初の接点となっています。エッジでのネットワーク分離イベントの影響を軽減し、増加するDNSトラフィックにシームレスに対応するため、既存のEdge Locationに加えて、AWSリージョンにもDNSフリートを拡大しました。 つまり、CloudFront DNSは現在、Edge POPとAWSリージョンの両方でホスティングされているということです。Edge POPやAWSリージョンで問題が発生しても、他のAWSリージョンがDNSリクエストを継続して処理できるため、可用性への影響を最小限に抑えることができます。
この拡張により、CloudFront DNSの地理的フットプリントが大幅に広がり、DNSクエリのレイテンシーが最大30%削減されました。これは、CloudFrontを利用したアプリケーションのDNS解決が高速化され、ページの読み込みが迅速になり、よりレスポンシブなユーザーエクスペリエンスが実現できることを意味します。 私たちは、ネットワークとアプリケーションの両レイヤーでヘルスチェックを実施しており、個々のPOPの障害、ISPの問題、ネットワーク上の微妙なグレーフェイルなどに起因する可用性の問題を早期に検知できます。これを補完するため、プラットフォームにはカスタムモニタリングメカニズムとサードパーティのDNSモニタリングソリューションが統合されています。内部ルーティングアルゴリズムがこれらの多様なソースからの知見を集約し、トラフィックを事前に再ルーティングすることで、アプリケーションの可用性を途切れることなく確保しています。
現在、POP容量メトリクスやRoute 53とCloudFront DNS間のハンドオフを含む、重要なCloudFront DNSコンポーネントはすべてマルチリージョンでデプロイされています。CloudFrontの設定を更新すると、マルチリージョンセットアップがこれらの変更をリアルタイムでポーリングし、迅速に同期して適用されます。2021年12月のUS-EAST-1での障害時に、お客様がCloudFrontディストリビューションを更新できなかったような問題に直面することがないよう努めています。
CloudFrontのルーティングアルゴリズムとAnycast IPの導入
次はパフォーマンスについてです。道路や都市の代わりに、サーバー、リンク、クライアントの負荷、ネットワークレイアウト、サーバーの健全性データで構成された巨大なマップを想像してください。これがCloudFrontのルーティングアルゴリズムが使用するものです。DNSリクエストに応答する複雑なルーティングテーブルで、これらすべての要因に常に対応しながら、各リクエストに最適な経路を見つけ出します。長年にわたり、CloudFrontのトラフィックが増加するにつれて、ルーティングテーブルはさらに複雑になってきました。データセンターからの送信ネットワーク接続が大量のデータトラフィックによってオーバーロードされると、Egress Link輻輳が発生します。CloudFrontのトラフィックが急速に増加する中、Egress Link輻輳やパケットロスなどの問題を回避しながら、これらのリアルタイムな変化により賢く、より迅速に対応する方法が必要でした。
この課題に対処するため、私たちはアルゴリズムを見直し、より適応的で応答性の高いものにしました。処理するデータを2つのグループに分類しています。1つ目は、あまり頻繁に変更されないインプットで、エンドユーザーのネットワークトポロジーなどがこれに該当します。2つ目は、顧客トラフィック、POPの健全性、POPの容量など、頻繁に変更されるインプットです。この再設計により、トラフィック需要が増加しても、より迅速な調整が可能になり、高いパフォーマンスを維持できるようになりました。これは、OlympicsやThursday Night Footballなどの大規模イベント時でも、最高のパフォーマンスを維持するために重要な役割を果たしています。
パフォーマンス改善の取り組みの一環として、Thursday Night FootballでのResolver-based DNSルーティングにおいて、DNSの背後にあるクライアントIPの実際の位置が常に正確に把握できているわけではないことが分かりました。これは、クライアントとDNSの距離が離れすぎている場合に、最適とは言えないルーティングにつながることがあります。この問題に対処するため、現在ではDNS Client Subnetを、レイテンシーベースおよびキャパシティ管理型ルーティングと組み合わせて使用しています。例えば、エンドユーザーがメキシコにいるのに、DNSリゾルバーがフロリダにある場合、以前であればエンドユーザーはフロリダのEdge Locationに接続されていたでしょう。
現在は、エンドユーザーのISPがEDNS0に対応している場合、エンドユーザーの位置情報がCloudFront DNSに渡され、ユーザーはメキシコのCloudFront POPに接続されます。AWSのグローバルな規模を活かし、米国および世界中の主要なISPと提携して、EDNS0を通じたトラフィックの誘導を開始しています。特定のISPでは、最大100%のトラフィックがこの改良されたルーティング方式を使用しています。
最近の発表に関して、この話題についてお伝えできることを嬉しく思います。CloudFrontを使用する場合、エンドユーザーは数千のCDN IPアドレスのいずれかを通じて接続し、これらのIPはエンドユーザーの位置に応じて変更される可能性があります。通常はこれで問題ありませんが、ネットワークキャリアと提携する企業などの特定のSaaSシナリオでは理想的ではありません。データ免除や特別価格の提供のためにCDNトラフィックを識別する必要があったり、アウトバウンドファイアウォールルールにCDN IPアドレスを含める必要があるパートナーもいるかもしれません。数千の変動するCDN IPを管理するのは困難な場合があるため、2週間前にCloudFrontはAnycast IPアドレスのサポートを開始しました。
CloudFrontのディストリビューションでこの機能を設定すると、21個の専用Anycast IPのセットが提供されます。リクエストが到着すると、BGPによってエントリーPOPにルーティングされます。より適切なPOPでリクエストを処理できると判断した場合、エントリーPOPがAnycast IPアドレスのルートをアナウンスし、エンドユーザーに最も近いPOPからレスポンスが返されます。
CloudFrontのセキュリティ機能とキャッシング戦略
DNS応答の後、HTTPリクエストはCloudFrontのエッジロケーションに向かって送信されます。AWSでは、セキュリティがお客様にとって基本的な価値提供であることを理解しています。これまでの年月をかけて、CloudFrontチームは一連の保護メカニズムを構築・統合してきました。AWS Shieldシステムは、すべてのインバウンドトラフィックをスクラビングし、AWSリージョンレベルで大規模なDDoS攻撃を緩和するために深層パケット検査を実行します。これは完全に透過的で、リクエストがCloudFrontに到達する前に行われます。
さらに、AWS WAF（Web Application Firewall）を使用して、アプリケーション層の攻撃からアプリケーションを保護し、攻撃対象領域をさらに縮小することができます。 ここ数年、アプリケーション層への攻撃はますます巧妙になってきています。悪意のある攻撃者は、DDoS攻撃やOWASP Top 10の脆弱性など、アプリケーション層の脆弱性を標的にしています。この攻撃の複雑化により、進化する脅威からアプリケーションを保護するために、より堅牢で階層化されたセキュリティソリューションの必要性が浮き彫りになりました。このような脅威に対応するため、CloudFrontチームはCDNレベルでLayer 7 DDoS攻撃やフラッシュクラウド攻撃を自動的に緩和するDDoS Detection Engineを開発しました。これにより、お客様のデータに新しいレベルのセキュリティを提供し、パフォーマンスの継続性を確保します。これはアプリケーション固有のルールを持つAWS WAFに取って代わるものではなく、むしろAWS上の階層化されたセキュリティフレームワークの一部として考えてください。
これを説明するために、CloudFront POPの内部アーキテクチャについて、L1、L2、L3という3つのキャッシュ層でコンテンツがどのように管理されているかを説明します。HTTPリクエストがPOPに到達すると、まずロードバランサーに到達します。ここでは、ECMPルーティングを使用してすべてのL1サーバー間でトラフィックやTCP接続を均等に分散させます。L1サーバーはロードバランサーのすぐ後ろに位置し、非常にスケーラブルで、このレベルで必要な数のサーバーをホストできます。
リクエストがL1に到達すると、TCP接続が終端され、このポイントでTLSセッションが確立されます。DDoS Detection Engineは、POPがエンドユーザーにレスポンスを返す際に機能する、すべてのL1サーバーに組み込まれています。このエンジンは、異常検知、リクエストフィンガープリンティング、シグネチャ分析などの高度な技術を使用してトラフィックを積極的にスキャンし、異常なパターンを検出します。CloudFrontフリート全体に及ぶ確率的データ構造を活用して脅威レベルを評価し、これらのリクエストに信頼度スコアを割り当てます。このスコアに基づいて適切な緩和戦略を決定し、必要に応じてリクエストをブロックします。最も優れている点は、これがリクエストと同時に処理され、アプリケーションに追加の遅延を発生させないことです。
コンテンツが非常に人気が高いかホットな場合、最も頻繁にアクセスされるコンテンツの一部を保持するL1階層にキャッシュされます。これにより、人気のあるコンテンツを直接キャッシュから提供できます。やや人気の低いコンテンツはL2キャッシュに移動されます。ここでは一貫性のあるハッシュアルゴリズムを使用して、すべてのL1サーバーが同じオブジェクトを同じL2サーバーにルーティングするようにしています。これにより、ストレージの効率的な利用が確保され、コンテンツをより効果的に分散させることでキャッシュのオフロードが向上します。 CloudFrontがキャッシュに存在しないことが分かっているリクエストや、no-storeまたはPOSTリクエストを受け取った場合、L1は直接オリジンにアクセスできます。なぜなら、L2とL3にそのオブジェクトが存在しないことが分かっているからです。
リクエストがEdgeロケーションに到達すると、次の問題はこのリクエストにどのルールが適用されるかということです。ここでEdge POPはディストリビューションの設定を読み込んで、その中で何が設定されているかを確認します。例えば、TLS 1.3やHTTP/3の使用を設定している場合、またはWebSocket接続用に設定している場合、これらの接続はEdgeで確立される際にここで適用されます。 このポイントでディストリビューションの設定が読み込まれると、設定されているキャッシュルール、圧縮設定、そしてPOPで実行されているEdge Computeがあるかどうかを確認します。
まず、スマートなキャッシング戦略の構築についてお話ししましょう。セグメンテーションから多層キャッシング、キャッシュの無効化、プロアクティブなモニタリングまで、これらの各ステップは、パフォーマンスとコンテンツの鮮度のバランスを取るのに役立ちます。 静的アセットのキャッシュセグメンテーションから始めると、スムーズなアップデートのために長期的なCache-Controlヘッダーとバージョニングを使用します。動的コンテンツについては、Cache Policyとstale-while-revalidateなどのテクニックを使用して、コンテンツがオリジンで検証されている間でも、より速いレスポンスを確保します。最初は動的コンテンツはキャッシュできないように思えるかもしれませんが、例えばライブビデオを考えてみましょう。常に最新のセグメントが必要なためキャッシュ不可能だと思うかもしれませんが、実際にはその多くがキャッシュ可能なのです。
Cache Policyを使用することで、クエリ文字列、リクエストヘッダー、ユーザー固有またはリクエスト固有のデータに基づいて変更できるCookieを含むキャッシュキーを設定することで、キャッシュルールを作成できます。これにより、動的コンテンツの異なるバリエーションを適切にキャッシュすることができます。 CloudFrontへのリクエスト数を減らすため、ブラウザにより長いTTLを設定することをお勧めします。同時に、同じオブジェクトに対してCloudFrontではやや短いTTLを設定します。そうすることで、ブラウザのキャッシュが期限切れになって新しいリクエストが発生した時には、CloudFrontがすでにオリジンからコンテンツを更新している状態になります。これはCache-Control max-ageとs-maxageディレクティブを組み合わせることで実現できます。
ビルドパイプラインやCMSにキャッシュパージを組み込むことで、コンテンツが変更されるたびに自動的に無効化をトリガーすることができます。これにより、古いキャッシュが残っているかどうかを心配することなく、ユーザーが常に最新バージョンのコンテンツを取得できるようになります。 キャッシュパフォーマンスを最適化するには、まずCloudFrontのログを確認することから始めましょう。これらのログは、Cache HitとCache Missの比率を明確に示してくれます。
エッジコンピューティングとOrigin保護の進化
パフォーマンスをさらに向上させるために、Webページのパフォーマンスをより包括的に把握できる外部モニタリングツールを導入しましょう。これらのツールは、キャッシングだけでなく、パフォーマンスを最適化できるページ読み込み時間の特定や、速度低下の原因となっているボトルネックの特定など、さまざまな領域を明らかにすることができます。
このWebページを例に見てみましょう。LCPは、Webページ上で最も大きな表示要素が完全に読み込まれ、ユーザーに表示されるまでの時間を測定します。それは画像、動画、あるいはこのページのテキストブロックかもしれません。ここにある大きな画像がLCP要素として機能しています。 このWebページでウォーターフォールレポートを実行すると、ブラウザが画像の読み込みを開始するのは 0.7秒後であることがわかります。では、どうすればよいでしょうか？WebページのソースHTMLに Preloadタグを追加する実験を行いました。ご覧の通り、左側の実験では大きな画像が1.6秒で読み込まれているのに対し、 右側のオリジナルでは2.2秒かかっています。まとめると、もしLCPが 画像である場合は、Preloadの使用を検討してください。これは、パフォーマンスを向上させる簡単なステップです。
LCP画像をPreloadすることで、 Webページのレンダリング時間を短縮することができました。キャッシュポリシーで圧縮を設定すると、下流に配信されるオブジェクトのサイズがさらに削減されます。圧縮に関して、フォントについて少しお話ししたいと思います。フォントは Webページの初期ロードの大部分を占める可能性があるため、圧縮戦略はパフォーマンスにとって重要です。これについて2つの重要なポイントをお伝えします。WOFF2フォントは広く圧縮されており、より効率的なので、これを使用することをお勧めします。比較すると、WOFF version 1フォントはGzip圧縮されています。HTTP Archiveのデータによると、6〜8%のWebサイトがWOFF2フォントにGzip圧縮を適用しているとのことです。二重圧縮は避けてください - これはブラウザのCPU負荷を増加させ、不必要にWebサイトを遅くするだけです。
アセットを最適化したところで、次は レイテンシーをさらに削減するために、エンドユーザーの近くでリクエストを処理できるComputeについて詳しく見ていきましょう。Edge POPでCloudFront Functionsを実行できます。これは ミリ秒単位で実行されるように設計された軽量なCompute処理用のサービスです。CloudFront FunctionsはCloudFrontのEdgeロケーションでJavaScriptコードをネイティブに実行し、1秒あたり数百万のリクエストを瞬時に処理できるスケーラビリティを持っており、お客様はバーストや制限を気にする必要がありません。独自のサーバーレススクリプティングプラットフォームを備え、軽量なJavaScriptコードを使用することができます。
そして、CloudFront Key Value Store（KVS）があります。これはCloudFront Functionsと統合されたグローバルな低レイテンシーのデータストアです。KVSを使用することで、関数コードと関数データを切り離して、それぞれを独立して管理することができます。これにより関数コードがシンプルになり、関数の更新のためのコード変更をデプロイすることなくデータを更新することが容易になります。お客様が CloudFront Functionsを利用している多くのユースケースの中から、A/Bテストの実行についてお話ししたいと思います。新機能やレイアウトをテストし、コンバージョンを測定し、ユーザーエンゲージメントを評価するための簡単な実験を行うことは一般的です。結果に応じて、そのアイデアを破棄するか、本番環境に採用するかを決定します。
CloudFront Functionsで実験フレームワーク全体を実行できるようになりました。この図では、実験がユーザーをランダムにある実験バリアントに割り当て、そのエクスペリエンスで一貫性を保つためのセッションCookieを作成します。複数のページバリアントを異なるOriginから提供する場合、1ヶ月前までは、Originルーティングを管理するためにLambda@Edgeで別の関数を書く必要がありました。しかし今では、CloudFront Functions内でそれが可能になりました。Originを動的に切り替え、Originの書き換えを効率化し、CloudFront Functionsでトラフィックルーティングを実行できます。
このCloudFront Functionsを使用するアプローチは、Point of Presence (POP)のエッジで直接計算が実行されるため、パフォーマンスをさらに最適化し、レイテンシーを削減するのに役立ちます。 Key Value StoreにOrigin IDを保存し、そのデータを使用してCloudFront Functions内でOriginホスト名を動的に構築できます。これは、頻繁に実験を実施し、Originの作成と削除を行う場合に特に便利です。CloudFrontの設定を常に更新する代わりに、CI/CDパイプラインで単にKey Value Storeをデプロイまたは更新するだけで、実験の進化に合わせて新しいOriginへのリダイレクトをシームレスに行うことができます。
HTTPリクエストがエッジPOPからRegional Edge Cache (REC)に向かう際、 レイテンシーマトリックスに基づいて最適なRECが割り当てられます。RECはマルチアーキテクチャを採用しており、可用性とレジリエンシーを向上させています。割り当てられたRECに問題が発生した場合、パフォーマンスを維持するために代替RECに切り替えるフォールバックオプションがあります。CloudFrontプラットフォームには、リクエストレイテンシー、接続時間、リクエスト量などの重要なメトリクスを追跡する組み込みのモニタリング機能があります。私たちは独自のカスタムモニタリングを構築しており、異なるHTTPメソッドや異なるオブジェクトサイズ、待機パターンを持つHTTPリクエストをプラットフォームに送信しています。これらのデータを総合的に分析することで、必要に応じてエッジPOPから異なるRECにリクエストをルーティングできるトラフィックエンジニアリングを実行できます。
Lambda@EdgeはRECで実行される別のサーバーレス関数です。CloudFront Functionsがヘッダー操作のような軽量な高速タスクに最適である一方、Lambda@Edgeはより長い実行時間と、より複雑でリソース集約的なワークロードの処理を可能にすることで、機能を強化します。より多くのパワーと柔軟性がエッジコンピューティングで必要な場合に理想的です。 HTTPリクエストがRECからOrigin Shieldに向かう際、Originへの負荷をさらに軽減する追加のキャッシュレイヤーがあります。この設定により、ユニークなアセットごとに1つのリクエストのみがOriginに転送され、レイテンシーを最小限に抑え、キャッシュヒット率を最適化します。Warner Bros. DiscoveryはOrigin Shieldを設定しており、その機能について説明します。
CloudFrontのOrigin最適化とパフォーマンス向上策
次に、HTTPリクエストの最後の部分を見ていきましょう。リクエストは今RECにありますが、次に何が起こるのでしょうか？ ここでCloudFrontは、アプリケーションがホストされているOriginからコンテンツを取得します。ここではAWSネットワーク内にいて、CloudFrontがOriginに正常に接続できるようにするために多くの要素が関係しています。ここでは4つの重要な概念について説明します：CloudFront Origin Groups、Origin Access Control (OAC)、Lambda@Edge、そしてVPC Originです。
まず、Origin Groupsについてお話ししましょう。CloudFrontのエッジがキャッシュされたコンテンツを高可用性で提供する方法についてはすでに説明しましたが、Originそのものの可用性についてはどうでしょうか？例えば、ライブ動画ストリーミングを運用していて、数分どころか数秒の停止や中断でも視聴者に大きな影響が出るような場合を考えてみましょう。その解決策の一つは、CloudFrontの背後で冗長性のために2つのOriginを並行して運用することです。一方のOriginが過負荷になったりアクセス不能になったりした場合に、バックアップがあるわけです。CloudFrontは、HTTPベースのヘルスチェックを使用して、プライマリからスタンバイへのフェイルオーバーを実行します。お客様からは、ほぼ瞬時のフェイルオーバー判断が高く評価されています。
2つのOriginを設定し、各リクエストから返される HTTPステータスコードを観察することで、プライマリサーバーの健全性をリアルタイムでチェックできます。プライマリサーバーがエラーコードを返すか、完全に到達不能になった場合、CloudFrontは即座にバックアップOriginに切り替わります。4XXや5XXエラーなど、フェイルとみなしたいHTTPエラーコードを自由に設定できます。次は、OriginとしてAmazon S3を使用する場合について説明しましょう。S3は静的Webサイトや動画などの静的コンテンツのホスティングに最適で、CloudFrontを使用してそれらを視聴者に配信できます。しかし、視聴者や悪意のある人がS3バケットから直接コンテンツを取得するのを防ぐにはどうすればよいでしょうか？
このシナリオの解決策がOrigin Access Control（OAC）です。S3をOriginとして使用する場合、OACの実装は不可欠です。OACを設定すると、S3に直接アクセスしてコンテンツを取得することはできなくなり、パブリックインターネットからはCloudFrontを経由してのみアクセスが可能になります。これにより、セキュリティ制御やユーザー認証をバイパスする不正なアクセスを防ぐことができます。
Origin Access Controlでは、 CloudFrontのOriginとして使用するS3バケットは、リクエストの署名とバケットのアクセス制御ポリシーを使用して保護されます。CloudFrontは各リクエストに署名を行い、S3バケットに適用されたアクセス制御ポリシーによって、各リクエストを許可するか拒否するかが決定されます。OACには、短期的な認証情報、頻繁な認証情報のローテーション、リソースベースのポリシーなど、セキュリティのベストプラクティスが組み込まれています。
Lambda@Edgeを使用すると、Originへの入力リクエストと出力レスポンスを操作できます。CloudFront Functionsとは異なり、Lambda@Edgeではリクエストとレスポンスの本文自体を検査および変更できるため、より高度な操作が可能です。これらの操作には、より多くの計算能力が必要だったり、サードパーティのコードやライブラリに依存したり、APIやデータストアへのネットワーク経由の呼び出しが必要になったりする場合があります。ユースケースとしては、入力側ではAPIのスキーマ検証、出力側ではデータの変換やマスキング、さらにサードパーティのライブラリを使用したオンザフライの動画変換や画像最適化などがあります。
Eコマースアプリケーションにおける商品カタログサービスのアーキテクチャ例を見てみましょう。オリジンリクエストでは、Lambda@Edgeがリクエストボディにアクセスしてスキーマ検証を実行できます。オリジンレスポンスでは、モバイルやデスクトップなど、さまざまなタイプのクライアントデバイス向けに商品画像やその他のメディアを最適化するためのライブラリを呼び出すことができます。
CloudFrontは最近、VPC originsと呼ばれる新機能をリリースしました。この機能により、パブリックな接続なしでVPCのプライベートサブネットにホストされたアプリケーションからコンテンツを配信できるようになりました。Origin Access ControlがS3バケットを保護するのと同様に、VPC originsは動的オリジンを保護します。このリリースにより、Application Load Balancer、Network Load Balancer、EC2インスタンスをプライベートサブネットに配置し、CloudFrontディストリビューションを通じてのみアクセス可能にすることができます。CloudFrontは、CloudFrontエッジから直接VPCへのネットワークトンネルを確立し、パブリックインターネットを完全にバイパスすることでこれを実現します。これによりオリジンの接続が簡素化され、オリジンに対するパブリックIPv4アドレスの必要性が排除され、オリジンへのアクセスがCloudFrontディストリビューションを通じてのみ可能となることでセキュリティの影響範囲が縮小されます。
コンテンツのソースとしてオリジンは不可欠ですが、最高のパフォーマンスを実現し、オリジンのスケーリング要件を最小限に抑えるには、エッジとオリジン間のリクエストを削減する必要があります。CloudFrontは、オリジンへのラウンドトリップを最小限に抑え、高速化するためのいくつかの最適化を自動的に実装しています。リクエストコラプシングはそのような最適化の1つで、Amazon Prime VideoのThursday Night Footballのようなライブビデオストリーミングのユースケースで特に効果を発揮します。さまざまな場所から多数の視聴者が同時にキャッシュにまだない新しいオブジェクト（最新のビデオセグメントなど）をリクエストする場合、CloudFrontはエッジでこれらの類似したリクエストを認識します。そして、これらすべてのリクエストを1つのオリジンフェッチにまとめ、同じキャッシュされたファイルをリクエストしているすべてのクライアントに提供します。このリクエストコラプシングは、エッジPOPとRegional Edge Cacheとオリジン間の両方で、CloudFrontシステムの複数のレイヤーで発生します。
CloudFrontが実装するもう1つの最適化は、バイトストリーミングです。キャッシュミスが発生した場合でも、CloudFrontは視聴者に可能な限り最高のエクスペリエンスを提供しようとします。オブジェクト全体がオリジンからキャッシュにダウンロードされるのを待ってからキャッシュからファイルを提供するのではなく、CloudFrontはオリジンから最初のバイトが到達した時点でそのファイルを視聴者に送信し始めます。CloudFrontは文字通りそのオブジェクトを視聴者にストリーミングするため、キャッシュミス時の大きな遅延のペナルティを回避できます。
次は接続効率です。このセッションでは、HTTPオブジェクトやリクエストの寿命におけるミリ秒単位の時間について話していますが、TCPコネクションの確立とTLSハンドシェイクの実行に必要な時間は、その時間の大きな部分を占めています。CloudFrontはこのハンドシェイクを効率的に使用しようとします。CloudFrontがオリジンへの接続を確立すると、同じオリジンへの別のリクエストがその期間中に発生した場合に備えて、その接続を数秒間開いたままにしようとします。これにより、TCPコネクションとTLSハンドシェイクを再確立する必要がないため、将来の接続がはるかに高速になります。
Warner Bros. DiscoveryのOlympics配信事例
この1年間、Warner Bros. Discoveryは、インドでのOlympics、ラテンアメリカでのUEFA Cup、そして2024年の大統領選挙など、数々の大規模イベントを配信してきました。House of the Dragonのファンの方々にも、もちろんコンテンツを届けました。House of the Dragonの新エピソードを毎週配信する際、何百万人ものお客様が再生ボタンを押そうと待ち構えています。そして実際に再生が始まると、バックエンドサービス、特にEntitlementサービスとURL配信サービスに大量のリクエストが殺到します。お客様がエピソードの長さである50～60分間コンテンツを視聴し続けると、同時視聴者数が着実に増加していきます。これにより、広告システムやOrigin、そしてPOPに大きな負荷がかかります。
Olympicsはスケーラビリティにさらなる課題をもたらします - それは同時開催イベントのスケーリングです。Olympicsを運営する際には、何百ものイベントが同時に進行し、それぞれがHouse of the Dragonのエピソードと同じくらいの規模になる可能性があります。インドでは47の国々で19の言語でOlympicsが配信されました。これは膨大なデータが私たちのシステムを流れることを意味し、特にCDN IPピアリングには大きな帯域幅が必要となり、エンドユーザーに影響が出ないよう慎重なCDNロードバランシングが求められます。8月4日だけでも6億分のストリーミングがありました - これは1,141年分に相当します。100m決勝は最も多くのトラフィックを記録し、試合開始5分前にトラフィックが急増しましたが、私たちは一切の障害なくこれを実現しました。これは、Warner Bros. Discoveryのチームとパートナーであるアマゾンウェブサービスが、このレベルのスケールとレジリエンシーを実現するために行った努力の証です。
大規模イベントの運営は、システムのほぼすべての部分が試されるため、困難を伴います。これらの課題を4つの主要なカテゴリーに分けてご説明します。1つ目はセキュリティです - このような大規模イベントは注目を集めますが、時として望まない種類の注目を集めることもあります。不正アクセスは収益と顧客の信頼に影響を与えます。お気に入りの番組を視聴するためにサブスクリプション料金を支払ったのに、同じコンテンツが違法サイトで無料で視聴できることを知ったらどう感じるでしょうか。これによってストリーミングプラットフォームは顧客を失う可能性があります。
次は品質です。皆さんの中で、品質が悪かったり、バッファリングが多すぎたりしてストリーミングを中断した経験はありませんか？視聴者は高品質の音声と映像を期待しています - 私が言っているのは、様々なネットワーク環境で、複数のデバイスにおいて4K HDR Atmosを実現し、なおかつバッファリングを一切発生させないということです。3つ目はスケールです。私はすでに3種類のスケール - 同時開催イベントのスケーリング、同時視聴者数のスケーリング、ストリーム開始時のスケーリング - について話しましたが、Olympicsはこれらすべてを含んでいます。これらすべてを100%の可用性で、グリッチやダウンタイムなしで実現しなければならないことを想像してみてください。
これが、私たちの視聴者が期待しているレベルの信頼性なのです。
これまで説明した4つの主な課題について、Amazon CloudFrontを使用してどのように解決するのか、簡単に見ていきましょう。しかし、解決策に入る前に、ユーザーがコンテンツをストリーミングする際のアーキテクチャを見てみましょう。複数のRegional Edge Cache（REC）が稼働しており、CloudFrontはそのCDNの1つです。これは「CDNサンドイッチアーキテクチャ」と呼ばれるもので、すべてのデータがCloudFrontを経由し、CloudFrontだけがOriginに接続される仕組みになっています。これによってキャッシュのオフロードが改善され、Originをスムーズかつ効率的に運用することができます。
次にセキュリティについて説明しましょう。Cross-Origin Resource Sharing（CORS）により、複数のプラットフォームでストリームを公開する柔軟性が得られます。厳密なCORSポリシーを設定することで、ビジネスにとって重要な不正アクセスを防ぐことができます。あるメジャーなライブイベント中、サイトが私たちのストリームを自分たちのアプリケーションに埋め込もうとしたため、不正アクセスの試みが急増しました。これは2つの理由で深刻な問題でした：セキュリティ違反であることと、ハッカーの分の料金を私たちが支払うことになる隠れたコストが発生することです。この対策として、CloudFront Functionsと厳密なCORSポリシーを使用して不正アクセスを防いでいます。CloudFrontはネイティブでCORSをサポートしていますが、カスタマイズの柔軟性を得るためにCloudFront Functionsを使用しています。QRコードの先にあるGitHubリンクで、CORSの実装をご確認ください。
今回のOlympicsでは、前回のOlympicsと比較して、サブスクリプション率が77%増加しました。視聴者数の増加に伴い、ストリームを保護し続ける必要性も高まっています。セキュリティをさらに強化するため、CloudFront Functionsを使用してトークンを検証し、不正アクセスを防いでいます。
100万人の顧客がストリーミングする2時間のNBAゲームを運営する場合、トークン検証のためにCloudFront Functionに合計18億のリクエストが発生することになります。ストリームのセグメント時間を4秒と仮定すると、各ユーザーが4秒ごとにリクエストを行うことになります。これをオンプレミスのソリューションで実施しようとすると、CTOが巨額の計算コストについて私のデスクに来ることは間違いありません。CloudFront Functionsを使用することで、低コスト、低レイテンシー、高いスケーラビリティを実現できます。ここで示すコストは、試合の全期間における1ユーザーあたりのコストです。
Olympicsの重要な瞬間の1つである100メートル決勝について話しましょう。100万人の顧客が視聴し、当然ながら10億のリクエストがバックエンドシステムに到達しました。RECはトラフィックからOriginを保護する優れた役割を果たしていますが、実際にはまだ多くのリクエストがOriginに到達します。さらに、2つのRECが同時にリクエストを行う場合、それらはおそらく同じオブジェクトを要求しています。これはOriginの可用性に課題をもたらす可能性があります。
この問題をどのように解決したのでしょうか？私たちはOrigin Shieldを使用しました。Originに最も近いRECをOrigin Shieldとして設定することができます。 その仕組みはこのようになっています：複数のRECがOriginに接続されているOrigin Shieldを通じてリクエストを集約します。これによってキャッシュのオフロードが向上し、 Originに到達するリクエスト数が削減されます。Originへのリクエストが減少することで、必要な接続数も少なくなります。 また、Origin ShieldとOrigin間で永続的な接続が確立されているため、Keep-alive接続がすでに存在しています。 そのため、新たな接続を作成し続ける必要がなく、スループットの向上にも貢献します。
同じシナリオで、100万人の視聴者が2時間のゲームを4秒のセグメント長でストリーミングし、合計10億リクエストが発生する場合、Origin Shieldを使用することで、キャッシュオフロードが5%改善されることがわかりました。結果は次の通りです： オンデマンドコンテンツで99%のキャッシュオフロード、ライブコンテンツで95%のキャッシュオフロードを達成しました。自社のWebサイトを運営している場合や、独自のEコマース、ストリーミングプラットフォームを運営している場合は、Originを保護するためにOrigin Shieldの使用を強くお勧めします。
次に、Sagarはエッジでのパフォーマンス最適化に焦点を当てて発表を続けました。ここまで、エッジでのパフォーマンス最適化に焦点を当ててきました。 SeanがCloudFrontからOriginまでの最適化について説明した後も、Olympicsのような大規模トラフィックイベント時におけるエンドユーザーとCloudFront間のラストマイルレイテンシーの課題が残っています。帯域幅の小さい都市では、視聴者体験に影響を与える輻輳が発生することが観察されています。この問題に対処するため、先ほど大規模なキャッシュ可能なトラフィック向けにEmbedded POPを構築し、エンドユーザーのISP内に直接配置を開始したことについてお話ししました。
これによりCloudFront CDNを視聴者により近づけ、ISPから直接コンテンツを配信することで、より高速な体験を実現します。今年のUEFA Cup開催に先立ち、私たちはチームと緊密に協力してEmbedded POPをアプリケーションに組み込み、視聴者のリバッファリング率を低減することができました。 現在Embedded POPを使用している全顧客ベースにおいて、CloudFront POPから直接提供されるリクエストと比較して、First Byteレイテンシーが最大20%改善されていることが確認されています。Embedded POPはオプトイン機能であり、最も素晴らしい点は、アプリケーションへの統合に追加コストがかからないことです。アカウントチームに連絡して、Embedded POPがお客様のワークロードに適しているかどうかを確認してください。
アプリケーションにEmbedded POPを統合する方法は2つあります。 1つ目は、アプリケーションの変更を必要としないHTTPリダイレクトを使用する方法です。バックエンドで変更を行い、リクエストがCloudFrontのエッジPOPに到達すると、異なるホスト名でリダイレクトを発行します。ブラウザはリダイレクトをシームレスに処理しますが、視聴者がストリーミングデバイスやゲーム機を使用している場合は、リダイレクトをサポートしているか確認する必要があります。リダイレクトが発生すると、新しいホスト名でCloudFrontに新しいリクエストが送信され、ISP内にEmbedded POPが利用可能な場合、エンドユーザーはそこに接続します。これにより追加のTLSセッションが発生しますが、現在のほとんどのデバイスやブラウザは接続を再利用するため、私たちの経験では、このオーバーヘッドは最小限です。多くのゲーミング顧客はこのアプローチを好んでいます。なぜなら、初期のリダイレクトが迅速で、長時間のゲームダウンロードにおいて、1回のリダイレクトの影響は総ダウンロード時間に対して無視できるためです。
もう1つのオプションは、CloudFront Client Routing SDKをエンドユーザーに認証済みURLを提供するURL発行システムに直接統合することです。その仕組みについて説明しましょう。クライアントがURL発行システムにマニフェストをリクエストすると、システムはコンテンツのストリーミング用のセキュアなリンクを生成します。私たちのSDKは発行サービスに直接統合されています。クライアントがマニフェストをリクエストすると、CloudFrontからストリーミングを開始できます。このアプローチには2つの利点があります。まず、SDKを使用することで、クライアントのサブネット情報をCloudFront DNSに渡すことができ、クライアントのIPがEDNS0をサポートしていない場合でも、より効率的できめ細かいルーティングが可能になります。次に、リクエスト全体が同じホスト名上で完結するため、追加のTLSセッション確立のオーバーヘッドを回避できます。ライブストリーミングのお客様は、わずかな時間でも節約できるこのアプローチを好んで採用しています。
Embedded POPsはルーティングの最適化とレイテンシーの削減における重要な要素ですが、ライブストリーミングで発生する課題の一部にしか対応していません。ライブストリーミングは単にコンテンツをユーザーにより速く届けることだけではなく、もっと多くの要素が関係しています。例えば、最適なルーティングと地域的なパフォーマンス改善を実現しても、ネットワークの変動という課題は残ります。特にトラフィックの多いイベントでは、スケーラビリティの課題も依然として存在します。ユーザーは帯域幅の変動を経験する可能性があり、さまざまなデバイスや複数のリージョンにわたって高品質なストリーミングを維持することは困難な場合があります。それでは、Seanに彼のチームが構築した素晴らしいものについて説明してもらいましょう。
Media-Quality Aware Resiliencyの導入とセッションまとめ
Seanは次のように紹介しました：「本日、皆様にお伝えしたいエキサイティングなリリースがもう1つあります。それは、Media-Quality Aware Resiliency（MQAR）です。MQARは、スポーツイベントやコンサートなどの重要なライブビデオストリーミングで最高のレジリエンシーを維持したい場合に理想的なソリューションです。以前、Origin Groupsを使用して、ストリームが完全に利用できなくなった場合にCloudFrontがプライマリからバックアップストリームにフェイルオーバーできることについてお話ししました。しかし、可用性だけが考慮事項ではありません - ビデオストリームの品質も同様に重要です。例えば、ビデオストリームは利用可能であっても、ビデオフレームが欠落したり、音声品質が低下したりするなど、品質が劣化している場合があります。」
従来は、ビデオ品質を監視し、プライマリからバックアップビデオソースへのフェイルオーバーを手動でトリガーするために、「eyes on glass（目視監視）」と呼ばれる人間のオペレーターが必要でした。この切り替えには数秒かかり、その間視聴者は品質の低下を経験することになります。しかし、今回私たちはMedia-Quality Aware Resiliency（MQAR）をリリースしました。これは、AWS Elemental Media ServicesとCloudFrontの統合で、2つの冗長ビデオストリームそれぞれに対して動的に計算される品質スコアを利用します。この動的に生成される品質スコアに基づいて、ほぼ瞬時にリージョン間でOriginを選択することができます。これは基本的に目視監視を自動化し、より迅速なフェイルオーバーを実現します。
アーキテクチャについて説明しましょう。ライブビデオをストリーミングする場合、2つの冗長なAWS Elemental Liveビデオソースを用意します。それぞれが冗長性のために2つの異なるAWSリージョンにある2つのAWS Elemental Media処理パイプラインに接続されます。インジェストからトランスコーディング、パッケージング、配信まで、このビデオ処理パイプラインの各段階で、2つの入力信号の品質と可用性が自動的に比較されます。この品質は、どの入力信号を使用するかを決定するために使用されます。リージョン間の2つのストリームは時間同期されているため、一方から他方へのフェイルオーバーが発生しても、視聴者はビデオストリームの中断を感じることはありません。Amazon CloudFrontは、Origin Shield、Regional Edge Cache、エッジロケーションなど、CloudFrontシステムの各段階で独立して、その時点で最も高い品質スコアを持つストリームに基づいて、2つの冗長ビデオパイプラインのどちらから取得するかを判断します。
このセッションを振り返ってみましょう。 まず、アーキテクチャから始めました。CloudFrontがどのようにして、700以上のPoints of Presenceを活用してエンドユーザーの近くにコンテンツを配置し、あらゆる種類のコンテンツに対して高可用性と低レイテンシーを実現するよう設計されているかを説明しました。コンテンツは、AWSのバックボーンネットワークを通じてOriginからフェッチされ、パブリックインターネットの輻輳を回避し、世界中の主要なISPと接続しています。キャッシング戦略については、Embedded POPsを使用して大容量ファイルをIPネットワーク内のビューワーにさらに近づけることができます。また、Cache PolicyとOrigin Shieldを活用することで、キャッシュを最大限に活用してサイトのパフォーマンスを向上させ、Originへのアクセスを最小限に抑えることができます。
エッジでのコンピューティングについては2つのオプションを紹介しました：CloudFront POPで直接リクエストを操作する軽量なCloudFront Functionsと、堅牢なサーバーレスコンピューティング環境を提供するLambda@Edgeです。Originの保護については、VPC Originsを使用してVPCへの接続をCloudFrontディストリビューションのみに制限し、Origin Access ControlでS3 Originのセキュリティを確保します。最後に、DNSレイテンシーの削減と可用性の向上、CloudFrontエッジサービスに組み込まれた新しいDDoS Detection Engine、そして固定IPアドレスが必要なユースケース向けのAnycast IPサポートなど、継続的なイノベーションについてお話ししました。以上で本日のトークを終わります。モバイルアップでセッションのアンケートにご協力ください。これは、イベントでのセッションを年々改善していくために役立ちます。発表者を代表して御礼申し上げます。 質疑応答は会場の外で承ります。ご清聴ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion