re:Invent 2024: Booking.comによるCloudFrontを活用したWebワークロード移行と最適化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Migration and modernization with Amazon CloudFront (CDN305)
この動画では、Booking.comのグローバルトラフィック配信担当者が、Amazon CloudFrontを活用したWebワークロードの移行とモダナイゼーションについて解説しています。ハードウェアアプライアンスから独自のMini-POPシステムを経て、CloudFrontへの移行を決断した背景や、その過程で直面した課題が具体的に語られます。特に、CloudFrontをリバースプロキシとして活用することで30%ものロードタイム改善を実現した事例や、Lambda@EdgeとCloudFront Functionsを組み合わせた独自のEdge Functions Frameworkの構築など、大規模Webサービスならではの知見が共有されています。また、移行時の具体的な注意点として、URLの最大長制限やConnection Timeoutの設定など、実践的な学びも提供されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
CloudFrontを活用したWebワークロードの移行とモダナイゼーション：セッション概要
皆様、おはようございます。ようこそお越しくださいました。Re:Inventで素晴らしい一週間をお過ごしのことと思います。本日のセッションにご参加いただき、ありがとうございます。これからAmazon CloudFrontを使用したWebワークロードの移行とモダナイゼーションについて詳しくご説明させていただきます。私はEdge Servicesのワールドワイドテックリーダーを務めるTino Tranです。本日は、このサービスの主要なユーザーであるお客様をお迎えできることを大変嬉しく思います。
「ありがとうございます、Tino。私はAliと申しまして、Booking.comのグローバルトラフィック配信を担当しています。本日は私たちのサービスの移行とモダナイゼーションにおける素晴らしい journey についてお話しさせていただきます。皆様にとって学びとなる内容があれば幸いです。」私たちがAliを今回お招きしたのは、彼らのモダナイゼーションの過程で得られた多くの学びと知見を、多くのお客様に共感していただけると考え、公開して共有したいと思ったからです。また、他のお客様との協業を通じて学んだテクニックについてもお話しさせていただきます。なお、これは300レベルのセッションです。コンテンツデリバリーネットワークやHTTPなどの基本的なWebの仕組みについて、ある程度ご理解いただいていることを前提としています。もし不慣れな方がいらっしゃいましても、できる限りフォローさせていただきますので、セッションのアンケートにご記入いただく際はその点をご考慮ください。
クラウド移行の戦略とCloudFrontの進化
クラウド移行に取り組むお客様と協業する際、最初によく聞かれる質問は「どのようにワークロードを移行すべきか」というものです。モダナイゼーションを先に行うべきか、それともLift and Shiftで移行を優先すべきか。誰もがモダナイゼーションを望んでいます。今日のAIのように、まさにバズワードとなっています。しかし実際のところ、クラウドへの移行自体が、ある程度のモダナイゼーションを伴うものなのです。より現代的なインフラストラクチャーとより多くの機能にアクセスできるようになり、より効果的にサービスを運用し、成長を続けることができるようになります。移行の方法は、その時点での緊急のビジネスニーズによって異なります。データセンターからの退去を検討されているお客様の場合、できるだけ早く移行したいと考えるため、Lift and Shiftが理にかなっています。実際、私たちもそれを推奨しています。ただし、同時に、クラウドマネージドサービスやクラウドネイティブサービスを活用する機会を探ることも推奨しています。これにより、クラウドネイティブサービスを使用することの投資対効果と価値を実感し、それらのサービスの使用と運用の経験を積むことができます。
本日のトークでは、特にCloudFrontをクラウドネイティブサービスとして活用し、ワークロードの移行とモダナイゼーションを実現する方法に焦点を当てます。 CloudFrontは私たちのコンテンツデリバリーネットワークサービスであり、実は最も古いサービスの1つです。長年にわたってサービスを成長させてきましたが、その主な目的は、Webワークロードの高速化とインターネット上の脅威からの保護を支援することです。
先ほど申し上げたように、私たちは長年にわたってネットワークを成長させ、インフラストラクチャーの改善とスケールアウト、そしてインフラストラクチャースタックのモダナイゼーションに継続的に投資してきました。世界中にEdge PoPと呼ばれるエッジロケーションを配置した階層型アーキテクチャを採用しています。これらのEdge PoPは世界の主要都市に配置されています。通常、 必要な容量に応じて、それぞれの地域に1つ以上のPoPが配置され、エンドユーザーにより近い場所でサービスを提供できるよう、トランジットセンターやインターネットエクスチェンジの近くに展開されています。
これらのエッジPoPの背後には、Regional Edge Cacheがあります。Regional Edge Cacheは中間層のキャッシュで、基本的にスーパーPoPと言えます。世界中のAWSリージョン内に直接配置され、より大きな容量を確保しています。これにより、キャッシュの幅を広げ、キャッシュヒット率を向上させ、キャッシュ可能なワークロードに対するOriginの負荷を軽減することができます。Regional Edge Cacheがリージョン内にあることの利点は、クラウド全体の機能とより緊密に連携できることで、サービスを利用する際により多くの機能を提供できることです。世界中のEdge LocationとAWSリージョンの間には、AWSが独自に管理するバックボーンネットワークがあります。これは重要な点で、パブリックインターネット経由のルーティングを回避し、接続を最適化し、トラフィックルーティングの不安定さを多くの部分で解消することができます。
昨年、私たちはEmbedded PoPと呼ばれる新しいタイプのEdge Locationを導入しました。Embedded PoPは世界中のISPネットワーク内に直接配置されており、エンドユーザーにさらに近い場所でサービスを提供できるようになりました。これらのPoPは、特にキャッシュ効率が高くスパイク的なトラフィックに対応するように設計されています。一度に大量のトラフィックが発生するライブビデオ配信ワークロードや、人気のソフトウェアダウンロードなどを想像してみてください。これにより、インターネットエクスチェンジでのスケーリングの課題を克服し、これらのワークロードに対してさらに優れたエンドユーザー体験を提供することができます。このように、私たちはサービスへの投資を続け、サービス内の機能も追加してきました。
Booking.comのインフラストラクチャ進化：Mini-POPからCloudFrontへ
長年にわたり、Booking.comは小さなオランダのスタートアップから、世界最大のeコマース企業の1つへと成長してきました。 私たちは、誰もが世界を体験できるようにすることを目指しています。あなたが誰であっても、どこに行きたいと思っても、それを実現します。そのために、私たちは技術に投資し、旅行におけるあらゆる摩擦を取り除くために懸命に取り組んでいます。いくつかの数字をご紹介しましょう。
2010年以来、 私たちは素晴らしい目的地や宿泊施設で45億人以上のゲスト到着を迎えてきました。ホテルだけではありません - 世界175の異なる場所で、一般住宅、アパートメント、さらにはバンガロー、イグルー、ツリーハウスまで提供しています。 さらに、ライドシェア、レンタカー、タクシー、アトラクション、体験、そして世界中の主要な空港間のフライトまで提供しています。その規模の大きさは想像できると思います - これらすべてを合わせると、数十ペタバイトのデータが私たちのエッジを通過し、さまざまなデータセンターやAWSリージョンに到達しています。
私たちのエコシステムは非常に多様です。結局のところ、私たちには約30年のエンジニアリングイノベーションの歴史があります。1996年以来、優秀なエンジニアたちが、さまざまなタイプのMonolithからMicroservices、コンテナ化されたアプリケーションまで、様々なインフラストラクチャとアーキテクチャを構築してきました。私たちは自社のデータセンターを運営し、プライベートクラウドを持ち、そして多くのワークロードにパブリッククラウドも採用しています。
本日は、私たちのインフラストラクチャの一つの側面、トラフィックエンジニアリングに焦点を当ててお話しします。約10年前、私たちはL7ロードバランサーとして動作するハードウェアアプライアンスを購入していました。これらは素晴らしく機能しましたが、設定は手動で、垂直方向にしかスケールできないため、スケーリングが困難でした。大規模なアクティブバックアップを確保するために、常に2倍の容量を確保する必要がありました。そこで、オープンソースプロキシ、マルチパス、等コストルーティング、ANASTを組み合わせて、独自のロードバランサーを構築することにしました。Distributed Load Balancerと呼ぶプロダクトを開発し、データセンターにデプロイして、すべてのロードバランサーを一元的に設定できるようにしました。
これは長期にわたって非常にうまく機能しました。しかし、Booking.comはグローバルに指数関数的な成長を続け、自社のデータセンターのロードバランサーだけでは不十分になりました。そこで、Mini-POPと呼ばれるものの構築を開始しました。これは最小限の機能を持つPoints of Presenceです。これらを世界中にデプロイし、専用回線でメインデータセンターと接続することで、独自のグローバルなContent Delivery Networkやリバースプロキシとして機能させました。これにより、十分な顧客クラスターがある世界中の地域でのサービス提供が可能になりました。しかし、Booking.comの成長は続き、これらのMini-POPの管理は容易ではありませんでした。データセンタースペースの確保のために世界中の業者と交渉し、接続の信頼性を確保し、冗長性を追加する方法を見つけ出す必要がありました。
運用の負担が増大し始め、投資対効果が急速に低下していきました。そこで、私たちは一歩下がって、実際に必要なものを見直すことにしました。これは、パブリッククラウドの採用が増加していることを観察していた時期と重なりました。私たちには、クラウドオペレーションを加速し、運用の負担から解放してくれるソリューションが必要でした。また、測定可能で容易に検出できるパフォーマンスの改善と、私たちの非常に高いコンプライアンスとセキュリティ基準を満たすものが必要でした。
CloudFrontの採用と可観測性の確立
Aliと彼のチームと協力する中で、Amazon CloudFrontが完璧なソリューションであることにすぐに気づきました。彼らは世界中にアプリケーションをホストするデータセンターを持っており、現在はAWSクラウドにもアプリケーションをデプロイしています。また、ミドルウェアロジックを実行し、これらのオリジンサーバー間でトラフィックをルーティングするためにMini-POPをデプロイしています。CloudFrontは、実はこれらの多くの機能をすぐに使える形で提供しています。キャッシュを使用せずにリバースプロキシとしてCloudFrontを使用でき、パフォーマンス、信頼性、セキュリティの面で多くのメリットをすぐに得ることができます。多くの顧客が気づいていないことですが、それだけでも大きな価値があります。さらに、CloudFrontはオリジンに依存せず、AWSの内外を問わずあらゆるオリジンにトラフィックをルーティングできます。また、Lambda@EdgeとCloudFront Functionsの形でエッジコンピューティング機能を提供し、エンドユーザーの近くでロジックを実行することができます。
これらすべてが彼らのユースケースにとって非常にうまく機能しました。なぜなら、Mini-POPがすでにこれらの多くの機能を実行していたからです。これは私のチームの一部にとって驚きでした。私たちは少なくとも10年間CloudFrontを使用していましたが、静的アセットをキャッシュするContent Delivery Networkとしての使用に慣れていたからです。動的コンテンツに使用するのはユニークでしたが、世界中に700のPOPがあり、すでに構築された機能とその非常に強力なバックボーンを活用することは理にかなっていました。そこで、試してみることにしました。
しかし、本番のワークロードをCloudFrontに移行する前に、クラウドで構築しておくべき基本的な要件があることが分かりました。まず、監視とトラブルシューティングのツールを構築し、次にお客様とCloudFront間、そしてCloudFrontからOriginまでの通信を保護するためのセキュリティとコンプライアンスを確立する必要がありました。その後、パフォーマンスを測定し、データで実証する方法が必要でした。Booking.comでは、データによる裏付けなしに何かを決定することは認められないのです。最後に、ルーティング設定もクラウドに移行する必要がありました。
可観測性から始めると、パブリックインターネット上でWebトラフィックを提供する場合、お客様にはさまざまな形での可視性が必要です。まず、トラフィックを確認し、長期間にわたって分析できる必要があります。ユーザーがどこから来ているのか、どのようなリクエストを受けているのか、どのようなレスポンスを返しているのか、さらには国情報も知りたいものです。これらは標準ログまたはアクセスログを通じて提供され、これらのログは直接Amazon S3に配信されます。数週間前からは、Amazon Data FirehoseやCloudWatch Logsにも配信できるようになり、ログの分析場所の選択肢が増えました。
このデータをリアルタイムで確認する必要もあります。ライブイベントを配信している場合や、移行の文脈で大きな変更やデプロイメントを行う場合、その変更を監視し続けることは理にかなっています。リアルタイムログでは、標準ログと同じログフィールドをすべて提供し、Amazon Data Firehoseを通じて、お好みのログ分析エンジンに配信することができます。重要な点として、リアルタイムログを使用すると、First ByteやLast Byte LatencyなどのOriginレイテンシーメトリクスや、ASN番号の形式でクライアントの接続元に関する情報など、追加のフィールドを取得できます。
どこにデプロイされるにせよ、Function Codeを書く際には、トラブルシューティングができる必要があります。時にはカスタムデータの分析のためにログを使用することもあるでしょう。CloudFront FunctionsのログとLambda@Edgeのログは、CloudWatch Logsを通じて提供されます。ログはそこに配信され、そのサービス内で直接クエリやインサイトを実行できます。非常に重要な点として、CloudFront Functionsは私たちのEdge PoPで実行されますが、Lambda@Edge Functionsは世界中のレプリケート先のリージョンのLambda内で実行されます。FunctionのログはコントロールプレーンのあるUS-EAST-1に配信されますが、Lambda@Edgeのログは実際にFunctionが呼び出されたリージョンに配信されます。
また、メトリクスも重要であることを認識しています。ダッシュボードやアラートを設定できる必要があります。これらは、CloudWatchという監視サービスを通じて様々な方法で提供されており、カスタムダッシュボードやアラームを作成することができます。また、CloudFrontコンソールでは標準のダッシュボードも利用可能です。
セキュリティの確保とCloudFrontの制限への対応
これにより、私たちは独自のObservabilityを構築するために必要なものがすべて揃いました。最初は標準的なログをS3バケットにダンプし、Amazon Athenaを使用してエッジで何が起きているかを確認していましたが、これは私たちにとって非常に遅いものでした。そこで、OpenSearch取り込みサービスを使用してすべての標準ログを取得し、OpenSearchに配置することで、ログのインデックス化が行われ、非常に素早くクエリを実行できるようになりました。大規模なスケールのため、この段階ではアクセスログはあまり気にせず、エラーログのみを配置することにしました。
次にリアルタイムログを検討しました。当初は、リアルタイムログを直接Kinesisにダンプする最新機能がなかったため、独自のLambdaを作成してリアルタイムログをサンプリングし、Kinesis Data Firehoseを通じてOpenSearchにもストリーミングしました。AWSから最近提供されたサービスを使用して、コストを抑えるために非常に小さな割合でリアルタイムログをサンプリングし、これもOpenSearchに配置してSLAとSLOを生成しています。エラー率など、私たちが重視するさまざまなメトリクスを監視しています。Edge Computeについては、単純にCloudWatchを使用しており、これで十分でした。
最後に、Amazon CloudWatch Internet Monitorを使用しました。これはCloudWatchのサービスで、世界中の異なる顧客とのラストマイル通信に関するObservabilityを提供します。これをリアルタイムログで利用可能なデータと組み合わせることで、世界中のクライアントクラスターごとの接続速度を実際に確認することができました。ネットワーキングチームと協力して、世界のある国のユーザーとともにラストマイル通信を最適化しようとした鮮明な記憶があります。最終的に、Observabilityとレジリエンスの基準に準拠するための主要なメトリクスを構築しました。そこで、Detailed Errorを確認しました。これはCloudFrontのメトリクスで、CloudFrontとオリジン間のTCP接続でどのようなエラーが発生しているかを明確に把握できます。
また、Lambda、キャッシュ率、全体的なレイテンシーに関するより多くのメトリクスも収集しました。これにより、CloudFrontを使用するための最初の基盤の柱が完成しました。
通信のセキュリティ確保については、CloudFrontでシンプルなソリューションを見つけました。詳細を確認したい場合は、QRコードをご利用ください。CloudFrontには、AWS Secrets Managerから秘密値を読み取ってヘッダーを注入できるネイティブ機能があります。AWS ecosystemのAPI GatewayやALBなどを使用している場合は、AWS WAFで保護でき、WAFがこの秘密値が正しい値で存在することを確認します。私たちのデータセンターの分散ロードバランサーでは、このソリューションを活用し、Secrets Managerから直接秘密値を取得しています。DLBでは2層のセキュリティを構築しました：まず、CloudFrontのIPアドレスのホワイトリスト化、次に秘密値の存在確認です。これにより、CloudFrontとデータセンター間の通信を保護しました。エンドカスタマーとCloudFront間の通信を保護するために、すべてのSSL証明書をACMに移行しました。これらを使用してCloudFrontディストリビューションにエイリアスを追加し、標準的なWAFの使用に加えて十分なセキュリティを確保しました。
AWSにおいてセキュリティは重要であり、私たちは常にお客様にとってより使いやすいものにするよう努めています。実装が難しければ難しいほど、セキュリティレベルが低下する可能性があるためです。クラウドネイティブなオリジンを使用する場合、Aliが説明したように、CloudFrontとオリジン間の接続を保護するために、IPホワイトリストと組み合わせて共有シークレットヘッダーを使用できます。これはあらゆるタイプのオリジンで機能します。S3やElemental Media Services、Lambda Function URLsなどのクラウドネイティブなオリジンでは、Origin Access Control（OAC）という機能が組み込まれており、どのCloudFrontディストリビューションがそのリソースにアクセスできるかを正確に指定するIAMポリシーを設定できます。リクエストがCloudFrontに到達すると、オープンソースプロトコルであるSigV4プロトコルを使用して認証ヘッダーを挿入します。この利点は、一時的なトークンを使用した署名を管理することで、より安全になり、脅威に対する影響範囲とエントリーポイントを削減できることです。重要な点として、CloudFrontが認証ヘッダーを挿入する際、クライアントが認証ヘッダーを送信している場合、それを上書きします。クライアントが挿入した認証ヘッダーをそのまま維持したい場合もあり、CloudFrontがそれを転送しないように設定できますが、その場合はIAMポリシーを適切に更新して、検証が一致するようにする必要があります。
CloudFrontの内部構造と最適化メカニズム
数週間前、私たちはVPC originsという画期的な機能をリリースしました。クラウドネイティブなオリジンに加えて、EC2にオリジンがある場合、CloudFrontとプライベートサブネット内のそのオリジンの間に安全なトンネルを確立できるようになりました。パブリックインターネットへの公開やインターネットゲートウェイへのルート作成が不要になりました。VPC to VPCネットワーキングを使用して安全なトンネルを確立します。これは攻撃対象領域を削減でき、推奨されているように、CloudFrontをパブリックに公開されているWebアプリケーションの真の玄関口とすることができるという利点があります。また、IPv4コストの削減も可能です。
先ほど、CloudFrontをインラインプロキシとして使用するだけで、セキュリティを含む多くの利点が即座に得られると述べました。これが重要な理由は、CloudFrontを使用すると、パケットが多くの保護機能が組み込まれたエッジロケーションで私たちのネットワークに入るためです。パケットの正確性をチェックし、DDoS脅威を確認し、そのトラフィックをスクラビングします。また、AWS全体のネットワークで分析している脅威インテリジェンスデータに基づいて、Known offenders listを展開することもできます。これらはすべて、リクエストを終了する前に、アプリケーションに近づく前の入り口で行われます。
Aliが言及したように、私たちは認証局であるAmazon Certificate Manager（ACM）と統合されています。CloudFrontを使用する場合、ACMから無料の証明書を取得してそこにデプロイすることも、独自の証明書を持ち込むこともできます。これをお客様が簡単に利用できるようにしたいと考えています。私たちは常にサービスを詳細にモニタリングし、Webトラフィック、接続確立の一般的なパターン、一般的なフローを検査しています。そのため、クライアントが私たちに接続する方法全体の非効率性を探り、問題が発生する前に特定することができます。良い例として、昨年のHTTP/2 rapid reset攻撃があります。この攻撃は1秒あたり1億5500万リクエストのピークに達しましたが、CloudFrontを使用していたお客様は大きな影響を受けませんでした。なぜなら、私たちのエンジニアが数ヶ月前に接続の脆弱性を特定し、攻撃が深刻化する前にガードレールを実装していたからです。
また、レイヤー7の保護を提供するWebアプリケーションファイアウォールであるAWS WAFとも統合されています。ルール、カスタムマネージドルール、サードパーティのルールを設定できます。CloudFrontを通じて、デフォルトのルールセットをワンクリックで展開できる統合を提供しています。これらすべてがエッジで利用可能であり、パブリックに公開されているHTTPトラフィックにCloudFrontを使用することは、AWSのベストプラクティスとなっています。
これまで私たちは、ObservabilityとSecurityという2つの主要な基盤について説明してきましたが、次はCloudFrontをEdgeとして使用する場合と、従来のMini-POPソリューションとの違いを測定する方法が必要です。 これをより深く理解するために、バックエンドへのWebリクエストの一般的な流れを見てみましょう。 通常、DNSクエリから始まり、TCPハンドシェイク、TLS終端と進み、そしてリクエストはEdgeを通ってバックエンドまで到達します。バックエンドは送り返す必要のあるデータの計算に時間をかけます。 ブラウザがバックエンドから最初の部分を受け取った時点が、Time to First Byteと呼ばれるものです。 ブラウザがHTMLデータを十分に受け取り、DOMオブジェクトを構築できる段階に達した時点が、DOM Loaded Timeと呼ばれます。 そして、ブラウザが静的アセット、JavaScript、画像などをすべて読み込んだ時点が、Window Loaded Timeと呼ばれます。
Booking.comでは、強力な実験文化を持っていることを誇りにしています。すべてがデータ駆動である必要があり、社内では非常に包括的な実験システムが稼働しており、Booking.comに触れるほぼすべての場面で1000もの実験が同時に実行されています。時には2つの異なるアーキテクチャ間や2つの異なるバックエンドサービス間でユーザーを振り分けたり、単にボタンの色がお客様にどのような影響を与えるかをテストしたりすることもあります。 この実験システムは、バックエンド処理の非常に早い段階で実行されます。
この実験システムを使用してEdge間の選択を決定することは簡単な作業ではありませんでした。CookieやユーザーIDで決定できるものではないため、データ駆動の判断を行うには創造的なアプローチが必要でした。 データサイエンスチームと協力して、Booking.comの1つのサービスを選び、そのサービスのトラフィックを4時間ごとのウィンドウで、Mini-POPを使用するバリアントAとCloudFrontをEdgeとして使用するバリアントBの間で100%切り替える独自の実験を設計しました。データの一貫性を確保するため、この4時間のウィンドウを毎日1時間ずつずらし、同じユーザーが毎日同じ時間に同じバリアントにヒットしないようにしました。このデータを統計的に有意なものにするため、測定を2週間にわたって継続しました。
驚いたことに、世界のすべての地域で改善が見られました。 特に驚いたのは、私たちが自社のデータセンターを持っている地域でさえ、データセンターに直接アクセスするよりも、CloudFrontを経由してデータセンターにアクセスする方が速かったことです。個人的にも驚きでした。リクエストにもう1つのホップを追加することで、なぜパフォーマンスが向上するのでしょうか？ 全体として、遠隔地域では少なくとも10%、一部の遠隔国では最大30%のロードタイム改善が見られ、これは確実にコンバージョンにつながる数字です。
興味深いのは、動的コンテンツアクセラレーション用のリバースプロキシとしてサービスを導入する際、最初に上がる質問が「これはどのように機能するのか」ということです。リクエスト・レスポンスのパスにこの追加のホップを入れることは、物理的には理にかなっておらず、直感的ではありません。しかし、その仕組みを詳しく見てみると、ユーザーがアプリケーションにアクセスする際、まず接続を確立する必要があります。アプリケーションがホストされている場所からユーザーが遠ければ遠いほど、長距離を移動する必要があるため、レイテンシーのペナルティが発生します。これは光速の制限に関わる問題です。CloudFrontを使用すると、ユーザーは近くのEdgeロケーションでより早く接続を終端できるようになります。
エッジロケーションとサービス間のバックホールでは、永続的な接続を維持しており、これによって数多くの最適化を実現してお客様により良いスループットとパフォーマンスを提供しています。さらに、AWSをご利用で、オリジンがAWS内にある場合は、当社のバックボーンネットワークを利用できるため、パブリックインターネット経由でのトラフィック転送に伴う不安定さを回避することができます。パブリックインターネット経由でトラフィックを転送する場合、その時々のインターネットの混雑状況によって容量や帯域幅が変動します。CloudFrontを使用する場合、私たちがこれを監視し、リージョンとPOPの形態をとるデータセンター間のルーティングを管理して、お客様がいつでも利用できる状態を確保しています。
これらの最適化についてより詳しく見ていきましょう。まず最初に接続が確立されますが、長年にわたってプロトコルはHTTP/2、そして最近ではQUICプロトコルを使用したUDP上のHTTP/3へと進化してきました。この接続を最初に確立する必要がありますが、お客様から伺った課題の一つは、最新の標準規格に追従し、プロトコルに組み込まれたすべての機能を活用することが難しいということでした。そこで私たちがそれを代行します - コンソールで設定して使用することができます。
双方向のユースケースがあることを理解しており、WebSocketプロトコルを通じてプロトコルを簡単に利用できるようにしています。最近では、HTTP/2上でより圧縮された双方向プロトコルであるgRPCのサポートを開始しました。これにより、クライアントからバックホール上のオリジンサーバーまで、gRPC接続を確立することができます。TCPの輻輳ウィンドウの最適化に関して、私たちは多くの対策を講じています。TCPには、ネットワークの過負荷を防ぎ、その接続を使用する際に徐々に測定し、時間とともに輻輳ウィンドウを線形的に拡大していくTCP slow startという組み込み機能があります。
CloudFrontを使用する場合、私たちはいくつかの最適化を実装しています。TCP fast openやSSLセッション再開などの機能を活用し、AWSのオリジンを使用する場合は、より迅速にスケールアップして輻輳制御ウィンドウを拡大することができます。gRPCを除いて、オリジンサーバーとCloudFrontのエッジロケーション間の接続はHTTP/1で行われます。これにより、すべてのTCP最適化を実装し、リクエストを集約できるため、最高のパフォーマンスを提供できることがわかっています。これは私たちがCloudFrontを採用した主な要因でした - 1つのエッジロケーションで1000人のお客様がCloudFrontとの新しい接続を開始し、CloudFrontがそのエッジロケーションから1つの接続を確立してすべてのリクエストを一緒に送信する様子を想像してみてください。TCPとTLS終端にかかる時間を大幅に節約でき、これがコミュニケーションの大幅な改善における重要な要因となりました。
CloudFrontを活用したトラフィック管理とルーティングの最適化
観測可能性とセキュリティを確立し、実験を通じてCloudFrontのメリットを実証した後、CloudFrontの背後に複数のオリジンを設定するという課題に取り組む必要がありました。この問題を理解するために、Mini-POPソリューションを見てみましょう。GeoDNSと重み付けポリシールーティングポリシーを組み合わせて使用し、お客様を最寄りのPOPに誘導し、同じエリアの複数のPOPや複数のデータセンター間でトラフィックをルーティングして均等に分散していました。CloudFrontでは異なるアプローチを取り、体験の一貫性を維持するために、データセンターがある地域でも、すべての場所でCloudFrontを使用することにしました。
現在、GeoDNSに代わってCloudFrontが近接性ルーティングを担当しています。しかし、CloudFrontの背後では、一部のサービスがAWSリージョンとデータセンターの両方で同時に複数のオリジンで稼働しています。私たちは、キャパシティとAWSコストをより適切に管理するため、これらのオリジン間でトラフィックを比較的均等に分散させることを目指しています。CloudFrontには複数のオリジン間でロードバランスを行うネイティブ機能がないため、Lambda@Edgeを含むさまざまなソリューションを検討しましたが、最終的にRoute 53を選択しました。実装は単純で、CloudFrontの背後に、origin.example.comのようなドメインをRoute 53の重み付けルーティングポリシーを使用してセットアップし、均等なトラフィック分散のために全てのオリジンに同じ重みで登録しました。
さらに、Route 53のヘルスチェック機能が簡単に実装できるという利点もありました。1つのオリジンが失われた場合、トラフィックは自動的に他のオリジン間で再分散されます。これは有望に見え、複数のデータセンター間でスムーズなトラフィック分散が継続すると期待していましたが、CloudFront導入後の現実は異なっていました。トラフィックのスパイク的なパターンと不安定な動作が発生し始め、リクエストが上下に変動し、時には最大40%もの差が生じることがありました。これによりキャパシティ管理が困難になり、オリジン間でトラフィックが変動するためAWSリソースの管理も難しくなりました。
ここで実際に何が起きたのかを理解するために、個々の顧客の行動を見てみましょう。通常、個々の顧客は自身のDNS解決リクエストを送信し、Amazon Route 53に到達して、接続すべきオリジンについての応答を受け取ります。Route 53へのクエリは1つの顧客を表すため、データセンター間で顧客が均等に分散されているのが確認できます。
しかし、Amazon CloudFrontを導入すると、顧客は常に最寄りのエッジロケーションにアクセスするようになり、そのエッジロケーションは複数の顧客を同時に処理できます。CloudFrontのエッジロケーションはRoute 53に1つのDNSクエリを送信しますが、それはもはや1人の顧客だけではなく、そのエッジロケーションにいる顧客のクラスター全体を表しています。エッジロケーションはそのDNS解決をキャッシュするため、キャッシュの有効期間中、全ての顧客は1つのエントリーポイントを経由してオリジンにアクセスすることになります。例えば、10個のエッジロケーションがあり、1つに100万人の顧客がいて、他はそれぞれ1,000人の顧客がいる場合、その100万人の顧客は一緒にオリジンA、B、Cの間を移動することになります。
この利点は、同じIPを使用する顧客が増えることで接続の再利用性が向上することです。CloudFront導入後、すぐにリクエストに対する接続の比率が2倍になりました。接続タイムアウトとDNS TTLの設定を微調整した後、接続の再利用性が最大6倍まで向上し、これは重要な成果です。なぜなら、接続の再利用が増えることで、TCPとTLS終端にかかる時間を節約できるからです。
これらの基盤が整ったところで、CloudFrontを使用してすべてのワークロードの移行を開始する時が来ました。私たちは、これまでの準備のおかげで順調に進むと考えていましたが、実際にはそうはいきませんでした。 一般的な変更管理の手法に従って移行を行う場合、小規模から始めて徐々に規模を拡大していく必要があります。Amazon Route 53は、地域やIPアドレス、パーセンテージでユーザーをクラスター化できる様々なルーティングポリシーを提供しており、この目的に最適なツールであることが分かりました。
DNSが関係する移行では、DNSの伝播を迅速に行う必要があるため、変更を最小限に抑える必要があります。 私たちは、CloudFrontの利用を段階的に増やすため、重み付けラウンドロビンポリシーを採用し、最初はトラフィックの1%だけを対象としました。綿密な準備を行い、CloudFrontの基準や制限についても詳しく検討していたにもかかわらず、様々な問題が露呈しました。実際の問題を特定するには、本番トラフィックの一部を流す必要があったのです。
私たちは1%から15%、そして50%へと段階的に増やしていきました。 この過程で、CloudFrontの仕組み、エッジロケーションの動作、そしてグローバルネットワークが私たちのシステムとどのように相互作用するかについて、多くのことを学びました。興味深い発見の一つは、CloudFrontがRFC標準を厳密に遵守していることでした。例えば、RFCではURLの最大長が8キロバイトと規定されているのですが、内部サービスの中には30,000文字を超えるURLを使用しているものがありました。これをきっかけに調査を行い、パラメータが繰り返し追加される再帰的なエラーを発見することができました。
もう一つの課題は、CloudFrontのデフォルトの接続タイムアウトが32秒に設定されていることでした。Long-pollingリクエストが終了するまでに最大5分待機するようなケースがあることが判明し、実装方法を見直す必要が出てきました。
これらの課題に対処するため、実装方法を見直す必要がありました。AWSのソリューションアーキテクトやチームと密接に協力して、サービスの設定方法を変更する必要がありました。CloudFrontはマルチテナントサービスであるため、専用のIPアドレスを持つことができません。 パートナーの中にはIPホワイトリストだけで通信を保護する従来の方法を使用している企業もあったため、より現代的な通信セキュリティの方法を見つけ出すために、パートナーと協力する必要がありました。
Aliが共有したこれらの教訓は、自己管理型のカスタム環境を運用している多くのお客様に共通するものです。最新のWeb仕様に準拠していないカスタマイズであっても、ある程度は許容されることがあります。しかし、CloudFrontのような共有サービスやマルチテナント環境に移行する際には、大規模な様々なワークロードのWebトラフィックをホストしているため、適応すべき教訓が出てきます。CloudFrontがこれらのガードレールを設けているのには理由があります。私たちは、クライアントやお客様がサービスをどのように利用しているかを常にモニタリングしながらHTTP標準を遵守し、すべてのお客様に影響を与える可能性のある誤用を防ぐためにこれらのガードレールを実装しています。
Aliが言及したように、コネクションタイムアウトは一定の時間までしか延長できず、彼らの当初のセットアップでは機能していませんでした。これをより良く理解するために、CloudFront POPsの構築方法を見てみましょう。CloudFrontは高度に抽象化された階層型アーキテクチャで構築されており、各層が異なる責任を持っています。1台のサーバー内で、エッジロケーションには複数の階層があります。複数のサーバーがあり、場所によってはさらに多くのサーバーを持っています。Webリクエストがエッジロケーションに到達すると、ECMPルーティングを実行してトラフィックをサーバーにルーティングし、一貫性のあるハッシュを実装してリソースを最大限に活用し、可能な限り再利用を提供します。DNSを尊重し、IPアドレスに基づいてキャッシュを管理してキャッシュプールを運用しています。
リクエストの到達方法とディストリビューションの設定方法によって、そのフローは変化する可能性があります。キャッシュ可能なコンテンツでない場合、特定のレイヤーをスキップすることもあります。また、クラウドネイティブな機能を呼び出す場合は、Regional Edge Cacheに直接アクセスすることもあります。重要なポイントは、サーバーのフリート全体のどの地点でも接続を確立できるということです。先ほど説明したように、私たちは世界中の50カ国以上、100都市以上に展開しており、各都市に複数のエッジロケーションがあります。これらすべてのサーバーがオリジンへの接続を開くと、オリジンロケーションのリソースを消費し、潜在的にレイテンシーを引き起こす可能性があります。
CloudFrontでは、Keep-Aliveタイムアウトを最大60秒まで設定できます。ただし、Booking.comのようなより高度なユースケースの場合、私たちはお客様と協力します - サポートチケットを開いていただければ、CloudFrontエンジニアリングチームがワークロードを理解し、可能な限り適切に調整します。これらの移行は、お客様だけでなく、私たちにとっても学びの機会となります。Aliが言及した静的IPアドレスのユースケースは、多くのお客様に共通するものです。以前は、エッジロケーション全体でのIPの割り当て方法によってルーティングが決定されるため、これを提供することができませんでした。
リクエストがCloudFrontに到達すると、DNSベースのルーティングを行います。エンドユーザーへのPOPの近接性だけでなく、容量が確保されていることやPOPが正常であることなど、複数のパラメータを考慮します。私たちが常に測定・監視しているこれらの属性すべてを通じて、それに応じて最高のパフォーマンスを提供できます。このプロセスを通じて、エッジロケーションに誘導するIPアドレスを返しますが、これらのIPアドレスは移動する可能性があります。
先月、私たちはAnycast Static IP Addressesという新機能をリリースしました。現在、CloudFrontから独自のStatic IP Addressesを取得し、ゼロレーティングや、プライベートネットワークからの通信を特定のIP範囲に制限したいお客様のユースケースにご活用いただけます。Anycast IP Addressesでは、BGPプロトコルを介してAnycastプロトコルを使用してサーバーにトラフィックをルーティングし、そこからGREトンネルを使用してリクエストを転送すべきかどうかをRoute Tableで判断します。これで、CloudFrontを導入してDynamic Content Accelerationに活用する場合のイメージをご紹介しましたので、次はサービス内の機能について説明し、以前よりもエッジでより多くのことができるようになった点についてお話ししましょう。
エッジコンピューティングの活用：Lambda@EdgeとCloudFront Functions
CloudFrontは、エッジ機能を2つの方法で提供しています。1つ目はLambda@Edgeで、これは通常のLambdaと同様ですが、Lambda@Edge関数をデプロイすると、Regional Edge Cacheを持つ世界中のリージョンに複製され、そこからCloudFrontを通じて関数を呼び出すことができます。
もう1つの機能がCloudFront Functionsです。CloudFront Functionsはエッジロケーションで直接実行され、大量のリクエストを低レイテンシーで処理できるように設計されています。実行時間は1ミリ秒未満です。一方、Lambda@Edgeではより長時間の関数実行が可能で、ネットワーク呼び出しやより複雑なデータ操作、ライブラリの統合などが行えます。数多くのユースケースが可能で、これらは以前よりもエッジでより多くのことを実現しようと創造的に考えているお客様から学んだユースケースです。
多くのお客様が実感している真の価値は、リダイレクトや正規化、CORSなどの共通ロジックを、アプリケーションチームが個別に非統一的にデプロイして更新する必要がなく、SREチームが中心となってアプリケーションロジックを一元化できる点です。クラウドネイティブサービスを通じてエッジロケーションでこれらを提供することで、キャパシティをより効果的に管理する機会を得ることができます。
長年にわたり、お客様はよりモダンなアーキテクチャへと移行してきました。それはマイクロサービスから始まり、現在ではフロントエンドにおいてMicro-Frontendアーキテクチャを採用するお客様が増えています。これにより、チームはWebアプリケーション内の独立したドメインを所有し、独立して提供できるようになり、より高いアジリティを実現できます。Webアプリケーションの移行や変更を行う際は、ゆっくりと始め、小さく始めて、徐々に進めていくことが重要です。
これらのチームが所有するアセットやドメインにわたって、この作業を実行できる必要があります。通常、サブドメインを使用して、各チームが所有する個々のコンポーネントやドメインの所有権を割り当てます。また、URIやURLパスを使用する場合もあります。より高度なケースでは、テストや異なるバリアントのテストを段階的に行えるよう、ヘッダー値を使用して変更を徐々に導入しているお客様も見受けられます。
CloudFront Functionsでこれを実現する方法をご説明しましょう。これらのFunctionsは、リクエストがCloudFrontに到達した時点で、リクエストの多くの属性を確認できます。この例では、URLとユーザーの国を確認しています。CloudFrontを設定することで、リクエスト・レスポンスのパスに、リクエストに関する追加情報を注入することができます。そして、Functionの中で、Key Value Storeと呼ばれる機能を使用して、実行したいアクションを決定できます。この例では、アメリカのお客様向けに設計されたコンテンツを提供するために、URIパスを書き換えることにします。
Functionのコードを見てみましょう。Functionが呼び出されると、すべてがFunction Handlerを通過します。重要なのは、実際のリクエストにどれだけアクセスできるかということです。イベントオブジェクト（基本的にはJSONオブジェクト）が渡されます。このオブジェクトを解析して必要な属性を探し、そこから書き換えを行い、適切に変更を加えるFunctionコードを作成します。
Webアプリケーションに変更を加える際、単純なDNSの切り替えとは異なります。アクティブなセッションを持つユーザーがサービスに接続しており、そのセッションを維持する必要があります。提供しようとしているその接続や体験に完全に紐付けられていることを確認したいのです。これを実現する一つの方法が、CloudFront Functionsの使用です。この場合、設定した重み付けポリシーを参照するFunctionコードを作成します。例えば、トラフィックの10%を新しいOriginに送信したい場合、Key Value Storeを通じてこれを変更・更新できます。これに基づいて、そのセッションにCookieを割り当て、それに応じてトラフィックをルーティングします。レスポンスの際には、Cookieがまだ存在しない場合にそれを設定できます。Functionsを使用したOriginの選択は、re:Inventの直前にリリースされた新機能です。
これが、モダナイゼーションやWebアプリケーションコンポーネントの移行のために変更を加える際のトラフィックの移動方法です。また、より優れた可用性とパフォーマンスを実現するため、よりモダンなアーキテクチャへの移行を望むお客様も増えています。AWSでは、この10年ほどの間、Cell-based Architectureに向かって進んできました。
パフォーマンス、コスト、運用面の考慮に加えて、組織はより良い可用性を求めています。Cell-based architectureは、社内外の多くのお客様が採用しているパターンです。このアーキテクチャでは、異なる場所に個別のソフトウェアスタックを配置することで、より高い冗長性を実現します。この場合、冗長性のためだけでなく、エンドユーザーをシャーディングするために異なるRegionにデプロイし、不適切なデプロイメントによる影響範囲の拡大を防ぎます。変更をロールアウトする際、一箇所にデプロイして問題が発生しても、特定の顧客にのみ影響が及び、ユーザーベース全体には影響しないため、可用性が向上します。
このアーキテクチャで最も課題となるのは、ルーティング層が唯一の非冗長コンポーネントとして残ることです。CloudFrontとFunctions、そして先ほど紹介した機能を活用することで、この課題に対応できます。この例では、問題が発生した際の顧客への影響を最小限に抑えるため、サブスクリプションプランなどのユーザープロファイルに基づいてトラフィックをシャーディングします。複数のドメイン、サブドメイン、さまざまな環境で CloudFrontを採用し、100%のカバレッジを達成した後、私たちはモダナイゼーションの機会を探り始めました。CloudFront上でHTTP/3、IPv6、WebSocket、gRPCなどの機能を簡単に実装できることに、私たちは驚きました。
セキュリティ態勢も大幅に強化されました。セキュリティチームは、インターネットに公開された複数のエンドポイントを管理し、様々なセキュリティ対策を実装する必要がなくなりました。WAF-Bot、WAF-Fraud、そして様々な大規模攻撃から保護してくれるAWS Shield Advancedを使用して、一箇所に集中して対応できるようになりました。しかし最大の利点は、複雑なエコシステム全体で、初めてビジネスロジックを実行する単一の場所を持てたことです。このマルチアプリケーション層アーキテクチャのグラフを見ると、通常、セキュリティやコンテキストの拡充などを実装する共通ロジック層があります。モノリシックアプリケーションではこれらを共通ミドルウェアと呼び、マイクロサービスではリバースプロキシサービスまたは共通ロジックサービスと呼びます。
エコシステムを調査すると、これらのコンポーネントが至る所に散在していることがわかりました。モノリシックアプリケーションとサービスエコシステムの中に、これらのコンポーネントが多数存在していたのです。これらをEdgeに移行することで、ついに個々のサービスオーナーが現在の制約から解放されました。モノリシックアプリケーション内で実行され、共通ミドルウェアに依存している場合、これが変更されるまで移行できません。これらのコンポーネントの一部をEdgeに移行しただけで、社内のモダナイゼーションが加速したのを目の当たりにしました。
Booking.comのEdge Functions Frameworkの構築
Lambda@Edgeの仕組みを見てみましょう。顧客がCloudFrontにリクエストを送信すると、通常はEdgeロケーションを経由してRegional Edge Cacheに到達します - これをViewer Requestと呼びます。リクエストはバックエンドに続き、これをOrigin Requestと呼びます。Originが結果を返すと、それがOrigin Responseとなります。Lambda@Edgeはこれら4つの場所それぞれで実行できます。しかし、Viewer RequestとViewer Responseは、コード容量と計算実行の面で非常に制限がありました。Origin Responseは遅すぎました。というのも、Originに到達する前にコンテキストを拡充する必要があったからです。これにより、実行可能なLambdaオプションはOrigin Requestのみとなりました。社内では、統一認証を全サービスに実装したい認証チームをはじめ、フィンガープリンティング、A/Bテスト、トレーサビリティID、ロケールコンテキストの拡充、ボット対策など、Lambda@Edgeの使用をめぐって各チームが競合していました。これらの課題に対応するため、私たちはTypeScriptを使用して独自のFunction RunnerとFrameworkを構築することにしました。
私たちが Edge Functions Framework と呼ぶこのフレームワークは、TypeScript で書かれており、複数の モジュールやサブモジュールを非同期で実行します。処理が遅くなった場合に実行を中断するシステムを備えており、さらにすべてのリクエストを保護するために、どのモジュールがリクエストを中断できるか、また外部呼び出しを行えるかを制御する権限 システムを実装しています。これは私たちのシステム全体をカバーする上で非常に重要な要素となっています。
私たちは、任意のサブモジュールを簡単にオン・オフできるグローバル設定オブジェクトを構築することにしました。何か問題が 発生した場合、10秒以内にその設定をすべての場所に反映できるようにしています。複数のサブモジュールを実行しながらも、レイテンシーを10ミリ秒以下に 抑えるという目標を維持しています。私たちのモジュールは次のような構成になっています： 各サブモジュールに私たちのフレームワークをインポートし、インターフェースを実装して、独自のハンドル関数を実装する必要があります。
Edge Functions Module Runner とすべてのサブモジュールを1つの Lambda にパッケージングするパイプラインを用意しています。この Lambda を複数の CloudFront ディストリビューション に接続するだけで、エッジで何が起きているかを制御・伝播できるグローバルオブジェクトを実現できます。当初は DynamoDB グローバルテーブルを使用していましたが、これは暫くの間うまく機能していました。しかし、実験を重ねた結果、すべての設定を JSON ファイルに入れて CloudFront にキャッシュヘッダー付きで保存する方が、実際には速くてコスト効率が良いことがわかりました。
すべてのワークロードが CloudFront に適しているわけではありません。私たちには、CloudFront を超えて「エッジ」の定義を拡張する必要があるユースケースがいくつかありました。その一例が Booking.com Affiliates です。これらは 数千のドメインとサブドメインで、単純に私たちのロードバランサーに CNAME で紐付けられています。実際のところ、これらの DNS ゾーン のほとんどは私たちの管理下にはありません。これらは私たちのサービスにトラフィックをリダイレクトする契約を結んでいる外部ベンダーのものです。 その中には証明書さえ持っていないものもあり、それでもグローバルな低 レイテンシーを実現しながら、耐障害性を確保する必要がありました。Booking.com では、夜も安心して眠れるような冗長性を確保するため、すべてのものを複数のリージョンにデプロイするというルールがあります。最後に、WAF と Shield で保護され、同じセキュリティ基準を満たす必要がありました。
解決策はとてもシンプルでした。 キャッチオールリダイレクトを備えた Application Load Balancer を使用し、そのポイントを WAF と Shield で保護し、さらに AWS Global Accelerator を使用しました。これは Anycast サービスで、Application Load Balancer に接続すると、すべてのエッジロケーションでブロードキャストされる静的 IP を提供し、すべての顧客に対してリダイレクトを返すだけのシンプルな仕組みです。
CloudFront活用の総括と今後の展望
まとめますと、本日は私たちの journey についてお話ししました。ハードウェアアプライアンスから始まり、分散型ロードバランサーの構築を経て、エッジとしてCloudFrontを使用するに至るまでの道のりです。セキュリティと可観測性の基盤をどのように構築し、データ駆動型のアプローチで、CloudFrontを使用した実験をどのように行ってきたかを説明しました。CloudFrontの背後でRoute 53を使用して、異なるオリジン間でトラフィックをシフトしバランスを取る方法について説明しました。そして、今夜のトークのハイライトと言えるポイントについて議論しました：CloudFrontとオリジン間の永続的な接続により、リバースプロキシとダイナミックトラフィックの大幅なレイテンシー削減を実現しました。CloudFrontの標準仕様と制限について注意点を共有し、どれだけ事前準備をしたと思っていても、実際に何が起こるかを確認し、そこから学ぶために1%のカナリアデプロイメントが必要だということをお伝えしました。最後に、エッジコンピューティングと、インフラストラクチャの最新化にLambda@Edgeをどのように活用しているかについてお話ししました。
ありがとう、Ali。Aliが共有したポイントに加えて、皆さんに重要なポイントをお伝えしたいと思います。この発表から何かを持ち帰っていただけるとすれば、ここにまとめた内容です。まず第一に、CloudFrontはリバースプロキシとして使用できます。ダイナミックコンテンツのアクセラレーションに非常に適しています。キャッシングを設定する必要すらありませんが、設定すればさらに効果的です。
APIデリバリーサービスに関して、多くの場合、お客様はキャッシングについて考えていません。実際には、たとえ非常に短い時間でもキャッシュすることで、大きな価値が得られることがわかっています。二つ目のポイントは、パフォーマンス、可用性、セキュリティポスチャーの向上です。HTTP公開エンドポイントの前にリバースプロキシをデプロイするのは非常に簡単です。DDoS保護やペリメータ保護などの重要な部分は私たちにお任せください。これらの機能を有効活用してください。実際、パブリックに公開されるエンドポイントにはCloudFrontを使用することがアーキテクチャのベストプラクティスとなっています。
移行やリフトアンドシフトを行う場合、経験を積む必要があります。単純なリフトアンドシフトでは見落としがちな事項も、早い段階からクラウドネイティブサービスの使用を開始し実験することで、適切に計画できる可能性があります。CloudFrontはその良い例です - 私たちが持つ多くの統合機能や、CloudWatchを通じた運用ツール、モニタリング、ロギングなどをご覧いただきました。これらはすべて、クラウドを新規に採用する場合や、いずれ採用する場合に価値があります。Aliが指摘したように、私たちが緊密に協力して計画を立て、すべての要件を確認し、基礎的なテストとPoCを実施したとしても、初期の計画と実行フェーズでは発見できないことがまだあります。そのため、ゆっくりとロールアウトし、テストし、測定して、少なくとも90-95%まで到達していることを確認してください。本番環境に移行する際には、細かな調整が必要になることを念頭に置いておいてください。
最後に、強調したいポイントがあります - 移行は一つのトピックであり、クラウドサービスの使用は別のトピックです。CloudFrontを使用すると、実際にモダナイゼーションが容易になります。今日お話しした一部のルーティング機能について考えると、Webアプリケーションのストラングラーパターンの実装を支援したり、DNSルーティングを超えたより高度な方法でトラフィックをシフトしたりすることができます。
最後に、いくつかのリソースをご紹介させていただきます。こちらが私たちのDeveloper Portalページで、このQRコードからアクセスできます。ここでは、私のSolutions Architectureチームが多くのコンテンツを公開しています。 お客様がこのポータルに魅力を感じていただける理由は、多くのお客様に共通する実践的なユースケースを重点的に取り上げているからです。お時間がございましたら、ぜひこのウェブサイトをご覧ください。以上で本日の発表を終わらせていただきますが、アンケートのご提出をお忘れなくお願いいたします。このような内容のプレゼンテーションが皆様のお役に立ったかどうか、ぜひフィードバックをいただければ、今後のイベント企画の参考にさせていただきます。皆様、ありがとうございました。そして、ぜひ会話を続けさせていただければと思います。LinkedInでご連絡いただくか、このセッション後に廊下でお声がけください。同様の取り組みをされている方がいらっしゃいましたら、ぜひご連絡ください。情報交換させていただき、皆様から学ばせていただければと思います。私たちも、私たちの知見を喜んで共有させていただきます。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion