リクエスト共有の謎を解く
スタッフ SRE
Fastly では誰もが「キャッシュは最高」と言う言葉が大好きです (理由の1つ目はその通りだから、2つ目は私たち全員が「効率性」の大ファンだからです)！そうです、私たちはキャッシュ効率が大好きです。効率的なキャッシュは、パフォーマンス、セキュリティ、レジリエンス、コスト削減、その他多くのことを大幅に向上させることができます。オリジンサーバーへの連絡が少なければ少ないほど良いのです。そして、それはあなたの Web サイトやアプリを訪れるユーザーにとって非常に重要です。瞬時に、すばやく、効率的であるべきだからです。つまり、サーバーの負荷を管理することが優先事項です。
リクエスト共有とは
効率化に貢献する私たちのプラットフォームの「スーパーパワー」の1つは、リクエスト共有です。これは、同じオブジェクトに対する複数の同時リクエストをオリジンへの1つのリクエストにまとめ、そのレスポンスを使用して保留中のすべてのリクエストを満たす方法です。これが何を達成するのかをよりよく理解するために、キャッシュされたレスポンスの基本を詳しく見てみましょう。
簡単で効率的ですよね？しかし、このプロセスの各ステップには時間がかかるため、さらに詳しく見ていきましょう。
ひとまず順調な滑り出しです。しかし、多くのユーザーが同時に同じものを求めているのに、オリジンからそれを取得できなかった場合はどうなるでしょうか。これは、ライブ動画ストリーミングや新しいゲームのリリース中に頻繁に発生します。そこで発生するのが、リクエスト共有です。Fastly のアーキテクチャとキャッシュプラットフォームにより、フェッチを開始した後に到着したリクエストに対して同じオリジンレスポンスを使用して応答できます。つまり、これらのリクエストはすべて、オリジンからの追加フェッチなしで、可能な限り最新のレスポンスを得ることができるということです。ユーザーは新鮮なコンテンツを入手でき (さらに満足度の高い体験ができ)、オリジンは保護され、何よりも非常に効率的です。
リクエスト共有が発生するタイミング
前の例では、リクエスト共有が Fastly のキャッシュ行動の強力なサブセットであることがわかりました。これは常にデフォルトで有効になっており、それからメリットを得るために特別なことをする必要はありません。とはいえ、それは特定のことを非常に短い時間枠で発生させることを要求する状況的行動であり、すべての顧客のワークフローがメリットを得られるわけではありません。
まず、リクエストはキャッシュインタラクティブである必要があります。つまり、後続のリクエストで使用できるキャッシュオブジェクトを生成します。PASS リクエストと多くのエラーはデフォルトでキャッシュされません。つまり、それらのリクエストを正常に共有することはできません。キャッシュできない場合、レスポンスでリクエストを共有することはできません。
次に、リクエストを共有するには、オリジンからのフェッチを開始したリクエストと同時である必要があります。これは、以前のリクエストを満たすためにすでに取得中のリクエストを受け取ることを意味します。レスポンスが完了すると、通常のキャッシュ行動が引き継がれ、共有は停止します。これは、頻繁に変更され非常に人気のあるキャッシュオブジェクトで最もよく発生するため、多くのユーザーが同時にそれらを欲しがり、オリジンから頻繁に取得する必要がでてきます。
同時実行性は、クラスターやオリジンシールドなどの機能によって向上します。これらの両方は、効率とパフォーマンスを向上させるために、プラットフォーム内でリクエストを集中させます。また、オブジェクトが大きいか、オリジンに過負荷がかかっているために、オリジンの応答に時間がかかると、リクエスト共有の発生率が高くなります。レスポンスを待つ時間が長くなるため、その間にリクエストが共有される可能性が高まるのです。
やや直感に反して、オリジンの高速化と最初の1バイトを受信するまでの時間 (TTFB) を改善する機能により、リクエストを共有する頻度が減ります。前述のように、オリジンからのレスポンスを待っている間のみ、リクエストを共有します。レスポンスの準備が整ったら、共有を停止します。ストリーミングミス機能を有効にすることで、オリジンレスポンスのヘッダーを受信次第、キャッシュオブジェクトの使用を開始できるため、このウィンドウを大幅に短縮できます。
上記は、人気のあるライブビデオサービスの Media Shield ダッシュボードの一部を示しています。リクエスト共有は発生していますが、オリジンが高速で、設定が非常に効率的であるため、受信するリクエスト数に比べてそれほど頻繁には発生しません。
リクエスト共有の指標
リクエスト共有とは何か、またそれが何をするのかがよくわかったので、注目したい指標を調べてみましょう。これらの指標は、それが機能しているかどうか (あるいは機能していないか) を理解するのに役立ちます。また、それがどれほど効果的に運営されているかを把握できます。
現在、リアルタイムおよび履歴の統計で利用可能な以下の2つの指標を導入しました。
request_collapse_usable_countrequest_collapse_unusable_count当社のお客様はこれらの指標を当社の API を通じて見つけることができ、またはカスタムパネルを使用して当社のオブザーバビリティおよび Media Shield ダッシュボード内で表示できます。さらに詳しく説明いたします。
Usable_count: リクエストを共有して使用可能なキャッシュオブジェクトを見つけた頻度をカウントします。オブジェクトを使用可能にするには、オブジェクトがキャッシュ可能であり、キャッシュの有効期間が正である必要があります。キャッシュの有効期間は、オブジェクトの有効期限 (TTL) からその経過時間 (キャッシュ内に存在していた時間) を差し引いたものです。オブジェクトのキャッシュ寿命が正の値でなくなると、期限切れとなり、失効済みデータを配信する以外のキャッシュには無効になります。キャッシュ可能性は beresp.cacheable 変数によっても制御されており、他の場所で文書化されています。
Unusable_count: は上記の反対で - usable_count です。レスポンスが使用不能な場合、オリジンから再度取得する必要があります。一般的にこれは悪いことであり、オリジン、サービスの設定に問題があるか、キャッシュできないワークフローが PASS されていない可能性があります (この2つを足すと、リクエストがどれだけ頻繁に共有されているかが分かります！)
リクエスト共有の指標を理解する
もう少しです！私たちのプラットフォーム内でのトラフィックの動向を確認するためのダッシュボードがあります。そこで何を探すべきかはご存知ですよね。ですが、管理すべき新しい数値もたくさんあります。これらの何が良いのでしょうか？あるいは何が悪いのでしょう？
上記は、多くのユーザーが定期的に新しいコンテンツを求めてポーリングを行う、非常に忙しいオープンソースプロジェクトのリクエスト共有指標を示しています。これにより、リクエスト共有が発生する頻度が増加しています。
何がうまくいっているか、何がうまくいっていないかを理解するためには、まずユーザーのトラフィックパターンに関する基礎知識が必要です。リクエストがあまり変更されない多数の URL に分散している場合、リクエスト共有はほとんど発生しないでしょう。リクエスト共有の大部分は、リクエストが互いに同じ25～150ミリ秒以内に到着した場合に発生することを覚えておくことが重要です。それは非常に短い時間枠です。特定のワークフローは、リクエスト共有からのメリットを享受する可能性が非常に高いです。ニュースサイト、ライブ動画ストリーミング、人気のあるファイルのダウンロードでは、リクエスト共有がはるかに頻繁に発生する可能性があります。それは、どれだけ多くのユーザーが同時に同じオブジェクトをリクエストするかによって決まります。
上記の実際の Web サイトのサンプルでは、同じキャッシュオブジェクトへのトラフィックが突然急増するまで、リクエスト共有はあまり発生しません。
強調しておきたいのは、リクエストの量が多くても少なくても、良いことでも悪いことでもないということです。これは、例外を除いて、増減を気にする必要のない指標です (詳細は後ほど説明します)。何を示しているかというと、私たちがあなたのオリジンから直接ユーザーに同時にサービスを提供している頻度です。経験則として、全体的なリクエスト量と比較してこれらの数がどのくらい多いかを考慮することをお勧めします。小規模なリクエスト共有が発生し、使用不可能な結果になることはまったく普通のことです。これは、多くのバックエンドエラーがキャッシュ可能ではないためです。また、ユーザーの行動によっては、ちょうど良いタイミングでオブジェクトをリクエストすることで、受け取るまでに有効期限が切れてしまうことがあります。これは全く想定内です。
上記のように、使用できないレスポンスの多くは問題があるように見えることがあります。しかし、この Web サイトは毎時1,000万件以上のリクエストを処理しており、私たちが目にしているのは、キャッシュできない正当なエラーレスポンスによる通常のインターネット行動です。
先ほど述べた注意事項に戻りますが、リクエスト量と比較して使用できないカウントが大量にある場合は特に注意が必要です (その現象に気付いた場合は Fastly の担当者に連絡してください)。これはリクエストシリアル化の潜在的な指標です。これについては、今後のブログで詳しく説明しますが、簡単に言うと、リクエストのシリアル化とは、Fastly が複数のリクエストを一度に満たすためにオブジェクトを取得しようとしているが、レスポンスが有効なキャッシュオブジェクトを作成できないことを意味します。このような状況が発生すると、最初のリクエストで使用できないオブジェクトが取得され、次のリクエストで再試行されます。このような状況が続く場合、私たちは一度に一つのリクエストにのみ繰り返し対応することになります。これは非常に非効率的で、実際のユーザーに影響を与える可能性があります。
これらの指標のもう1つの難点は、リクエストが非常に注目を集めるオブジェクトに集中しているのか、わずかに注目されるオブジェクトに多数存在するのかを示すことができないことです。これが重要なのは、使用できないオブジェクトが大量に分散していることが、ワークフローにとってはまったく普通のことかもしれないからです。リクエスト共有は複雑なトピックですが、ここまでお読みいただいたなら、これが効率化プロセスにおいて有益であるよう願っています。このトピックについては、今後のブログでさらに詳しく取り上げる予定です。ご期待ください！