re:Invent 2024: AWSがCloudFront Hosting Toolkit発表 - フロントエンド向け新ツール
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Amazon CloudFront Hosting Toolkit: A new tool for frontend hosting (CDN312)
この動画では、AWSで静的フロントエンドを簡単にホスティングできるオープンソースツール「Amazon CloudFront Hosting Toolkit」について解説しています。AWS Amplify Hostingでは実現できない高度なカスタマイズを可能にしながら、Amazon CloudFrontやAmazon S3のセットアップに関連する複雑な作業を自動化します。AWS CodePipelineとAWS Step Functionsを活用したデプロイメントパイプラインにより、GitHubとの連携やアトミックなインスタントデプロイを実現し、世界700箇所のPoints of Presenceを持つCloudFrontを通じて効率的なコンテンツ配信を行います。CLIを使用した数分での簡単なデプロイや、L3 CDK Constructとしての利用も可能な、実用的なツールの全容を紹介しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon CloudFront Hosting Toolkit: 静的フロントエンドのホスティングを簡素化
みなさん、こんにちは。ランチは楽しんでいただけましたでしょうか。本日のLightning Talkでは、Amazon CloudFront Hosting Toolkitについてお話しさせていただきます。これは、開発者の皆様が、AWSで静的フロントエンドを簡単かつ容易にホスティングできるよう、私たちのチームが作成したオープンソースツールです。その際、基盤となるインフラストラクチャーの完全なコントロールを維持することができます。私はAchraf Soukと申します。AWSのSolutions Architectとして7年間勤めております。
AWSで静的フロントエンドをホスティングする場合、最もシンプルで一般的なアプローチはAWS Amplify Hostingを使用することです。GitHubリポジトリをAmplifyに接続するだけで、このマネージドサービスがすべてを処理してくれます。プロジェクトにコミットや変更を加えると、自動的に変更を検知し、ウェブサイトの新しいバージョンをビルドして公開します。ストレージ使用量、データ転送量、ビルド時間などの要素に基づいて課金され、私も自身のウェブサイトでこれを使用しています。
しかし、Amplify Hostingのようなマネージドサービスでは不可能な、基盤となるインフラストラクチャーをカスタマイズしたいシナリオもあります。例えば、静的フロントエンドとAPIを同じドメイン名で提供するためにコンテンツ配信をカスタマイズしたり、Edge Functionsを使用してウェブサイトをローカライズしたりする場合です。あるいは、ホスティング自体をカスタマイズしたり、S3バケットの暗号化を実装したり、Multi-Region Originを実装したりすることもあるでしょう。また、A/Bテストを実装してデプロイメントパイプラインをカスタマイズしたい場合もあります。
このようなカスタマイズが必要な場合、すべてを一から構築する必要があり、これは簡単な作業ではありません。Amazon CloudFront、Amazon S3、その他多くのAWSコンポーネントについて学び、各コンポーネントのベストプラクティスを適用する方法を理解する必要があります。アトミックで即時的なデプロイなどの機能をどのように実装するかも考えなければなりません。さらに、このインフラストラクチャーをデプロイするためにAWS CDKやCloudFormationについても学ぶ必要があります。これこそが、CloudFront Hosting Toolkitが解決しようとしている具体的な課題なのです。
CloudFrontとS3のセットアップに関連する複雑さについて、詳しく見ていきましょう。まず、North VirginiaでTLS証明書を設定し、次にS3バケットを作成してベストプラクティスを適用する必要があります。CloudFrontのキャッシュポリシーとセキュリティヘッダーを管理するためのポリシーを作成する必要があります。そして、S3へのリクエストが確実にCloudFrontを経由するようにOrigin Access Controlを作成します。CloudFrontディストリビューションを作成した後、CloudFrontがバケットからコンテンツを取得できるようにS3バケットに権限を追加します。さらに、index.htmlの追加方法を把握し、最後にDNSレコードを変更する必要があります。
CloudFront Hosting Toolkitは、これらすべての作業をバックグラウンドで自動的に処理してくれます。CLIを使用してわずか数分で簡単にデプロイできます。GitHubとの連携や、アトミックなインスタントデプロイなどの機能を提供し、すべてのベストプラクティスを適用します。このToolkitを使用することで、アトミックなインスタントデプロイを実現できます。
CloudFront Hosting Toolkitの仕組みと実装詳細
また、Webサイトに独自のCustom Domainを使用することもできます。CLIの使用感について詳しく見ていきましょう。まず、 NPM Packageをインストールする必要があります。ローカルマシンにリポジトリをクローンしたら、そのフォルダに移動してInitコマンドを実行します。Initコマンドにより、Toolkitはプロジェクトを検出し、使用されているフレームワークとGitHubプロジェクトのリンクを識別します。その後、Deployコマンドを実行すると、ホスティングインフラストラクチャやデプロイメントパイプラインなどのインフラストラクチャが実際にデプロイされます。セットアップには数分かかり、その間にGitHubリポジトリへの接続を確認する必要があります。
バックグラウンドでの動作の仕組みとアーキテクチャについてご説明します。デプロイメントパイプラインは、AWS CodePipelineを使用してオーケストレーションされ、AWS CodeBuildでWebサイトのアーティファクトをビルドし、AWS Step Functionsで新バージョンへの変更をオーケストレーションします。新しいバージョンを作成したり、コンテンツに変更を加えたりするたびに、ビルドは Amazon S3 Bucketの新しいフォルダにアップロードされ、CloudFrontに新バージョンを指すようChange URIコマンドが送信されます。ユーザーは即座に新バージョンを見ることができます。これはGitHubの変更によって自動的にトリガーされますが、独自のCI/CDパイプラインを使用してデプロイをカスタマイズしたい場合は、WebサイトのアーティファクトをS3 Bucketにドロップするだけでも、このパイプラインがトリガーされます。
ホスティングインフラストラクチャはとてもシンプルです。各ビルドのアーティファクトを専用のフォルダに格納するAmazon S3 Bucketがあり、それをAmazon CloudFrontを通じて配信します。前述の通り、新しいバージョンができるたびに、専用のフォルダがCloudFrontにアップロードされます。URIを変更したい場合、CloudFrontに関連付けられたKey Value Storeの状態を更新します。このKey Value Storeは、CloudFrontのエッジロケーションに配置されているグローバルに分散されたストアです。これにより、エッジロケーションで実行されるCloudFront Functionが、リクエストとの対話方法をカスタマイズし、使用するWebサイトの最新バージョンを判断して、S3 Bucket上の適切なフォルダにURLを書き換えることができます。
Amazon CloudFrontについて簡単にご説明します。これはAWSのContent Delivery Networkで、HTTPベースのワークロードを持つすべてのお客様に推奨しているサービスです。Well-Architectedなウェブアプリケーションにとって基本的な構成要素であり、より優れた信頼性、パフォーマンス、セキュリティ、そしてAWSからのより良好なエグレスコストを提供します。世界中に約700のPoints of Presenceを持つグローバルに分散されたサービスです。
ユーザーがWebサイトを操作する際のリクエストフローを見てみましょう。ユーザーがAboutページに移動すると、CloudFrontにGETリクエストを送信します。これはEdge Locationで受信され、 Edge LocationでCloudFront Functionが実行され、使用すべき現在のBuild IDをKeyValueStoreから取得します。このBuild IDを取得すると、 Build IDを含むS3のフォルダにURLを書き換えます。初めてアクセスされてキャッシュミスの場合は、S3バケットにアクセスします。このCache IDはキャッシュキーの一部となり、変更を加えた際に CloudFrontのキャッシュではなくS3から新しいコンテンツを取得することを保証します。
ここで、Webサイトに変更を加えた場合を考えてみましょう。新しいバージョンが利用可能になると、パイプラインがトリガーされます。 開発者がコミットをプッシュすると、パイプラインが起動します。
パイプラインでは、 GitHubから新しいコードを取得し、Webサイトの新しいアーティファクトをビルドして、Amazon S3の新しいフォルダにWebサイトをアップロード します。AWS Step Functionsを使用してこのワークフローを開始し、プラットフォームのKeyValueStoreで稼働中のバージョンIDを更新します。
次回ユーザーがWebサイトにアクセスする際も、同じプロセスが実行されます。 Edge Locationでリクエストを受け取り、Functionを実行して最新のBuild IDを取得します。今度は 新しいBuild IDのフォルダを指すようになり、ユーザーはすぐに新しいバージョンを利用できるようになります。
CloudFront Hosting Toolkitについてさらに詳しく知りたい方のために、私が説明した内容をまとめた使用方法のドキュメントを共有させていただきます。CIのユーザーエクスペリエンスについては詳しく説明しませんでしたが、上級開発者の方で、CDKプロジェクトでCloudFront Hosting Toolkitを使用したい場合は、L3 CDK Constructとしても利用可能です。プロジェクトへの貢献に興味がある方は、ぜひメンテナンスや機能追加にご協力ください。私たちには多くのアイデアがあり、ボランティアを歓迎しています。
ご清聴ありがとうございました。CloudFrontやエッジセキュリティに関する同様のトピックについてもっと学びたい方は、私がLinkedInで定期的に教育コンテンツを投稿していますので、ぜひフォローしてください。ここで一旦区切らせていただき、このプロジェクトについて皆様からのご質問をお受けしたいと思います。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion