はじめに
概要
本調査は「webサーバー 分散」に関する技術や仕組みをやさしくまとめたものです。WebサイトやAPIに来るアクセス（トラフィック）を複数のサーバーに振り分けることで、応答速度を改善し、障害時の影響を小さくする手法を中心に解説します。専門用語は必要最低限にとどめ、具体例を交えて説明します。
本書の目的
この資料は、負荷分散の基本を理解したい方に向けています。実務での導入判断や運用の初歩を学ぶための入門書として役立てることを目的とします。概念だけでなく、代表的な方式の違いや使いどころも示します。
読者対象
- Webサービスの開発者や運用担当者
- インフラの導入を検討している方
- ネットワークやサーバーの基礎を学びたい学生
初心者の方も読みやすいように配慮しています。
本書の構成
第2章以降で、負荷分散の意味、ロードバランサーの仕組みと機能、代表的な分散方式（ラウンドロビン、ランダム、最小コネクション、動的分散）を順に解説します。最後にプロキシを使った負荷分散も紹介します。各章で簡単な例を示し、実務での使い分けが分かるようにしています。
読み方のヒント
全体を通して読めば設計の全体像がつかめます。急ぎの方は、関心のある分散方式の章から読み進めると効率的です。
Webサーバー分散とは何か
概要
Webサーバー分散とは、アクセス要求（トラフィック）を複数のサーバーに振り分け、特定の一台に処理が集中するのを防ぐ仕組みです。目的は応答の遅延やサービス停止を避け、利用者に安定した体験を提供することです。
なぜ必要か
例えばセール中の通販サイトで一度に多くの人がアクセスすると、1台のサーバーだけでは処理が追いつかず応答が遅くなったり落ちたりします。複数台で負荷を分けると、処理が安定して速くなり、障害が起きても他のサーバーで代替できます。
仕組みのイメージ
スーパーのレジに例えると分かりやすいです。お客さんを複数のレジに振り分ければ一つの列に並ぶ時間が短くなります。同様に、Webの要求を複数のサーバーに配ると全体の待ち時間が減ります。技術的にはロードバランサーやDNSの分散設定などで振り分けます。
導入時の注意点
- セッション管理：利用者の状態をどこで保持するか設計します（例：共有ストレージやステートレス設計）。
- 冗長性：単一障害点を作らないよう複数台構成や監視を用意します。
- 健康チェック：応答しないサーバーを自動的に除外する仕組みが必要です。
監視すべき指標
レスポンスタイム、CPUやメモリ使用率、同時接続数、エラーレートなどを常に確認すると、負荷分散の効果が見えやすくなります。
上記を踏まえて導入すると、ユーザーにとって快適で信頼性の高いサービスを実現できます。
ロードバランサーの仕組み
基本的な役割
ロードバランサーは、クライアントからのリクエストを一元で受け取り、複数のサーバーへ振り分ける装置またはソフトウェアです。例えば、オンラインショップで同時に多くの人がアクセスしても、負荷を分散することで応答が遅くならないようにします。
動作の流れ（簡単な例）
- クライアントが注文やページ表示を要求します。
- リクエストはまずロードバランサーに届きます。
- ロードバランサーはあらかじめ決めた方法で、適切なサーバーのIPアドレスにリクエストを渡します。
- サーバーが処理して応答を返します。クライアントは処理先を意識しません。
なぜ必要か
単一のサーバーだけだと負荷に耐えられず、故障時にはサービス全体が止まります。ロードバランサーを使えば、負荷を均等にし、故障したサーバーを自動で避けることができます。
補助的な機能
多くのロードバランサーは、サーバーの状態を定期的に確認する「ヘルスチェック」や、同じ利用者を同じサーバーに固定する「セッション維持」などの機能を持ちます。これによりユーザー体験を安定させます。
ロードバランサーの主要機能
負荷分散
ロードバランサーは受け取ったリクエストを複数のサーバーに振り分けます。各サーバーの負荷をリアルタイムで確認し、応答が早い・空きが多いサーバーに送ることで全体の処理速度を保ちます。例えば、通販サイトでアクセスが集中したときに、処理能力のあるサーバーへ順に振り分けるとページ表示が遅くなりにくくなります。
死活監視（ヘルスチェック）
ロードバランサーは定期的に各サーバーの状態を確認します。応答がない、エラーが続くと自動でそのサーバーへの振り分けを止めます。これにより障害が起きたサーバーにリクエストを送らず、利用者への影響を小さくできます。復旧すれば再び振り分け対象に戻します。
セッション管理（スティッキーセッション）
同じユーザーの一連のやり取りを同じサーバーで処理できるようにします。会員ログインやカート情報など、途中の状態を保つ必要がある場合に役立ちます。方法はクッキーやIP、セッション情報を使うものがあり、必要に応じて切替えます。
ラウンドロビン方式
概要
ラウンドロビン方式は、来た順に順番でサーバーへリクエストを振り分けるシンプルな方法です。設定が簡単で、同等の性能を持つ複数のサーバーに均等に負荷を分散できます。小規模から中規模の環境でよく使われます。
メリット
- 設定や理解が分かりやすく運用負担が少ないです。
- リクエストが均等に配分されやすく、特定のサーバーに負荷が集中しにくいです。
デメリット
- 各サーバーの処理能力や接続状況を考慮しないため、性能差がある場合は効率が落ちます。
- 長時間の接続やセッション維持が必要な処理には向かない場合があります。
運用のコツ
サーバーの性能が均一であることを確認し、ヘルスチェック機能で故障サーバーを自動で除外します。セッションを使う場合は、セッション共有やクッキーで状態を管理します。
具体例
3台のサーバーA→B→Cの順でリクエストを回すと、10件のリクエストはA,B,C,A,B,C,A,B,C,Aの順で配分されます。シンプルで予測しやすい挙動です。
ランダム方式
概要
ランダム方式は乱数で受け付けたリクエストをサーバーに割り振る方法です。設定が簡単で、特別な状態把握を不要に運用できます。サーバー構成が均一な環境で、偏りが少なく働きます。
メリット
- 設定や実装が非常に簡単です。
- 毎回独立した選択を行うため、特定サーバーに集中しにくいです。
- 小規模なシステムや短時間のトラフィック変動に強いです。
デメリット
- サーバー能力や現在の負荷を考慮しません。重い処理が続くと一部が過負荷になります。
- 完全な均等分散を保証しません。短期的には偏りが出ることがあります。
適した場面
- サーバー性能がほぼ同じと分かっているとき
- 実装コストを抑えたいとき
- セッション保持が不要な短いリクエスト処理
実装のポイント（簡単な例）
サーバーの一覧から乱数でインデックスを選びます。
例: サーバー数が3台なら、0〜2の乱数を生成して該当サーバーへ送るだけです。
注意点
- サーバー性能に差がある場合は重めのリクエストで不均衡が起きやすいです。モニタリングを併用してください。
最小コネクション数方式
概要
最小コネクション数方式は、現在保持している接続数が最も少ないサーバーに優先してリクエストを振り分ける方法です。長時間接続が多いサービスや、サーバーごとに処理能力が異なる環境で効果を発揮します。
具体的な動作例
- ロードバランサーがリクエストを受け取る。
- 各バックエンドの現在の接続数を問い合わせる、または保持する。
- 最も接続数が少ないサーバーにリクエストを転送する。
例：A=2接続、B=5接続、C=3接続ならAに送る。
いつ有効か
チャットやWebSocket、動画ストリーミングのように接続が長時間続く場合に向きます。短時間で終わる大量の静的リクエストには効果が薄いことがあります。
注意点と実装のポイント
- サーバー間の性能差がある場合は重み付け（ウェイト）を使うとよいです。処理能力が高いサーバーに低い接続数でもより多く割り当てます。
- 接続数の取得はリアルタイム性が重要です。遅延があると偏りが出ます。
- スティッキーセッションや長いタイムアウトがあると負荷分散の効果が落ちますので、必要性を見極めてください。
- 実装は簡単で、ほとんどのロードバランサーが標準でサポートしています。
動的分散方式
概要
動的分散方式は、サーバーの負荷や応答時間をリアルタイムで監視し、負荷の高いサーバーには少なく、余裕のあるサーバーに多くリクエストを割り当てる方式です。状況に応じて配分を変えるため、効率よくリソースを使えます。
仕組み
- モニタリング：CPU使用率、同時接続数、応答遅延（レスポンス時間）などを短い間隔で取得します。
- 重み付け：各サーバーに現在の状態に応じた重みを付けます。負荷が低いほど重みを大きくします。
- 振り分け：重みに応じてリクエストを配分します。単純な比率や、過去の平均応答時間を使うことが多いです。
具体例
セール中の通販サイトを想像してください。あるサーバーの応答が遅くなったら、そのサーバーへの割当を減らします。別のサーバーに余裕があれば、そちらに多く振り分けます。これにより全体の応答が安定します。
利点と注意点
利点は効率的で柔軟な運用ができ、サーバーの追加・削除を即座に反映できる点です。ただし、監視データの遅延や揺れ（振動）に注意します。短期間で重みを大きく変えると振動が起きやすいので、移動平均や最小更新間隔を設けると安定します。
プロキシを利用した負荷分散
概要
プロキシサーバーをクライアントとサーバーの間に置き、受け取ったリクエストを適切なバックエンドに振り分ける方式です。クライアント側の設定変更が不要で、既存システムへ導入しやすい点が特徴です。
仕組みと例
代表的なのはリバースプロキシです。クライアントはプロキシに接続し、プロキシが内部のアプリサーバー群へ転送します。たとえばnginxやHAProxy、Varnishがよく使われます。nginxを使えば、複数のサーバーにラウンドロビンで振り分けたり、リクエスト内容で振り分けたりできます。
主な機能
- SSL終端：プロキシで暗号化を解除し、バックエンドの負担を減らします。
- キャッシュ：静的コンテンツをプロキシで保持して配信を高速化します。
- ヘルスチェック：死活監視で故障したサーバーを自動的に除外します。
- セッション維持（スティッキー）：同一ユーザーを同じサーバーに送る設定が可能です。
導入時の注意点
単一のプロキシは障害点になり得ます。冗長化やフェイルオーバー、ログ管理、適切なタイムアウト設定を用意してください。セキュリティ面ではヘッダの取り扱いやアクセス制御を確実に行うことが重要です。
以上の点を押さえれば、既存システムへ無理なく負荷分散を導入できます。
