re:Invent 2023: CloudFrontの15年間の進化と最新機能 - AWSのCDN戦略
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Evolve your web application delivery with Amazon CloudFront (NET322)
この動画では、AWSのContent Delivery Network ServiceであるCloudFrontの15年間の進化と最新機能が紹介されています。キャッシング戦略の変遷、Dynamic Content Acceleration、Edge functionsの活用事例など、ウェブ配信の最適化に関する深い洞察が得られます。Capital OneのAuto NavigatorサービスでのA/Bテストの実装や、新しいEmbedded POPの開発など、CloudFrontの可能性を広げる具体的な取り組みも紹介されています。インターネットスケールのセキュリティ対策や、独自Webサーバーの構築によるパフォーマンス向上など、最先端のCDN技術を学べる内容です。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
CloudFrontの15年間の進化と成長
プレゼンテーションへようこそ。このトピックに馴染みのない方も、できる限りわかりやすく説明していきますので、ご安心ください。それでは始めましょう。
ご存知かもしれませんが、CloudFrontはAWSのContent Delivery Network Serviceです。パブリックインターネットを通じて配信されるウェブコンテンツの高速化と保護に特化したサービスです。 今月、このサービスは15周年を迎え、私たちにとって大きな節目となりました。このタイムラインを見ていただくとわかるように、最初のローンチ以来、大きく成長してきました。2008年のローンチ時には、世界中にわずか14のEdgeロケーションしかありませんでしたが、時間とともにネットワークにより多くのロケーションと機能を継続的に追加してきました。
現在、世界中に600以上のEdgeロケーションを展開しています。100以上の都市、50カ国以上に展開しています。また、ネットワークアーキテクチャの中間キャッシュとして、13のRegional Edge Cacheも展開しています。EdgeロケーションとAWSリージョンの間は、AWS Global Networkを使って接続しています。これはAWSが管理するプライベートネットワークで、主に世界中のトラフィックをルーティングする際のパフォーマンスと信頼性を向上させるために使用されています。
ご覧の通り、最初のローンチ以来、ネットワークを大幅に拡大してきました。この成長の多くは、CloudFrontで重要なワークロードを実行しているお客様の数が増えていることと深く関係しています。 メディアエンターテインメント、ゲーム、金融サービス、小売りなど、幅広い業界のお客様がいらっしゃいます。これはほんの一部のお客様リストですが、皆さんもこれらのブランドをご存知かもしれません。結局のところ、私たちがサービスを進化させ続け、時間とともにより多くの機能や能力を追加していくのは、すべてのお客様のニーズに応えるためなのです。
キャッシング戦略の進化：静的コンテンツからダイナミックコンテンツへ
今日のセッションでは、多くのお客様がウェブ配信の支援を求めて私たちに相談される際に本当に求めているコア要件のいくつかについて掘り下げていきます。その最初の一つがキャッシングです。キャッシングは、どのCDNにとっても基本中の基本です。キャッシングを行えること、そしてそれを上手く行えることが必須です。そして、グローバルに分散したネットワークでキャッシングを行う理由は、 時間が経っても大きく変わっていません。
しかし、私たちが変化を目にしたのは、ネットワーク上で提供されるコンテンツです。初期の頃、多くの顧客は主に静的なコンテンツを提供していました。というのも、彼らは自社のウェブサイトを使って、顧客に広く情報を共有するだけだったからです。しかし時間とともに、より対話的なウェブ体験、よりダイナミックなコンテンツ、そしてよりパーソナライズされたコンテンツへと進化していきました。私たちにとって、これは私たちも適応しなければならないことを意味しました。アクセスパターン、キャッシュする必要のあるコンテンツの量、そしてキャッシュ自体への期待が変化しているのを目の当たりにしています。
2008年にサービスを開始した時、私たちは14のEdge locationを持っていました。そして、ネットワークに顧客を追加していくにつれて、ネットワークの拡張を続け、より多くのlocationを追加しました。これにより、私たちのリーチを拡大し、キャパシティを増やすことができました。しかし、すぐに気づいたのは、顧客により良いパフォーマンス、特にキャッシングパフォーマンスを提供するためには、それぞれの独立したlocationで利用可能なキャッシュ幅だけに頼ることはできないということでした。
2016年、私たちはRegional Edge cacheを追加しました。Regional Edge cacheは、世界中のAWSリージョンに配置した中間層のキャッシュです。本質的には、非常に大きなキャッシュ幅を持つスーパーPoPです。これにより、Edge PoPでキャッシュミスが発生した場合に、近くのRegional Edge cacheにリクエストをまとめることができます。これを導入したとき、素晴らしい効果がありました。顧客は即座にキャッシュヒット率の向上を目にしました。私たちにとっても、いくつかの利点がありました。顧客のオリジンへの負荷を増やすことなく、より多くのEdge locationを追加することができるようになりました。
2020年、私たちはOrigin Shieldを導入しました。Origin Shieldは、実際にそれらのRegional Edge cacheの1つを3番目のキャッシング層に変える機能として設定できます。Regional Edge cacheでキャッシュミスが発生した場合、そのリクエストはOrigin Shield locationにまとめられます。これは、ビデオライブラリのような非常に大きなコンテンツカタログを持ち、より高いキャッシュヒット率を求める顧客や、センシティブなオリジンを持ち、より多くのオフロードを求める顧客にとって素晴らしい機能です。
現在、私たちが顧客とキャッシング戦略について協力する際、実に多くの異なる点を考慮しています。まず最初に見るのは、コンテンツの人気度と、それがリクエストされた際にキャッシュヒットする可能性にどのように影響するかです。先ほどCloudFrontのアーキテクチャをお見せしましたが、私たちは階層化されたキャッシング戦略に依存して、人気の低いコンテンツがキャッシュで利用可能になる可能性を高めています。顧客と協力する際、私たちは自社のネットワークを超えて考えています。クライアントからオリジンサーバーまでの全体を見て、そのコンテンツをキャッシュしたい場所を探しています。
もう一つ私たちが注目しているのは、コンテンツの可変性、つまりどれくらいの頻度で変更されるか、あるいはどれくらい早く期限切れになるかということです。初期の頃、多くのお客様は単にCSSやJavaScriptなどの静的ファイルを長期間キャッシュするだけでした。彼らは最長1年のTTLを設定していました。しかし、ウェブ体験ははるかに動的になり、数秒単位の非常に短命なコンテンツをキャッシュすることにも大きな価値があることがわかってきました。これを最も効果的に行うには、オブジェクトごとにキャッシュを調整する機能を提供することです。そのため、私たちはHTTP標準の一部であるCache-Controlヘッダーの使用をお勧めしていますが、サービス自体にも設定や制御機能が組み込まれています。
次に注目しているのは、コンテンツの共有可能性です。先ほど述べたように、ウェブ体験は個々のユーザーにとってはるかにパーソナライズされたものになっています。これは、お客様が単一のユーザーまたは少数のユーザーに固有のデータセットを持っていることを意味します。コンテンツはあまり変更されない可能性があるので、キャッシュする意味はあるでしょうが、対象となる視聴者が少ないため、人気が低い可能性があります。そのため、キャッシュスペースの競合が課題となる可能性があります。このような場合、私たちは実際にブラウザなどのクライアントでこのコンテンツをキャッシュすることをお勧めしています。
お客様と協力する際に常に探しているのは、キャッシュを活用してアプリケーションのパフォーマンスと効率性を最大限に高める機会です。HTTP標準には、活用できる機能があり、ワークロードに応じて、期限切れになったがまだキャッシュに存在するコンテンツを提供する柔軟性があります。オリジンに問題がある場合、ネガティブキャッシングを活用してエンドユーザーに一貫した良好な体験を提供することができます。TTLの期限に関して厳密でない場合は、キャッシュを更新している間に少し古いコンテンツを提供することもあります。これらの属性はすべて私たちが注目しているものであり、アプリケーションの戦略を立てる際に考慮すべき要素の組み合わせなのです。
Dynamic Content Acceleration：CloudFrontの革新的な最適化技術
次に話したいのは、Dynamic Content Accelerationについてです。2012年に、私たちはDynamic Content Accelerationを立ち上げました。ネットワークが大きくなり、リーチが広がるにつれて、直接オリジンに行くよりも、私たちのネットワークを介して長距離でコンテンツを提供することに実際に大きな価値があることに気づきました。特に動的コンテンツと言う場合、キャッシュできないコンテンツを指します。 まず最初によく聞かれるのは、これが実際にどのように機能するのかということです。なぜなら、リクエスト・レスポンスのパスに追加のPoint of Presence (POP)を加えているからです。これは妥当な観察です。その答えは、私たちが多くのことを行っているということです。
まず第一に、クライアントとサーバー間のTLS接続を確立する距離を短縮することで、接続を最適化します。TLSやTCPに詳しい方なら、通常いくつかのラウンドトリップが必要であることをご存知でしょう。長距離でこれを行うと、リクエストパケットを送信する前に多くの遅延が発生します。第二に、Edge POPからオリジンサーバーへの永続的な接続を維持します。これにより、単一のクライアントだけでなく、複数のクライアント間で接続を再利用することができます。さらに、これらの接続を常に調整して、より速くスケールアップし、より良いスループットを提供できるようにしています。
他のプロバイダーと私たちを本当に区別する最後の機能は、AWSでオリジンをホストしている場合、AWS Global Networkを使用してオリジンへのトラフィックをルーティングできることです。パブリックインターネット経由でトラフィックをルーティングする場合、その時点でのネットワークの状態に縛られがちです。ルートが変更されたり、パケットロスや混雑が発生したりすることがあります。AWSネットワークでは、ネットワークエンジニアが常にこのネットワークを監視し、AWSの境界を越えるカスタマートラフィックの観察に基づいて容量需要を予測し、それに応じてスケーリングしています。
私たちはこの投資を非常に真剣に受け止めています。2012年には、実際にピアリング接続で100ギガビットイーサネット接続に移行した最初のプロバイダーの1つでした。その10年後の昨年、すでに400ギガビットイーサネット接続への移行を発表しました。ネットワークを監視すると、かなりの利点が見られました。長距離では、ネットワークジッターが最大2倍減少し、ネットワークレイテンシーが30%減少しました。
次に、適切なプロトコルを使用するだけで、あるいは時にはプロトコルの最新バージョンを使用するだけで、アプリケーションのパフォーマンスを向上させる方法について話しましょう。HTTP、TLS、TCPなど、これらのプロトコルは長年存在しており、各イテレーションでより良くなっています。より効率的になったり、よりセキュアになったりしています。すぐにできることの一つは、最新のプロトコルを使用してテストし、アプリケーションに適しているかどうかを確認することです。例えば、CloudFront内だけでも、TLS 1.2からTLS 1.3に移行したとき、最初のバイトのレイテンシーが即座に20%減少しました。そしてセッション再開をオンにすると、改善率は50%にまで跳ね上がりました。
注目に値するのは、プロトコルは公開されており誰でも実装できますが、実装には投資が必要だということです。良い例として、昨年我々はUDP上に構築されたHTTP/3 over QUICプロトコルのサポートを発表しました。 接続の移行機能やシングルラウンドトリップの接続確立などを活用するために、最高のパフォーマンスを実現するために独自の終端レイヤーを構築しました。CloudFrontを使用する利点は、そのような作業をすべて私たちに任せられることです。デプロイ、テスト、チューニングを行い、最適なプロトコルを見つけることができます。
テストは重要です。CDNで何かを設定し、Edge PoPからオリジンサーバーまでの既存のプロトコルを維持する能力は、活用できる利点です。例えば、現在でも単一の接続で複数のリクエストをストリーミングするマルチプレキシング機能を活用するために、HTTP 1.1から2.0への移行を試みているお客様がいます。それをオンにすると、アプリケーションサーバーがそのストリーム上で同時に発生するトラフィックの急増を処理するようにスケールされていないことに気づく可能性があります。そのため、すぐにロールバックしたり、時間をかけてキューイングを構築してから再度オンにしたりすることができます。これらはすべて考慮すべき点です。
双方向通信の需要増加とgRPCサポートの導入
近年、継続的に成長しているもう一つのトレンドは、双方向通信の需要の増加です。WebSocketプロトコルは、私たちが長年サポートしてきたプロトコルで、ブラウザなど多くのクライアントでサポートされているため、ほぼ標準となっています。このプロトコルの使用例には、ライブスコア更新、チャットアプリケーション、インタラクティブなゲーム内体験などがあります。これらは全て、お客様から聞いているこのプロトコルの使用事例です。
しかし、私たちは常にお客様の声に耳を傾けています。先週、実際にgRPCのサポートを発表しました。gRPCは長年存在するプロトコルで、HTTP/2上に構築されており、低遅延ネットワーク接続に適しています。また、バイナリフォーマットプロトコルに基づいています。従来、これはサーバー間通信用に設計されていましたが、一部のお客様との対話を通じて、モバイルデバイスなどのカスタムアプリケーションでは、このプロトコルを活用したいという要望があることがわかりました。私たちは、このサポートを開始したことを誇りに思っており、実際に先週ローンチしたばかりです。
アダプティブウェブデリバリーとEdge functionsの進化
次に、現代のCDNに求められる機能的な能力について話したいと思います。アダプティブウェブデリバリーは、最近ではかなり一般的なトレンドになっています。クライアントは変化し、常に進化しており、その種類も非常に多様です。ネットワーク環境も常に変化しています。モバイルネットワークが増え、ラストマイルの範囲も以前より広がっています。アプリケーション所有者が知りたいのは、クライアント環境が実際にどのようなものかということです。彼らは、これらの環境に対応して、顧客に可能な限り最高のエンドユーザー体験を提供したいと考えています。
CDNにとって、これは彼らをサポートする能力を提供する必要があるということを意味します。お客様と協力する中で、アプリケーションアーキテクチャはもはやオリジンだけでなく、Edgeにも、CDNにも拡張されていることがわかってきました。そのため、私たちは細かな設定機能、Edgeでのコンピューティング機能を提供する必要があり、それらは全て開発者にとって使いやすいものでなければなりません。CDNはもはや管理タスクではなく、それ自体がアプリケーションアーキテクチャの一部となっているのです。
CloudFrontでは、これらの機能の多くがサービスにネイティブに組み込まれています。しかし、高度なユースケースのために、Edge functionsがあります。2017年に、Lambda@Edgeをローンチしました。Lambda@Edgeは、CloudFront設定から、リクエストフローのリクエストパスとレスポンスパスで、世界中に複製されたLambda関数を呼び出す機能です。これは高度なユースケース向けに設計されています。PythonやNode.jsのコードを書くことで、サードパーティのソフトウェアをCloudFront設定に統合したり、ネットワーク呼び出しを行ったりすることができます。
2021年に、CloudFront functionsを追加しました。CloudFront functionsは、JavaScriptを使用した軽量な関数で、高負荷・低レイテンシーのユースケース向けに設計されています。毎秒数百万のリクエストまでスケールアップが可能で、サブミリ秒での実行を目指して設計されています。Edgeで直接リクエストの操作などを行えることは非常に価値があります。これらの関数は、当社のEdge PoPに直接デプロイされます。
KeyValueStoreがもたらす新たな可能性
先週、KeyValueStoreという新機能も発表しました。これは実は、re:Inventに間に合わせるために大急ぎで開発したものです。KeyValueStoreは、その名の通りのデータストアです。Edge locationに直接デプロイされ、CloudFront functionsからKeyValueStoreへの呼び出しを可能にします。KeyValueStoreにより、多くの新しい機能が解禁されました。アプリケーションデータを関数コード自体から切り離すことができるようになったのです。これにより、いくつかの重要なことが可能になりました。例えば、マイクロ秒単位の非常に効率的な時間枠で呼び出しを行えるようになりました。
お客様の観点から見ると、以下のようなユースケースが見られます。設定変更やフィーチャーフラグの更新のたびに関数コードをデプロイする代わりに、Edge PoPに直接APIコールを行うことで、更新内容が世界中に伝播されるようになりました。KeyValueStoreについてもう一つ興味深い点は、その導入に伴い新しいランタイムが導入されたことです。
KeyValueStoreの導入により、新しいランタイムが導入されました。この新しいランタイムでは、より効率的なJavaScriptコードを書くことができます。一般的なJavaScriptモデルを使用した非同期操作を行う機能も開放されました。ここで、お客様がCloudFrontとEdge functionsを使用してウェブ配信を最適化している方法について、いくつかのユースケースを紹介したいと思います。
最初のユースケースは、ネットワーク状況に関するものです。お客様からよく聞かれるのは、「エンドユーザーが不安定なネットワーク接続にある場合、最低限の機能を使えるように、機能を制限したエクスペリエンスを提供したい。しかし、そのような状況を検知し、Edge architectureに組み込む方法が必要だ」というものです。今日の多くのクライアントプロトコルライブラリでは、実際にネットワークパスのコストを判断するための呼び出しを行うことができます。例えば、これはiOSライブラリから抽出した呼び出しです。
サーバーとの接続状態が良くないという応答を受け取った場合、サーバーに機能を制限したエクスペリエンスを提供するよう伝える方法の1つとして、Save-Dataヘッダーを使用することができます。Save-Dataヘッダーを使えば、インデックスリクエストと一緒にそれを送信できます。そして、CloudFront functionでは、簡単なif文を書いて「このURLを、帯域幅を節約するバージョンのサイトを提供するパスに書き換えよう」と指示することができます。
Capital OneのAuto Navigator：CloudFrontを活用したA/Bテストの実例
もう1つの例として、レイテンシーとパフォーマンスを最適化するためにEdge functionsを使用しているお客様がいます。IMDBという顧客は、CORSに関連するユースケースを見つけました。CORSについてご存知かもしれませんが、これは異なるドメイン間でのアセット共有を許可するための標準です。このプロトコルの一部として、あるドメインが別のドメインでホストされているアセットにアクセスできることを確認するために、プリフライトリクエストを送信します。サーバーのパフォーマンスに影響を与える可能性のあるネットワーク呼び出しがある場合、ブラウザはこのプリフライトリクエストを送信する必要があります。
この顧客が気づいたのは、エンドポイントにアクセスする顧客が増えるにつれて、プリフライトリクエストも増加し、彼らのオリジンは1つのAWSリージョンにホストされていたということです。その結果、実際のデータを提供するリクエストを送信する前に、追加のラウンドトリップが発生していました。彼らは実験を行い、キャッシングを試してみて、ある程度の効果を確認しました。リクエストやドメインの多様性は良好で、役立ちました。そして、Edge functionsの実験を始めたところ、 リクエスト時間を200ミリ秒短縮できることがわかりました。
このアーキテクチャを拡張すると、KeyValueStoreについて考えた場合、このようなユースケースで承認したいドメインを動的に変更する必要がある場合、関数コードを更新する代わりに、KeyValueStoreへのAPI呼び出しを行うことができます。最後に紹介したいユースケースは、クライアントへの配慮です。先ほど述べたように、現在ではスマートTVからWebアプリ、AndroidやiOSまで、さまざまなタイプのクライアントがあります。エンドユーザーが使用しているデバイスによって、エクスペリエンスが異なる可能性があります。CloudFrontには、ここに示すような追加のヘッダーを挿入することで、それらを識別してタグ付けするネイティブ機能があります。
非常に高度なユースケースでは、お客様がSEOクローラーなどのために最適化したいと考えることがあります。Webアプリケーションでクライアントサイドレンダリングを行っているお客様もいて、動的レンダリングのためにCloudFrontとCloudFront functionsに依存している場合があります。この例では、CloudFrontがクローラーを検出した場合（後ほどbot検出についてもう少し詳しく説明します）、CloudFrontに統合されているAWS WAFを使用して、どのタイプのbotがエンドポイントにアクセスしているかを具体的に検出できます。そこから、Lambda@Edge関数を呼び出して、そのトラフィックをどこにルーティングするかを決定できます。SEO最適化されたバージョンのウェブサイトにルーティングすることもできるでしょう。
さて、ここでマイクをHarish Kathpaliaに渡したいと思います。彼がCapital Oneのワークロードにおいて、これらの機能をどのように活用しているかを共有してくれます。
Auto Navigatorの課題：サーバーサイドレンダリングとA/Bテストの両立
ありがとう、Tino。先ほどのスライドで、Tinoは CloudFront functionを A/B テストに使用できると説明しましたが、今日はそれについて詳しく話します。しかし、その実装について議論する前に、私たちがそれを導入した製品の概要を簡単に説明させてください。私とKevinは Capital Oneの金融サービス部門に所属しており、自動車購入製品や自動車ディーラー向けの製品を開発しています。Auto Navigatorは、車を購入するお客様が車を検索できる製品の一つです。
このツールは、実際の資金調達オプションを確認する機能も提供しているので、お客様は推測する必要がありません。クレジットスコアに影響を与えることなく、事前審査を受けることができます。興味がある場合は、ディーラーに連絡先情報を共有することもできます。各車両について、APRレートやその他の詳細を含む実際の支払いオプションが表示されます。条件を変更したり、別の車を選んだりすることも可能です。Auto Navigatorを使えば、オファーを生成し、ディーラーに行って試乗し、そのまま車を購入することができます。本当に簡単なんです。
さて、製品チームとビジネスチームは常に、事前審査や車の検索など、このページの複数のバリエーションをテストしたいと考えています。これは、UXデザインの効果や、お客様がこれらの変更にどのように反応しているかを確認するためです。企業として、学びを得て、仮説を検証し、それをお客様の成果に照らして検証することは非常に重要です。私たちは、リアルタイムで主要指標を可視化し、統合が容易で、市場投入までの時間が短縮され、他のチームも簡単に適用できる多変量A/Bテストの技術的ソリューションを探していました。そこで、A/Bテストに関する4つの重要な要件を設定しました。
CloudFront functionsを活用したA/Bテスト戦略
最初の要件は、セットアップが簡単であることでした。テストの計画、セットアップ、実行、結果の分析が簡単かつ迅速に行えるべきです。2番目の要件は、server-side renderingでした。なぜserver-side renderingが必要なのでしょうか？これについては後ほど詳しく説明しますが、server-side renderingはその名の通り、ページがサーバー側でレンダリングされることを意味します。これにより、ユーザーはJavaScriptやCSSファイルの読み込みを待つことなく、コンテンツをより速く表示できます。
server-side renderingが必要な理由は、SEO（検索エンジン最適化）の要件があるからです。ページがサーバー側でレンダリングされると、ネットワーク接続が遅い場合でもユーザーにとって非常に効果的です。ページのコンテンツがページの読み込み前にレンダリングされるため、検索エンジンが簡単にページをクロールしインデックスを作成できます。ソーシャルメディアのクローラーや検索エンジンのボットは通常、JavaScriptでレンダリングされたコンテンツを好みません。ソーシャルメディアでの共有が私たちのマーケティング戦略の重要な部分だったため、server-side renderingがより良い選択肢でした。
4番目の要件は、優れたユーザーエクスペリエンスでした。これには、明確で直感的なナビゲーションが含まれます。どのバリエーションをレンダリングする場合でも、顧客が簡単にナビゲートできるようにする必要があります。多くの顧客がモバイルデバイスを使用しているため、レスポンシブデザインが非常に重要です。また、ユーザーのニーズや期待に沿った魅力的なコンテンツも、私たちにとって非常に重要です。
A/Bテストの成果：パフォーマンス向上とビジネスの成長
このA/Bテストを実装するために、私たちはいくつかのソリューションを検討しました。1つ目は、クライアントがコールを行い、レスポンスの一部としてバリアントバージョンを取得する社内ソリューションでした。2つ目は、contextual banditsです。Contextual banditsと単純なA/Bテストの違いは、contextual banditsが機械学習アルゴリズムを実装し、パフォーマンスの高いバリエーションにトラフィックを振り分けることです。これにより、パフォーマンスの低いバリエーションへのトラフィックが減少します。3つ目のオプションは、サードパーティの既製ツールでした。
これらのソリューションはすべて素晴らしいものでしたが、1つ大きな欠点がありました。それは、すべてがAPIベースだったことです。特定のバリアントバージョンを取得するだけでも、ネットワークの経路のため、多くの時間がかかりました。例えば、Las Vegasにいる場合、US Westにルーティングされます。US Westから、East CoastでホストされているAPIへのコールが行われます。これは、active-passiveで運用しているためです。直接のコールではありません。Vault、ALB、Route 53を考慮すると、レイテンシーがどんどん増加していきます。
APIソリューションのもう一つの問題点は、単にバリアントを取得するだけでなく、コードベース全体を一つにまとめてしまうことです。つまり、どのバリアントバージョンを取得しても、それは大きなパッケージの一部となります。どのバリアントがレンダリングされるかに関わらず、すべてが単一のコードベースにバンドルされてしまうのです。
私たちが求めていたのは、真の比較につながる独立したバリエーションをテストする能力でした。しかし、その詳細については、Kevinに引き継ぎます。彼が実装の詳細について説明します。
ありがとう、Harish。さて、ここからが面白い部分です。ユーザー体験のテストについて、実際に直面していた問題についてもう少し深く掘り下げてみましょう。 Harishが言っていたように、すべてがバンドルされていることの問題点の一つは、サイズがパフォーマンスを低下させることです。すべてのバリアントがバンドルされた大きなパッケージは、ダウンロードに時間がかかり、解釈に時間がかかり、レンダリングにも時間がかかります。その結果、SEOとユーザー体験の両方に悪影響が出ます。Googleは私たちを完全に見放してしまいました。インデックスが全くされず、インターネット上で見つけることができませんでした。最悪の日々でした。ユーザー体験も明らかに印象の悪いものでした。
そこで私たちは何をしたのでしょうか？「よし、サーバーサイドレンダリングを導入しなければ」と考えました。人々が私たちを見つけられるようにする必要がありました。そこで、まずはサーバーサイドレンダリングを実装することにしました。サーバーサイドレンダリングを始めてみると、常にコントロールが勝っていることがわかりました。なぜでしょうか？サーバーサイドレンダリングだけを行い、フロントエンドでの再ハイドレーションが必要な場合、コントロールがコントロールと等しい時はうまくいきます。しかし、コントロールを配信してからバリアントが選択されるたびに、見た目がひどくなってしまいました。ユーザーは一つのページが配信されたと思ったら、突然それが消えて全く新しいページが表示されるので、非常に不安になり、バリアントから離脱してしまうのです。どのバリアントでも離脱率が非常に高くなりました。
コントロールに対するこのような強いバイアスの原因がわかったので、何か対策を講じることにしました。私たちが決めたのは、CloudFront functionsを活用することでした。 AWSが持つ600のノードを利用し、決定論的な関数を書きました。同じ入力が与えられれば、常に同じ出力を生成するのです。この関数をファンクションレベルに置き、必要なものを動的に割り当てられるようにconfigを構築しました。それをS3に保存し、関数とS3の両方をプッシュするための完全なパイプラインを作成する必要がありました。なぜなら、それらは焼き付けられる必要があったからです。
現在のソリューションでは、S3上のファイルと関数自体の間で同期が行われています。同じ設定、同じJSONオブジェクトを設定自体に組み込む必要があります。文字数や実行時間に制限があるため、両端から攻められているような状況です。しかし、これは素晴らしいソリューションでした。リクエストが来ると、パスを修正します。誰かがindexを要求すると、サイコロを振ってそのアルゴリズムを実行します。stickyクッキーがない場合は、その場で生成してリクエストに付加します。クライアントに戻って設定されるので、次回アクセス時には文字通り同じバリアントに固定されます。これは決定論的なプロセスだからです。
そのアルゴリズムをそのままクライアント側に組み込みました。クライアントがレンダリングする際、クッキーを確認し、すべてが同じになります。これは素晴らしいソリューションでした。あまりにも良かったので、プロダクトチームに提供したところ、彼らは大喜びしました。彼らは何百ものテストを実行しました。様々なタイプのホームページや、Harishが話していたプリクエルなどのすべてを試しました。彼らは地理的位置情報に基づいた機能も望みました。例えば、ラスベガスだけが特定のバリアントを取得するようにすることもできました。
これがCloudFront functionの素晴らしいところです。単なるA/Bテストだけでなく、多くのことにアクセスでき、非常に洗練されたテストを行うことができる可能性が開かれています。
これが私たちのフルページテストです。先ほど言及したように、左側がコントロールで、常に勝っていました。そのため、私たちはいつも「リッチな体験は、シンプルな体験を常に上回るだろう」と考えていました。しかし、最終的に分離して実際のスピードを両者に適用してみると、スピードが常に勝利することがわかりました。バリアントはコントロールを圧倒的に打ち負かしました。まったく競争にならないほどでした。その結果、クリックスルー率が向上しました。コンバージョンも上がりました。プロダクトチームは非常に喜びました。レスポンスが速くなり、ユーザーは私たちのコンテンツにより積極的に関与するようになりました。
そして、その結果はどうだったでしょうか？すべてを小さくし、これらすべての要素を分解することで、パフォーマンスを向上させました。 パッケージを小さくし、シンプルなレンダリングを行うなど、すべてのことを行った結果、パフォーマンスは3倍に向上しました。そして、それが実現し、Googleなどによるインデックス作成が可能になると、オーガニックトラフィックは4倍に増加しました。そして最大の成果は、サイト滞在時間でした。サイト滞在時間は600%増加しました。ユーザーは以前の6倍長く私たちのサイトに滞在するようになりました。そのように長時間滞在すると、ユーザーは積極的に関与するようになります。積極的に関与すると、事前審査を受けたり、車を見たり、私たちが提供できるものにより深く関心を持つ可能性が高くなります。
私たちは、何百時間もかけて開発したツールを全て使い始めました。そして実際にビジネスが上向きになりました。多くのリードを生成し始め、今年からは実際にプラットフォームを収益化できるようになりました。そうなんです、製品として十分な品質に達し、現在は販売しているのです。これが現在の状況です。
KeyValueStoreがもたらすA/Bテストの新たな可能性
しかし、私は KeyValueStore にとてもワクワクしています。 幸運なことに、私たちは KeyValueStore をプレビューすることができました。おそらく、初めて聞いたときに Alex と Tino に電話をかけて懇願したからでしょう。何ヶ月も彼らにメールを送り、しつこくお願いし続けました。なぜなら、これが私たちの A/B テストの次のレベルだと考えているからです。私たちが知っているのは、function 自体から 5 メガバイトを削除できるということです。もう両端からロウソクを燃やす必要はありません。config ファイルの指数関数的な成長を心配する必要がなくなったので、function 自体にはるかに多くの機能を入れることができます。パラメータを処理し、それを格納する必要がありますが、この分離により、function で何をしたいかについてはるかに柔軟になり、config がどれだけ大きくなるかを心配する必要がなくなります。十分なスペースがあるからです。
もう一つの素晴らしい点は、S3 が不要になったことです。S3 が不要なので、パイプラインも必要ありません。リリースする必要もなく、API コールを行うだけでいいのです。response body の話と同じですね。これで、100% 同期が保証されます。KeyValueStore が更新されると、function と return body は常に同期します。クライアントと function は常に同期します。キャッシュの無効化を心配する必要もなく、ブラウザで呼び出されるものについて心配する必要もありません。そのすべてが解消され、単一の API コールで済むのです。
先ほど話した、ML や AI を含む、すべての魅力的な既製の API 駆動機能について、私たちは応答時間の問題で使用できませんでした。それらのパフォーマンス向上を実現しようとすると、使用に耐えられませんでした。しかし今では、それをバックサイドに置くことができます。API が判断を駆動する代わりに、同じシステムが必要なときに、グローバルにそれらのテーブルを動的に割り当てる API コールを好きなだけ頻繁に行うことができます。1日1回でも1時間に1回でも、何でも構いません。これは私たちにとってゲームチェンジャーだと考えています。また、Edge にいるため、US West とは話していないという事実も活用しています。ベガスを出る必要もないほど、応答が速くなります。
では、それは何を意味するのでしょうか？何が良いのでしょうか？ こんなのはどうでしょう：ノーコードテスト、直接 HTML インジェクションはどうでしょうか？私たちの製品には CTA カードと呼ばれるものがあります。これは call to action のことで、新しいバリエーションや異なる色などをテストするのが大好きです。ご覧のように、赤で囲まれているのがデフォルトのものです。レンダリング時に、config を非常に速く取得でき、config に十分なスペースがあるため、実際に HTML をインラインで挿入できます。レンダリング時に、それを入れ替えることができます。サイコロを振り、どの割り当てを決定すべきかを正確に知り、それらの可能なバリアントのいずれかを HTML で、同じ四角の中にリアルタイムで直接注入できます。コードを変更する必要はなく、MFE（マイクロフロントエンド）を再リリースする必要もありません。それでも、KeyValueStore とAPI コールで更新できる function を使ってオフラインで行うので、あらゆる種類のクールな実験を実行できるのです。
もう一つ私たちが注目しているのは、コンポーネントテストです。市場投入までの時間や、クライアントサイドでレンダリングする必要があるMFEの関係で、両方のバリアントを含む単一のパッケージが必要な場合があります。避けられない場合もあり、このようなビジネスルールを持っています。configを非常に速く取得できるため、実際にレンダリングされるバリアントをレンダリング前に決定できます。つまり、一方をレンダリングしてから置き換えるのではなく、コンポーネントが画面に表示される前に判断できるのです。そのため、私たちはKeyValueStoreにとてもワクワクしており、本番環境に導入できるのを心待ちにしています。これにより、実験の可能性が大きく広がると考えているからです。ありがとうございました。では、Tinoに戻したいと思います。
CloudFrontのセキュリティ機能：インフラからアプリケーションまで
KevinとHarish、素晴らしい説明をありがとうございます。これは、CloudFrontとEdge functionsを使って実験を行い、製品のビジネス駆動型の意思決定に本当に必要なデータを収集する方法の素晴らしい例ですね。彼らは文字通りゼロからAuto Navigatorサービスを成長させ、今では収益化できるようになったんですよね？素晴らしいです。
さて、これまでキャッシング、動的コンテンツの提供、アプリケーションロジックのEdgeへの拡張について話してきました。ご覧の通り、トレンドとしてはますますEdgeに移行しています。CloudFrontとCDNは、ほとんどのアプリケーションにとってインターネットへの入り口となっています。そのため、現在ではCloudFrontを通じてHTTPの公開アセットを提供することがベストプラクティスとなっています。つまり、インターネットスケールの脅威について考える必要があるということです。セキュリティは常にAWSの最優先事項であり、サービスを出入りするインターネットデータをより多く見ることができるようになるにつれ、高度な判断を下し、サービスを成長させ続けることができます。現在では、それ自体がセキュリティサービスとなっているのです。
AWSやCloudFront内でセキュリティを考える際、私たちはいくつかの柱に分けて考えています。 まず、インフラストラクチャ層を見ています。DDoS攻撃などから保護するための対策を講じる必要があります。これらの攻撃はリソースを、つまりアプリケーションを停止させてしまいます。時間の経過とともに、実際2012年頃からネットワーク層でのDDoS攻撃が多く見られるようになり、エンジニアたちはShieldのようなサービスとなった機能の開発を始めました。Shieldは私たちのDDoS保護サービスです。
次に注目しているのはアプリケーションセキュリティです。レイヤー7でアプリケーション固有の緩和策を実装するための機能を提供する必要があります。2015年に、AWS WAFをリリースしました。WAFは当初からCloudFrontに統合されています。それ以来、両サービス間の統合を進め、次のスライドで説明する高度な機能を追加し、お客様にとって使いやすいものにしてきました。
セキュアな接続についても考慮する必要があります。暗号化は重要です。すでにお話ししたように、TLSをカバーし、さまざまなプロトコルをサポートしていますが、お客様にとってより使いやすくする必要があります。その良い例が、CloudFrontと統合されているAmazon Certificate Manager (ACM)です。CloudFrontでHTTRSトラフィックを提供したい場合、実際に無料で証明書を提供しています。次に考えるのはセキュアなアクセスです。望ましくないユーザーや権限のないユーザーからリソースを保護するために必要な機能を提供することも重要です。
では、実際にどのように機能するか見てみましょう。お客様がエンドポイントの保護を求めてくる場合、通常、オンプレミス環境やAWSリージョンにオリジンがあります。HTTPの公開エンドポイントの場合、CloudFrontを前面に配置することをお勧めします。そうする理由はいくつかあります。レイヤー3とレイヤー4では、ネットワークに高度な緩和機能が組み込まれています。Edgeロケーションの各ラックの上には、Black Watchというサービスがあります。これは自社開発のサービスで、ボーダーに入ってくるすべてのネットワークパケットを検査し、そのパケットを破棄すべきかどうかを判断します。例えば、HTTPリクエストでない場合、「これは何だろう？排除しよう」といった具合に、さまざまなプロファイルを見ています。
CloudFrontを使用する際のもう一つの利点は、リアクティブな検査から緩和ではなく、インラインでの検査を行っていることです。問題を検出したら、すぐに破棄します。レイヤー7では、先ほど述べたようにAWS WAFと深く統合されています。 WAFは近年大きく進化しました。現在では、ボット検出や、レート制限、カスタムルールの作成など、高度な機能を備えています。SQLインジェクションやクロスサイトスクリプティングなどの一般的な脅威に対抗するためのAWS管理ルールやパートナー管理ルールもあります。サービス内でうまく統合されており、使いやすいように設計されています。
最後に話したいのは、CloudFrontが常にトラフィックを監視しているということです。 インターネットに面したサービスであり、インターネット上で発生するWebアプリケーショントラフィックの大部分を見ています。そうすることで、様々なことを識別できます。常にサービスのサーバー効率を評価し、脅威になる前に脆弱性を特定しています。良い例として、数ヶ月前に発生したHTTP/2リセット攻撃があります。その何ヶ月も前に、効率化の一環として、エンジニアがコードを調査し、ここに脆弱性があるかもしれないと特定しました。そこで、リソースをすべて消費できないように緩和策を講じました。実際に攻撃が起きたとき、何が起こっているのかを正確に把握し、お客様に大きな影響が出る前に緩和することができました。
アプリケーションセキュリティに関して、ある人が私に言ったのは、「セキュリティは簡単でなければならない。そうでなければ使用できない」ということです。お客様と話をする中で、セキュリティを考える際にはいくつかの異なる視点があることがわかりました。多数のアプリケーションを横断的に見るセキュリティチームがあります。彼らは非常に厳格な要件を持ち、セキュリティ設定について深くカスタマイズしたいと考えています。一方で、アプリケーションオーナーもいます。アプリケーションオーナーは、アプリケーションスタック全体を総合的に見ています。彼らにとっては、オンボーディングの速さと統一された体験が重要です。
そのフィードバックを受けて、私たちは現状を見直しました。AWS WAFには、詳細に実装できるカスタマイズ機能がすべて揃っています。そして、CloudFrontコンソール内に、ワンクリックでセキュリティ統合を行える機能を導入しました。これにより、CloudFrontコンソール内で直接WAFの設定をワンクリックで行うことができるようになりました。そこから、CloudFrontの設定を分析し、すぐに有効化できる推奨設定を提案します。これらのルールがユースケースに適しているかを評価するため、モニターモードで開始することもできます。WordPressアプリケーションのようなものを提供している場合は、それを検出してデプロイすることもできます。
さらに、コンソール内に直接セキュリティダッシュボードを導入しました。 このセキュリティダッシュボードには、トラフィックの種類を調査し理解することをより簡単にする機能が追加されています。エンドユーザーがどこから来ているか、トラフィックのうちボットトラフィックが占める割合はどのくらいかなどを確認できます。これらの側面を調べた後、対策を講じることができます。ブロックするか、レート制限を設けるか、あるいはCloudFront内で直接他の機能を適用するかを決定できます。
CloudFrontの未来：Embedded POPとアーキテクチャの刷新
最後に取り上げる要件は、私たちが常に内部で検討しているものです。インターネットは止まることなく、ますます大きくなっていきます。人々はより多くのEdge computeを望むようになり、キャッシュすべきデータも増えていきます。トラフィック量は常に増加しており、私たちはネットワークを拡大し続けるために、Points of Presence (POPs)を追加する以外の創造的な方法を見つけ出さなければなりません。これにより、エンドユーザーにより良い体験を提供できるのです。
ここ数年、私たちは実際に新しいタイプのPOPである「Embedded POP」の開発に取り組んできました。これについては以前のセッションでも少し触れました。Embedded POPは、ビデオストリーミングワークロードや人気のあるソフトウェアダウンロードなど、バイト量の多いキャッシュ可能なコンテンツに特化して設計されています。これらのワークロードの配信における課題は、非常にスパイキーであることです。平均的なトラフィックパターンの12倍までスケールアップすることを確認しています。ネットワークの容量を見ると、実際の制約はCloudFrontネットワーク自体ではなく、ローカルISPプロバイダーとピアリングするインターネットエクスチェンジポイントにあることがわかりました。
トラフィックが非常にスパイキーな性質のため、これらの接続を私たちやプロバイダーがスケールアップすることは、必ずしも経済的に実行可能ではありません。しかし、これは非常に重要です。なぜなら、これらのボトルネックがSuper Bowlのストリーミングや次のビデオゲームのリリースなどの大規模イベントに大きな影響を与える可能性があるからです。Embedded POPはこの問題に対処します。ラックユニット、つまり実質的にはアプライアンスをローカルISPに提供することで機能します。彼らは私たちとパートナーシップを組み、自社のデータセンター内にこれらのデバイスをデプロイします。これらのデバイスはCloudFrontソフトウェアを実行し、私たちがそのソフトウェアを管理します。
これにより、エンドユーザーにより近づき、ISPネットワークの深部にコンテンツを提供し、ISPと相互接続の両方でネットワークの負荷を軽減することができます。また、容量とリーチを拡大し、これは今後数ヶ月で積極的に拡張していく予定です。これらの拠点の価値は、容量要件以外にもあります。ラストマイルを考えると、インターネットエクスチェンジやピアリング接続からエンドユーザーまでの距離に制限があります。インターネットは深く、ネットワークによってはかなり深くまで及びます。
このトラフィックを観察した結果、これらのPOPを展開することで、一部のユースケースでは初回バイトのレイテンシーを最大65%削減できることがわかりました。ネットワークの負荷を最大95%軽減することができます。実際の革新は、キャッシング技術自体やPOPの展開方法ではなく、POPの構築方法にあります。これらはISPに出荷するデバイスで、通常のAWSインフラと同様に物理的なアクセスはありません。そのため、AWSのセキュリティ基準に合わせて構築する必要があります。
これらのボックスはすべて、ホスト認証、マルウェア検出、ファームウェア検証などの優れた機能を直接内蔵して構築されています。不正な改ざんを検知した場合、デバイスを物理的に自己破壊する機能さえあります。最後に、ここ数年取り組んできたことの1つに、CloudFrontアーキテクチャの刷新があります。ここにQRコードがありますが、これをスキャンすると、CloudFrontをネットワークおよびソフトウェアアーキテクチャとしてどのように構築したかについて、詳細に説明した過去の講演を見ることができます。
2008年にCloudFrontを立ち上げた当時、NGINXとSQUIDを最先端技術と考えて使用していました。それは長年にわたってうまく機能してきました。しかし、時間とともに新しいプロトコルが進化するにつれ、それらのプロトコルのサポートをより迅速に提供する必要があることに気づきました。CDNのユースケースにあまり関係のない大規模なコードをレビューすることは、機敏性を重視し、顧客に新機能を提供する上で必ずしも最適ではありません。そこで、ここ数年取り組んできたのが、CDNのユースケースに特化した独自のWebサーバーの構築です。
このWebサーバーは、AWSのエンジニアが管理する新しいランタイム上に構築されており、マルチスレッド化されてスケーリングとEdgeコンピューティングのユースケースに対応できるよう設計されています。将来的には、CloudWatchやS3などのネイティブなAWS機能とうまく統合されることを想定しており、すでにPOPアーキテクチャ全体に展開を開始しています。HTTP/3とQUICの導入に際しては、実際にターミネーションレイヤーから始めました。ここ数ヶ月、そして近い将来にかけて、コネクションプーリングレイヤーにも取り組んでいます。すでに一部のリクエストで最大100ミリ秒のパフォーマンス向上が見られています。
質疑応答への移行
さて、以上でプレゼンテーションは終了です。残り時間は約8分ありますので、質疑応答の時間に移りたいと思います。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion