この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
本記事の内容は 2022.9 時点のブログ記事とドキュメント、FAQを参考に書きましたが、最新の情報は Cloudflare のドキュメントをご確認ください。また、本記事では FIFO （ファーストインファーストアウト）キュー方式を前提に記載しました。
サービスの根本
Waiting room が根本的に実現したかったのは、サーバーを守ること
無理だと感じる、その前に
Waiting Room はいつ発動するのか
アクティブユーザーの合計数
アクティブユーザーの合計数：ベストプラクティスではオリジンの同時処理数の75%で、設定できるのは最低限200以上
オリジンサーバーの同時処理接続数が 1000 であれば 750 となります。
しかし！ 「751番目からのユーザーは仮想待機室に送られる」とは限りません。
「いつ待機し始めるの？」裏側の仕組み
オリジンサイトに入れるユーザー数をスロット数と呼びます。
{スロット数: オリジンに入れるユーザー数} = {アクティブユーザーの合計数} - {データセンタを通過したユーザー数}
スロット数が 0 （空きがない）に近づいてくると、データセンターはキューイングを開始します。
実際は、これを 1 つのデータセンターではなく複数のデータセンターで実現しています。
どうやって？それぞれのデータセンターがスロット数を分け合います。
「東京データセンタ A では 375、大阪データセンタ B でも 375、よろしくね」
基本的に、データセンター A や B は分けてもらった分だけを観察しています。
キューイングを始めるタイミングもデータセンタレベルで独立的に任せられています。
もちろん、データセンターで処理したスロット数は裏で集約しています。集約された値が API やダッシュボードに表示されている値です。
では、分け合うといってもその割合はどう決めているか？
スロット数を分担する割合を、過去2分間のトラフィック量を基に流動的に調整しています。
（例）2つのデータセンターがあって、最初は 50:50(%) で割り振りました。過去2分間、片方を通るアクセスが多ければ 40:60(%) に変更されるわけです。これを 2 分毎に繰り返します。
しきい値は固定値でなく変動値
複数のデータセンターにくるトラフィックの量も、キューを開始するタイミングもバラバラで、割り振られるスロット数も2分毎に変化します。
なので、しきい値といっても結局は目安程度のもので、「751回目」のようにはカウントしきれないのです。
アクセスが急増！！
「いつ発動するの？」 「750 **前後**で発動します。」
青グラフはアクセスの増え方が緩やかです。Waiting Room はしきい値 750 よりもたくさんのユーザーをオリジンに受け入れます。
比べて、オレンジグラフはアクセスが急に増えました。Waiting Room は「えらいこっちゃ」ということでしきい値 750 に達していないですが、前もって待機室を発動させます。
どちらも想定内の挙動です。「アクティブユーザーの合計数」はあくまで目安という立ち位置です。
分単位の新規ユーザー数
しきい値に関係する項目がもう一つあります。
75%をアクティブユーザーの合計数にしたけれども、もし、一斉にアクセスされてサーバーが耐えられるか心配な時にお使いください。
サーバーの耐久性、サービスの継続性が大事なケースでは、分単位の新規ユーザー数を活用してみてください。
分単位の新規ユーザー数：設定可能な値は、最低 200 以上、アクティブユーザーの合計数以下
小さいグループに分けてご案内します
アクティブユーザーの合計数 750 と同じ値を設定すると、最初の1分で 100% のユーザーをオリジンに通します。
比べて、分単位の新規ユーザー数を使うと、小さいグループに分けてオリジンに通すことでサーバー側の急激な負荷を減らすことができます。
{分単位の新規ユーザー数} ÷ {アクティブユーザーの合計数} x 100 = { } %
200 ÷ 750 x 100 = 約 26 %（約は省略）
1分毎に 26 %のユーザーを1グループとみなし、順次オリジンに通します。
オリジンに通された後は？
セッション時間
セッションが保たれる時間（分）で、1 分から指定できます。
ユーザーがオリジンに滞在するであろう時間が目安です。
セッション時間は _cfwaitingroom という Cookie の有効期限になります。この Cookie でセッションの有効性を判定しています。
シーケンス図
1.. 判定：ループ（毎20秒）
まず、オリジンにアクセスさせるか OR 待機させるかの判定が入ります。この判定は 20 秒毎に繰り返されます。
通過 →→ オリジンサーバーにアクセスさせる。ユーザーはサイトに到達する。
待機 →→ ユーザーの画面には Waiting Room の待機画面を表示させる。予想待ち時間も表示される。20秒毎に判定結果を反映します。画面は自動リロード。
2.. 通過（オリジン）
オリジンに到達する最初のセッションで、Cookie に有効期限がつきます。
有効期限はセッション時間(分)で指定した値です。
3.. 操作中
HTTP通信があるたび有効期限を更新します。
(例)セッション時間：5 分であれば HTTP 通信があるたびに、5 分間有効な新しい Cookie が払い出されます。
4.. セッションが切れたら 1. に戻ります。（並び直し）
セッションが切れるのは、
- 最後の HTTP 通信から {セッション時間} 分後に再アクセスしようとする
-
最後に発行された Cookie の有効期限を過ぎている
-
タブやブラウザを閉じる
セッションを更新しないこともできる
HTTP 通信毎に更新する前提で図におこしましたが、「HTTP 通信毎に更新しない」こともできます。
その場合は、最初のアクセスから Cookie 有効期限（セッション時間値）が過ぎたら無条件セッションが切れ、最初の判定（1）に戻ります。
まとめ
Cloudflare Waiting Room の裏側を一部ご紹介いたしました。
弊社のこちらのブログもあわせてご参考いただけますと幸いです。
- Cloudflare Waiting Roomの設定項目（アクティブユーザーの合計数、分単位の新規ユーザー、セッション時間）についてまとめてみた
- ワクチン予約サイトを落とさない Cloudflare Waiting Room の設定方法
長文読んでいただきありがとうございました！
4
