開発用途でWordPress向けのマネージドサーバーを検討する際、表面的な機能一覧を見るだけでは、実際の使い勝手や性能までは分かりにくいものです。PHPのスレッド割り当てが同時リクエスト処理にどのような影響を与えるのか、複数のキャッシュレイヤーがどのように連携してデータベース負荷を軽減しているのか、そしてコンテナ化が実運用環境において本当に問題の発生を防げているのか、といった点を理解することが重要になります。
この記事では、KinstaのPHPスレッド管理、マルチレイヤーキャッシュ、隔離コンテナの技術的なアーキテクチャについてご説明します。
PHPスレッドの概要とWordPressパフォーマンスにおける重要性
PHPのスレッドは、キャッシュされていないリクエストを処理します。各スレッドは一度に1つのリクエストを処理するため、「サイトで使用可能なスレッド数＝サイトが同時に処理できる訪問者数」ということになります。
サイト訪問者がキャッシュされていないページを読み込んだり、フォームを送信したり、商品を買い物カゴに入れたりすると、以下の処理が行われます。
- ウェブサーバーがリクエストを受け取り、PHP-FPMに渡す
- PHPがリクエストを使用可能なスレッドに割り当てる
- スレッドがPHPのコードを実行し、データベースのデータを取得して、 動的な出力を生成
- 完了後、スレッドが再び使用可能に
このように、キャッシュされていないリクエストはPHPのスレッドを1つ使用するため、処理の速さはPHPやMySQLの応答時間に影響されます。こうした点は、実は意外と知られていません。
一方、キャッシュされたリクエストはこの一連の処理をすべてスキップし、PHPには一切到達しません。そのため、キャッシュのHIT率は、実際に必要となるスレッド数を左右する最も大きな要因となります。
WooCommerceサイト、会員制サイト、REST APIトラフィック、ヘッドレス構成などは、はるかに頻繁にキャッシュをバイパスするため、一般にスレッドを素早く消費します。
たとえば、APIの応答に平均250ミリ秒かかるとすると、1つのスレッドは1秒間に4回処理できます。スレッドが8本あれば、単純計算で毎秒32リクエストが上限になります。ただし、実際の環境では処理時間にばらつきがあるため、常にこの数値が出るわけではありません。
同時トラフィックによるPHPスレッドの消費
スレッド数が特に重要になるのは、複数のリクエストが同時に発生するタイミングです。たとえば、サイトに4つのスレッドがあり、同時に6件のキャッシュされていないリクエストが届いた場合は、以下のようになります。
- 4件のリクエストはすぐに処理を開始
- 2件のリクエストは空いているスレッドを待つ
新しいトラフィックが、スレッドが空くスピードを上回って到着すると、リクエストは処理待ちとなり、バックログが徐々に増えていきます。
遅いデータベースクエリは、この状況をさらに悪化させます。たとえば、1回の実行に10秒かかるデータベースクエリがある場合、その間は1つのスレッドが占有されたままになります。このような遅いクエリをそれぞれ発生させるリクエストが同時に3件届くと、3つのスレッドが合計30秒間にわたって使用されることに。その間、残りのスレッドだけで、他のすべてのトラフィックを処理しなければなりません。
WooCommerceフィルター、アカウントページ、または決済ワークフローを追加すれば、スレッドへの圧力はさらに高まります。
シンプルなサイトであれば、PHPスレッドは4つで十分ですが、ECサイトの場合は、バイパスキャッシュの比率が高いため、少なくとも6つ以上は必要になります。
スレッド数と実行時間の関係
サイトで必要になるスレッド数を見積もるには、「1秒あたりのキャッシュされていないリクエスト数 × 平均実行時間」という考え方が参考になります。
この考え方に当てはめると、1秒あたり10件のキャッシュされていないリクエストが発生し、平均実行時間が0.5秒のサイトでは、リクエストをキューに溜めずに処理するために、およそ5つのスレッドが必要になります。
このことから、単純にスレッド数を増やしただけでは、必ずしもパフォーマンスが向上するとは限らないことが分かります。たとえば、遅いデータベースクエリの影響で平均実行時間が0.5秒から2秒に伸びた場合、必要となるスレッド数は4倍に増えてしまいます。
これを解決するには、コード実行を高速化する必要があります。クエリを最適化し、外部API呼び出しを減らし、適切なオブジェクトキャッシュを実装することで、実行時間を劇的に短縮し、トラフィックを処理するために必要なスレッドを減らすことができます。
Kinstaプラン全体でのPHPスレッドの割り当て
Kinstaでは、各サイトに割り当てられるCPUやRAMのリソース量に基づいて、PHPスレッド数を設定しています。すべてのKinstaサイトは個別のLXDコンテナ上で動作しているため、リソースはサイトごとに分離されています。
プラン別の一般的な傾向
- 小規模サイト向けプラン：1スレッドあたり256MB・2〜4スレッドを割り当て（キャッシュのヒット率が高いブログや静的コンテンツ中心のサイトに最適）
- 中規模サイト向けプラン：1スレッドあたり256MBで・6〜8スレッドを割り当て（一部のWeb制作会社向けプランでは1スレッドあたり512MBに増量）
- 上位プラン：1スレッドあたり512MB・10〜16スレッドを割り当て（トラフィックが多いサイトや、処理が複雑なサイト向け）
- マルチサイト：プランに応じて8〜14スレッドを割り当て
スレッドの割り当ては、専用コントロールパネル『MyKinsta』で調整可能です。ログイン後、「WordPressサイト」＞（サイト名）＞「情報」に移動し、「PHPパフォーマンス」セクションの「変更する」をクリックします。サイトのトラフィックパターンに基づいてメモリプールまたはスレッド数を増やすことができます。
この柔軟性により、実際のサイトの作業負荷に合わせてPHPを調整することができます。
サイトのPHPスレッド要件の見積もり
先に触れたとおり、キャッシュをバイパスするトラフィック量により、適切なスレッドの割り当ては異なります。
- 静的コンテンツサイト：リクエストの大半がキャッシュで処理されるため、通常2〜4スレッドで十分
- WooCommerceストア：商品点数や検索・絞り込みの複雑さ、購入処理の負荷などを考慮し、8〜12スレッド程度
- APIを多用するアプリやヘッドレスアプリ：実行時間に基づく（例：0.25秒のリクエスト＝1スレッドあたり毎秒約4）
- 会員制サイトやLMSプラットフォーム：ログイン中のユーザーはキャッシュを通らずに処理されるため、挙動としてはECサイトと同じ
MyKinstaの分析画面では、現在のスレッドの使用パターンを特定するのに役立ちます。
トラフィックの多い時間帯にリクエストキューやタイムアウトエラーが発生する場合は、スレッドの割り当てを調整する必要があります。
PHPのスレッド上限を超えると何が起こるか
スレッドの枯渇は、ある程度決まったパターンで発生します。
リクエスト専用のキューがあるわけではなく、サイトに割り当てられたPHPスレッド数が、同時に処理できるキャッシュされていないリクエスト数の上限になります。リクエストが到達した時点で空いているスレッドがなければ、そのリクエストはスレッドが解放されるのを待つことになりますが、その待ち時間が長くなりすぎると、502や503といったBad Gateway／タイムアウトエラーが発生します。
一般的な症状には、以下のようなものがあります。
-
すべてのスレッドが処理中になると、リクエストはNGINXやPHP-FPM内で待機状態に
-
ローディングが終わらない、決済の各ステップが遅い、AJAX通信が途中で止まるといった遅延をエンドユーザーが体感
-
待機できる上限に達すると、502や504などのエラーが表示されるようになる
-
遅い処理が完了し、キャッシュが再生成されると、通常は30〜120秒ほどで自動的に回復
原因として最も多いのは、遅いデータベースクエリです。遅いデータベースクエリは、PHPのスレッドによって処理されるのに時間がかかり、一般的にサイトのパフォーマンスを低下させます。
外部API呼び出しも同様の問題を引き起こします。支払いゲートウェイ、税金計算サービス、配送APIは、決済中に頻繁にスレッドをブロックします。
スレッドの枯渇を診断するには、複数のデータソースをあわせて確認することが重要です。KinstaのAPMツールを使えば、処理に時間のかかっているリクエストをトレースし、どこにボトルネックがあるのかを特定できます。また、スロークエリログを確認することで、データベースのパフォーマンスに問題がないかを把握できます。さらに、Nginxのキューメトリクスからはリクエストがどのように滞留しているかを確認でき、キャッシュのHIT/MISS比率を見ることで、キャッシュが適切に機能しているかどうかを判断できます。
解決策は、以下の処理の実行時間を最適化することです。
- 遅いデータベースクエリ：インデックスの作成、クエリの最適化、クエリ数の削減
- 重いプラグイン：軽いものに置き換えることができるか検討
- Cronタスク：クセスの少ない時間帯（オフピーク）に実行するよう設定
- 外部API呼び出し：キャッシュの活用やバックグラウンド処理、サーキットブレーカーの導入が有効
スレッド数を増やす前に、まずはこれらの最適化を行うことが重要です。スレッド数の増加は、平均実行時間を十分にコントロールできるようになってから検討しましょう。
Kinstaのマルチレイヤーキャッシュ
キャッシュは、リクエストがPHPに到達する頻度を減らす役割を果たします。Kinstaでは、以下の3つのキャッシュレイヤーを採用しています。
- エッジキャッシュ：訪問者に近いグローバルロケーションから静的コンテンツを提供
- Redisのオブジェクトキャッシュ：クエリの結果をメモリに保存することでデータベースの負荷を軽減
- Kinsta CDN：分散されたエッジロケーションから静的アセットを配信
これらのレイヤーが連携し、PHPスレッドとデータベースに到達するリクエストを最小限に抑えます。
Cloudflareによるエッジキャッシュ
Cloudflareのグローバルエッジネットワークは、キャッシュキーに基づいてキャッシュされたHTMLページを提供します。
- URLとクエリパラメータ
- 特定のCookie
- 認証状態
- WooCommerceカート/セッションCookie
これにより、パーソナライズされたコンテンツが誤って別のユーザーに配信されるのを防ぐことができます。
また、キャッシュのバイパスルールによって、WordPress管理画面やWooCommerceの決済ページなど、常に最新の状態を保つ必要がある動的コンテンツはキャッシュされません。
この仕組みによるパフォーマンス上の違いは大きく、エッジキャッシュにヒットしたリクエストはPHPスレッドを完全に通過せず、WordPressのインストール自体に到達しません。たとえば、リクエストの80％がエッジキャッシュで処理されるサイトでは、残りの20％のトラフィック分だけPHPスレッドが必要になります。
Redisによるオブジェクトキャッシュ
Kinstaでは、アドオンとしてRedisを提供しており、RedisがWordPressのオブジェクトキャッシュシステムで確実に動作するようにします。別途プラグインは不要です。
Redisはデータベースのクエリ結果をメモリ上に保持するため、同じクエリを何度も実行する必要がなくなります。ただし、Redisは適切に設計・構築されたサイトのパフォーマンスをさらに高めるためのものであり、負荷の大きいクエリやインデックスが設定されていないテーブルを補うための応急的な対策ではありません。
Redisは以下のような状況で役立ちます。
- 多くのユーザーが同じデータ（投稿、商品、カテゴリ）を読み込む場合
- WooCommerceストアがカテゴリ検索や商品チェックを行う場合
- APIが同一のクエリを繰り返す場合
ただし、Redisは本質的に遅いPHPロジック、ブロックされた外部API呼び出し、最適化されていないループを高速化することはできません。
Kinsta CDNによるグローバルアセット配信
KinstaのCDNは、260以上のグローバルロケーションから静的アセットを配信します。このアプローチにより、海外からの訪問者の待ち時間が短縮され、オリジンサーバーからの静的アセットの読み込みがなくなります。またブラウザがWebPをサポートしている場合、自動的に画像をWebPに変換します。
キャッシュコントロールヘッダーは、CDNが各アセットをどのくらいの期間キャッシュするかを決定します。更新頻度に応じて、アセットの種類ごとに適切なキャッシュ期間を設定することが可能です。たとえば、コアとなるCSSファイルは、長めのキャッシュ期間を設定できます。Kinsta CDNとエッジキャッシュのキャッシュパージは、MyKinstaからそれぞれ個別に、またはまとめて実行できます。
Kinsta CDNとエッジキャッシュを組み合わせることで、HTMLページや動的コンテンツ、静的アセットをそれぞれ適切なレイヤーで処理できます。その結果、ほとんどのリクエストがオリジンサーバーに到達せず、PHPスレッドを消費しない構成を実現できます。
隔離コンテナで「うるさい隣人」問題を解決
共用サーバー環境では、1つのサイトが多くのリソースを消費すると、しばしば問題が発生します。Kinstaでは、LXD隔離コンテナ技術を採用し、以下のリソースを備えた独自のコンテナで各サイトを実行します。
- 専用CPU
- 専用RAM
- 分離されたファイルシステム
- 独立したソフトウェアスタック
これにより、リソースを他のサイトと共有することなく、1つのコンテナで発生した問題が他のコンテナに影響を与えることはありません。
最適化されたコンピュート基盤上でコンテナを稼働させることで、急なトラフィック増加時でも、パフォーマンスの変動を抑えることができます。
サイトの要件に応じたスケーリング
現在利用中のプランのリソース上限を常に超える場合は、コンテナ内で垂直方向にスケーリングすることができます。
たとえば、PHPパフォーマンスアドオンでは、より多くの計算能力を必要とするサイト向けに、スレッドとメモリを追加することが可能です。
また、上位プランへ移行することで、コンテナに割り当てられるリソースやスレッド数、1スレッドあたりのメモリ容量を増やすことができます。これは、現在のプランではリソースが不足してきたサイトに適した選択肢です。
重要なのは、最適化が必要なのか、それともリソース容量の追加が必要なのかを正しく見極めることです。スレッドが飽和しているにもかかわらずCPU使用率が低い場合、原因はスレッド数ではなく、遅いデータベースクエリや外部API呼び出しにある可能性が高いと言えます。こうした遅い処理を改善しないままスレッド数だけを増やしても、処理が完了するまで多くのリクエストを長時間待たせる結果になります。
まとめ
PHPのスレッド管理、マルチレイヤー構成のキャッシュ、そして隔離コンテナ技術は、WordPressをスケールさせるうえで、いずれもパフォーマンスに大きく影響する重要な要素です。スレッドの仕組みや、キャッシュがどのように負荷を軽減するのかを理解することで、適切なサーバープラン選びや、より効果的なサイト最適化を実行しやすくなります。
ご興味がありましたら、KinstaのWordPress専用マネージドクラウドサーバーをぜひ一度お試しください。WordPressサイトの負荷を支える堅牢なインフラを提供しています。
