「どうしてウェブサイトがダウンしたの？ アクセスが集中するのは分かっていたはずでしょ！」
ウェブサイトが肝心な瞬間にダウンすると、よくこんな声を耳にします。ソーシャルメディア上でも、同じ質問が、同じような非難めいた口調で投げかけられます。「アクセスが集中することは分かっていたはずだ。なぜ、ギガ何たらをもう少し増やしておかなかったんだ？」
失望したユーザーにとっては、トラフィックが急増する前に企業がもっと予防策を講じておくべきだったことは明らかであり、問題が生じた原因としては計画の不備しか考えられないようです。
しかし、その予防策とは一体何なのでしょうか？負荷テスト？「より大きなサーバー」？それとも、サーバーを増やすことでしょうか？それとも、あの魔法のようなスケーラブルなサーバーレスクラウドなんてどうでしょう…？！
多くの場合、チームのウェブ開発者たちと初めて会うのは、彼らがCrowdHandlerのオンボーディングセッションに参加し、うつむいて気落ちしている時です。彼らは自分が失敗したと感じています。マニュアル通りにすべてを行ったにもかかわらず、ウェブサイトは正常に稼働し続けなかったため、時間の制約から、現在は「待合室」機能でその場しのぎの対応をせざるを得ない状況です。ミーティングの最初の10分間は、言い訳を聞き流すことに費やされます。
「そんな話はもう聞き飽きました」。現在プラットフォームを再構築中で、新しいサイトにはこうした問題はないでしょう。変更できないレガシーなコードベースを引き継いでしまったのです。パフォーマンスの問題で悪名高いフレームワークXの古いバージョンに縛られてしまっています。もちろん、すべての問題を修正することは可能です。ただ、タイミングの問題なのです。
この気まずさの原因は、ボトルネック（ウェブサイトが何千人ものユーザーに対応できない原因となる問題）のほとんどがコードに起因しており、開発者たちはその責任を自分たちにあると感じているからだ。
こうしたボトルネックは、多くの場合、バックエンド、つまりストアフロントの裏側にあるシステム――例えば、チケット発行や予約管理、クレジットカード決済処理を行うシステムなど――に発生します。しかし、同様に頻繁に、ボトルネックはストアフロントそのもの、つまりWebコードの中に生じます。開発者が完全に制御できるコードの中にです。
開発者たちの言い訳を聞いても、私たちは優越感や自惚れを感じるわけではありません。むしろ、共感する気持ちの方が強いのです。真実はこうです。誰のコードも、最初からそのままスケールするものではなく、スケーラブルなコードの書き方についてこれまで教えられてきたことのほとんどは間違っているのです。
なぜそれがあなたのせいではないのかについては、後ほど説明しますが、まずは「待合室」について考える新しい視点をご紹介したいと思います。
CrowdHandlerを導入することは、失敗を認めることではありません。むしろ、スケーラビリティの問題を解決するための第一歩となる可能性があります。CrowdHandlerを単なる応急処置としてではなく、皆様の業務を支え、改善に役立つ診断ツールとして捉えていただければと思います。
あなたのせいじゃないよ
では、ウェブサイトがトラフィックに対応できない場合、なぜ開発者の責任ではないのでしょうか？
主流のコードにコード関連のボトルネックが数多く見られる理由は、主流のWeb開発者が通常、非常に人気のあるWebサイトの開発に携わっていないためです。Web開発者が研修や学習を行う際、最適化やパフォーマンスの高いコードの書き方に関する理解は、たいていの場合、理論上のものに留まってしまいます。
スケーラブルなコードの書き方を理論上で学び、実際に10万人のユーザーがサイトにアクセスしてきたとき、マイク・タイソンの「誰もが口に一発食らうまでは計画を持っているものだ」という言葉を思い出す。さて、君は口に一発食らったわけだ。誇りに思うべきだ！ ウェブ開発者の圧倒的多数は、その感覚を味わうほど人気のあるプロジェクトに携わる機会など決してないのだから。
ですから、あなた――そしてあなたの上司――に言いたいのです。ウェブサイトが魔法のように拡張して、どんなレベルのトラフィックにも対応できるなんてことは、そもそもあり得ないのです。そんなことを期待すべきではありません。
では、答えは何でしょうか？
もちろん、サイトをできるだけ効率的で拡張性の高いものにしたいと思うでしょう。しかし、ここで話題にしているような規模の場合、拡張性に関するいわゆる「解決策」の多くは、実際には機能しません。
理論上は高速なフレームワークや言語に注目するかもしれませんが、数千人あるいは数百万人のユーザーにサービスを提供するとなると、大局的に見ればその差はほとんどありません。
何が本当に違いを生むかご存知ですか？それはキャッシュです。Memcachedを使ってサーバー側で実施するような精密なオブジェクトキャッシュではなく、ユーザーに近い場所で、まるで自分の制御が及ばないかのように感じられる「ダーティエッジ」のHTTPキャッシュのことです。これは確かにパフォーマンスを向上させますが、適切に実装するのは難しく、また、それを十分に考慮していないフレームワークやコンテンツ管理システムに後付けで導入するのも困難です。
ですから、まずは負荷テストから始めてみるのもいいかもしれません。しかし、多少物議を醸す意見かもしれませんが、定期的な負荷テストがそれほど役立つとは思いません。私の経験上、それは多くの場合、費用のかかる時間の無駄にすぎないからです。
なぜでしょうか？ それは、実際のユーザーの行動は複雑だからです。負荷テストのために、ユーザーがページを閲覧し、商品を選択し、カートに追加して、チェックアウトするという基本的なユーザージャーニーを設定することはできますが、現実の世界ではそうはなりません。現実の世界では、顧客はページを行き来し、あらゆる選択肢を検討し、気が変わったり、長い間立ち止まってからページを再読み込みしたり、さらには異なる商品のタブを4つ開いて比較したりします。 こうした複雑なジャーニーが同時に何千件も発生し、予測不可能な形で同じデータベースの行を相互参照している可能性があります。
そこで、ステージング環境で一連の負荷テストを実行し、200万人のユーザーでウェブサイトがダウンした時点で、200万人を「魔法の数字」と宣言するかもしれません。 しかし、その200万件のユーザージャーニーは、果たしてどれほど現実的なものでしょうか？それらは、本番環境における200万件の「本物で実用的な体験」を本当に示しているのでしょうか？それとも、ユーザーが現実的な行動を取り始めた時点で、本番のウェブサイトはもっと早くダウンしていたのではないでしょうか？（実際のセール中に誰かが高負荷な売上レポートを実行しようと決めた瞬間はさておき……あ、そのテストは行っていないのですか？）
負荷テストには非常に多くの時間がかかることも忘れてはなりません。ユーザーフローのスクリプトを簡略化したとしても、テストを何度も繰り返し実行し、正常に動作するまで設定上の問題を修正し続ける必要があります。そして、正常に動作するようになったら、ウェブサイトがダウンするまでテストを続けなければなりません。これは終わりのないサイクルになりかねません。 当社のクライアントの多くは、負荷テストツールを使って実環境で見込まれるほどのトラフィックを生成できないか、あるいはそれを行うには費用がかかりすぎて手が出せないという状況にあります。
最後に：ここで説明している負荷テストは、大規模なプロジェクトです。年に1回、大規模な負荷テストを実施している企業は数多くあります。しかし、そうした企業でも、週に何度も新しいコードを本番環境にデプロイしています。たった1行のコードが不適切な場所に配置されただけで、その負荷テストの努力がすべて無駄になり、目標としていた数値が根本から変わってしまう可能性は十分にあります。 現在、継続的インテグレーションを利用してコードを本番環境にデプロイしています。もし、継続的な負荷テストを実行する方法さえあれば……
連続負荷試験
CrowdHandlerを、従来の負荷テストに代わる、はるかに生産性が高く、手頃な価格の選択肢としてご検討いただければと思います。その理由は、CrowdHandlerが保護対象のウェブサイトに基づいて、実環境での継続的なパフォーマンス情報を提供し、より効率的かつ反復的な作業を可能にするからです。
セール期間中、ダッシュボードには各ページの読み込みにかかる時間が表示され、ページ全体のパフォーマンスが要約されます。CrowdHandlerの自動調整機能は、リアルタイムでページ速度を分析し、ユーザー数を追跡し、サイトが処理できる新規ユーザーの最適な流入数を算出します。
つまり、実際のユーザーを利用して本番環境に対して継続的な負荷テストを実行し、その結果をリアルタイムで調整しているのです。
しかし、従来の負荷テストとは異なり、この方法には「待合室」という安全弁が組み込まれています。もし数値が予想を大きく外れたとしても、最悪の場合でもウェブサイトがダウンするわけではなく、単に待ち時間が長くなるだけです。
そして、たとえ待ち時間が思ったより少し長くなっても、システムの実稼働時の挙動を観察して学ぶことができます。どのページが特に遅いのかがわかるため、アプリケーションのボトルネックを特定できる一方で、自動調整機能によってキューが管理され、ユーザーエクスペリエンスは良好な状態が保たれます。実際の販売時のデータを観察することで、次回に向けてどの部分の最適化に注力すべきかがわかります。
ウェイティングルームが導入されていない場合、アプリケーションに原因不明のボトルネックが発生していたとしても、それを診断したり、あるいは観察することさえほぼ不可能でしょう。なぜなら、ウェブサイトは完全にダウンしてしまい、緊急の対策の導入に必死になっているからです。たとえ後で診断データを回収できたとしても、制御不能なトラフィックによってさらに悪化する負荷の急増という緊急事態の中では、根本原因を明確に把握することは難しいでしょう。
だからこそ、私はCrowdHandlerを単なる「応急処置」ではなく、ツールキットの不可欠な要素としてご紹介しているのです。当社の「待合室」機能を選ぶことは、諦めてその場しのぎの対策を取るということではありません。むしろ、冷静な判断を保ち、パフォーマンスを継続的に向上させながら、ソーシャルメディア上での批判を軽減するのに役立つ、新たな診断ツールを導入することになるのです。
ですから、もしCrowdHandlerの利用を検討しているなら、どうか尻尾を巻いて私たちのもとに来ないでください。胸を張ってください！あなたはウェブ開発者です。大人気のプロジェクトに携わり、さらに良いものにするために尽力しています。あなたはすべてを正しく行っています。