Waiting Room ーしきい値を決めるときに知っておきたい「だいたい、こんな仕組み」

Cloudflare Waiting Room が発動しユーザーを仮想待合室に誘導する条件 "しきい値" を決めるとき、だいたいの仕組みがわかっているとお役に立てるかと思いブログにしました。 #アクティブユーザーの合計数#分単位の新規ユーザー数#セッション時間#仮装待合室#ユーザーの順番付け#サーバーの負荷を軽減させる

本記事の内容は 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 の裏側を一部ご紹介いたしました。

弊社のこちらのブログもあわせてご参考いただけますと幸いです。

長文読んでいただきありがとうございました!