ロードバランサー
1 つの Web サイトに対して世界中からやってくる大量のアクセスを、複数の Web サーバに効率よく振り分けて負荷を分散する仕組み(機器やクラウドサービス)のこと。交通整理の警察官のような役割を果たし、AWS の ELB、nginx、HAProxy などが代表例。1 台のサーバがトラブルでダウンしても、他のサーバが自動で処理を引き継ぐため、サイト全体の可用性(サーバ稼働率)(システムが停止せず動き続けられる能力)や耐障害性(一部が壊れても全体が機能停止しないタフさ)が劇的に向上する。
運用の要点：中小サイトには過剰投資? 「ここぞ」という場面での導入判断
ロードバランサーは大規模サイトや、急激なアクセス集中に耐えるためのインフラ。そのため、アクセスが穏やかな中小規模のサイトの平常運用に導入するのはコストの過剰投資(無駄遣い)になりがち。基本的には、「TV CM の放映連動」「大規模な SNS キャンペーン」「新商品の予約開始」など、瞬間的に普段の数十倍〜数百倍の大量アクセスが見込まれる場面でピンポイントに導入・増強を検討する。実務での実装はインフラエンジニアの領域だが、Web 担当者は「どれだけのアクセスを持ちこたえたいか」を業者に伝え、コストの議論を主導する必要がある。その際、本番前にピーク時を模した模擬アクセスを送る「負荷テスト(限界測定)」をセットで行うのがプロの鉄則。
現場でよくある「落とし穴」
「ロードバランサーを入れたから絶対に落ちない」という過信は、当日の中継現場で悲劇を生む。
- 「入り口だけ広げて奥で詰まる」データベースのボトルネック地獄：負荷分散で「もう大丈夫」と安心し、システム全体のスケーラビリティ(アクセス増に応じて処理能力を拡張できる柔軟性)のチェックを怠ってしまう。悲惨な末路として、ロードバランサーを使って Web サーバを 5 台に増やし、アクセスを綺麗に分散させたものの、すべてのサーバがデータを書き込みに行く「共通のデータベースサーバ」の強化を忘れていた。結果、キャンペーン開始と同時にデータベースが処理しきれずにパンクし、Web サーバがどれだけ元気でもサイト全体が「500 Internal Server Error(真っ白な画面)」で完全ダウン。インフラ業者と大揉めになり、キャンペーンの売上も大損失に終わる(インフラ設計は、サーバだけでなくデータベースやネットワークも含めて総合的に見なければ意味がない)。
言葉をよく利用する人
- 情シス
- インフラエンジニア
- バックエンドエンジニア
- Web 担当者(発注側)
会話上での使用例
TV CM 連動キャンペーンを控え、アクセス急増でサイトが落ちないか相談する場面
-
マーケター
今度のCM放送に合わせてキャンペーンページを公開するんですが、一気にアクセスが集中してサイトが落ちたりしませんか。心配で。
-
Web 担当者
そこはロードバランサーを入れて、複数台のサーバーにアクセスを振り分ける構成で備えようと思っています。あわせて、ピーク時の10倍くらいの負荷を想定した負荷テストも事前にやっておきますね。
-
マーケター
それなら安心です。テスト結果も見せてもらえると助かります。
サーバーダウン時の可用性向上をインフラ担当と相談する場面
-
情シス
サーバーが1台落ちたときに、サイト全体が止まらないようにしたいんですが、何か手はありますか。
-
Web 担当者
ロードバランサーを挟んで複数台構成にしておけば、1台ダウンしても残りで処理を続けられます。ただ、それで万全と過信せず、サーバー側のスケール対策も合わせて設計しておきたいですね。