DNSラウンドロビンは、同じホスト名に複数のAレコードを登録し、問い合わせのたびに返すIPアドレスの順番を変えることで、アクセスを複数のサーバーに分散させる方法です。ロードバランサーなしで始められる手軽さがある一方、死活監視がなく、分散も均等にはなりません。この記事では、レコードの設定方法、偏りや障害時の動き、WordPressを複数台で動かすときに揃える設定、確認方法を説明します。
DNSラウンドロビンの仕組み
たとえば www.example.com に次の3つのAレコードを登録します。
www.example.com. 300 IN A 203.0.113.11
www.example.com. 300 IN A 203.0.113.12
www.example.com. 300 IN A 203.0.113.13権威DNSサーバーは3つのアドレスをまとめて返し、その並び順を問い合わせごとに入れ替えます。多くのクライアントは先頭のアドレスに接続するため、結果としてアクセスが3台に散らばります。
ここで知っておきたいのは、DNSラウンドロビンは「負荷を大まかに散らす」手段であって、厳密な負荷分散でも冗長化でもないという点です。
- 死活監視をしない：1台が止まってもそのIPを返し続けます。ブラウザの多くは接続できないと次のアドレスを試しますが、待ち時間が発生し、アプリやAPIクライアントでは失敗することもあります。
- 分散が均等にならない：大手プロバイダーや公開DNSのリゾルバーは1つの応答を大勢の利用者に使い回すため、TTLの間は同じ順番が多くの人に届きます。また、リゾルバーやOSが受け取った順番を並べ替えることもあり、先頭が固定されやすい環境もあります。
- サーバーの性能差を考慮しない：基本的には台数で割るだけです。
止まったサーバーを応答から外したい場合は、ヘルスチェック付きのDNS（DNSフェイルオーバーやヘルスチェック連動の複数値応答）か、ロードバランサーを使います。
DNSラウンドロビンが向いている場面
次のような条件なら、DNSラウンドロビンは低コストで有効です。
- 同じ内容を返すサーバーが複数あり、どれに当たっても結果が変わらない
- 多少の偏りや、1台停止時の一時的なエラーを許容できる
- 拠点の異なるサーバーへ、大まかにアクセスを分けたい
逆に、ログイン状態や買い物かごを持つサイトで、障害時にも利用者へ影響を出したくない場合は、ロードバランサーのほうが適しています。
手順1：DNSレコードを設定する
作業前に現在のDNSレコードをエクスポートするか記録してバックアップし、対象レコードのTTLを短くしておきます。
BINDなどゾーンファイルで管理している場合上の例のように同じ名前のAレコードを並べ、SOAのシリアルを増やして named-checkzone で確認してから再読み込みします。返す順番の制御は rrset-order オプションで設定できますが、既定の並べ方はバージョンによって異なるため、使っているBINDのリファレンスを確認してください。
Amazon Route 53 の場合シンプルルーティングのAレコード1件に、複数のIPアドレスを改行区切りで入力します。止まったサーバーを外したい場合は、各IPを別のレコードにして「複数値回答」ルーティングを選び、それぞれにヘルスチェックを関連付けると、正常と判定されたアドレスだけが返ります。
Cloudflare の場合同じ名前のAレコードを複数作成します。プロキシを無効（DNSのみ）にしていれば、利用者には複数のIPがそのまま返ります。プロキシを有効にした場合は、利用者に見えるのはCloudflareのIPになり、Cloudflareがオリジンを選びます。ヘルスチェックや重み付けをしたい場合は、有料の Load Balancing 機能の領域です。
ここでの説明は一般的な構成に基づくもので、各サービスの画面表記や機能の範囲は変わることがあります（2026年10月現在）。
TTLは、サーバーの増減やIP変更を早く反映させたいなら60〜300秒程度、構成が安定しているなら長めにします。短いほど権威DNSへの問い合わせが増える点は覚えておいてください。
手順2：WordPressを複数台で動かす準備をする
DNSラウンドロビンで振り分けるには、どのサーバーに当たっても同じサイトが表示される必要があります。WordPressで揃えるべき点は次のとおりです。
データベースは1つにする各サーバーがそれぞれのDBを持つと、記事やコメントがサーバーごとにばらばらになります。全台から同じDBサーバー（またはマネージドDB）に接続させます。
アップロードファイルを共有する管理画面から画像をアップロードすると、受け付けたサーバーの wp-content/uploads にだけ保存されます。共有ストレージをマウントする、オブジェクトストレージへオフロードするプラグインを使う、などの方法で全台から同じファイルが見えるようにします。
wp-config.php の認証キーとソルトを揃えるWordPressのログイン状態はクッキーで保持され、その検証には AUTH_KEY や LOGGED_IN_SALT などの値が使われます。サーバーごとに値が違うと、別のサーバーに振り分けられた瞬間にログアウトします。全台で同じ値にし、この値は公開リポジトリに置かないよう管理してください。
ファイルの変更は配布の仕組みで行う管理画面からプラグインを更新すると、そのサーバーだけが新しくなります。デプロイの手順で全台に同じファイルを配り、管理画面からのファイル変更は DISALLOW_FILE_MODS で止めておくと、台数間の食い違いを防げます。
WP-Cron は1台で実行する全台でWP-Cronが動くと、予約投稿や定期処理が重複して走ることがあります。define( 'DISABLE_WP_CRON', true ); で既定の動作を止め、1台だけでサーバーのcronから実行する構成が扱いやすくなります。
# 1台だけで実行する cron の例（5分ごと、WP-CLI を使用）
*/5 * * * * cd /var/www/example.com && wp cron event run --due-now --quietSSL証明書を全台に用意するLet's Encrypt の HTTP-01 認証では、認証用のアクセスが別のサーバーに振り分けられて失敗することがあります。DNS-01 認証で発行する、1台で取得した証明書を全台へ安全に配布する、などの方法を選んでください。
このほか、ページキャッシュやオブジェクトキャッシュをサーバーごとに持つ場合は、記事更新時に全台のキャッシュを消す必要があります。Redisなどの共有キャッシュにまとめると管理が楽になります。
手順3：分散されているか確認する
権威DNSに直接問い合わせると、並び順が入れ替わる様子を確認できます。
# 権威DNSサーバーに数回問い合わせ、順番が変わるか見る
for i in 1 2 3 4 5; do
dig +short www.example.com A @ns1.example.com
echo "---"
done
# 公開リゾルバー経由（キャッシュの影響で順番が固定されることがある）
dig +short www.example.com A @8.8.8.8DNSの応答だけでは、実際のアクセスの割合は分かりません。各サーバーのアクセスログで、一定期間のリクエスト数を比べます。
# 各サーバーで、直近のアクセス数を数える例（ログの場所は環境に合わせて変更）
sudo wc -l /var/log/nginx/access.log大きく偏っている場合は、特定のリゾルバーからのアクセスが集中している、TTLが長すぎる、といった原因が考えられます。
1台を外すときの手順
メンテナンスで1台を外すときは、DNSから先に外し、TTLの時間以上待ってからサーバーを止めます。順番を逆にすると、キャッシュが残っている利用者が止まったサーバーに接続して失敗します。作業後は、DNSに戻してからもアクセスログでリクエストが戻ってきたかを確認します。
まとめ
- DNSラウンドロビンは同じ名前に複数のAレコードを登録し、順番を入れ替えて大まかに分散させる方法です。
- 死活監視がなく、リゾルバーのキャッシュで分散も偏るため、冗長化には別の仕組みが必要です。
- Route 53 の複数値回答やロードバランサーを使うと、止まったサーバーを外せます。
- WordPressでは、DB共有、アップロードの共有、認証キーとソルトの統一、ファイル配布、WP-Cronの一本化、証明書の準備を揃えます。
- 効果はDNSの応答ではなく、各サーバーのアクセスログで確認します。