WebアプリをホストするためにCloudFrontを設定します

私の前回の記事では、CloudFrontのCSSとJavaScriptのチャンクとバンドルを提供するWebアプリをセットアップする方法について説明しました。アプリがブラウザで実行されると、アプリのルートHTMLファイルから要求されたアセットがCDNとしてCloudFrontから引き出されるように、Viteに統合しました。

CloudfrontのEdgeキャッシュには利点がありますが、これらの複数の場所からアプリのリソースを提供することには、それ自体のコストがありません。前回のブログ投稿の構成とともに実行されている私自身のWebアプリのWebPageTestトレースを見てみましょう。

この投稿では、これを回避する方法を示します。 CloudFrontでWebアプリ全体をホストする方法を説明し、クラウドフロントを前方に（プロキシ」（プロキシ」、データ、AUTHなどのキャッシュ不可能なリクエストを基礎となるWebサーバーにします。

これは、前回の記事で見たものよりもかなり多くの作業であり、Webアプリの正確なニーズに基づいて指示が異なる可能性が高いため、マイレージは異なる場合があります。 DNSレコードを変更し、Webアプリに応じて、特定の資産がキャッシュされないようにするために、いくつかのキャッシュヘッダーを追加する必要がある場合があります。これらすべてに取り組みます！

この記事でここでやっていることのために、前回の記事で説明したセットアップが利点を提供しているかどうか疑問に思うかもしれません。長い接続時間を考えると、CDNを獲得した方がよいでしょうか。代わりに、Webサーバーからすべての資産を提供して、それほど長く避けることを避けるでしょうか？私はこれを自分のWebアプリで測定しましたが、上記のCDNバージョンは実際には高速でしたが、それほど高速ではありませんでした。最初のLCPページの負荷は約200〜300ms高速でした。そして、それは最初の負荷のためだけのものです。この接続がセットアップされると、エッジキャッシングは、その後のすべての非同期にロードされたチャンクに対してはるかに多くの価値を追加するはずです。

DNSのセットアップ

私たちの最終目標は、CloudFrontからWebアプリ全体を提供することです。つまり、ドメインにヒットすると、現在リンクされているWebサーバーではなく、結果がCloudFrontから来ることを望んでいます。つまり、DNS設定を変更する必要があります。これにはAWSルート53を使用します。

私は例としてmydemo.technologyを使用しています。これは私が所有しているドメインです。ここですべての手順をお見せします。しかし、あなたがこれを読むまでに、私は私のWebアプリからこのドメインを削除しました。したがって、後で私が実際のcnameレコードを表示し始めると、それらはもはや存在しません。

ルート53ホームページに移動し、ホストゾーンをクリックします。

[ホストゾーンの作成]をクリックし、アプリのドメインを入力します。

私たちはまだ何も達成していません。私たちはAWSに、このドメインを私たちのために管理することを望んでいることを伝え、AWSは私たちのトラフィックをルーティングする名前のサーバーを私たちに与えてくれました。これを有効にするには、ドメインが登録されている場所に移動する必要があります。独自のカスタム名サーバーに入力する場所があるはずです。

私のドメインはGoDaddyに登録されており、この記事全体のスクリーンショットに反映されていることに注意してください。 UI、設定、およびオプションは、レジストラに表示されるものとは異なる場合があります。

警告：変更を行う前に、元の名前サーバーとすべてのDNSレコードを書き留めることをお勧めします。そうすれば、何かが失敗した場合、あなたが始める前に物事がどのようになったかにロールバックするために必要なものはすべて揃っています。また、すべてが正常に機能していても、他のレコードをルート53、つまりMXレコードなどに再添加したいと思うでしょう。

クラウドフロント配布のセットアップ

Webアプリをホストするために、クラウドフロント配信を作成しましょう。前回の投稿で基本について説明したので、すぐにわかります。前からの大きな変化の1つは、Originドメインに入力するものです。トップレベルのドメイン、例えばyour-app.netを入れないでください。必要なのは、アプリがホストされている基礎となるドメインです。それがHerokuの場合は、URL Herokuが提供します。

次に、安全なHTTPS接続でこのサイトを使用する予定がある場合は、デフォルトのプロトコルを変更してください。

この部分は非常に重要です。 Webアプリが認証、データのホスティング、またはその他のものを実行している場合は、GET以外に他の動詞を有効にしてください。この部分をスキップすると、認証、変異データなどの投稿要求が拒否され、失敗します。あなたのWebアプリが資産を提供するだけでなく、それらすべてが外部サービスによって処理されている場合、未解決の場合！素晴らしいセットアップがあり、この手順をスキップできます。

前回と比較して、キャッシュキーとOriginのリクエスト設定にかなりの変更を加える必要があります。

最小のTTLが0のキャッシュポリシーを作成する必要があるため、送信するキャッシュ非キャッシュヘッダーは適切に尊重されます。また、すべてのクエリ文字列を有効にすることもできます。複数のGraphQLリクエストが異なるクエリ文字列で一緒に出てきたとき、私は奇妙な動作を見ていました。

私の方針はこのように見えました：

Origin Requestポリシーの場合、必要に応じて、認証やデータクエリなどのクエリ文字列とCookieを必ず送信してください。明確にするために、これにより、Cookieとクエリ文字列がCloudFrontからWebサーバー（Herokuなど）に送信されるかどうかが判断されます。

私のものは次のようになります：

最後に、応答ヘッダーポリシーについては、リストから「プリライト付きのCOR」を選択できます。最終的に、最初の2つは、それらをセットアップする方法に応じて異なる名前を持ちます。しかし、私のものは次のようになります：

このクラウドフロント分布にドメインを接続しましょう。残念ながら、これはあなたが期待するよりも多くの仕事です。 Amazonが知っていることはすべて、私たちはそうではないので、実際にドメインを所有していることをAWSに証明する必要があります。ルート53にホストされたゾーンを作成しました。そして、それが私たちに与えた名前サーバーを取り、GoDaddy（またはあなたのドメインが登録されている人）に登録しました。しかし、Amazonはまだこれを知りません。実際、このドメインのDNSを制御することをAmazonに示す必要があります。

まず、SSL証明書を要求します。

次に、証明書のリンクをリクエストしましょう。

次に、公開証明書オプションを要求するオプションを選択します。

ドメインを提供する必要があります。

そして、私の場合、証明書は保留中です。

だから、私はそれをクリックします：

これは、私たちがこのドメインを所有して制御することを証明しています。別のタブで、ルート53に戻り、ホストゾーンを開きます。

次に、CNAMEレコードを作成する必要があります。レコード名の最初の部分をコピーします。たとえば、cnameが_xhyqtrajdkrr.mydemo.technologyの場合、_xhyqtrajdkrrパーツを配置します。記録値については、値全体をコピーします。

AWS名サーバーをドメインホスト、GoDaddy、または誰よりも登録したと仮定すると、AWSはすぐにDNSエントリを作成することができます。

最初に設定した名前サーバーが伝播するのに時間がかかる場合があります。理論的には、最大72時間かかる場合がありますが、通常は1時間以内に更新されます。

あなたはドメインで成功を見るでしょう：

…および証明書と同様に：

なんて！ほぼ完了。次に、これらすべてをクラウドフロント配信に接続しましょう。クラウドフロント設定画面に戻ることができます。現在、カスタムSSL証明書の下で、私たちが作成したもの（および過去に作成した他のもの）を確認する必要があります。

次に、アプリのトップレベルドメインを追加しましょう。

残っているのは、ルート53にこのクラウドフロント配信にドメインをルーティングするように指示することです。それでは、ルート53に戻り、別のDNSレコードを作成しましょう。

IPv4のAレコードとIPv6のAAAAレコードを入力する必要があります。どちらの場合も、トップレベルのドメインのみを登録しているだけなので、レコード名を空にしておきます。

レコードタイプを選択します。次に、レコードをエイリアスとして指定し、エイリアスをクラウドフロントディストリビューションにマッピングします。これにより、クラウドフロントの分布を選択するオプションが開きます。以前にドメインをCloudFrontで登録していたため、選択を行うときにその分布のみが表示されるはずです。

IPv6サポートに必要なAAAAレコードタイプについて、まったく同じ手順を繰り返します。

Webアプリを実行し、実際に機能することを確認してください。それはすべきです！

テストして検証するもの

わかりました、私たちはここで技術的に完成していますが、あなたのWebアプリの正確なニーズを満たすためにまだいくつかのことが残っている可能性があります。さまざまなアプリにはさまざまなニーズがあり、これまでに私が実証したことは、より良いパフォーマンスのためにクラウドフロントを通して物事をルーティングするための共通のステップを私たちに歩き回りました。より多くの愛を必要とするアプリに固有のものがある可能性があります。そのため、セットアップ中に遭遇する可能性のある追加のアイテムをいくつかカバーしてください。

まず、あなたが持っている投稿があなたの起源に正しく送られていることを確認してください。 CloudFrontがあなたの起源にクッキーを転送するように正しく構成されていると仮定すると、これはすでに機能するはずですが、チェックには害はありません。

より大きな懸念は、Webアプリに送信される他のすべてのGETリクエストです。デフォルトでは、CACHEDの場合、CACHEDのGETリクエストがCACHED応答を使用してWebアプリに提供されます。これは悲惨なものになる可能性があります。 GETで送信されたRESTまたはGRAPHQLエンドポイントへのデータ要求は、CDNによってキャッシュされます。また、サービスワーカーを出荷する場合は、通常のバージョンがバックグラウンドで送信され、変更があれば更新される通常の動作の代わりに、それもキャッシュされます。

CloudFrontに特定のものをキャッシュしないように指示するために、「キャッシュコントロール」ヘッダーを「ノーキャッシュ」に設定してください。 Expressのようなフレームワークを使用している場合、このようなものでデータアクセスにミドルウェアを設定できます。

 app.use（ "/graphql"、（req、res、next）=> {
  res.set（ "Cache-Control"、 "No-Cache"）;
  次（）;
}）;
app.use（
  「/graphql」、
  Expressgraphql（{
    スキーマ：executableschema、
    graphiql：本当、
    rootvalue：root
  }）
）;

サービスワーカーのようなものについては、静的ミドルウェアの前にそれらのファイルに特定のルールを置くことができます。

 app.get（ "/service-worker.js"、express.static（__ dirname "/race/dist"、{setheaders：resp => resp.set（ "cache-control"、 "no-cache"）}））;
app.get（ "/sw-index-bundle.js"、express.static（__ dirname "/race/dist"、{setheaders：resp => resp.set（ "cache-control"、 "no-cache"）}））;
app.use（express.static（__ dirname "/race/dist"、{maxage：432000 * 1000 * 10}））;

等々。うまくいかないことがあるので、すべてを徹底的にテストします。また、変更するたびに、Webアプリを再ランニングしてキャッシュから正しく除外されていることをテストする前に、CloudFrontで完全な無効化を実行し、キャッシュをクリアしてください。 CloudFrontのInvalidationsタブからこれを行うことができます。それを開いて、すべてをクリアするために、価値のために /*を入れます。

動作するクラウドフロントの実装

すべてが実行されているので、Webpagetestでトレースを再実行しましょう。

そして、そのように、私たちは私たちが以前に見たように、私たちの資産のために私たちが以前に見たようなセットアップ接続をもはや持っていません。私自身のWebアプリでは、LCPで500msの大幅な改善が見られていました。それは堅実な勝利です！

CDNでWebアプリ全体をホストすることは、すべての世界の最高のものを提供できます。静的リソースのエッジキャッシュを取得しますが、接続コストはありません。残念ながら、この改善は無料ではありません。必要なすべてのプロキシを正しくセットアップすることは完全に直感的ではありません。その後、CDNのキャッシュに巻き込まれないキャッシュ不可能な要求を避けるために、キャッシュヘッダーをセットアップする必要があります。

以上がWebアプリをホストするためにCloudFrontを設定しますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。