Waiting Room は、トラフィックが事前に定義したしきい値に近づき、アプリケーションが落ちるおそれがあるときに、訪問者をキューに入れます。
特定のアプリケーションページ向けに Waiting Room を作成して有効化 すると、次のようになります。
-
ページのトラフィックが多くない場合、訪問者はそのページへ直接アクセスします。
-
ページのトラフィックが ユーザー定義のしきい値 に近づくと、訪問者は仮想の Waiting Room に入り、自分の番になるまで待ちます。
- 各ユーザーは Cookie を受け取ります。この Cookie が、Waiting Room からオリジンのウェブサイトへのリクエストの動的な流出を、先入れ先出し（FIFO） の順で管理します。
- Waiting Room にいるあいだ、ユーザーのブラウザは 20 秒ごとに自動更新され、推定待ち時間の最新情報を表示します。
- ユーザーが Waiting Room を出てアプリケーションに到達したあと、セッション期間 で指定した時間は、離脱して再入場しても待つ必要はありません。
- Waiting Room は動的な流入と 流出 に対応しているため、空き枠がより早く現れ、推定待ち時間はより短く、より正確になります。
Waiting Room は、Cloudflare のデータセンターのグローバルネットワーク上で動く Workers のうえに構築されています。
Waiting Room の対象となるホストまたはパスにリクエストが来ると、そのリクエストは最寄りの地理的データセンターにある Waiting Room Worker へ送られます。Worker は、ユーザーをキューへ送るか、ウェブサイトへ送るかを判断します。
その判断は、管理者が定義したしきい値 と Waiting Room の状態の 2 つに依存します。
管理者が定義したしきい値で重要なのは、total active users と new users per minute です。
-
total active usersは、Waiting Room の対象ページで同時に許可したいユーザー数の目標しきい値です。 -
new users per minuteは、ウェブサイトへの 1 分あたりのユーザー流入の最大レートの目標しきい値です。
これらの値のいずれかが急増すると、キューイングが起きることがあります。total active users の計算に影響するもう 1 つの設定が session duration です。ユーザーは、Waiting Room の対象ページへのリクエストから session duration 分のあいだ、アクティブとみなされます。
もう 1 つの要因は Waiting Room の状態です。これはローカルのデータセンター単位で維持されますが、世界中のトラフィックに応じて継続的に変化します。各データセンターは、それぞれ独自の Waiting Room 状態で動作します。この状態は、その時点で把握できる、世界中のウェブサイトのトラフィックパターンのスナップショットです。このアプローチ（Worker レベルで判断する）の利点は、リクエストに大きな遅延を足さずに判断できることです。Waiting Room のアルゴリズムは、Waiting Room の状態に基づいて、各 Worker が使える枠数を動的に割り当てます。Worker 内で枠がなくなると、キューイングが始まります。追加の遅延がないため、顧客は追加遅延を気にせず、Waiting Room を常時オンにできます。
Waiting Room の状態は、数秒ごとにグローバルな情報で更新されます。Cloudflare の Durable Objects にパイプラインを用意し、トラフィックの変化が世界中へ伝播するようにしています。このアーキテクチャにより、追加の遅延を入れず、できるかぎりリアルタイムに近い精度で判断できます。
アーキテクチャの詳細と、こうした判断をした理由については、技術的な深掘りブログ ↗ を参照してください。