コンテンツにスキップ 
ワードプレスマルチサイトのパフォーマンス 真のボトルネックを解決することはほとんどありません。共有データベース、共有コード、共有サーバーリソースは依存関係を生み、負荷のピーク時にはネットワーク上のすべてのサイトの速度を低下させます。このアーキテクチャが要求の増加に伴い機能しなくなる理由、それに伴うリスク、そして私がどのように対応しているかを説明します。 スケーラブル 代替案を計画する。.
中心点
- 共有リソース: 1つのサイトがすべてを遅くする
- セキュリティ: 1つのミス、多くの失敗
- スケーリング理論と実践
- ホスティングの制限: CPU、IO、DB
- オルタナティブ: サイトごとの隔離
ピーク時の負荷でマルチサイトが遅くなる理由
監査では、常に次のような状況を見かけます。 単数 トラフィックのピークがあるサイトは、ネットワーク全体に影響を与えます。CPU のピーク、IO 待ち時間、データベースのロックは、孤立して発生するものではなく、ネットワーク内のすべてのプロジェクトに影響を与えます。すべての最適化は、複合的な負荷に合わせて規模を設定する必要があり、実際には 過剰計画 それでもボトルネックが発生します。クリーンなキャッシュレイヤーでさえ、中央リソースが過負荷になるとバッファリングには限界があります。この問題をより深く理解したい方は、典型的な原因を以下でご覧いただけます。 マルチサイトのインフラストラクチャの制限.
建築：共有リソース、共有ボトルネック
マルチサイトは共有します データベース, コードパスやサーバーパフォーマンスは便利だけど、リスクもあるよ。プラグインの更新は、すべてのサイトの動作を同時に変えちゃうし、テーブルのロックはネットワーク上のすべてのクエリに影響するんだ。Cronもタスクを集中処理するから、複数のサイトが同時にジョブをスケジュールすると、長いキューができちゃうことがあるよ。 バックアップ、インデックス、メンテナンスウィンドウは、エラーが常に循環的に影響するため、特別な注意が必要です。この連動は、ガバナンスルールによって緩和することができますが、 カップリング 技術的には存続する。.
実務におけるセキュリティおよび管理上のリスク
グローバルに有効化されたプラグインのセキュリティ上の欠陥は、すべてのサイトを機能不全に陥らせる可能性があり、これはまさに リスクの束 価値。チームは、更新や設定の変更を行うためにスーパー管理者を待つことが多く、修正までの時間や機能追加までの時間が長くなります。すべてのプラグインがマルチサイトに対応しているわけではないため、特別なケースやエッジケース、後でのリグレッションが発生します。テーマの更新はサイト A には有効でも、サイト B では機能しなくなることがあります。このようなアンカー効果は、特に個別性の高いプロジェクトでよく見られます。 責任を明確に分離するには、以下が必要です。 ローラー マルチサイトで頻繁に摩擦を引き起こすプロセス。.
理論と運用におけるスケーリング
紙の上では、共通のコードベースによって節約できる 支出, しかし、運用では、この結合によってメリットが失われてしまいます。ネットワークは負荷を増加させ、中央のデータベースはすべてのピークに対応しなければなりません。同時に、より多くのサイトが影響を受けるため、メンテナンスウィンドウも長くなります。複数のサイトが並行して同様のクエリを実行したり、スケジューラジョブが衝突したりすると、ログに頻繁に競合が発生していることがわかります。これは、理論上の 節約 および実際の遅延。.
ホスティングの制限を正しく評価する
共有ホスティングは、CPU、メモリ、IO、DB接続の制限がすべてのサイトで共通に適用されるため、マルチサイト運用を早期に妨げることがよくあります。 ヒント 厳しく抑制する。マネージドWordPressプラットフォームは分離に役立ちますが、非常に異なるワークロードが集中すると、妥協点となります。50以上のサイトでは、障害を最小限に抑えるため、サイトグループごとに個別のリソースプールまたはクラスタを計画しています。さらに、明確なキャッシュ計画も効果的です。エッジ、フルページ、オブジェクト、トランジェント、それぞれ明確なTTLとウォームアップルーチンを設定します。 フルページレイヤーを賢く利用すれば、 フルページキャッシュの拡張 そして、読書による負担を効果的に軽減します。.
モノリスではなく分散型 – コントロールプレーンアプローチ
私は、コードを読み取り専用アーティファクトとして配布するコントロールプレーンを好みます。各サイトは、Web、PHP-FPM、キャッシュ、DB用に独自のスタックを使用し、それによって真の 断熱 これにより、サイトごとにターゲットを絞ってスケーリングを行い、エラーを特定し、ダウンタイムを制限することができます。デプロイは中央で標準化されて実行されますが、実行時間は分離されたままです。この設定により、ガバナンスと独立性が両立し、連鎖反応が軽減されます。以下の表は、その違いを具体的に示し、私が 分離 業務で優先する。.
| アスペクト | マルチサイト（連合） | サイトごとの分離スタック |
|---|---|---|
| データベースの負荷 | 共通DBに追加され、競合が発生する可能性があります。 | 分離されたデータベース、単一のサイトに制限された競合 |
| エラーの影響 | エラーは多くのサイトに影響を与える可能性があります | エラーはプロジェクトに限定されます |
| スケーリング | CPU/IO の共通ボトルネック | サイトごとに必要に応じてスケーリング |
| キャッシュ戦略 | 多くのサイトに対応するレイヤー、微調整はほとんど不要 | サイトごとの微調整、明確なTTL、パージロジック |
| 安全上のリスク | 攻撃面分割 | 爆風半径が小さい |
| 展開 | 1つのアップデート、多くの効果 | Canary je サイト、段階的な展開 |
| Cron/メンテナンス | 中央キュー、遅延の可能性あり | 個別のキュー、明確な計画立案が可能 |
検索機能、キャッシュ、クロン – 典型的な障害
複数のサイトにわたるグローバル検索は魅力的に聞こえますが、サイトごとに別々のインデックスを作成した方が、ほとんどの場合、より明確で 信頼できる. キャッシュ戦略には、サイトごとに異なるTTL、パージルール、プリウォームプロセスが必要です。そうしないと、更新によってネットワーク全体のコンテンツが不要に無効化されてしまいます。Cronでは、長いタスクが配信に影響を与えないよう、専用のランナーやキューを計画しています。レイヤーの違いを理解すれば、より適切な判断ができるようになります。比較 ページキャッシュとオブジェクトキャッシュ 調整ネジを明確に示しています。.
現実的なコスト計算
私はプロジェクトを、ホスティングを含む、サイトあたりの月額ユーロで計算するのが好きです。, チームタイム リリース、モニタリング、インシデント対応のために。マルチサイトは最初は安そうに見えるけど、ネットワーク障害があるとすぐにお金がかさむよ。30 サイトが 1 時間ダウンすると、サイトグループごとにインスタンスを追加するよりも高くつくんだ。予算は、明確な SLI/SLO と、リリースのペースをコントロールするエラー予算でうまくやりくりしよう。結局、その方が得になるよ。 プランニング 断熱材により、想定される節約額よりも頻繁に発生します。.
マルチサイトが意味のある場合 – 明確な基準
私は、多くの類似した、ミッションクリティカルではないサイトを集中管理する必要があり、かつ 必要条件 技術的に均質性を維持する。例：キャンペーン用のシンプルなマイクロサイト、教育分野での標準ページ、厳格にデザインを統一した出版社。ここでは、プラグインに大きな違いが生じることなく、更新やバックアップを一元的に管理することが重要です。多様性、トラフィック、統合度が高まると、その利点は失われます。その場合は、私は 断熱 標準化されたコントロールプレーンを備えています。.
実践ガイド：美辞麗句を排した意思決定の論理
まず、インベントリから始めます：負荷プロファイル、クエリトップリスト、キャッシュヒット率、エラー率などです。 リリースリズム. その後、リスクの優先順位を付けます。爆発半径はどの程度まで許容できるか、チームはどのくらいのスピードで対応すべきか、どのサイトには特別なルールが必要かなどです。 第 3 段階：アーキテクチャの決定 – 技術的に均質で重要度が低い場合にのみマルチサイトを採用、それ以外の場合は分離されたスタックによるコントロールプレーンを採用。第 4 段階：運用ルール – サイトごとのモニタリング、明確なエスカレーションによるアラート、ロールバックパス、カナリアデプロイメント。第 5 段階：継続的 確認 SLOレポートおよびサイトごとの費用を通じて。.
データベースの現実：オプション、オートロード、インデックス
マルチサイトでは、負荷は多くの場合、 データベース, 一見しただけではわからないけど、各サイトは独自のテーブルを持ってるけど、グローバルメタデータとか、一部のパスは共有されてるんだ。問題なのは、大きな autoload-オプション：サイトごとに自動ロードオプションに保存される量が多すぎると、PHP は すべての人に メモリにメガバイト単位のデータを要求します。これにより、応答時間が長くなり、オブジェクトキャッシュに負荷がかかり、ピーク時にはメモリ圧迫が発生します。そのため、私は定期的に autoload = 'yes' エントリを整理し、レガシーオプションを削除し、大規模な構造をターゲットを絞った遅延読み込みに移行します。.
インデックスに関しては、標準的なインデックスでは不十分な場合が多い。特に ポストメタ そして ユーザメタ 複合指数（例：. (投稿ID、メタキー)）多くのメタクエリが実行されている場合。また term_relationships そして term_taxonomy タクソノミーフィルターが大量のデータに適用されると、競合が発生します。私は、スロークエリログを分析し、クエリプランを確認し、テーマ/プラグインの軽率なループによって発生する N+1 クエリを遮断しています。重要：マルチサイトでは、非効率的なクエリが倍増します。小さなミスがネットワークの問題に拡大します。.
ログインユーザーとEコマースにおけるキャッシュの落とし穴
フルページキャッシュは多くの効果をもたらしますが、次の場合、その効果は失われます。 クッキー ゲーム中である。ログインユーザー、ショッピングカート、セッション、コメントのクッキーは、キャッシュバイパスにつながることが多い。マルチサイトでは、多くのログインセッションがあるサイト1つで、スタック全体に負荷がかかる。共通のPHP/DBレイヤーがウォームアップされ、エッジレイヤーとFPCレイヤーのアクセス頻度が低下する。そのため、私は厳密に計画を立てている。 可変-サイトごとのルール、動的ブロック（ESI/フラグメントキャッシュ）の明確な分離、および admin-ajax.php およびチャッティな REST エンドポイント。チェックアウトページとアカウントページには独自のポリシーが適用され、閲覧ページは最大限キャッシュされ、個別にプリウォームされます。.
ファイル、メディア、ストレージ
マルチサイトでは、アップロードは通常、以下の場所に保存されます。 /uploads/sites/{ID}. これは整然としているように聞こえますが、実際には、サムネイルの生成、画像の最適化、バックアップが同時に実行されると、IOホットスポットが発生します。すべてのサイトが1つのサーバー上に存在する場合、 セントラル ファイルシステム（NFS/共有ボリューム）では、IOキューが互いにブロックし合います。重いメディアジョブをバックグラウンドプロセスに分離し、並列処理を制限し、オブジェクトベースのストレージへのスワップアウトを確認します。一貫性のあるパス、クリーンなリライト、および有効期限ヘッダーに関する明確なルールが重要です。分離されたスタックでは、メディアのピークが残ります。 ローカル – これにより、他のプロジェクトへの影響が大幅に軽減されます。.
可観測性：メトリクス、トレース、負荷プロファイル
測定可能なものなし SLI スケーリングに関する議論は、すべて直感によるものです。私は、TTFB およびサイトごとの合計時間について P50/P95/P99 を測定し、エラー率、キャッシュヒット率、DB レイテンシを追跡しています。 さらに、レイヤーごとの RED/USE メトリクス（レート、エラー、継続時間、利用率、飽和度、エラー）も追加しています。トレースは、どのハンドラ/クエリが優勢であるかを示し、ノイズの多い隣人を特定するのに役立ちます。重要：ダッシュボードとアラート サイトごとに – ネットワークだけじゃない。サイト X が接続プールをいっぱいにしているとか、サイト Y の cron ジョブが CPU を飽和させているとか、そういうこともわかるんだ。サンプリングとログの削減によって、可観測性自体がコストやパフォーマンスの問題になるのを防げるんだ。.
移行と出口戦略：マルチサイトから分離スタックへ
私は常にマルチサイトを 出口. この手順は効果的であることが証明されています。
- インベントリー：ドメイン、ユーザー、プラグイン/テーマ、メディア容量、統合、リダイレクト。.
- コードアーティファクト: 1回ビルドし、読み取り専用で配布。環境ごとに厳密に構成。.
- データエクスポート：サイトごとにコンテンツとユーザーをきれいに抽出し、メディアを同期し、アップロードパスを書き換える。.
- アイデンティティ：ユーザーマッピング、SSO/セッションドメインの明確化、ドメインごとのクッキーの分離。.
- デュアルラン：本番データによるステージング、合成テスト、カナリアトラフィック、レイテンシーおよびエラーの比較。.
- カットオーバー: DNS/エッジの切り替え、パージ/ウォームアップ、監視の厳格化、ロールバックパスの準備。.
- 後処理：リダイレクト、リンク切れチェック、インデックス、キャッシュ、cronワーカー、サイトごとのバックアップ。.
これにより、移行リスクが低減され、チームはコードやプロセスの無秩序な拡大を招くことなく自律性を獲得できます。.
コンプライアンスとクライアント保護
クライアントをネットワーク内で明確に分離することは、技術的な問題だけでなく、 コンプライアンス. データロケーション、保存期間、アクセス分離、バックアップの粒度に注意を払っています。サイト A だけの復元は、サイト B に影響を与えてはいけません。マルチサイトでは、これは難しいことです。ログ、管理者アクセス、シークレットは、サイトごとに分離する必要があります。同じことが以下にも当てはまります。 ワフ– およびレート制限：ネットワークに対する厳しいルールは、無関係な他のサイトにも影響を及ぼす可能性があります。分離されたスタックにより、差別化されたポリシーが可能になり、法的リスクが軽減され、監査が容易になります。.
国際化：マルチサイト対プラグイン
多言語対応には、ドメインやサブサイトが言語ごとに分かれているマルチサイトが魅力的だよね。私は実用的な判断をするよ： 分割された コンテンツ、共通コンポーネント、および類似のワークフローでは、明確なフォールバックを備えた言語プラグインで十分な場合が多くあります。市場、法的文書、統合、チームが大きく異なる場合は、別々のスタック（必ずしもマルチサイトである必要はありません）を採用する方が合理的です。重要なのは、 hreflang, 、一貫性のあるスラグ、言語ごとのキャッシュ、ワークフローを熟知した編集チーム。市場がさまざまな規模で拡大するにつれて、分離化により計画性が向上するというメリットがあります。.
業務プロセスとチームの規模拡大
スケーリングは、技術ではなくプロセスによって失敗することがよくあります。私は リリース・トレイン, 、機能フラグ、明確なメンテナンスウィンドウ。変更は同じ品質ゲートを通過しますが、ロールアウトはサイトごとに制御可能です。 オンコールのルールは、影響範囲（誰が誰に影響を与えるか）に基づいています。キャッシュのパージ、DB のロールバック、Cron のストール、レート制限には、ランブックが必要です。権限は最小限に抑えられています。サイト管理者はコンテンツを管理し、プラットフォームチームはスタックを管理します。これにより、スーパー管理者がボトルネックになることなく、組織を成長させることができます。.
残るもの：決定的な洞察
マルチサイトは便利に感じますが、その連携は パフォーマンス トラフィック、多様性、リスクが増加すると、運用は脆弱になります。私は、小規模で独立したユニットを計画し、それらを意図的に成長させ、エラーを限定的に抑えることを好みます。共通コードは有用ですが、共通ランタイムはめったにありません。明確な SLI/SLO、厳しい制限、そしてよく考えられたキャッシュ計画は、モノリシック構造よりも速度の向上に貢献します。長期的な視点を持つ人は、以下に重点を置きます。 断熱 標準化によって、いわゆる近道ではなく。.
