WordPressの冗長化は本番だけでいい？さくらのクラウドで環境別に決める

2026年6月15日

みゃむ

こんにちは！新人のみゃむです。

前回の1台でいい？DBは？さくらのクラウド WordPress構成では、台数・DBの置き方・冗長化の範囲の3つを整理しました。
今回は、そのうち冗長化の話だけ、もう少し詳しく書きます！

WordPressをさくらのクラウドで運用するとき、本番だけロードバランサやWeb2台が要るのか。
開発や検証まで同じ冗長化にそろえる必要があるのか。
この線引き、私は一度かなり困ったんです。

冗長化について迷ったときの参考になれば幸いです！

ロードバランサの設定より先に、環境ごとの線引きを！

この記事でいう「冗長化」とは

WordPressをさくらのクラウド上で冗長化するとき、ここでは次の3つを指します。

サーバ（VM）をWeb用に2台以上用意する
ロードバランサ（L4）でアクセスを振り分ける
Web2台のwp-contentなどを揃える（NFSなど。ラボの冗長化（2）で検証したやり方）

DBのレプリケーションやDRBD、クラスタは別の話です。
本番でDBまで冗長にするかは、案件次第で考えます。
DBまわりは冗長化構成を考える（3）あたりを読んでもらえると助かります！

構成の選び方の記事から、冗長の話だけ掘り下げる理由

前回の記事では、1台か2台か、DBの置き方、どの環境まで冗長にするかをまとめて触れました。
「開発・検証はシンプルで、本番だけ厚くする、でよいことが多い」という話もしました。

でも現場だと、全部の環境を本番と同じ構成にしないと不安という空気で、開発環境にまでロードバランサが乗ることがあります。
今回は、環境ごとに何を足すかを表とあとで紹介する確認用の質問で詳しく書きます。

ロードバランサの設定手順そのものは、冗長化構成を考える（1）を読んでもらえればと思います。

開発・検証・本番、それぞれどこまで冗長にすればいい？

さくらのクラウドでWordPressを載せるとき、見積もり表や構成図に、環境ごとに一行ずつ書くだけで、説明がだいぶ楽になりました！

環境	冗長化の目安	よくある構成	理由
開発	シンプルで足りる	Webサーバー1台+ 共有セグメント or ルータ＋スイッチ	コストと手数。ロードバランサの行が不要なことが多い
検証	だいたい開発と同じ	サーバ1台（スペックは本番に近づけても台数は1）。LBなし	動作確認が目的。
本番	止まってよい時間次第	サーバ2台＋ロードバランサ＋NFS等	公開対応時の止まり時間で決める

開発・検証・本番の3行に、「どの環境まで冗長にするか」を一行ずつ書いておくだけで十分です。
1台か2台か、DBの置き方は前回の構成記事を見てください。

開発環境はシンプルで足りることが多い

開発は、機能を試す・テーマを触る・プラグインを確認する、が主な目的です。
さくらのクラウドなら、共有セグメント or ルータ＋スイッチとサーバ1台にWordPressとDBを同居させる構成が多いです。
Webサーバが1台落ちても、公開サイトには直結しません。

ここにL4ロードバランサを足すと、ロードバランサ本体に加えてWeb2台分のサーバの運用が増えます。
開発までそこまで厚くする必要はほとんどないと思います。

検証環境も、原則は開発と同じ考え方

検証（ステージング）は、本番に近いサーバのスペックにすることがあります。
スペックだけ本番に近づけて、台数は1のまま、という提案もよくあります。

「検証も本番と同じロードバランサ構成にしないと」となりがちですが、そのまま進めると本番と同じだけのロードバランサ・サーバ2台が環境数分だけ増えます。

本番リハーサルが契約上必須、みたいな理由がない限り、検証は1台で足りると思います！

本番環境だけ厚くする判断のしかた

まず聞きたいのは、本番でサイトが止まってよい時間帯や時間があるか、です。
ここが分かると、ロードバランサを足すかどうかがはっきりしてきます。

公開中は止まってほしくない、という要件があるとき、本番だけサーバ2台＋L4ロードバランサの話が出てきます。
wp-contentの同期（NFSなど）もセットで検討します。
さくらのクラウド上での手順は、ラボの冗長化（1）ロードバランシングと（2）NFSの順で検証しています。

提案が膨らみやすい、よくある3パターン

見積もりを組み立てるとき、本番を冗長化すると「サーバ2台」「ロードバランサ」「NFS（ファイル共有）」が考慮されます。
開発・検証の見積もりにも、本番と同じ内容をそのまま載せると見積もり全体が一気に膨らむ、というパターンがよくあります。

全部の環境を本番と同じ構成にしたい

「不安だから、開発・検証・本番を全部同じ構成にしたい」という話、現場でよく出ます。

止まってよい時間は環境ごとに違いますが、本番だけ「止まっちゃ困る」案件で、開発・検証は数時間止まっても業務に響かない、という切り分けが多い印象です。

開発・検証まで本番と同じようにすると、ロードバランサとサーバ2台分が環境の数だけ増え、おおよそ2倍どころでは済まないこともあります。
さくらのクラウドでの料金イメージは、Web/DB 2台構成の見積もりあたりで確認できます。

検証環境にもロードバランサが必須だと思い込む

「検証でもロードバランサを試さないと本番で不安」という考え方もあります。

検証でロードバランサを試す理由を一言で言えるか、が分かれ目です。
本番リリース手順のリハーサルが契約に書いてある、などの例外は後述します。
それ以外は、検証はサーバ1台で動作確認、本番だけロードバランサ＋Web2台、という進め方が多いです。

可用性を確認せずにサーバー台数だけ増える

本番の「止まってよい時間」を聞かずに、とりあえずWeb2台とロードバランサを足してしまうパターンです。
私も最初、そこを聞かずに進めて、あとから手戻りしたことがあります。

先に本番の止まり時間だけ決めると、開発・検証はサーバ1台のままでいいかどうかが見えてきます。

提案前に顧客へ確認したいこと

提案の前に、顧客へ聞きたいことをメモに並べたものを、ここでは質問リストと呼びます。
冒頭で書いた「本番で止まってよい時間、みたいなこと」も、この中のひとつです。
以下が、私がさくらのクラウドの見積もりを見直すときに使った例です。

本番でサイトが止まってよい時間はいつか

本番で、サイトが止まってよい時間帯・時間はあるか？
メンテナンスは、いつなら許容できるか？
公開停止が許されない時間帯（更新作業中も含む）はあるか？

ここが決まると、本番だけロードバランサを足すかどうかが見えてきます。

開発・検証でWeb2台を試す必要はあるか

開発・検証でも、サーバ2台＋ロードバランサが要るか？
検証環境のダウンは、業務に影響するか？
本番リリース手順を、検証で本番同等の構成（LB＋Web2台）で試す契約・要件はあるか？
冗長化の対象はWebまでか、DB（さくらのクラウドのDBアプライアンス等）までか

上の質問で「本番の止まり時間」だけ先に答えが出れば、開発・検証はサーバ1台のままで足りるかどうかがだいたい決まります。
この質問リストを、そのまま打ち合わせメモにコピーして使ってください。

質問リストの使い方

私は、この質問リストをメモに並べてから、見積もり表を見直しました。
開発・検証の行に載っていたロードバランサと2台目のサーバだけ削れば、本番だけ冗長化する形になります。
削る部分がはっきりすると、顧客への説明も短くなりました。

顧客への説明では、「本番だけロードバランサを足す理由」を、止まってよい時間の答えとセットで話すと伝わりやすかったです。

開発・検証まで本番と同じ構成にする例外

本番と同じ手順のリハーサルが契約で求められる場合

本番と同じロードバランサ構成で、リリース手順を検証で試す必要がある契約や要件があります。
そのときは、検証環境にもL4ロードバランサ＋サーバ2台を検討します。

社内ルールで全環境を同一構成にするとき

社内や顧客のルールで、「すべての環境を同一構成にする」と決まっている案件もあります。
その場合は例外として、開発・検証も本番と同じロードバランサ＋Web2台にそろえます。

それでも、なぜ同一にするのかを一行メモしておくと、あとから見直しやすいです。

あわせて読みたい、ラボの記事

知りたいこと	参考記事
構成全体の地図（台数・DB・冗長）	1台でいい？DBは？さくらのクラウド WordPress構成
本番の冗長化（LB・NFSなど）	冗長化（1）〜（3）
Web/DB 2台の見積もり	Web/DB 2台構成の見積もり
バックアップの線引き	バックアップはどこまで必要？