ローンチ日はゆっくり倒れません。一度に倒れます。
キャパシティ設計は、トラフィックが「ある速度で」来ることを前提にします。販売開始の瞬間、キャンペーンのローンチ、試験結果の公開、予約枠の開放は速度では来ません — 一瞬で来ます。アプリケーションも丁寧に劣化はしません。コネクションプールが埋まり、データベースが詰まり、応答時間が伸び、利用者が再読み込みし、それが問題の原因となった負荷をさらに倍にします。
よくある対処はむしろ悪化させます。オートスケールはスパイクが着地し、データベースがすでにボトルネックになった後にインスタンスを足します。レート制限はリクエストを拒否します — コンサートチケットのために並んだ客にとって、それはサイトが壊れているのと区別がつきません。どちらも同じ印象を残します。最も準備しておきたかった瞬間に、準備できていなかった、と。
待機ルームは問題の形を変えます。来場者は拒否も破棄もされず、順序づけられます。アプリケーションはうまくさばける人数だけをさばき、それ以外は順番と推定時間つきで席を確保し、席が空いた瞬間にプラットフォームが次の人を通します。
私たちのアプローチ
キューはアプリケーションの前、デリバリープラットフォーム上で動きます。つまりアプリケーションが限界に達しているときもキューは立っています。誰かを通す・保持する・解放するのに、アプリケーションのコードは一切関与しません。
アプリケーションが実際にさばける上限
公開サービスに同時に入れる来場者数の上限を設定します。この数字は、ハードウェアが理論上通せる量ではなく、アプリケーションが実証的にうまくさばける量から決まります。
人数だけでなく到着速度へのゲート
別の上限が、1分あたりに入れる新規来場者数を制限します。大きくても安定した人数には耐えるのに、1万人が同じ秒に到着すると崩れるバックエンドを守るのはこの制御です。
モニターモード — キャパシティはイベント前に見つかる
待機ルームをモニターモードで動かすと、誰も止めずに「止めていたら何が起きたか」を数えます。自社トラフィックで、普通の日にキューを見積もり、推測ではなく信頼できる数字を持ってイベントに臨めます。
検証済みボットはキューの席を消費しない
検証済み検索エンジンと監視プローブは認識され除外されるため、イベント中もインデックス作成と死活監視は継続し、そもそも購入しないトラフィックに席を使いません。
機能
以下はすべて、トラフィックポリシーの他の設定と同じ画面から公開サービスごとに設定でき、すべての変更はホットリロードで — イベント中であっても — 反映されます。
公開サービスごとの同時来場者上限
アプリケーションごとに限界は異なり、1台の装置がそれぞれに別の待機ルームを同時に運用できます。上限は装置ではなくサービスの属性です。
1分あたりの新規来場者 — 急増対策
到着ゲートは同時実行上限とは独立しています。2万人が中にいても平気なプールが、2万人が一度に来ると壊れることはあります。この2つを分けるのがこの制御です。
条件付きの待機ページ — 必要な場所にだけ
キューは条件で適用されるため、決済とチケットの経路を守りつつ、カタログ・ヘルプ・ステータスページは開いたままにできます。来場者は希少なものだけを待ち、サイト全体を待つわけではありません。
順番と推定待ち時間を来場者に表示
番号のないキューはフリーズと区別がつきません。待機ページは来場者がどこにいて、どれくらいかかりそうかを示します。これが「待つ」と「去る」の分かれ目です。
席は保持される — 再読み込みで失わない
順番は来場者のセッションに紐づくため、再読み込み、接続断、モバイル回線からWi-Fiへの切り替えでも最後尾に戻されません。再読み込みの嵐が自傷行為でなくなります。
自社の待機ページ
ページは自分で管理するテンプレートです — 自社ブランド、自社の言語、自社のメッセージ。背後のアプリケーションが満杯でも、プラットフォームが配信します。
席が空いた瞬間に入場
セッションが終わるたびに、次の来場者が自動的に解放されます。実態と合わなくなったタイマーを待つ人はいません。
イベント中のライブ可視化
キューの深さ、1分あたりの入場数、平均待ち時間、離脱率がイベント進行中に画面に出ます。上限を上げ下げする判断は、電話ではなく事実で行われます。
運用の深さ
待機ルームの価値は、扱いにくい場面での挙動で決まります — イベント中のフェイルオーバー、キュー内のボット群、不安定な回線の来場者。
キューはアプリケーションではなくプラットフォームにある
エージェントもライブラリもコード変更も、運用すべき別のキューサービスもありません。アプリケーションは待機ルームの存在を知ることすらなく、単にさばける以上のトラフィックを見ません。
セッションに紐づく公平な順序
入場は先着順で、順番はIPアドレスではなく来場者のセッションに従います。企業NAT、通信事業者のCGNAT、共有オフィス回線が全員を一列に押し込めることはありません。
他の防御と組み合わさる
ボットスコアリングはキューの前で動くため、自動化トラフィックはキューに入れられるのではなく処理されます。中にいる利用者にはレート制限が引き続き適用されます。待機ルームは正直な来場者を管理するものであり、セキュリティ制御を担うものではありません。
フェイルオーバーを乗り切る
キューの状態はクラスタ全体に複製されるため、販売開始中のノード障害で列がリセットされることはありません。イベントは残存ノードで、全員の順番を保ったまま続きます。
再読み込み・新規タブ・共有端末での挙動
2つ目のタブは新しい席を取らず、同じ席に合流します。セッション期限切れと離脱には明示的なルールがあり、去った来場者の席は永久に保持されずキューへ戻ります。
イベント中に有効化・無効化できる
機能全体がホットリロードでの変更です。販売開始の数分前に有効化し、ピークが過ぎた瞬間に無効化できます。接続を1本も落とさず、何も再起動しません。
活用シナリオ
販売開始とチケッティング
コンサート、試合、旅行商品の販売は1年分のトラフィックを90秒に凝縮します。待機ルームはさばききれないスパイクを秩序ある列に変え、来場者は見える席を保ちます。
製品ローンチとキャンペーン
成功したキャンペーンは、ネットワーク層では攻撃と区別がつきません。待機ルームは、その成功のすべてを1秒でインフラに吸収させることなく、マーケティングを成功させます。
公共部門の申請受付枠
試験結果、納税期限、予約開放は、分単位で全国民に告知されます。順番が見えるキューは、市民に示せる最も公平な答えでもあります。
金融の給与日・月末ピーク
予測できて繰り返すピークのために、月で最も忙しい1時間へ恒久的に合わせる必要はありません。待機ルームがピークを吸収し、プラットフォームは平常日に合わせたままで済みます。
よくある質問
レート制限とは何が違いますか？
アプリケーションの変更は必要ですか？
適切な同時実行数はどう決めますか？
来場者が再読み込みしたり接続が切れたらどうなりますか？
検索エンジンや監視はキューで詰まりませんか？
イベント中にクラスタノードが落ちたらキューはどうなりますか？
四半期を決めるその1分に備える
同時実行上限、到着ゲート、自社ブランドのキュー — サービスごとに設定し、イベント前にモニターモードで見積もります。あなたのトラフィックで一緒に構築しましょう。