Drupalホスティング：本当に動くサーバー要件

「Drupal は遅い」という評判の出どころは、ほとんどがホスティングです。そしてそれは、ソフトウェアの問題というより購買の判断の問題です。サイトはきちんと作られ、そのあと PHP ファイルが数本あるだけの会社案内サイト向けに値付けされたプランの上で公開されます。結果として、本格的なレンダリングパイプラインを持つコンテンツ管理システムが、自分では変更できないメモリ上限のなかで、自分では制御できないオペコードキャッシュの上を、自前のツールを走らせるシェルも持たないまま動くことになります。

人が頭のなかで比べている相手は WordPress ですが、その比較は的外れです。WordPress がほとんど何の上でもそれなりに動くのは、その市場シェアがホスト側に「ほとんど何の上でもそれなりに動かす」ことを強いたからです。Drupal は、新しい PHP、新しいデータベース、本物のキャッシュバックエンド、コマンドライン、そしてコードベースを「編集するフォルダ」ではなく「ビルド成果物」として扱うデプロイ手順を前提にしています。

Drupal がホストに本当に求めるものは何か。 使っているリリースの下限以上の PHP バージョン、新しめの MySQL、MariaDB または PostgreSQL、実務上は 256MB の PHP メモリ、OPcache、Composer と Drush を動かすためのシェルアクセス、本物の cron 設定、そしてログイン利用者が出てきたら外部のオブジェクトキャッシュです。安価な共用ホスティングは、このうち三つか四つを同時に満たせません。

Drupal がサーバーに実際に求めるもの

公開されている要件は短く、具体的で、誰でも読めます。それなのに、購入前にそれを読む人はほとんどいません。しかもこの要件はバージョンごとに違い、いまはその違いが特に重要です。下限のうち二つが 2026年12月に動くからです。

PHP バージョンの下限は交渉できない

Drupal 11 は PHP 8.3 を最低要件とし、8.3、8.4、8.5 をサポートします。Drupal 10 は 8.1 を要件として 8.4 までをサポートし、Drupal 12 は下限をさらに PHP 8.5 へ引き上げます。これらの数字は Drupal 自身の PHP 要件ドキュメント に基づいており、信用に値する一覧はそれだけです。

これは見た目より重い話です。PHP のブランチそのものに期限があるからです。php.net のサポート対象バージョン一覧 によれば、PHP 8.2 のセキュリティサポート終了は 2026年12月31日、8.3 は 2027年12月31日まで、8.4 は 2028年12月31日までです。PHP 8.1 はすでに過ぎています。「PHP 8.1 と 8.2 が使えます」と宣伝するホストは、いますでにパッチの当たらない、あるいは数か月以内にそうなるスタックを売っていることになります。

二つの日付は重なります。Drupal 10 は 2026年12月9日にサポートを終了し、コアのリリーススケジュール によれば Drupal 12 は同じ週に出ます。ホストが PHP 8.3 以降を提供できないなら、その後はサポートされた Drupal を動かせません。まだ 10 を使っているなら、Drupal 移行の費用、選択肢、期限 がその意味するところを扱っています。

データベースエンジンと本当の最低要件

データベースサーバー要件 によれば、Drupal 11 は MariaDB 10.6 以降、MySQL 8.0 以降、PostgreSQL 16 以降、または SQLite 3.45 以降を求めます。Drupal 10 はもっと緩く、MariaDB 10.3.7、MySQL 5.7.8、PostgreSQL 12、SQLite 3.26 です。アップグレードが、依頼主の想定になかったデータベースの入れ替えまで引き起こすのは、まさにこのためです。

見落とされがちな点が二つあります。MySQL と MariaDB では、ストレージエンジンが InnoDB でなければなりません。Drupal がトランザクションと行レベルロックに依存しているからです。PostgreSQL では、インストール前に Drupal 用のデータベース上で pg_trgm 拡張を作成しておく必要があり、CREATE EXTENSION を実行させてくれないマネージドデータベースサービスは使えません。

SQLite は正式にサポートされており、ローカル開発には十分です。ただし編集者が何人も同時に保存し始めると、本番の答えにはなりません。先に頭打ちになるのは書き込みの並行性だからです。

メモリ、拡張モジュール、ウェブサーバー

Drupal のドキュメント上の最低値は PHP メモリ 64MB で、それを下回ると警告が出ます。同じページには、本番では 128MB か 256MB が一般的で、メディアの多い環境ではさらに必要だとも書かれています。実務では 256MB を作業上の数字と考え、コマンドライン向けにはさらに引き上げる前提でいてください。メモリを食うのはページ配信ではなく、Composer と大きな移行処理だからです。

必要な拡張の一覧は平凡ですが、確認する価値はあります。データベースドライバつきの PDO、XML、JSON、mbstring、cURL、外向き HTTPS のための OpenSSL、そして画像派生物のための GD か ImageMagick です。Drupal 12 はパスワードハッシュに Argon2 を加えます。とても古い PHP ビルドに欠けているものが、これでもう一つ増えます。

ウェブサーバーについては、Drupal は Apache 2.4.7 以降と Nginx 1.1 以降をサポートし、Drupal 11.0.0 以降は Microsoft IIS をサポートしません。Apache ではクリーン URL のために mod_rewrite が必要で、同梱の .htaccess を効かせるために AllowOverride All も必要です。最後の点はよく人を捕まえます。Drupal の保護ルールの一部は .htaccess にしか存在しないので、Nginx で運用するならサーバー設定の側に手作業で同じものを再現しなければなりません。手順としては定型ですが、定型的に飛ばされてもいます。サーバーセキュリティ監査 で最初に見るのがこの点です。

なぜ共用ホスティングでは Drupal が回らないのか

共用ホスティングが悪いホスティングなのではありません。別の形をしたアプリケーション向けに最適化されているだけです。そして Drupal は、その制約に対して予測どおりの四か所で壊れます。

シェルがなければ Composer も Drush もない

いまの Drupal は Composer プロジェクトです。コア、コントリビュートモジュール、それらの PHP 依存関係はすべて Composer が解決します。そして一度 Composer がモジュールを管理し始めたら、コアも Composer が管理しなければなりません。Composer と手作業のファイル更新を混ぜることが、そもそも更新できないサイトができあがる道筋です。

ファイルマネージャつきのコントロールパネルにそれはできません。FTP クライアントにもできません。SSH がなければ Drush も失われます。キャッシュの再構築、設定のインポート、データベース更新、利用者のパスワードリセットは、実際にはすべて Drush で行うものです。drush cr を実行できないサイトでは、復旧の一手ごとにサポートチケットが必要になります。

見えない、まして変えられない上限

共用アカウントでは memory_limit を他人が決めます。たいていは 128MB、ときにはそれ以下で、512MB を必要とする一度きりの移行のために引き上げる手段はありません。

より大きな問題は OPcache です。OPcache はコンパイル済みのスクリプトバイトコードを共有メモリに置き、PHP がリクエストのたびにファイルを解析し直さずに済むようにします。共用ホストでは、そのメモリ領域が何百というアカウントで共有されます。Drupal は PHP ファイルを何千も持つため、奪い合う領域のなかでは重い店子であり、追い出されます。症状は、誰かが訪れた直後の一分だけ速く、一時間後にはまた遅いサイトです。

そして、そもそも存在しないものがあります。Redis なし、Memcached なし、PHP プロセスマネージャの制御なし、長時間動くキューワーカーを走らせる手段もなし、です。

実際には走らない cron

Drupal の自動 cron モジュールは、既定で三時間ごとに、サイトを訪れた利用者によって起動されます。混雑したサイトでは、検索インデックスの更新の代金を訪問者がページ読み込みで時々払う、という意味になります。閑散としたサイトでは、cron が事実上走らないという意味になります。検索インデックスは古びて、ログテーブルは切り詰められず、公開されたセキュリティ更新も確認されません。

ドキュメントは代わりに外部から cron を起動することを勧めています。そのほうが必ず定刻に走り、消費する資源も少ないからです。それには本物の crontab エントリが必要で、いちばん安いプランはそれを提供しません。

キャッシュの各層と、訪問者が当たるのはどれか

Drupal のキャッシュは多くの人が思うより層が多く、しかもそれらは互いの代わりではありません。積み重なっていて、上の層が取りこぼしたものを下の層が受け止めます。

OPcache は Drupal より下にある

OPcache は Drupal の機能ではありません。インタプリタの階層でコンパイル済み PHP バイトコードをキャッシュするので、Drupal 側のキャッシュが当たるかどうかに関わらず、すべてのリクエストに効きます。ここを外すと、その上にある何をもってしても取り返せません。すべてのリクエストが、ルーターにたどり着く前にフレームワークを再コンパイルする代金を払うからです。共有メモリは余裕をもって確保し、本番ではタイムスタンプ検証を無効にしてください。本番でファイル群が変わるのはデプロイのときだけです。

Internal Page Cache と Dynamic Page Cache

Internal Page Cache はコアのモジュールで、既定で有効になっており、匿名利用者だけに提供されます。匿名の訪問者は全員が同じページを見るという前提のもと、最初のリクエストで応答全体を保存し、それを使い回します。パーソナライズのないマーケティングサイトでは、仕事のほとんどをこの層がこなします。

Dynamic Page Cache もコアで、やはり既定で有効で、こちらは認証済み利用者を含む誰に対してもキャッシュします。仕組みは、レンダリングシステムがページのうち本当に個人的な部分をプレースホルダに置き換え、その周りをすべてキャッシュするというものです。ログイン状態の Drupal のページでも大部分がキャッシュされうるのはこのためで、実際に動的なのはユーザーメニューといくつかのブロックだけです。

BigPipe とレンダーキャッシュ

その両方の下にあるのがレンダーキャッシュで、個々のブロック、フィールド、ビューの結果、エンティティの描画結果をキャッシュします。ページキャッシュを外したページも、たいていはデータベースから組み立て直されるのではなく、レンダーキャッシュのヒットを寄せ集めて作られます。

残りを引き受けるのが BigPipe です。Drupal 8.1 からコアに入り、8.3 で安定版となり、8.5 から標準インストールプロファイルに含まれています。すべてのプレースホルダが解決するのを待つ代わりに、キャッシュ可能なページをすぐに送り出し、パーソナライズされた断片をあとから流し込みます。設定は不要で、匿名利用者よりも認証済み利用者にずっと効きます。

つまり、きちんと構成されたサイトの匿名訪問者は Internal Page Cache か、その前段の CDN に当たり、ここまでの大半に触れません。ログイン中の編集者は毎回のリクエストで Dynamic Page Cache、レンダーキャッシュ、BigPipe に当たります。認証済みのトラフィックの単価がずっと高いのはそのためです。

外部オブジェクトキャッシュ

上のすべての層は、エントリをどこかに保存する必要があります。既定ではそれがデータベースのキャッシュテーブルで、つまりキャッシュの読み出しが同じサーバー上でコンテンツのクエリと競合します。

Redis モジュール は、キャッシュ、ロック、フラッド、キューの各バックエンドを Redis または Valkey のような互換ストアへ移します。使えるのは PhpRedis 拡張、Relay 拡張、あるいは純 PHP の Predis ライブラリです。Memcached も同等の選択肢です。小さな匿名サイトでは、これで変わるものはわずかです。ログイン利用者のいるサイトでは、たいていこれが手に入るなかで最大の改善になります。もっとも騒がしい書き込み負荷をデータベースから外し、ロックを安くするからです。

Drupal の前に置くリバースプロキシと CDN

Varnish や Nginx のようなリバースプロキシ、あるいは CDN は、PHP がまったく関与しないうちにリクエストへ答えます。匿名トラフィックにとって、これは一桁ミリ秒で配信するか、数百ミリ秒かけるかの違いです。同時に、人がいちばん怖がる層でもあります。ニュースサイトやショップで古い内容が残ることは、目に見える失敗だからです。

CDN を安全にするのはキャッシュタグ

Drupal の答えがキャッシュタグです。キャッシュタグはデータの依存関係を表し、node:5、user:3、node_list のような文字列で書かれます。キャッシュされた項目はどのタグに依存しているかを記録するので、ノード 5 を編集すれば、それを参照していたキャッシュ済みの断片、ページ、ビューが、どこにあっても無効化されます。

大事なのは、Drupal がそのタグを外へ知らせられることです。コントリビュートモジュールが Fastly 向けには Surrogate-Key ヘッダー、Cloudflare 向けには Cache-Tag ヘッダーとして出力し、Drupal が指示したときに CDN がタグ単位でパージします。これによって CDN は、時間頼みの賭けからイベント駆動のキャッシュへ変わります。編集が数秒のうちに該当する URL だけをパージするので、長い有効期間を設定できるのです。

ヘッダーの予算には注意してください。Cloudflare の キャッシュタグによるパージのドキュメント は、Cache-Tag ヘッダーの合計をフィールド名を除いて 16KB、おおよそ 1,000 個のユニークタグに制限しており、API 呼び出しでは 1 タグあたり最大 1,024 文字、ダッシュボードからのパージは 1 回 100 タグまでです。多数のエンティティを一覧する Drupal のビューは、それをはるかに超えるタグを生成しかねません。すべてを並べるページは、モジュール側でタグを間引くかハッシュ化する設定にしない限り、黙ってヘッダーからあふれます。

Drupal ホスティングの選び方：四つの階層を正直に

現実的な選択肢は四つで、どれが正しいかは、認証済みトラフィックがあるかどうかと、サーバーを運用する人がいるかどうかで決まります。以下の価格帯は英国の顧客が実際に支払っている水準で、付加価値税を含まず、特定のベンダーの見積もりではなく目安です。

共用ホスティング

本番で Drupal を動かす人には向きません。シェルアクセス、メモリ、オペコードキャッシュ、オブジェクトキャッシュ、cron のすべてで同時に落第します。予算が本当にここで頭打ちなら、同じくらいの価格の小さな非マネージドインスタンスのほうが、お金の使い道として優れています。

非マネージド VPS またはクラウドインスタンス

月額でおおよそ GBP 20 から GBP 120 出せば root 権限つきのマシンが手に入り、これが Drupal サイトの大多数に合います。PHP のバージョンを選び、OPcache を適切に確保し、Redis を入れ、crontab を設定し、Nginx をきちんと構成できます。手に入らないのは、それをやってくれる人、パッチを当てる人、監視する人、そして午前二時に復旧してくれる人です。この階層が正解になるのは開発者か制作会社と保守契約がある場合で、本当の費用はインスタンスではなくその契約のほうです。

マネージド Drupal 専門プラットフォーム

マネージド Drupal ホスティングは、小規模サイトなら月額 GBP 40 前後から始まり、トラフィック、環境の数、サポート等級に応じて急速に上がります。買っているのは、最初から正しく型の決まったスタックと、Git ベースのデプロイ、ステージング環境、バックアップ、そして Drupal を理解した人が電話に出ることです。ほかに誰もいないのが代案なら価値がありますが、月に 4,000 訪問の会社案内サイトにプラットフォーム価格を払うなら割に合いません。

完全なカスタム基盤

データベースを分離し、キャッシュ専用ノードを置き、ロードバランサの背後にアプリケーションサーバーを並べ、ファイルはオブジェクトストレージへ。これが筋の通る話になるのは月額でおおよそ GBP 400 を超えたあたりからで、しかも認証済みトラフィック、外部連携、コンプライアンス要件のせいでマネージド階層が窮屈になった場合に限られます。もっとも能力が高く、もっとも要求も厳しい階層です。パッチ適用も監視も災害復旧も、すべて自分のものになるからです。アプリケーション側でその複雑さがどこから来るのかは、Drupal ウェブ開発ガイド が扱っています。

デプロイ：サーバー上でファイルを編集してはいけない

Composer が依存関係の木全体を解決する以上、サーバー上のコードベースは出力であって作業場ではありません。モジュールのファイルをその場で書き換えれば、次の composer update が上書きしますし、本番のコードが Git のどこにも一致しなくなります。

まともなリリース手順では、成果物を別の場所で作ります。コミット済みの composer.lock から CI で composer install を走らせれば、ビルドは再現可能になり、本番ホストには Composer も、依存解決のための PHP メモリも、vendor への書き込み権限も要らなくなります。できたものを配置し、データベース更新を走らせ、設定をインポートし、キャッシュを再構築します。切り戻しは、ひとつ前の成果物を指すだけです。

これはホスティングの問いにも静かに決着をつけます。FTP でファイルを編集する前提のホストは、仕様書に何が書いてあろうと、Drupal の保守の仕方と相容れません。

設定同期はどこに収まるか

Drupal は有効な設定をデータベースに持ち、それを YAML ファイルへ書き出します。コンテンツタイプ、フィールド、ビュー、各種設定が環境間を移動するのは、この仕組みによってです。設定管理のドキュメント は、移行元と移行先でサイト UUID が一致していなければならないと説明しています。最初のインポートが失敗する理由は、たいていこれです。

実務的に言えば、設定はコードだということです。ほかのものと一緒にコミットされ、レビューされ、デプロイされます。インポートの手順は、あとから管理画面でクリックするのではなく、リリースの一部として走ります。ホスティングもそれを支えられなければなりません。インポートを実行する場所と、失敗したインポートを本番に中途半端に当てたまま残さず切り戻せる環境が要ります。

ファイル、メディア、バックアップ

Drupal にはファイルシステムが二つあり、その違いが効いてきます。公開のほうはウェブルート配下にあり、ウェブサーバーが直接配信します。非公開のほうはウェブルートの外にあり、非公開ファイルへの要求はすべて Drupal を通って、アクセス権を確認されます。

したがって非公開ファイルは公開ファイルよりはるかに高くつきます。ダウンロードのたびに PHP が起動するからです。大きな非公開文書を配るサイトには、静的ファイルサーバーなら要らない余力が必要になります。

メディアをオブジェクトストレージへ逃がす

ファイルがアプリケーションサーバーに住み着くと、水平方向の拡張や再構築が苦しくなり、バックアップのたびにメディアライブラリ全体を運ぶことになります。公開ファイルシステムを S3 互換のオブジェクトストレージへ移せば両者が分かれ、CDN がメディアを直接配信できるようになり、アプリケーションサーバーは本当に使い捨てにできます。

バックアップに証明できないものを復元テストが証明する

バックアップが証明するのは、ファイルが存在することだけです。復元テストは、そのファイルが欠けていないこと、データベースとファイルが同じ時点のものであること、認証情報がいまも通ること、そしてどれだけ時間がかかるかを証明します。これは四つの別々の失敗のしかたであり、コントロールパネルの緑のチェックマークからは、どれも見えません。

少なくとも年に二回、実際に時計で測り、その数字を書き留めてください。復元に六時間かかり、許容できるのが一時間なら、問題はバックアップではなく設計です。復旧時間はホスティングの要件であり、障害対応のなかではなく仕様書のなかにあるべきものです。

Drupal ホストのサイジングを正しく行う

ページビューは単位として間違っています。CDN の後ろで月 200,000 の匿名ページビューを受けるサイトが小さなインスタンスで快適に動く一方、月 8,000 ページビューのサイトでも、その大半がログイン状態なら苦しくなりえます。

本当の要因は認証済みトラフィック

匿名のリクエストは、PHP に触れずにページキャッシュや CDN が答えられます。認証済みのリクエストはそうはいきません。その一つひとつがレンダリングパイプラインを走らせ、エンティティごとにアクセス権を確認し、プレースホルダを解決し、セッションを書き込みます。実務上の問いは何回訪問されるかではなく、同時にログインしている利用者が何人いて、その人たちが何を見てよいことになっているか、です。

編集者は極端な例です。コンテンツ管理画面は Drupal のなかでもっとも重いページに属し、しかも定義上キャッシュできません。編集者が十二人同時に作業するサイトには、公開トラフィックからは想像もつかない本物の同時実行要件があります。

ビュー、タクソノミー、キュー処理

認証済みトラフィックのほかにも、確実な費用源があります。フィルタとリレーションシップの多い大きなビューは高価な結合を生みます。深いタクソノミーの木は、描画のたびに用語の階層をたどります。そして検索インデックス、フィードの取り込み、メディア派生物の生成といった cron やキューの処理です。

キューワーカーは、避けられるならウェブサーバーの資源を訪問者と分け合うべきではありません。規模の大きいサイトでは別のプロセスかインスタンスに置き、取り込みの滞留がフロント側を遅くしないようにします。これは購入時に下す設計の判断であり、マネージド階層が合わなくなってカスタム基盤が意味を持ち始める、その分かれ目でもあります。

判断を正しく下すために

型は決まっています。ホスティングは小さすぎるのではなく、形が違うのです。シェルがなく、オブジェクトキャッシュがなく、オペコードキャッシュは他人のもので、PHP のバージョンはサポートから落ちかけている。同じサイトを同じくらいの価格で正しく仕様化されたインスタンスへ移すほうが、たいていはどれだけフロントエンドを最適化するよりも効きます。

Mecanik は ウェブサイト開発 の一環として Drupal の基盤を設計し、構築し、保守しています。速度ではなく露出のほうが心配なら、サーバーセキュリティ監査 を通して既存のスタックを見直します。プラットフォームではなく人が必要なら、Drupal 開発者の採用 が何を見るべきかを扱っています。

よくある質問

Drupal 11 の最低サーバー要件は何ですか？ PHP 8.3 以降、データベースは MariaDB 10.6、MySQL 8.0、PostgreSQL 16、SQLite 3.45 のいずれかです。ウェブサーバー側は Apache 2.4.7 または Nginx 1.1 以降で、Microsoft IIS は Drupal 11.0.0 からサポート対象外です。Drupal は PHP メモリ 64MB を下回ると警告しますが、本番で現実的な数字は 256MB です。

共用ホスティングで Drupal を動かせますか？ インストールはできますし、ページも返せます。ただし共用ホスティングはたいてい三つか四つの要件を同時に満たせません。Composer や Drush のためのシェルがなく、PHP のメモリ上限を上げられず、Redis も Memcached もなく、cron は誰かがページを開いたときにしか動きません。Drupal が遅いという評判は、この条件から生まれています。

Drupal のホスティング費用はどのくらいが妥当ですか？ きちんと構成された非マネージドインスタンス上の小規模な Drupal サイトなら、運用してもらう費用を除いて月額 GBP 20 から GBP 120 あたりが一般的です。マネージド Drupal プラットフォームは GBP 40 前後から始まり、トラフィックと環境の数に応じて数百ポンドまで上がります。カスタム基盤が筋の通る話になるのは、おおよそ GBP 400 を超えてからです。もっとも安い階層が、もっとも安く済む結果になることはめったにありません。

Drupal に Redis は必要ですか？ 小さな匿名サイトなら不要で、Internal Page Cache とデータベースで十分です。ログイン利用者、編集者、会員エリアができたら、Redis や Memcached のような外部オブジェクトキャッシュがキャッシュの読み出し、ロック、キューをデータベースから外します。かけた費用に対して得られる改善としては、たいていこれが最大です。

動的な Drupal サイトの前に CDN を置いても安全ですか？ 時間ではなくキャッシュタグで無効化するなら安全です。Drupal は応答が依存するすべてについて node:5 のようなタグを記録し、モジュールがそれを Cache-Tag や Surrogate-Key ヘッダーへ変換するので、CDN は編集の影響を受けたページだけをパージします。タグによる無効化がなければ、古いページを見せるか、キャッシュがまったく効かないかの二択になります。