ラウンドロビンは、届いた要求を複数のサーバーへ「順番に1つずつ」振り分ける、もっとも単純な負荷分散の方式です。仕組みが単純なぶん、どこで振り分けるか（DNS か、ロードバランサーか）によって効き方と弱点が大きく変わります。この記事では、ラウンドロビンの考え方、DNS とロードバランサーでの動きの違い、重み付けや最小接続数などの他の方式との使い分けを整理し、WordPress を複数台で動かすときに押さえる点を説明します。
DNS ラウンドロビンの具体的な設定手順や、1台が止まったときの対策は別の記事で扱っているため、ここでは「ラウンドロビンとは何か、何に向いて何に向かないか」の基本に絞ります。
ラウンドロビンの考え方
サーバーが A・B・C の3台あるとき、ラウンドロビンでは1件目の要求を A、2件目を B、3件目を C、4件目をまた A というように、順番に回して割り当てます。名前の由来は、署名の順番が分からないように円形に名前を並べた「円形の嘆願書」だといわれています。
この方式の長所は次のとおりです。
- 振り分けの計算がほとんど不要で、振り分ける側の負担が小さい
- 各サーバーの状態を細かく知らなくても動く
- 要求の重さがそろっていれば、台数でほぼ均等に負荷が分かれる
一方、弱点もはっきりしています。
- 要求ごとの重さの違いを考えない（重い管理画面の処理も軽い画像の配信も「1件」として数える）
- サーバーの性能差を考えない
- 振り分けの仕組み自体が死活を確かめない構成では、止まったサーバーにも要求を送り続ける
この弱点を補うために、重み付けや死活監視を組み合わせたり、別の方式を選んだりします。
DNS ラウンドロビンとロードバランサーの違い
ラウンドロビンという名前は同じでも、どこで振り分けるかで性質が変わります。
DNS ラウンドロビン
1つのホスト名に複数の A レコード（IPv6 なら AAAA レコード）を登録し、問い合わせのたびに答えの並び順を変えてもらう方法です。利用者の端末は、返ってきた一覧から1つを選んで接続します。
# 1つの名前に複数のアドレスが登録されているかを確かめる
dig www.example.com A +short追加の機器が要らず手軽ですが、次の点に注意が必要です。
- 順番を決めるのは DNS サーバーと端末：並び順は権威 DNS サーバーやキャッシュ DNS サーバーで変わり、端末側も OS のアドレス選択の規則で並べ替えることがあります。そのため、厳密に均等にはなりません。
- キャッシュが効く：一度受け取った答えは TTL の間使われるため、同じ利用者は同じサーバーに偏りがちです。
- 止まったサーバーを外せない：DNS は相手のサーバーが動いているかを知りません。止まった台のアドレスも返し続け、レコードを削除しても TTL が切れるまで古い答えが残ります。
ロードバランサーのラウンドロビン
nginx や HAProxy、クラウドのロードバランサーが受けた接続（または HTTP の要求）を、背後のサーバーに順番に渡す方法です。利用者が接続するのはロードバランサーだけで、背後のサーバーのアドレスは見えません。
振り分けをロードバランサーがその場で行うため、DNS のキャッシュの影響を受けず、死活監視で異常な台を外すこともできます。そのかわり、ロードバランサー自体が止まると全体が止まるため、ロードバランサーの冗長化も考える必要があります。
nginx では、upstream に複数のサーバーを書くと、特に指定しなければ重み付きのラウンドロビンで振り分けます。
upstream wp_backend {
# 方式を書かなければラウンドロビン
server 10.0.0.11:80 weight=2; # 性能の高い台に多めに渡す
server 10.0.0.12:80; # weight を省略すると 1
server 10.0.0.13:80 backup; # 他の台が使えないときだけ使う
}
server {
listen 80;
server_name www.example.com;
location / {
proxy_pass http://wp_backend;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}HAProxy では、backend の中で balance roundrobin と書きます。server 行の check を付けると死活監視が有効になり、応答しない台は振り分けから外れます。
backend wp_backend
balance roundrobin
server web1 10.0.0.11:80 check weight 2
server web2 10.0.0.12:80 checkここで使った weight・backup・check などの書き方は、nginx と HAProxy の公式ドキュメントに沿ったものです（2026年10月現在）。版によって使える項目が増えることがあるため、手元の版のドキュメントもあわせて確かめてください。設定を変えたら、反映の前に nginx -t や haproxy -c -f /etc/haproxy/haproxy.cfg で文法を確かめてから再読み込みします。
他の分散方式との使い分け
ラウンドロビンが合わない場面では、別の方式を選びます。代表的なものを比べると次のとおりです。
| 方式 | 振り分けの考え方 | 向いている場面 |
|---|---|---|
| ラウンドロビン | 順番に1つずつ | 要求の重さとサーバーの性能がそろっている |
| 重み付きラウンドロビン | 重みに比例して多めに渡す | サーバーの性能に差がある |
| 最小接続数 | 処理中の接続が少ない台に渡す | 処理時間がばらつく、接続が長く続く |
| 送信元 IP のハッシュ | 同じ送信元は同じ台に渡す | 同じ利用者を同じ台に寄せたい |
nginx では least_conn や ip_hash、HAProxy では balance leastconn や balance source が、それぞれ最小接続数と送信元による振り分けにあたります。WordPress のように、管理画面の保存や検索など重い処理と、キャッシュされたページの配信など軽い処理が混ざるサイトでは、単純なラウンドロビンより最小接続数の方が負荷が偏りにくいことがあります。どの方式が合うかはアクセスの傾向で変わるため、切り替えたら各台の負荷を見比べて判断します。
WordPress を複数台で動かすときの前提
どの方式でも、要求が毎回別のサーバーに届く可能性があります。そのため、サーバーごとに状態を持たない構成にしておくことが前提です。
- データベースは共通にする：各台が同じデータベースに接続します。
- アップロードしたファイルを共有する：
wp-content/uploadsを共有ストレージに置くか、オブジェクトストレージに逃がすプラグインを使います。ある台に上げた画像が、別の台では表示されない、という不具合がよく起きます。 - ログイン状態：WordPress のログインは Cookie で判定されるため、各台の
wp-config.phpの認証用キーとソルトを同じ値にそろえておけば、台をまたいでもログインが保たれます。 - プラグインとテーマを同じ版にそろえる：更新はすべての台に同じ内容で配布します。
- HTTPS の判定：ロードバランサーで SSL を終端する構成では、WordPress が HTTPS で開かれたと判定できるように、
X-Forwarded-Protoを見て判定する設定が必要になる場合があります。
まとめ
- ラウンドロビンは要求を順番に振り分ける単純な方式で、要求の重さとサーバーの性能がそろっているときに均等に分かれます。
- DNS ラウンドロビンは手軽ですが、キャッシュや端末の並べ替えで偏り、止まった台を自動で外せません。
- ロードバランサーのラウンドロビンは、死活監視と組み合わせて異常な台を外せます。nginx の
upstreamは既定で重み付きのラウンドロビンです。 - 性能差があれば重み付き、処理時間がばらつくなら最小接続数を検討し、WordPress ではデータベース・アップロード・認証キーの共通化を先に済ませます。