1台でいい？DBは？さくらのクラウド WordPress構成

2026年6月8日

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

WordPressをさくらのクラウドで動かす話になったとき、いちばん困ったのはスペック表より構成の選び方でした。
1台でいいのか、WebとDBを分けるのか、DBはどこに置くのか。
さらに、冗長化は本番だけでいいのか、開発や検証もそろえるのか。
この3つが同時に出てくると、どれを選べばいいかわからなくて、正直困ったんです。

なので今回は、WordPress のサーバー構成を「どこから決めるか」だけに絞って書きます。
手順の細部はラボの検証記事と公式マニュアルで追いかけてもらえると助かります！

WordPress構成、3つで決める！

規模・可用性・運用の3軸

構成を決める前に、メモ用の3行だけ書いておくと迷いが減ります。

軸	決めること	たとえば
規模	アクセス・DBの伸び方	社内ブログ1本 vs 更新多めのコーポレート
可用性	止まってよい時間	検証なら数時間、本番はメンテの時間帯を決める
運用	誰が触るか	制作会社だけSSHするか、顧客がFTPするか

私は最初、可用性の欄を空欄のままで進めていました。
その結果、あとから「そもそも止まっていいの？」っていう指摘で手戻りすることが多かったです。
さくらのクラウドで WordPress を運用するときは、数字より先にこの3軸を考慮しておくと、話が進むと気づきました。

社内ブログ1本なら規模は小さめ、コーポレート更新なら伸びを見込む、という当てはめもこの3軸でだいたい決まります。

WebとDBの置き場を先に決める

ルータ、ディスク、DBサービス……と考える前に、Webがどこで動いているか、DBがどこにあるかだけ、メモに書きます。
ここを飛ばすと、選択肢だけ増えてしまいます。

制作の現場だと、ステージングは1台で足りるのに、本番だけWebとDBを分けたい、って場面はよく出ます。
環境ごとに違ってよい、と言えるだけで、説明がだいぶ楽になりました。

判断が止まるときの共通パターン

手が止まるとき、だいたい次のどれかです。

止まる理由	先に決めること
全部を本番同等にしたい	どの環境まで冗長にするか
項目だけ増えている	WebとDBを1台か2台か
DBの選択肢が多すぎる	DBを同居かマネージドか

WordPressの構成選びは、1台か2台か・DBの置き方・どの環境まで冗長にするかの3つで進めればOKです。
正解は1つではないので、いま話しているサイトや環境ごとに、順番に決めていけば十分です。

1台構成と2台構成、どっちを選ぶ？

1台完結（パターンA）が向くとき

構成	向く環境・案件
1台（Web＋DB同居）	検証・開発・小規模・コスト最小

パターンAは、サーバ1台にWordPressとDBが同居する形です。
検証、社内の試験サイト、まず動かしてから本番を考える段階に向きます。
障害が起きたとき、WebとDBのどちらが原因か切り分けにくい点は覚えておいてください。
サーバが1台だけなので、構成図で説明しやすいのはメリットです。

WebとDBを分ける（パターンB）とき

構成	向く環境・案件
Web/DB 2台	本番・切り分けしたい案件

パターンBは、Web用サーバとDB用サーバを分ける形です。
テーマ更新でWebだけ再起動したい、という話が出たらパターンBが候補になります。
DBの負荷をWebから切り離したいときも同じです。
金曜夜の更新でWebだけ触りたい、という相談を受けたとき、WebとDBを分ける話と、DBの置き方の話が同時に出てきた覚えがあります。

画面や料金のイメージは、さくらのクラウドで「Web/DB 2台構成」の見積もりをしてみようで確認できます。

検証は1台・本番は2台、で進めるとき

検証はパターンA・本番はパターンB、みたいな切り分けもよく聞きます。

環境	よくある型	理由の例
開発・検証	パターンA（1台）	コストと手数を抑える
本番	パターンB（2台）	更新や障害の切り分け

私の案件でも、検証はパターンAで触り慣れて、本番だけパターンBにする、という進め方が多かったです。
「全部同じ構成にしないとダメ」というわけではありません。
環境名をメモに書いてから、1台か2台かを決めると、スッキリします。

表示速度を最優先にする場合は、VMにKUSANAGIを入れる選択もあります。
数値の比較はさくらのクラウドでKUSANAGI 9を検証！WordPress高速化の効果をベンチマーク比較にまとまっています。
台数の決め方とは別の話なので、必要になったら足すくらいで大丈夫です。

DBはどこに置く？

WebとDBを1台か2台か決めたら、次はDBをどう置くかです。
さくらのクラウドでは、だいたい次の3択になります。

置き方	ざっくりした特徴
Webサーバ同居	1台構成（パターンA）とセット。いちばん手軽
データベースアプライアンス	マニュアル沿いでDBを構築。運用を整理しやすい
オンデマンドデータベース	容量や性能を柔らかく伸ばしたいとき

Webサーバ同居の向き不向き

同居は、1台構成（パターンA）とセットで選ぶことが多いです。
台数が少なく、検証や小規模の本番で「まず動かす」に向きます。
一方、DBのバックアップやバージョン管理まで自分で設計する必要が出てきます。
本番ではDBをWebサーバから分けたいときは、データベースアプライアンスやオンデマンドデータベースを検討する流れが多いです。

データベースアプライアンスを選ぶ目安

DBをWebサーバから切り出したいが、構築手順を整理したいときは、データベースアプライアンスが候補です。
MySQLやMariaDBを、コントロールパネルとマニュアルに沿って立てられます。
WebとDBを分けた2台構成（パターンB）と相性がよいです。
TLSまわりの確認は、データベースアプライアンスにおけるTLS有効化の検証記事も参考になります。

オンデマンドデータベースを選ぶ目安

オンデマンドデータベースは、容量や性能の伸びを柔らかく取りたいときに検討します。
料金や接続の考え方はサービス固有です。
オンデマンドデータベースとは？さくらのクラウドでTLS接続とWordPress設定を検証を読むと、全体像がつかみやすいです。
同居とアプライアンスで迷ったときは、誰がDBのサイズ変更を触るかで決めると、あとでブレにくいです。

冗長化は本番だけでいい？開発・検証も要る？

3つ目の論点は、ロードバランサの設計より前に、「本番だけ冗長でいいのか」をはっきりさせる段階です。
ロードバランサやファイル共有（NFS）の細部は、あとで紹介する冗長化シリーズに任せます。

開発・検証はシンプルで足りることが多い

開発や検証は、多くの場合1台構成（パターンA）で足ります。
ロードバランサを置く、Webを2台にする、といった話は、本番の要件が固まってからで十分なことが多いです。
「検証も本番と同じロードバランサ構成にしないと」となりがちです。
そのまま進めると、コストと運用が一気に増えます。
まず本番で止まってはいけない時間を一行で書きます。
そのうえで、開発はシンプルで足りるか、顧客と確認するのが先です。

本番だけ冗長化する考え方

本番で公開の可用性が求められるとき、冗長化の候補が上がります。
Webを2台にしてロードバランサで振り分ける、コンテンツを同期する、といった話は、冗長化構成を考える（１）ロードバランシングから順に読むと、弱点と改善の順番が頭に入りやすいです。
続きは（2）コンテンツ領域の同期とNFS、（3）レプリケーション・DRBD・クラスタへ。

環境	よくある考え方
開発・検証	1台構成（パターンA）で十分なことが多い。冗長化までは要らないことが多い
本番	可用性要件があるときだけロードバランサなどを検討

開発も本番同等にそろえるのはどんなとき

開発・検証まで本番と同じ冗長構成にするのは、次のようなときだけでよいことが多いです。

そろえる理由の例	注意点
本番リハーサルが必須の契約	コスト・運用が2倍以上になりやすい
リリース手順を本番同等で試す	検証環境の更新頻度も本番並みになる

私は一度、「全部を本番同等にしないと不安」という空気に押されて、開発までロードバランサの案が載った提案を見ました。
顧客と一緒に、本番だけ冗長化する形へ戻しました。
そのとき、いちばん困っていたのは金額より、どの環境まで冗長にするかの線引きでした。
助けになったのは、環境名ごとに一行書いた表でした。

バックアップの線引きは構成とは別の話です。
バックアップはどこまで必要？さくらのクラウドではどうなる？も見ておくと、提案の幅が出ます。

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

台数・DBの置き方・冗長の範囲をざっと決めたあと、気になったところだけ、用途別の記事を読むと進みやすいです。

知りたいこと	読む先
1台と2台の料金・画面	Web/DB 2台構成の見積もり
DBの置き方（実装）	オンデマンドDBの検証、DBアプライアンスのTLS検証
本番の冗長化（技術）	冗長化（1）〜（3）
表示速度（KUSANAGI）	KUSANAGI 9ベンチマーク
バックアップの線引き	バックアップはどこまで必要？