Amazon CloudFront が Server Timing ヘッダーを導入

はじめに

Amazon CloudFront は新機能である Server Timing ヘッダーを最近発表しました。これは、リクエストを受け取ったときにコンテンツがキャッシュから提供されていたか、リクエストが CloudFront エッジロケーションにどのようにルーティングされたか、接続と応答プロセスの各段階でどれくらいの時間が経過したかといった、詳細なパフォーマンス情報を提供するものです。

Server Timing ヘッダーは、ビューアーのレスポンスに HTTP ヘッダーの形で追加のメタデータを提供し、クライアント側のアプリケーションコードで検査したり、使用することができます。Server Timing ヘッダーを使用すると、CloudFront パフォーマンスのトラブルシューティング、CloudFront 動作の検査、キャッシュミス、ファーストバイトレイテンシーなどユーザリクエストのトランザクション全体のメトリクスを収集・集計する際に、より詳細な洞察を得ることができます。

このブログでは、Server Timing ヘッダーを有効にする方法と、この機能を使用してユーザー体験を向上させることができる一般的な使用例について詳しく説明します。

Amazon CloudFront Server Timing ヘッダーを有効にする

このセクションでは、AWS マネジメントコンソールを使用して CloudFront ディストリビューションで Server Timing ヘッダーを有効にする方法について説明します。まず、CloudFront > ポリシー > レスポンスヘッダー で新規にカスタムレスポンスヘッダーポリシーを作成するか、既存のものを更新します。レスポンスヘッダーポリシーで、Server Timingヘッダー機能を有効にすることができます。以下の 2 つの図は、機能を有効にする例と、機能が有効になるとポリシーがどのように表示されるかを示しています。

レスポンスヘッダーポリシーを作成したら、CloudFront ビヘイビアに追加する必要があります。

図 1 : Server Timing ヘッダーを有効にするための レスポンスヘッダーポリシーセクション

図 2：Server Timing ヘッダーを有効にした レスポンスヘッダーポリシーの設定

Server Timing ヘッダーを使用すると、CloudFront を経由するリクエストに追加のパフォーマンス情報を提供するメトリクスを含めることができます。これらのヘッダーに含まれる情報は、様々な実装に使用できます。以下は、想定される使用例となります。

• 動的リクエストのリクエスト/レスポンス性能に対するサーバーサイドの影響を理解する
  • 動的リクエストの場合、CloudFront はオリジンとの通信を必要とします。Server Timing ヘッダーは、この通信にかかる時間や、全体のパフォーマンスに対するサーバー通信の影響についての情報を提供します。
  • サーバーサイドの通信メトリクスには、DNS 解決のタイミング、TCP 接続、FBL（First-Byte Latency）などがあります。これらの測定基準は、ワークロードのパフォーマンスを向上させるためのアクションを取るために使用することができます。
  • DNS 解決に時間がかかりすぎる場合は、TTL（Time to Live）を増やして、その後の遅延を減らすことができます。
  • TCP 接続に時間がかかっている場合は、キープアライブタイムアウトを増やして、ラウンドトリップ時間を短縮することができます。
  • FBL が高い場合、オリジンはより速くリクエストに対応するために、追加のリソース割り当てを必要とする場合があります。
• CloudFront のインフラストラクチャの中で、キャッシュされたコンテンツに対するリクエストがどこにルーティングされたかを詳しく知ることができます。
  • この新機能により、エッジロケーション（EDGE）、リージョン別エッジキャッシュ（REC）、Origin Shield など、リクエストが配信された特定のレイヤーを可視化することができます。
  • これらの指標は、Origin Shield を追加することが有用かどうか、RefreshHit を得ているコンテンツをよりよく提供するためにどのようなアクションが可能か、リクエストがどのように提供されているか全体像を把握したい場合に特に有用です。

Server Timing ヘッダーの分析

CloudFront が提供する HTTP リクエストは、エッジロケーション、リージョン別エッジキャッシュ 、Origin Shield 、キャッシュミスの場合はオリジンなど、CloudFront の様々なレイヤーからリクエストされ、上流にトラバースします。その後、レスポンスは同じレイヤーを経由してビューアーに送信されます。CloudFront のレイヤーの詳細については、2019年に開催された AWS New York Summit での講演をご覧ください。

Server Timing ヘッダーは、上流フローから情報や指標を取得し、特定のレスポンスヘッダーで返します。以下の Server Timingヘッダーの例は、レスポンスで返されます。

server-timing: cdn-cache-hit,cdn-pop;desc=”IAD89-C1″,cdn-rid;desc=”qx0z2Nquy2s3jjH3leHZI7k10X9sN9t5ZmIsjNCqvnJ2uOCjZmyFbQ==”,cdn-hit-layer;desc=”EDGE”

この情報から、リクエストは CloudFront キャッシュの第 1 レイヤー（cdn-hit-layer;desc=”EDGE” ）、IAD89-C1 PoP のエッジレイヤーでキャッシュヒット（cdn-cache-hit）したと結論づけることができます。実際、cdn-hit-layer メトリックは3つの値を取ることが可能です。EDGE はリクエストが到着したエッジロケーションを指し、REC はそのエッジロケーションの後ろにあるリージョン別エッジキャッシュを指し、Origin Shield は CloudFront ディストリビューションでそのオプションが有効になっている場合 Origin Shield レイヤーを指します。

ここで、キャッシュミスになり、オリジンに行ったリクエストを考えてみましょう。

server-timing: cdn-upstream-layer;desc=”REC”,cdn-upstream-dns;dur=0,cdn-upstream-connect;dur=195,cdn-upstream-fbl;dur=366,cdn-cache-miss,cdn-pop;desc=”IAD89-C3″,cdn-rid;desc=”bjEUzYyv7e3FyYoK93Tw0MNYhNV2zVTMbjFO8g-Tr5aEW108VkzM-w==”

どの CloudFront レイヤーがオリジンに接続したかを説明する cdn-upstream 接頭辞を持つ新しいメトリクス（cdn-upstream-layer;desc=”REC”）と、リクエストの様々な部分のパフォーマンスがあることに注意してください。

• cdn-upstream-dns;dur=0 CloudFront がオリジンのドメイン名を解決するのに費やした時間（ミリ秒単位）を示す。このメトリックの値がゼロ（0.0）の場合、DNSの結果がキャッシュされたか、または既存の接続が再利用されたことを意味します。
• cdn-upstream-connect;dur=195 オリジンとの TCP 接続および TLS セッションの確立に要した時間（ミリ秒単位）を示します。このメトリックの値がゼロ（0.0）の場合、既存の接続が再利用されたことを意味する場合があります。
• cdn-upstream-fbl;dur=366 オリジン要求が完了してから、オリジン応答で最初のバイトを受信するまでの期間（ミリ秒単位）を示します。FBL は First Byte Latency の頭文字をとったものです。
• サーバーのタイミングメトリクスの完全なリストについては、こちらのドキュメントを参照してください。

まとめ

今回は、CloudFront リソースの可用性とパフォーマンスの診断と維持に役立つ観測機能である Server Timing ヘッダーを紹介しました。Server Timing ヘッダーは、CloudFront が提供するツール群に追加されるもので、標準およびリアルタイムのログ、アラーム、コンソールレポートを使って CloudFront リソースを監視し、潜在的な問題を調査する方法がいくつか用意されています。詳しくは開発者ガイドをご覧ください。

Server Timing ヘッダーは、すべての CloudFront ディストリビューションですぐに使用できます。Server Timing ヘッダーは、CloudFront コンソールまたは AWS SDK から有効にすることができます。Server Timing ヘッダーを使用するための追加料金はありません。

翻訳は Solutions Architect の長谷川 純也が担当しました。原文はこちらです。