CrowdHandler をインストールして待合室を設定する際は、最初から正しく設定していただくことをお勧めします。
多くのユーザーが、負荷の急増という緊急事態の最中に、CrowdHandlerを本番環境に直接導入し、それが危機を救うのを目の当たりにしてきたことを、嬉しく思います。
とはいえ、どんなに気を付けていても……ミスはつきものです。そこで、ここでひとつ注意点を挙げておきます。お客様が陥りがちな7つの落とし穴と、よりスムーズなセットアップを実現するための回避策をご紹介します。
準備は万全だと思う？……
たとえば、新製品や新サービス、あるいはセールを開始するとしましょう。
ご自身のサイトでは、需要や負荷に関する問題が発生する可能性が高いことはご存じでしょう。例えば、非常に希少な商品を扱っているため需要が急増すると予想されている場合や、これまでにない数の訪問者が同時にサイトにアクセスすることが分かっているため、高い負荷の問題が懸念される場合などがあります。
つまり、待合室が必要になることはわかっているわけです。実際、最初から待合室を組み込んで開発しています。それはユーザー体験の一部となるでしょう。それがどのように機能するか、そして待ち行列が開発中のソリューションにどのように組み込まれるか、あなたは正確に把握しています。徹底的にテストされるでしょう。失敗するはずがありません。
…あるのかな？
念のため、CrowdHandlerのカスタム統合で最もよく発生する問題と、それらを回避する方法について確認しておきましょう。
1. 限定的な機能テスト
クライアントが、丹念に作り上げたカスタム統合機能を、社内の少人数の関係者（5人か10人程度）を対象にテストしているのをよく目にします。彼らは、標準的なユーザージャーニーをいくつか実行し、ユーザーが正しくキューに入れられ、サイトへリダイレクトされているかを確認します。
しかし、この種のテストでは、実際に待ち行列が発生している状況下でサイトがどのように動作するかを現実的に把握することはできません。何しろ、その少数のユーザーが待合室の手続きを経てサイトへのアクセスを許可された後は、待ち行列は存在しなくなるからです。しかし、多くの統合上の問題は、アクセスが集中しているサイトで待ち行列が発生したときに初めて明らかになる傾向があります。
テストを行う際は、ターゲットサイト上でユーザーが「プロモート済み」ステータス（通常はCrowdHandlerのクッキーによって示されます）を維持できているかどうかを必ず確認する必要があります。単にテストユーザーを待合室からサイトへ移動させるだけでなく、CrowdHandlerのセッションが維持されているかどうかをテストすべきです。
したがって、少なくとも以下のことを行う必要があります：
- レートを 0 に設定すると、キューが作動するようになります
- 一部のユーザーが接続できるよう、一時的にレートを引き上げる
- レートを再び0に設定する（これにより、アクティブなキューが再び作成される）
- 次に、サイトへ移行されたユーザーが、引き続き機能的なユーザージャーニーを完了できるかどうかを確認してください。
一部のユーザーを通過させた後、レート制限を0に戻すことは極めて重要です。なぜなら、この時点でユーザーのCrowdHandlerセッションが切断されると、そのユーザーはキューに戻されてしまうからです。しかし、レート制限を高いままにしておくと、それらのユーザーはキューに戻されず、統合に問題があることに気づくことができません。
2. 本番環境は開発環境を反映していない
もちろん、誰もが自分のステージング環境や開発環境が本番環境を忠実に反映していると言いたいところですが……しかし、私たちの経験上、そうなることはめったにありません。
私たちがよく目にする問題の一つは、クライアントが開発環境やステージング環境で数日、あるいは数週間もテストを行った後、本番公開の1時間前にその同じ設定を本番サイトに適用し、まったく同じように動作することを期待してしまうことです。それがうまくいかないことに気づいた時には、すでに手遅れになっています。
これは、本番環境と開発環境で違いが生じやすい点が、まさに「待機ルーム」を陥れやすい要因だからです。本番環境では導入が必須とされる多くのセキュリティ対策――たとえば、CDNの背後でのサイト運用、ファイアウォールの稼働、ボット対策など――は、通常、ステージング環境では必要とされないため、ネットワークのルーティングや設定の一部が異なる可能性があります。
ですから、以下の点の違いにぜひご注目ください：
- ネットワークルーティング（特にCDNやDNSの実装において適用される）
- ボット対策、ファイアウォールインフラ、または本番環境と一致しない設定
開発の最終段階で大きな問題が発生しないようにするため、本番環境へのリリースには、本番運用開始の少なくとも24時間前に行うことをお勧めします。開発環境やステージング環境での機能テストが完了したら、本番環境のうち、問題になりそうにない範囲（実際のユーザーに迷惑をかける可能性が低い、特定の保護されたURLパターンなど）に範囲を絞り、本番環境で小規模なテストを行ってください。 深夜に小規模な本番環境テストを行うことも可能です。
ただ……ぎりぎりまで先延ばしにしないでください。
3. IPアドレスのブロック
カスタム統合機能では、ユーザーのIPアドレスをCrowdHandler APIに送信し、そのIPがブロックリストに含まれていないかを確認します。しかし、サイトの設定によっては、ユーザーのIPアドレスの代わりにプロキシサーバーのIPアドレスが誤って送信されてしまうことが珍しくありません…その結果、CrowdHandlerのIPブロック機能が誤作動してしまうのです。
これは、統合を独自に実装している場合にのみ問題になりがちですが（当社の統合機能のいずれかをご利用の場合は、そのすべては当社側で対応済みです）、誤って実装してしまう可能性がかなり高いので、ご注意ください。
詳細はこちら：カスタムAPI連携のトラブルシューティング
4. 金利を高く設定しすぎる
多くの人は、自分のサイトが実際には処理できるよりもはるかに多くのトラフィックに対応できると思い込んでいます。そのため、私たちの経験上、お客様はインジェストレートを必要以上に高く設定してしまうことがよくあります。
初めてサイトを公開する場合、どれほどのトラフィックが予想されるのかは分かりませんし、率直に言って、どれほどのトラフィックに対応できるのかもまだ分からないでしょう。サイトが1秒あたり数千件のリクエストを処理できるというスペックに惑わされないでください。それは、キューから実際にどれだけのユーザーを処理できるかという点とは別問題だからです。
1分あたり60人以上のユーザー（つまり、1秒あたり1つの新規セッション）を容易に処理できるサイトはかなり稀ですので、サイトの負荷パターンを十分に把握していない限り、最初は30人以下から始めるのが無難でしょう。
要するに、最初は低めに設定したほうがいい。そうすれば、予想以上にうまくいった場合、簡単に利率を引き上げることができる。一度停止してしまったアプリを再開するのは、もっと厄介になるかもしれない。
関連項目：「負荷テストがうまくいかないのはなぜ？」
5. URLの除外
DNS連携、CDN連携、またはフロントコントローラーを用いた独自のサーバーサイド連携を利用している場合、ユーザーをキューに誘導するために、すべてのURLが1つずつチェックされます。
ただし、特定のURLはサードパーティ製アプリケーションによって呼び出される可能性があり、これらはキューに送信すべきではないため、これらのURLを除外する必要があります。
その明らかな例が、決済ゲートウェイです。ユーザーが、たとえばPayPalやStripeを使って取引を完了すると、決済ゲートウェイは注文確認の領収書を送り返し、その際にサーバー上の特定のURLにアクセスします。そのURLを除外設定していない場合、（すべてのURLをチェックしていることを思い出してください）CrowdHandlerの統合機能が介入し、決済ゲートウェイをキューに入れる必要があると判断します。その結果、注文は決して完了せず、ユーザーはチェックアウトできなくなってしまいます。
これが、十分な余裕を持って包括的な機能テストを行うべきもう一つの理由です。レートが0になるように設定して、キューがアクティブであることを確認し、保護されたドメインに依存している可能性のあるサードパーティ製アプリも含めた、ユーザーによる一連の操作をすべてテストしてください。
詳細はこちら：カスタムAPI連携のトラブルシューティング
6. テンプレートの過度な単純化
CrowdHandlerが人気を博している主な理由の一つは、カスタムテンプレートです。テンプレートがもたらす自由度を活かして、ユーザーが実に独創的で刺激的な活用例を生み出しているのを目にしてきました。
デフォルト（「初期」）テンプレートには、さまざまなシナリオに対応したメッセージや状態が用意されており、その中には特に分かりやすいものもあれば、そうでないものもあります。これには、ルームがまだ開いていない場合、ルームが定員に達している場合、不審な行動によりユーザーがブロックされている場合、およびユーザーにまだキューの順番が割り当てられていない場合などが含まれます。
しかし、テンプレートをカスタマイズする際、多くの場合、「正常な流れ」のみを考慮し、あまり目立たないエラーメッセージや状態を無視したり、さらに悪い場合には完全に削除してしまったりしがちです。その結果、ユーザーがこうした状況に陥った際、ほとんど役に立たないUIが表示されてしまうことになります。
ユーザーにはフィードバックが必要であることを理解しておくことが重要です。たとえそのフィードバックが、現在の位置情報や進捗バー、推定待ち時間など、あなたにとって必ずしもポジティブとは感じられない情報であってもです。私たちの経験上、こうした要素を非表示にすることは逆効果です。それらがなければ、ユーザーは予測不能な行動をとったり、情報不足に対して否定的な反応を示したりするようになります。その結果、売上の損失につながったり、さらには評判を損なうことにもなりかねません。
7. セッションのタイムアウト時間を極端に長く設定する
すべてのWebアプリケーションはセッションタイムアウトという概念を採用しており、CrowdHandlerも例外ではありません。
CrowdHandlerのデフォルト設定は15分であり、これはWebアプリケーションとしては比較的標準的なセッション時間です。つまり、ユーザーが何かをクリックすると、その後15分間は、CrowdHandlerはそのユーザーがまだサイトに滞在していると見なすということです。
ユーザーはページをクリックすることでセッションを維持しますが、15分のタイムアウト設定により、15分ほど離れてコーヒーを淹れても、戻ってきたときに再び待ち行列に並ばされることはありません。もう一度クリックすればセッションが復活するため、閲覧にはまだ十分な時間があります。
セッション数は、アプリの負荷を示すごく大まかな目安に過ぎないことを覚えておく価値があります。ユーザーがコーヒーを淹れに行っている間は、アプリに負荷をかけていないからです。
しかし、一部のお客様はセッションの有効期間を、短すぎたり長すぎたりする設定にしていることがわかりました。
いずれにせよ、これは逆効果です。設定値が低すぎると、ユーザーが閲覧中に再び待ち行列に戻されることになりかねません。逆に高すぎると、ユーザーが離脱した後もセッションが長時間有効なままになるため、非常に長い待ち行列を管理することになりかねません。
続きを読む：「1人入れば1人出る」
最初から完璧にこなせる準備はできていますか？
負荷の増加や需要の高まりを見込み、待合室の設置準備はできていますか？