時折、ソーシャルメディア上で、開発者たちから「なぜ待合室ソリューションなどを使うのか」と疑問を呈するコメントが見受けられます。彼らにとって、CrowdHandlerを導入することは、ツールキットへの賢明な追加というよりは、むしろ敗北を認めることになってしまうのです。
そもそも、魔法のように無限に拡張できるクラウドが利用できるのに、なぜ待合室向けのソリューションなど必要になるのでしょうか？
例を挙げると：
「無制限に拡張できる適切な負荷分散戦略か、それとも顧客を苛立たせる待合室か……うーん、難しい選択だ」
無制限の拡張？ そんなものは存在しない
どういうわけか、多くの開発者は、EC2グループの自動スケーリングやAWS Lambda、あるいはAzureやGoogleの同等のサービスといった自社のクラウドソリューションが、無限にスケーリングできると想定しているようです。
たぶん、彼らは自分たちが魔法でできていると思っているのだろう。
実のところ、クラウドソリューションは一定の範囲内でのみ拡張が可能であり、たとえ魔法のようにいくらサーバーを追加できたとしても、最終的には限界にぶつかってしまうのです。
そのパラメータには、ご自身で設定し、費用を負担しなければならないものも含まれます。つまり、ご予算の範囲内で、そのクラウドが運用を許可する条件のことです。しかし、おそらくデータベース技術に基づく最終的な制限も存在するでしょう。（結局のところ、ACID準拠のストレージ層が無限にスケーリングすることは不可能です。なぜなら、その性質上、ACIDトランザクションが無限に続くことはあり得ないからです。）
ですから、上記のようなコメントを見ると、その人は実際には現場でスケーリングをあまり経験していないのだとわかります。
というのも、ごく短期間で膨大なトラフィックに対応しようとするアプリケーションの開発に携わった経験があれば、いずれその限界に直面し、「無制限の拡張」などというものは存在しないことを理解するようになるからです。
オートスケーリングはうまくいく……が、うまくいかなくなる時もある
確かに、1日を通して、あるいは1か月単位で自動スケーリングできる、非常に優れたスケーラブルなアプリケーションをお持ちですね。繁忙期であっても、変動するトラフィックレベルに合わせて問題なく調整することができます。自動スケーリングアーキテクチャは、トラフィックがやや増加したことを検知すると、それに対応するために自動的にサーバーを追加し……その後、トラフィックが落ち着くとそれを検知して、サーバーをシステムから切り離します。これはうまく機能しています。
99％のケースでは、これらはすべて素晴らしいものです。しかし、オートスケーリングアーキテクチャに無限のスケーラビリティが求められるようなトラフィックパターンは、こうしたものとは全く異なります。ここで想定しているのは、アプリケーションの負荷が1分足らずの間に、突然10倍、100倍、あるいは1000倍にも急増してしまうようなシナリオです。
突然、以前の1000倍も忙しくなった
CrowdHandlerで観察される、こうした突発的なトラフィックの急増の最も顕著な例が、チケットの販売開始です。例えば、人気トップスターのツアーのチケットが販売開始されると、販売サイトのアクセス数は午前10時ちょうどに、ゼロから100万へと急増することがあります。
しかし、これはメガスターのチケット販売に限った話ではありません。突然のトラフィックの急増は、誰にでも起こり得ます。売り切れが予想されるセール、人気商品の突然の品切れ、ソーシャルメディアのインフルエンサーによる商品への言及（予想通りでもそうでなくても！）など、あらゆる要因がトラフィックの急増を引き起こす可能性があります。
こうしたケースでは、通常、オートスケーラーがトラフィックの増加を検知し――ページの読み込み時間が長くなっていることや、サーバーのCPU使用率が高くなっていることなどに気づく――それに応じてサーバーを追加して対応するということが起こりがちです。
ただし、この処理は即座には完了しません。コンテナの起動やキャッシュのウォームアップに時間がかかるためです。
実に皮肉なことに、オートスケーリングの仕組みが働き始めると、たいていパフォーマンスが著しく低下します。システムが再び安定するまでのこの停滞期間は、最大で5分間続きます。
待機ルームが設定されている場合、ここでその機能が作動します。パフォーマンスが低下し、そのままではエンドユーザーがアプリケーションのクラッシュに見舞われる恐れがある状況になった際、待機ルームは、システムが再び正常な状態に戻るまでの数分間、ユーザーを待機させる役割を果たします。
Triple 9の稼働時間
ところで、SLAでは全体的な稼働率についてどのように規定されていますか？というのも、1か月という期間で考えれば、スケールバックに要したその5分間は、たとえ多大な損害をもたらす可能性があったとしても、ほとんど目立たないからです。計算してみてください。5/43920 ですから、稼働率は依然として99.99%になります！しかし、ユーザー体験や評判という観点から見れば、その5分間こそが、その1か月の中で最も重大な瞬間となるでしょう。
では、問題を防ぐためにはどうすればよいのでしょうか？
トラフィックの過負荷の緩和 - 1：予測可能な場合
多くの場合、トラフィックのピークがいつ訪れるかは予測できます。例えば、高額商品の販売開始を金曜日の朝に設定することもあるでしょう。 あるいは、ブラックフライデーのセールを計画しているかもしれません。そこで私たちのアドバイスは、トラフィックの増加を待って自動スケーリングを行うのではなく、事前に「マジッククラウド」がスケールアップするようスケジュールを設定しておくことです。（これは、当社のパートナーであるMade Mediaが実践している方法です。彼らは、多くのクライアントがセールを行うこと、そしてそれが通常金曜日の朝に発生することを把握しているため、インフラが毎週金曜日の朝にスケールアップするようスケジュールを組んでいます。）
そして……ご想像の通り、CrowdHandlerを導入しましょう。なぜなら、スケーリングのパラメータについて極めて精通しており、予想されるトラフィックの規模を完全に把握しているという自信があっても、依然として大きな誤差の余地があるからです。一方、ウェイティングルーム機能なら、ほぼあらゆる状況に対応できます（そして、必要がない限り実際には作動しないという点も覚えておいてください）。
また、予期せぬ事態が起こることも確かです。よく、お客様から「なぜ待合室が稼働状態になっているのか」と問い合わせがあり、「CrowdHandlerのダッシュボードに『間違った』トラフィックや『実際には存在しない』トラフィックが表示されている」と言われることがあります。しかし、そのトラフィックは確かに存在しています――ただ、予期していなかっただけなのです。 その後、インフルエンサーから言及されたことが判明し、予期していなかったタイミングでサイトに大量のトラフィックが流入していたことがわかります。チケット販売の世界では、入念に準備されたPRスケジュールを確認せずに、ツアー発表の一環としてリンクを早々に公開してしまうアーティストがますます増えています。
トラフィックの過負荷を軽減する - 2：予測不可能な場合
トラフィックのピークがいつ訪れるか分からない場合（あるいは予測不可能なインフルエンサーと連携している場合！）、万全を期すために、CrowdHandlerをインストールして常時稼働させておくことを強くお勧めします。
さらに良いのは、オートチューンを有効にして使うことです。この場合：
- 交通量の増加
- キューが作動し、CrowdHandlerのAutotuneがレート管理を行います
- 自動スケーリング機能を備えたクラウドは、負荷の増加に対応してスケーリングを開始しますが、それによってパフォーマンスが低下します
- CrowdHandlerのAutotuneは処理速度の低下を検知し、一部のユーザーをキューに保留させ、適切なメッセージを表示することで、ユーザーに良好な体験を提供します。
- パフォーマンスが通常レベルに戻ると、オートチューンは処理速度を上げ、キューを迅速に空にします。
ユーザー体験に関する最後の言葉
面白いことに、たとえ魔法のような自動スケーリング機能を備えたクラウドが問題なく動作し、商品が1秒もかからずに完売したとしても、ユーザーは満足のいく体験を得られないでしょう（そして不満を漏らすかもしれません）。なぜなら、何かが非常に迅速に起こる場合――例えば、商品が購入可能になってから完売するまでの間に、まるで時間が全くないように感じられる場合――エンドユーザーにとっては非常に不公平に感じられるからです。 当社のお客様からは、CrowdHandlerのプロセスとそれに伴うメッセージングにより、ユーザーに一息つく時間を与え、情報を提供し続けることで、ユーザーの支持を維持できているという声をいただいています。
ですから、待機画面が表示されたら、その流れを信じてください。慌てないでください（ただし、メッセージ欄は賢く活用してください）。ユーザーにとっては、サイトがクラッシュしたり、すぐに「売り切れ」ページが表示されたりするよりも、数秒や数分間順番待ちをするほうが、はるかに気楽に感じられるはずです。