CrowdHandlerでは、初めてアクセス集中に備えようとしている方々とよくお会いします。場合によっては、本当に必要なのは「待機室」だけということもあります。
しかし、多くの場合、サーバーの追加やロードバランシングも初めて導入することになり、こうした点について私たちと話し合いたいと考えているようです。
あまり軽視しているように聞こえないように言いますが、これは当社の製品にとって最優先の課題ではありません。当社の製品は、待合室の背後にどのようなアーキテクチャがあるかには依存しないため、この点は当社にとってそれほど重要ではありません。当社が最も重視しているのは、お客様が処理できるトランザクションの処理速度です。
実際、時折発生するトラフィックのピークに備えて、通常の10倍のトラフィックに対応できるほどスケールアップすることは、現実的とは言い難い。とはいえ、サイトの最適化が進めば進むほど、待ち時間は短くなる。
多くのウェブ開発者は、本当に人気のあるプロジェクトに携わったことは一度もないにもかかわらず、十分に立派なキャリアを築いています。そのため、世間に広まっている「ベストプラクティス」とされるアドバイスの多くが、現実の世界では通用しないことに気づき、驚かされるのです。
当社の専門知識は、当初、大手メディアやエンターテインメントブランド向けに高可用性のウェブサイトを構築してきた経験に端を発しています。そのため、ウェブサイトのスケールアップに関する一定の知見を持っています。何が実際に効果的で、何がそうでないか、私たちは熟知しています。
重要ではないこと
アプリケーションサーバーの数
共有サーバーから専用サーバーへ移行するかもしれません。あるいは、専用サーバーから、ロードバランサーの背後に配置された複数のサーバーへ移行するケースもあるでしょう（従来のホスティングプロバイダーであっても、AWSのようなクラウドサービスであっても）。
実のところ、アプリケーションサーバーの負荷が上限に達することはめったにないため、この数値はそれほど重要ではありません。
JavaScript、PHP、あるいは.NETを使った処理でHTMLやJSONを生成する場合、それほどリソースを消費するものではありません。サーバーが1台だけでも、かなりのトラフィックに対応できます。
通常、アプリケーションサーバーは冗長性（1台のサーバーに障害が発生した場合でもリクエストを処理できるようにするため）を目的としてスケールアップされます。トラフィックが集中する状況では、アプリケーションサーバーはほとんどの時間を、データベースやAPI（リモートデータベースとして機能するもの）など、他の何かを待機することに費やす傾向があります。
アプリケーションサーバーは通常、上流からの応答を待機中に送信接続が不足するとクラッシュします。10台のアプリケーションサーバーがすべて、同じデータベースクエリやAPI呼び出しの待機状態で固まってしまっては、あまり役に立ちません。
データベース（DB）サーバーへのCPUの追加
では、つまり、まずはデータベースサーバーを確認すべきということですか？
「クラスター」という言葉はよく使われますが、アプリケーションにシャーディング機能を組み込んでいない限り（ぜひチェックしてみてください）、単にデータベースサーバーを追加するだけではパフォーマンスをスケールアップすることはできません。
もちろん、CPUコア数の多い、より高性能なDBサーバーにアップグレードすることも可能です。しかし、最近のアプリケーションの多くは、データベースにそれほど大きなCPU負荷をかけません。処理を遅くしているクエリは、多くの場合、ディスク速度（I/O）によって制限されています。特に、DBストレージがどこにあるのか分からないような洗練されたクラウド環境では、実際に問題に対処する必要が生じるまで、I/Oのボトルネックを見過ごしてしまいがちです。そして、いざその問題に直面したとき、真のI/Oパフォーマンスの重要性がどれほど大きいかを痛感することになるのです。
ディスクI/Oの追加
DBサーバーでのクエリ実行時間を調査してみると、CPUやディスクI/Oを増強すれば多少は改善されるかもしれませんが、負荷がかかった際にサイトがダウンするのを防ぐには不十分であることがわかるでしょう。データベースのスペックを2倍、あるいは4倍に増やしたところで、魔法のようにサイトが救われるわけではありません。
なぜそうならないのでしょうか？通常、その原因はクエリの最適化が不十分であること――多くの場合、人気はあるものの非効率的なフレームワークによって生成されたクエリ――であり、適切にインデックスが設定されていないためです。適切なインデックスを適用すれば、クエリの実行速度が1,000倍も向上する可能性があります。これは、DBサーバーに1,000倍のコストをかけるよりも、はるかに費用対効果が高いと言えます。
「無限」のクラウドスケーリング
簡単そうですね。ボタンをクリックするだけで、実行数やプロセス数、ハムスターの数が増えるのですから。
しかし、たとえこれらの設定をすべて完璧に整え、コスト面でも問題がないとしても、トランザクションに依存している場合（ほとんどのサイトがそうであるように）、トランザクションの段階でボトルネックに直面することになります。それがデータベース内であるにせよ（トランザクション型データベースは無限にスケーリングできないのです。調べてみてください）、あるいは決済APIのようなサードパーティのサービスであるにせよ（それらも、レート制限のあるトランザクション型データベース上に構築されています）。
何が重要なのか
ランディングページをキャッシュする
Instagramなどで、みんながシェアしたくなるようなあのページ、ありますよね？
キャッシュに保存してください。
同じページを数十万回（あるいは数百万回）も再生成して、サーバーリソースを無駄にしないでください。動的なページの場合は、静的なページにするか、少なくとも部分的に静的なページにしてください。ユーザーが在庫情報やその他の動的なデータを読み込む必要がある場合は、別のアクションステップにボタンを追加してください。
ユーザーが最も多くアクセスしているページがどこかわからない？ 調べてみましょう。これは極めて重要なデータです。キャッシュ設定を行い、リバースプロキシ（Varnishなど）やCDN（Cloudflareなど）を利用するか、あるいはWebサーバーから完全に静的なファイルを配信するようにしましょう。開発者にとっては好ましくない解決策かもしれませんが、数百万回のアクセスが予想されるウェブサイトの場合、キャッシュ処理が作業の80％を占めます。
CDN（コンテンツ配信ネットワーク）を利用する
CDNとは、高度な分散型キャッシュ層のことです。完全に最適化するのは難しい場合もありますが、導入自体は簡単です。CDNは、静的ファイルを世界中に配信するためだけのものであるとお考えでしょうか？
必ずしもそうとは限りません。今日、アクセス数が最も多いサイトの多くは、たとえどれほど「動的」に見えても、CDNの背後で運用されています。実際、この原理はNext.js/Vercelのようなフレームワークの基盤となっており、この手法によって目覚ましいパフォーマンス基準を達成しています。しかし、これは新しいことではありません。テレビ局、eコマース、チケット販売サイトなどは、あなたが生まれる前からすでにCDNを利用してきました。新しいフレームワークは、単にそのアプローチを効率化しているに過ぎません。CDNの選択肢には、次のようなものがあります：
- Cloudflare：手頃な価格で人気があり、設定も簡単です。
- CloudFront：AWSに標準で付属しており、AWSでサイトをホストしている場合には便利です。
- Akamai：この分野の先駆者のひとつで、多くの大手小売サイトに採用されている。
待合室を利用する
ほとんどのウェブサイトには、スケールアップしても解消できないトランザクション上の制限があります。チケットマスターのような大手企業でさえ、販売がピークに達する時期にはキューを使用しています――しかも、彼らには十分な数のサーバーがあるにもかかわらずです。まずはキャッシュ可能な部分をキャッシュし、その後、真に動的な部分の前に待機エリアを設置することから始めましょう。需要を満たそうと無計画にサーバーをスケールアップするよりも、こちらの方が良い第一歩となります。
待機ルームを設置し、確実に処理できるトランザクションレートを設定した上で、ピーク時の負荷下でサイトを監視し、実際のボトルネックを特定しましょう。多くの場合、そのボトルネックはデータベースの低速クエリログやAPIの応答時間に現れます。テーブルにインデックスを追加するだけで、スケーリングの問題が解決することもあります。また、理論上の負荷テストや推測ではなく、実際のトラフィックの挙動から学ぶことができるでしょう。
CrowdHandler
トラフィックが集中する状況において、最も効果的な戦略は、際限のないスケールアップではなく、賢明なリソース管理です。その鍵となるのが「待機室」です。
CrowdHandlerは、アクセスが集中する時間帯の管理を支援するため、柔軟で導入しやすいバーチャル待合室の提供を専門としています。
今すぐ無料トライアルにお申し込みください。