【PHP】「mod_php」と「PHP-FPM」について調べてみました

---

「mod_php」と「PHP-FPM」のパフォーマンス差はどれくらい？

具体的な数値は環境（サーバーのスペック、PHPのバージョン、アプリケーションの内容、同時接続数など）によって大きく異なりますが、一般的な傾向として言えるのは以下の通りです。

• 同時接続数が少ない場合（数人〜数十人程度）: mod_phpでもPHP-FPMでも、体感できるほどの大きな差が出ないことがあります。
• 同時接続数が増える場合（数百人〜数千人以上）: このあたりからPHP-FPMの優位性が顕著になります。mod_phpでは、Apacheのプロセス数が増えるにつれてメモリ消費が急増し、スワップ（メモリが足りなくなりストレージを使うこと）が発生して極端にパフォーマンスが低下したり、サーバーがハングアップしたりする可能性があります。PHP-FPMでは、メモリ効率が良いため、同じメモリ量であればより多くの同時接続を捌くことができます。

具体的な例（あくまで目安）:

• メモリ使用量: 同じPHPアプリケーションを動かした場合、mod_phpの方がPHP-FPMよりも数倍〜数十倍メモリを消費することがあります。特に、Apacheの子プロセスがそれぞれPHPエンジンをロードするため、プロセス数が多いと積算されて莫大な量になります。
• スループット（1秒間に処理できるリクエスト数）: 高負荷時では、PHP-FPMがmod_phpの数倍〜10倍以上のリクエストを捌けることもあります。これは、PHPプロセスを再利用するため、新しいプロセスの起動オーバーヘッドがないことが大きいです。

これは、「車にガソリンエンジンとモーターの両方を積む」のか、「ガソリンエンジンとモーターを分業させる」のかの違いに似ています。分業させた方が、それぞれの専門性を活かして効率的に動けますよね。

---

mod_phpでPHPスクリプトに問題が発生した場合、Apacheプロセス全体に影響を与える可能性があるとのことですが、具体的にはどういったことが起こるの？

これは、ApacheとPHPが同じ「家」の中に住んでいるような状態を想像すると分かりやすいです。

mod_phpの場合（同じ家）:

PHPスクリプトがバグっていたり、無限ループに陥ったり、大量のメモリを消費したりする問題が発生すると、そのPHPスクリプトを実行しているApacheの子プロセスが問題を引き起こします。

具体的には：

1. Apache子プロセスのクラッシュ: PHPスクリプトのバグが原因で、PHPエンジン自体がクラッシュし、そのPHPエンジンを内蔵しているApacheの子プロセスが異常終了します。
2. Apache全体のパフォーマンス低下: 特定の子プロセスが大量のCPUやメモリを消費し続けると、その負荷がサーバー全体に波及し、他の子プロセスも動きが遅くなったり、新しいリクエストを受け付けられなくなったりします。最悪の場合、Apacheの親プロセスがすべてのリクエストを受け付けなくなり、ウェブサイト全体が一時的に表示されなくなる（ハングアップする）可能性があります。
3. 「Internal Server Error (500)」の頻発: 特定のPHPスクリプトがクラッシュすると、そのリクエストに対して「500 Internal Server Error」が表示されます。これが広範囲で頻発すると、ユーザー体験が著しく低下します。
4. Apacheの再起動が必要になる: 状態が悪化すると、手動でApacheを再起動しないと回復しない場合もあります。

これは、家の中の一つの部屋（PHPスクリプト）で火事（問題）が起きると、家全体（Apacheプロセス）に煙が充満したり、延焼したりして、家全体が機能しなくなる、といったイメージです。

---

mod_phpがApacheと同じユーザー権限で実行されることで、他のユーザーのスクリプトから情報が漏洩するリスクが高まるというけれど、具体的にどういったこと？

これも「家」の例で説明します。

mod_phpの場合（同じ鍵を持つ同居人）:

mod_phpでは、Apacheウェブサーバーが起動しているユーザーアカウント（例えばwww-dataやapache）と同じ権限でPHPスクリプトが実行されます。

• ユーザー（アカウント）とは？: ここで言う「ユーザー」とは、LinuxやUnix系のOSにおけるシステムアカウントのことです。それぞれのファイルやディレクトリには、どのユーザーが読み書きできるかという権限が設定されています。
• 共有ホスティング環境とは？: 複数のユーザー（ウェブサイトのオーナー）が1台のサーバーを共有して利用するサービスのことです。例えば、レンタルサーバーで「Aさんのウェブサイト」と「Bさんのウェブサイト」が同じサーバー上に存在する場合などです。

この状況で、例えば悪意のあるユーザー（攻撃者）が、自分のウェブサイトのPHPスクリプトに脆弱性があったり、外部からの攻撃を受けたりして、そのスクリプトが乗っ取られたとします。

具体的に起こりうるリスク:

1. 他ユーザーのファイルへのアクセス:

   乗っ取られたPHPスクリプトは、Apacheと同じユーザー権限で動作しています。もしその権限が、他のユーザー（Aさんのサイト）のファイルやディレクトリにもアクセスできる設定になっていた場合、攻撃者は乗っ取ったPHPスクリプトを通じて、Bさんのサイトのデータ（設定ファイル、データベース接続情報、顧客情報など）を読み取ったり、改ざんしたりすることが可能になってしまいます。

2. システムファイルへのアクセス:

   さらに深刻な場合、Apacheが不用意にシステムファイルへのアクセス権限を持っていると、攻撃者がシステム全体に影響を与えるような操作（例えば、他のユーザーのホームディレクトリへの侵入や、システムコマンドの実行など）を行う道を開いてしまう可能性があります。

これは、同じアパート（サーバー）に住む住人全員が、玄関の鍵をコピーして持っているようなものです。もし一人の住人の鍵が盗まれたら、泥棒は他の住人の部屋にも簡単に入り放題になってしまいます。

PHP-FPMの場合（別の鍵と厳重なセキュリティドア）:

PHP-FPMは、異なるユーザー権限でPHPプロセスを起動・実行できます。例えば、Aさんのサイトはuser_aというユーザーで、Bさんのサイトはuser_bというユーザーでPHP-FPMプロセスを起動させることができます。

これにより、たとえAさんのサイトのPHPスクリプトが乗っ取られても、そのスクリプトはuser_aの権限でしか動作しないため、user_bが所有するファイルにはアクセスできません。これは、アパートの各部屋がそれぞれ異なる鍵を持っており、一つの部屋の鍵が盗まれても、他の部屋には侵入できないような状態です。この分離により、セキュリティが大幅に向上します。

---

各ApacheプロセスがPHPの処理を行うということだけど、同時接続があったとき、Apacheは具体的にどのようにプロセスを実行し、後者とどのような違いがあるの？

まず、Apacheがどのようにリクエストを処理するか、基本的なところから説明します。

Apacheのマルチプロセスモデル（MPM）:

Apacheは、複数の同時リクエストを処理するために「Multi-Processing Modules (MPM)」という仕組みを使います。一般的なMPMは以下の2つです。

• Prefork MPM: 古くからあるモデルで、各Apacheプロセスが単一のスレッドで動作します。新しいリクエストが来るたびに、親プロセスが子プロセスをフォーク（複製）して対応します。
• Worker MPM / Event MPM: 比較的新しいモデルで、複数の子プロセスを起動し、さらに各子プロセスが複数のスレッドを作成してリクエストを処理します。スレッドはプロセスよりも軽量なので、より効率的です。

mod_phpの場合（Prefork MPMを前提として説明）:

1. ApacheプロセスとPHPエンジンの一体化: Apacheが起動すると、設定された数の子プロセス（例: Prefork MPMならMaxRequestWorkersで指定された数）が予め生成されます。mod_phpが有効な場合、これらの各子プロセスは、PHPの実行エンジンをメモリにロードした状態で待機しています。
2. リクエストの処理:
   • ユーザーAがPHPファイル（例: index.php）をリクエスト。
   • Apacheはアイドル状態の子プロセスを1つ選び、そのプロセスが自身にロードされたPHPエンジンを使ってindex.phpを実行します。
   • PHPの処理が完了し、結果が返されるまで、その子プロセスは他のリクエストを処理できません。
   • ユーザーBが同時に別のPHPファイル（例: user.php）をリクエスト。
   • Apacheは別のアイドル状態の子プロセスを1つ選び、そのプロセスが自身のPHPエンジンを使ってuser.phpを実行します。
3. 同時接続とリソース: もし同時に100人がアクセスしたら、Apacheは100個の子プロセスを起動（または事前に生成しておいたものを利用）し、それぞれがPHPエンジンをロードした状態でPHPスクリプトを実行します。各子プロセスは、PHPエンジン部分だけでもかなりのメモリを消費するため、プロセス数が増えれば増えるほど、メモリ使用量が急増します。これが、mod_phpが高負荷時にリソース効率が悪くなる原因です。

PHP-FPMの場合:

1. ApacheとPHP-FPMの分業:
   • Apacheは、HTTPリクエストを受け付けることに特化します。PHPエンジンはロードしません。
   • PHP-FPMは、別の独立したサービスとして起動し、PHPプロセス（ワーカプロセス）のプールを管理します。これらのワーカプロセスは、PHPコードを実行する専門家です。
2. リクエストの処理:
   • ユーザーAがPHPファイル（例: index.php）をリクエスト。
   • Apacheは、これがPHPファイルだと判断すると、自身に組み込まれたFastCGIモジュール（例: mod_proxy_fcgi）を使って、そのリクエストをPHP-FPMのソケット（またはポート）に転送します。
   • PHP-FPMは、プール内のアイドル状態のPHPワーカプロセスを1つ選び、そのプロセスにindex.phpの実行を指示します。
   • PHPワーカプロセスはPHPコードを実行し、結果をPHP-FPMに返します。
   • PHP-FPMはその結果をApacheに返します。
   • Apacheは最終的に結果をユーザーAに返します。
   • ユーザーBが同時に別のPHPファイル（例: user.php）をリクエスト。
   • 同様にApacheがPHP-FPMに転送し、PHP-FPMは別のアイドル状態のPHPワーカプロセスを選んで処理させます。
3. 同時接続とリソース: 同時に100人がアクセスしても、ApacheのプロセスはPHPエンジンをロードしないため、軽量です。PHP-FPMのワーカプロセスだけがPHPを処理します。PHP-FPMはプロセスプールを効率的に管理するため、mod_phpのようにリクエストごとにPHPエンジンをロードする無駄がなく、メモリ使用量を抑えられます。

違いのまとめ:

• mod_php: Apacheの各子プロセスがPHPの処理能力を内蔵している。同時接続が増えると、その分だけPHPエンジンを内蔵した重いApacheプロセスが増殖し、メモリを食いつぶす。
• PHP-FPM: ApacheとPHPの処理を完全に分業させている。Apacheはリクエスト受付の専門、PHP-FPMはPHP実行の専門。これにより、効率的なリソース利用と高いスケーラビリティを実現。

---

後者は前者と違って、Apacheに組み込まれるものではなく、どちらというと、後者のモジュール？PHP側に近いところで操作するの？

はい、その理解で合っています。

• mod_php:

  これはApacheのモジュールです。Apacheウェブサーバーに直接「PHPを実行する機能」を組み込む形になります。httpd.confなどのApacheの設定ファイルでLoadModule php_module modules/libphp.soのように記述して有効化します。完全にApacheの一部として動作します。

• PHP-FPM:

  これは独立したソフトウェア（サービス）です。ApacheやNginxなどのウェブサーバーとは別個に起動し、バックグラウンドで動作します。PHPの実行環境を管理する「PHP-FPMサービス」として、OS上で動きます。

  ウェブサーバー（Apache）は、PHPスクリプトの実行が必要な際に、FastCGIプロトコルという通信方式を使って、このPHP-FPMサービスにリクエストを「転送」します。

  Apache側には、このFastCGI通信を行うためのモジュール（例えばApacheのmod_proxy_fcgiなど）が必要になりますが、これはPHP自体を実行するモジュールではなく、単にPHP-FPMとの「橋渡し」をするためのものです。

ですから、PHP-FPMは「PHP側に近いところで操作する」という表現が適切です。実際、PHP-FPMの設定ファイル（通常php-fpm.confやpool.d/*.conf）はPHPの設定ファイル群と一緒に管理されますし、systemctlコマンドなどでPHP-FPMサービスとして起動・停止・再起動を行います。

---

後者はメモリやCPUの使用効率が良いということだけど、どの程度違ってくるの？ApacheのプロセスがPHPの処理を行わないので、静的なコンテンツの配信には影響を与えない、ということだけど、これは前者と何が具体的にどう違うの？

メモリとCPUの使用効率の違い:

• mod_php:

  Apacheの各子プロセスがPHPエンジン全体をメモリにロードしているため、PHPスクリプトが実行されていない状態（例えば、画像ファイルやCSSファイルをリクエストしているだけ）でも、そのプロセスのメモリはPHPエンジンの分だけ消費されています。

  CPUに関しても、PHPスクリプトが一つ実行されるたびに、そのPHPエンジンを内蔵したApacheプロセスがCPUを消費します。リクエストの度に新しいプロセスをフォークするモデル（Prefork）では、プロセス生成のオーバーヘッドも大きくなります。

  例えば、1つのApache子プロセスがPHPエンジンを含めて30MBのメモリを消費するとします。同時接続数100なら、3GBのメモリがPHPのためだけに消費されることになります。

• PHP-FPM:

  ApacheのプロセスはPHPエンジンをロードしません。Apacheのプロセス自体は非常に軽量です。PHP-FPMのワーカプロセスだけがPHPエンジンをロードし、必要な時にだけCPUを使います。

  PHP-FPMはプロセスプールを管理し、プロセスを再利用するため、新しいプロセスの起動オーバーヘッドがほとんどありません。また、アイドル状態のワーカプロセスは、必要最低限のメモリしか消費しません。

  例えば、1つのPHP-FPMワーカプロセスが20MBのメモリを消費するとします。PHP-FPMは同時接続数に合わせて効率的にプロセス数を調整するため、mod_phpのように無駄なメモリ消費が抑えられます。静的なコンテンツのリクエストはApacheが直接処理し、PHP-FPMプロセスは関与しないため、メモリもCPUも消費しません。

静的なコンテンツの配信への影響の違い:

• mod_phpの場合:

  静的なコンテンツ（画像、CSS、JavaScriptファイルなど）のリクエストが来た場合でも、ApacheはPHPエンジンをロードした子プロセスを使ってそのファイルを配信します。つまり、PHPを動かすための重いエンジンを積んだ「トラック」で、たった一枚の「手紙」を届けているようなものです。これにより、静的コンテンツの配信でも余計なメモリを消費し、リソースの無駄が生じます。また、PHPスクリプトの処理でApacheプロセスが逼迫している場合、静的コンテンツの配信速度も影響を受ける可能性があります。

• PHP-FPMの場合:

  静的なコンテンツのリクエストは、ApacheがPHP-FPMに何も転送することなく、直接処理して配信します。ApacheのプロセスはPHPエンジンをロードしていないため、非常に軽量な「バイク」で手紙を届けるようなものです。PHP-FPMプロセスは完全にアイドル状態であり、メモリもCPUも消費しません。

  これにより、PHPアプリケーションの負荷が高まっても、静的なコンテンツの配信速度にはほとんど影響を与えません。ウェブサーバーの役割を「静的なファイルの配信」と「PHPスクリプトの実行依頼」に明確に分離しているため、全体的な効率が向上します。

---

前者と後者では、サーバー全体が停止するリスクが違うようですが、具体的に何がどう違い、表示される画面なども何が異なる？

mod_phpの場合（リスクが高い）:

• 具体的な違い: PHPスクリプトのバグ（無限ループ、メモリリークなど）が、Apacheのプロセスに直接影響を与えます。もしApacheの子プロセスがハングアップしたりクラッシュしたりすると、そのプロセスは他のリクエストを処理できなくなります。これが同時に多発すると、Apacheの利用可能なプロセスが枯渇し、新しいリクエストを受け付けられなくなります。
• 表示される画面:
  • 特定のPHPスクリプトに問題がある場合: そのスクリプトへのアクセスに対して「500 Internal Server Error」が表示されることが多いです。
  • Apache全体が機能不全に陥った場合: ブラウザが長時間応答を待った後、「このサイトにアクセスできません」や「接続がタイムアウトしました」といったメッセージが表示されることがあります。これは、Apacheがリクエストを受け付けられない、または処理を開始できない状態になったことを意味します。

PHP-FPMの場合（リスクが低い）:

• 具体的な違い: PHP-FPMはApacheから独立したプロセスとして動作します。PHPスクリプトのバグによってPHP-FPMのワーカプロセスがクラッシュしても、その影響は当該のワーカプロセスにとどまります。PHP-FPMの親プロセスがそれを検知し、自動的に新しいワーカプロセスを再起動します。Apacheは引き続きリクエストを受け付け、他の正常なPHP-FPMワーカプロセスに処理を転送することができます。
• 表示される画面:
  • 特定のPHPスクリプトに問題がある場合: そのスクリプトへのアクセスに対して「500 Internal Server Error」が表示されます。しかし、問題がワーカプロセスレベルで隔離されるため、他の正常なPHPスクリプトや静的コンテンツには影響がありません。
  • PHP-FPMサービス自体が停止した場合: ApacheはPHP-FPMに接続できなくなり、「502 Bad Gateway」（Nginxの場合によく出る）や、Apacheの設定によっては「500 Internal Server Error」が表示されることがあります。しかし、この場合でもApache自体は動作しており、静的なコンテンツの配信は可能です。PHP-FPMは通常、自動的に再起動するように設定されているため、一時的な問題で済むことが多いです。

要するに: mod_phpでは「PHPのトラブルがApacheのシステム全体を巻き込む」リスクがあるのに対し、PHP-FPMでは「PHPのトラブルをPHP-FPMプロセス内で閉じ込める」ことができるため、サーバー全体の安定性が大幅に向上します。

---

後者はプロセスプールを管理するというけれど、このプロセスプールとは何？

プロセスプール（Process Pool）とは、文字通り「プロセスの貯蔵庫」のことです。

PHP-FPMは、ウェブサーバーからのPHPスクリプトの実行リクエストを効率的に処理するために、あらかじめPHPのワーカプロセスを複数起動させて待機させています。この待機しているワーカプロセスの集まりが「プロセスプール」です。

イメージ:

レストランで例えると、

• CGI (旧式): お客さんが来るたびに、シェフを一人雇い、料理を作ってもらい、終わったら解雇する。 → 非効率。
• FastCGI (PHP-CGI): シェフを一人雇っておき、料理を作ってもらう。でも、シェフが休んだり、急に忙しくなったりした時の管理は、お店のオーナー（ウェブサーバー）が自分で何とかしないといけない。 → 少し効率的になったけど、管理が大変。
• PHP-FPM (FastCGI Process Manager): お店の奥に「厨房（プロセスプール）」があり、そこに複数のシェフ（PHPワーカプロセス）が常に待機している。お客さんがオーダー（リクエスト）をすると、ウェイター（ウェブサーバー）が空いているシェフにそのオーダーを渡し、シェフはすぐに料理を始める。料理が終わるとシェフはまた待機状態に戻る。もし注文が殺到しても、厨房のマネージャー（PHP-FPM）が、必要に応じて新しいシェフを呼んだり、忙しすぎるシェフを休ませたりして、効率的に管理してくれる。

プロセスプールのメリット:

• オーバーヘッドの削減: リクエストがあるたびにPHPプロセスを起動するコスト（時間とリソース）が不要になる。
• 高速なレスポンス: リクエストが来たらすぐにアイドル状態のプロセスに処理を割り当てられるため、応答速度が向上する。
• リソースの有効活用: 必要なプロセス数だけを起動し、それを再利用するため、メモリなどのリソースが無駄にならない。
• スケーラビリティ: 同時接続数の増加に合わせて、プロセス数を動的に調整できる。

PHP-FPMは、このプロセスプールを賢く管理することで、PHPアプリケーションのパフォーマンスと安定性を大きく向上させています。

---

後者で子プロセスに関する詳細な設定あるというけれど、子プロセスとは？孫プロセスもあるの？詳細な設定オプションがあるというけれど、具体的にはどういったもの？サーバーの負荷状況に合わせてチューニングするというのは、自動的に？それとも手動的に設定ファイルなどで編集して操作すること？

子プロセスとは？孫プロセスもあるの？

ここでの「子プロセス」とは、PHP-FPMの「ワーカプロセス」のことです。PHP-FPMの親プロセスがいて、その親プロセスがPHPスクリプトを実際に実行する複数の子プロセス（ワーカプロセス）を生成・管理します。

一般的な文脈では、「孫プロセス」という概念はPHP-FPMの直接的な動作ではあまり出てきません。しかし、もしPHPスクリプトがさらに別のプログラムを起動（execやshell_execなど）した場合、その起動されたプログラムはPHPワーカプロセスの「子プロセス」として動作することになります。PHP-FPMが直接管理するのは、あくまでPHPコードを実行するワーカプロセスまでです。

詳細な設定オプション（例: php-fpm.conf または pool.d/*.conf に記述）:

PHP-FPMのプロセスプールは、「プール」単位で設定されます。一般的にはwww.confというファイル名でデフォルトのプールが設定されています。

• pm (process manager):

  • static: 常に固定数の子プロセスを起動します。最もシンプルですが、リソースの無駄が生じることもあります。
  • dynamic: 初期の子プロセス数を指定し、必要に応じて動的に子プロセスを増減させます。推奨される設定です。
  • ondemand: リクエストがあった時だけ子プロセスを生成し、一定時間アイドル状態が続くと終了させます。メモリを最大限に節約したい場合に有効ですが、最初の応答が遅くなる可能性があります。

• pm.max_children:

  起動できる子プロセスの最大数。この数を大きくしすぎるとメモリを大量に消費し、サーバーがハングアップする可能性があります。サーバーのメモリ量に合わせて慎重に設定する必要があります。

• pm.start_servers (dynamicモードのみ):

  PHP-FPM起動時に最初に生成する子プロセスの数。

• pm.min_spare_servers (dynamicモードのみ):

  アイドル状態（何も処理していない）の子プロセスの最小数。この数よりもアイドルプロセスが少なくなると、PHP-FPMは新しい子プロセスを生成します。

• pm.max_spare_servers (dynamicモードのみ):

  アイドル状態の子プロセスの最大数。この数よりもアイドルプロセスが多くなると、PHP-FPMは一部の子プロセスを終了させます。

• request_terminate_timeout:

  PHPスクリプトの最大実行時間（秒）。この時間を超えてもスクリプトが終了しない場合、PHP-FPMはその子プロセスを強制終了します。無限ループなどでプロセスがハングアップするのを防ぎます。

• request_slowlog_timeout:

  PHPスクリプトがこの時間を超えて実行された場合に、スローログに記録します。どのスクリプトが遅いのかを特定するのに役立ちます。

• listen:

  ウェブサーバーがPHP-FPMと通信するためのアドレス。通常はUnixドメインソケット（例: /var/run/php/php8.2-fpm.sock）またはTCPポート（例: 127.0.0.1:9000）を指定します。

サーバーの負荷状況に合わせてチューニングするというのは、自動的に？それとも手動的に人間が設定ファイルなどで編集して操作すること？

基本的には手動的に人間が設定ファイル（php-fpm.confやpool.d/*.conf）を編集して操作します。

PHP-FPM自体が負荷状況を「見て」、dynamicモードであればプロセスの数を自動的に増減させますが、それはあくまでも設定ファイルで指定したpm.max_childrenやpm.min_spare_serversなどの範囲内でのことです。

サーバー管理者は、サーバーのメモリ量、CPUコア数、想定される同時接続数、PHPアプリケーションの特性（メモリ消費量、実行時間）などを考慮して、これらのパラメータを調整します。

• チューニングのステップの例:
  1. まず、初期設定で動かしてみる。
  2. サーバーのリソース監視ツール（top, htop, Prometheus + Grafanaなど）で、PHP-FPMプロセスがどのくらいメモリやCPUを使っているかを観察する。
  3. アクセスが増えたり、ウェブサイトの応答が遅くなったりするようなら、pm.max_childrenを増やしてみる。ただし、メモリが足りなくならないように注意する。
  4. アイドル状態のプロセスが多すぎる（メモリの無駄）なら、pm.max_spare_serversを減らしてみる。
  5. 遅いスクリプトがないか、request_slowlog_timeoutを設定してスローログをチェックする。

このように、試行錯誤しながら最適な設定を見つけていくのが一般的なチューニングの手順です。完全な自動化は難しく、管理者の知識と経験が求められます。

---

FastCGIプロトコルということは、HTTPプロトコルと同じような標準規格のことですか？レイヤーは７で、アプリケーション層で使用されるもの？

はい、その理解で大筋は合っています。

• FastCGIプロトコルは、HTTPプロトコルと同じような「標準規格」です。 特定のアプリケーション（PHP-FPMなど）とウェブサーバーが通信するために定められたルール（約束事）のセットです。
• レイヤーについて: OSI参照モデルの7層（アプリケーション層）に位置するプロトコルである、というのも正しい認識です。HTTPもアプリケーション層のプロトコルです。

違いと補足:

• HTTPプロトコル:

  • 目的: クライアント（ブラウザ）とウェブサーバーの間で、ウェブコンテンツの送受信を行うためのプロトコル。
  • 役割: 主に「ウェブページの表示」のための情報をやり取りします。テキスト、画像、動画などのリソースの要求と応答を定義します。
  • 典型的な通信: クライアント（ブラウザ） <-> ウェブサーバー（Apache/Nginx）

• FastCGIプロトコル:

  • 目的: ウェブサーバーと、その背後にある「外部アプリケーション（例: PHPインタプリタ、Python/RubyのWebフレームワークなど）」の間で、データを交換するためのプロトコル。
  • 役割: ウェブサーバーが受け取ったHTTPリクエストを、外部アプリケーションが理解できる形式に変換して渡し、外部アプリケーションが処理した結果をウェブサーバーが理解できる形式で受け取る、という仲介役を担います。
  • 典型的な通信: ウェブサーバー（Apache/Nginx） <-> 外部アプリケーション（PHP-FPMなど）

つまり、役割が違います。 HTTPはユーザーのブラウザとウェブサーバーがウェブページを見せるために直接話す言葉、FastCGIはウェブサーバーが裏で専門家（PHP-FPM）に仕事を依頼するために話す言葉、と考えると分かりやすいでしょう。どちらもアプリケーション層（レイヤー7）で機能します。

---

FastCGIが、常に起動しているプロセスを再利用するとはどういったこと？

これは、ウェブサーバーとFastCGIアプリケーション（例: PHP-FPM）の間で、以下のようなやり取りが行われることを指します。

ステップバイステップのイメージ:

1. 事前準備（初期起動時）:

   • PHP-FPMサービスが起動すると、複数のPHPワーカプロセスをあらかじめ起動させて、アイドル状態（待機状態）でメモリ上に保持しておきます。これが「プロセスプール」です。
   • これらのプロセスは、いつでもPHPコードを実行できる準備ができています。

2. リクエストの到着:

   • ウェブサーバー（Apacheなど）にユーザーからのPHPファイルへのリクエストが来ます。
   • ウェブサーバーは、このリクエストをPHP-FPMに転送します。

3. プロセスの再利用:

   • PHP-FPMは、プールの中から現在何も処理していない（アイドル状態の）ワーカプロセスを1つ選びます。
   • 選ばれたワーカプロセスに、ウェブサーバーから転送されたリクエスト（HTTPヘッダ、POSTデータ、クエリパラメータなど）を渡します。
   • ワーカプロセスは、そのリクエストに基づいてPHPスクリプトを実行します。

4. 処理の完了と待機状態への復帰:

   • PHPスクリプトの実行が完了し、結果（HTMLなど）が生成されると、ワーカプロセスはその結果をPHP-FPMを通じてウェブサーバーに返します。
   • 結果を返し終えたワーカプロセスは、終了せずに、再びアイドル状態に戻り、次のリクエストが来るのを待ちます。

これが「常に起動しているプロセスを再利用する」ということです。

もしこれがCGIのように「リクエストがあるたびに新しいプロセスを起動し、処理が終わったら終了する」方式だと、以下の余分なコストがかかります。

• プロセス起動のオーバーヘッド: プロセスを起動するたびにOSのリソース（メモリ確保、CPUタイムなど）を消費します。
• PHPエンジンのロード: PHPスクリプトを実行するために必要なPHPエンジンやライブラリを、リクエストごとに毎回メモリにロードし直す必要があります。

FastCGIは、これらのオーバーヘッドを排除し、すでにメモリにロードされて準備万端のプロセスを使い回すことで、高速かつ効率的な処理を実現しています。

---

「PHPのバイナリ自体がFastCGIプロトコルを話すようにコンパイルされたもの」とあるが、バイナリ自体というのは、PHPのスクリプトが機械語に翻訳されたファイルのことをさしている？また、「話す」というのはどういうこと？「コンパイル」とは？

一つずつ解説します。

• バイナリ自体というのは、PHPのスクリプトが機械語に翻訳されたファイルのことをさしている？

  いいえ、少し違います。ここでの「PHPのバイナリ」とは、PHP言語の実行環境そのもの（PHPインタプリタ）を指します。つまり、phpコマンドやphp-cgi、php-fpmといった、PHPコードを読み込んで実行するプログラムそのものです。

  PHPスクリプト（.phpファイル）は、あなたが書いたテキスト形式のコードです。このテキストコードは、直接CPUが理解できる機械語ではありません。PHPインタプリタというプログラムが、そのテキストコードを読み込み、内部的に解釈して（一部は中間コードに変換して）実行します。

  したがって、「PHPのバイナリ」とは、PHPスクリプトを実行するための「PHPエンジン」または「PHPインタプリタ」というプログラム（実行可能ファイル）のことです。

• 「話す」というのはどういうこと？

  ここで言う「話す」とは、「特定のプロトコル（通信規約）に従ってデータを送受信できる」という意味です。

  例えば、「人が英語を話す」とは、英語の文法や単語を使ってコミュニケーションができる、ということです。

  それと同様に、「PHPのバイナリがFastCGIプロトコルを話す」とは、PHPの実行プログラムがFastCGIプロトコルで定められたルール（データのフォーマット、送受信の手順など）に従って、ウェブサーバーとデータのやり取りができる、ということです。

  具体的には、ウェブサーバーからFastCGIプロトコルで送られてきたリクエストデータ（URL、POSTデータ、HTTPヘッダなど）を正しく解釈し、PHPスクリプトを実行した後、FastCGIプロトコルで定義された形式でその結果（HTTPステータス、レスポンスヘッダ、HTMLコンテンツなど）をウェブサーバーに返す、といった一連の通信ができることを意味します。

• 「コンパイル」とは？

  「コンパイル」とは、人間が書いたプログラムのソースコード（例: C言語やPHPの内部コード）を、コンピュータが直接実行できる形式（機械語の実行ファイルや、より効率的な中間コード）に変換する作業のことです。この変換を行うプログラムを「コンパイラ」と呼びます。

  PHP自体は通常「インタプリタ言語」と呼ばれ、スクリプトは実行時にインタプリタによって解釈されます。しかし、PHPインタプリタ（PHP-CGIやPHP-FPMのプログラム自体）は、C言語などで書かれており、これらはコンピュータにインストールされる前に「コンパイル」という過程を経て、実行可能なバイナリファイル（機械語のプログラム）になります。

  つまり、「PHPのバイナリ自体がFastCGIプロトコルを話すようにコンパイルされた」とは、PHPの実行プログラム（PHP-CGIなど）が作られる際に、そのプログラムにFastCGIプロトコルに対応するための機能（コード）が組み込まれて、最終的な実行ファイルとして生成された、という意味です。

---

ワーカプロセスとは何？

ワーカプロセス（Worker Process）とは、PHP-FPMにおいて、実際にPHPスクリプトの実行を担う個々のプロセスのことです。

PHP-FPMは、親となるプロセス（マスタープロセスとも呼ばれます）が一つ起動しており、この親プロセスがPHPスクリプトの実行リクエストを受け付け、複数の子プロセスを生成・管理します。この子プロセスこそが「ワーカプロセス」です。

• 役割: ウェブサーバーから転送されてきたPHPスクリプトのリクエストを受け取り、PHPコードを解釈・実行し、その結果をウェブサーバーに返します。
• 特徴:
  • それぞれが独立したPHP実行環境を持っています。
  • 処理が完了すると、終了せずに次のリクエストに備えてアイドル状態に戻ります（再利用される）。
  • PHP-FPMは、このワーカプロセスの数を動的に増減させたり、一定時間応答がないプロセスを強制終了させたりして、効率的に管理します。

レストランで例えると、「厨房で実際に料理を作る一人一人のシェフ」がワーカプロセスです。お客さんが増えればシェフを増やし、減れば休憩させたりします。

---

PHP-FPMプールとは何？これは複数作成できるものなの？

PHP-FPMプール（Pool）とは、PHP-FPMが管理するワーカプロセスのグループのことです。それぞれのプールは、特定のウェブサイトやアプリケーション、または特定のPHPバージョンに対応するように、独自のPHP設定とプロセス管理設定を持つことができます。

イメージ:

大きな工場の中に、いくつかの独立した「作業ライン」があるようなものです。

• 作業ラインA: 最新のPHP 8.2を使って、WebアプリケーションAを動かすためのライン。特定のユーザー（web_user_a）の権限で動き、メモリも多めに割り振る。
• 作業ラインB: 少し古いPHP 7.4を使って、WebサイトBを動かすためのライン。別のユーザー（web_user_b）の権限で動き、メモリは少なめに割り振る。
• 作業ラインC: 開発中のPHP 8.3を使って、テスト用のWebサービスCを動かすライン。

複数作成できるか？

はい、複数作成できます。 これがPHP-FPMの非常に強力で便利な機能の一つです。

複数プールを作成するメリット:

1. 異なるPHPバージョンの共存: 1台のサーバーでPHP 7.4、8.0、8.2など、複数のPHPバージョンを同時に動かすことができます。これは、異なるプロジェクトやレガシーなアプリケーションを同じサーバーでホストする場合に非常に役立ちます。
2. ユーザー権限の分離とセキュリティ向上: 各プールを異なるLinuxユーザー（OSのユーザーアカウント）で実行できます。これにより、ウェブサイトAのPHPプロセスが、ウェブサイトBのファイルにアクセスすることを防ぎ、セキュリティリスクを大幅に軽減できます。（先ほどの「他のユーザーのスクリプトから情報が漏洩するリスク」の対策になります。）
3. リソース管理の分離: 各プールごとに、ワーカプロセスの最大数、アイドルプロセスの数、メモリ制限などの設定を個別に調整できます。これにより、特定のウェブサイトがリソースを独占してしまうことを防ぎ、サーバー全体の安定性を高めることができます。
4. 設定の分離: 各プールごとにPHPの設定（php.iniの設定）を独自に持たせることができます。これにより、アプリケーションごとに最適なPHP設定を適用できます。

設定は通常、/etc/php/{PHPバージョン}/fpm/pool.d/ディレクトリ内の個別の.confファイルで行われます（例: www.conf, my_app.confなど）。

---

異なるユーザー権限でPHPスクリプトを実行できるとあるが、ここで登場するユーザーとは？この定義がわからない。具体的な場面を説明して。

ここで登場する「ユーザー」とは、LinuxやUnixなどのOSが管理するシステム上の「ユーザーアカウント」のことです。Windowsでログインする時のユーザー名や、ファイルにアクセス権を設定する際のユーザー（例: Administrator, Guestなど）と同じような概念です。

Linuxにおけるユーザーの役割:

• ファイルやディレクトリの所有権と権限: 各ファイルやディレクトリは、特定のユーザーとグループによって「所有」されています。そして、その所有者、所有グループ、その他のユーザーに対して、読み込み（r）、書き込み（w）、実行（x）の権限を設定できます。
• プロセス実行の権限: プロセス（実行中のプログラム）は、特定のユーザーの権限で実行されます。そのプロセスは、実行されているユーザーがアクセスを許可されているファイルやリソースにのみアクセスできます。

具体的な場面（共有ホスティング環境を例に）:

あなたはレンタルサーバーを借りて、複数のウェブサイトを運営しているとします。

• ウェブサイトA (例: あなたのブログ):

  • FTPでアクセスする際のユーザー名: yourblog_user
  • ブログのファイルが保存されているディレクトリ: /home/yourblog_user/public_html/
  • このディレクトリ内のファイルの所有者: yourblog_user

• ウェブサイトB (例: あなたが運営するECサイト):

  • FTPでアクセスする際のユーザー名: yourshop_user
  • ECサイトのファイルが保存されているディレクトリ: /home/yourshop_user/public_html/
  • このディレクトリ内のファイルの所有者: yourshop_user

mod_phpの場合（セキュリティリスクあり）:

mod_phpでは、Apacheが起動しているユーザー（例: www-data）の権限でPHPスクリプトが実行されます。もしwww-dataユーザーが、 /home/yourblog_user/public_html/と/home/yourshop_user/public_html/の両方にアクセスできてしまう設定になっていると（これはサーバーの設定ミスやデフォルト設定によってはあり得る）、どちらか一方のウェブサイトが攻撃を受けてPHPスクリプトが乗っ取られた場合、その攻撃者はApacheのwww-dataユーザーの権限を使って、もう一方のウェブサイトのファイルにもアクセスできてしまう可能性があります。

例えば、ブログが乗っ取られて、攻撃者がブログのPHPスクリプトから../../yourshop_user/public_html/config.phpのようなパスでECサイトの設定ファイルを読み取ろうとした場合、mod_phpであればwww-dataユーザーが両方のディレクトリにアクセス権を持っていると、読み取りが成功してしまう恐れがあります。

PHP-FPMの場合（セキュリティ強化）:

PHP-FPMでは、異なるPHP-FPMプールを異なるユーザー権限で実行できます。

• ウェブサイトAのPHP-FPMプール: user = yourblog_user, group = yourblog_user で実行。
• ウェブサイトBのPHP-FPMプール: user = yourshop_user, group = yourshop_user で実行。

このように設定することで、例えブログのPHPスクリプトが攻撃者に乗っ取られたとしても、そのスクリプトはyourblog_userの権限でしか動作しません。yourblog_userは通常、/home/yourshop_user/public_html/ディレクトリへのアクセス権限を持っていないため、攻撃者がECサイトのファイルにアクセスすることはできないようになります。

これが「異なるユーザー権限でPHPスクリプトを実行できる」ことの具体的な意味と、それがセキュリティにどう貢献するか、という話です。

---

共有ホスティング環境とは？

共有ホスティング環境（Shared Hosting Environment）とは、複数のウェブサイトやユーザーが、1台の物理サーバー（または仮想サーバー）のCPU、メモリ、ディスクスペース、ネットワーク帯域などのリソースを共有して利用する形態のウェブホスティングサービスのことです。

特徴:

• 低コスト: 1台のサーバーを複数で利用するため、各ユーザーあたりのコストが低く抑えられます。
• 手軽さ: サーバーのセットアップや管理はホスティングプロバイダが行うため、ユーザーはウェブサイトのコンテンツ作成に集中できます。
• 制限: 他のユーザーとリソースを共有するため、特定のユーザーが大量のリソースを消費すると、他のユーザーのウェブサイトのパフォーマンスに影響が出る可能性があります（「共用サーバー」とも呼ばれます）。
• セキュリティリスク: 先述の通り、同じサーバー上の他のユーザーのウェブサイトから、意図しない情報漏洩や攻撃を受けるリスクが、専用サーバーやVPS（仮想プライベートサーバー）に比べて高まります。

多くの個人ブログや小規模ビジネスのウェブサイトは、この共有ホスティングを利用しています。対義語としては、1台のサーバーを単独で占有する「専用サーバー」や、仮想化技術によって専用サーバーのように使える「VPS (Virtual Private Server)」などがあります。

---

PHPスクリプトがクラッシュしたときに、サービス全体が防止するのをPHP-FPMだとできるというのは、これは前者と比べると、どのようにクライアントの画面で違いがありますか？

この点でのクライアント（ブラウザ）の画面の違いは、主に「ウェブサイト全体が利用できなくなるか、特定のページだけがエラーになるか」という点に現れます。

mod_phpの場合（サービス全体が停止しやすい）:

• 影響の範囲: 特定のPHPスクリプトのクラッシュがApacheの子プロセス全体に影響を与え、それが複数のApacheプロセスに波及すると、ウェブサーバー全体が応答不能になるリスクが高いです。
• クライアントの画面:
  • エラーページ: 問題のPHPスクリプトにアクセスすると「500 Internal Server Error」が表示されます。
  • サイト全体が応答不能: 最悪の場合、サイト内のどのページ（静的コンテンツ含む）にアクセスしても、ブラウザが長時間読み込みを続けた後、「このサイトにアクセスできません」や「接続がタイムアウトしました」といったメッセージが表示されます。これは、ウェブサーバーがダウンしたか、リすべてのリクエストを受け付けられない状態になったことを意味します。ユーザーはウェブサイト全体にアクセスできなくなります。

PHP-FPMの場合（影響が限定的でサービス停止しにくい）:

• 影響の範囲: PHPスクリプトのクラッシュは、そのスクリプトを処理していたPHP-FPMの単一のワーカプロセスに限定されます。PHP-FPMの親プロセスがそれを検知し、そのワーカプロセスを自動的に再起動します。他のワーカプロセスやApacheサーバー自体は正常に動作し続けます。
• クライアントの画面:
  • エラーページ: 問題のPHPスクリプトにアクセスすると「500 Internal Server Error」が表示されます。しかし、他の正常なPHPスクリプトや、静的なコンテンツ（画像、CSS、JavaScript、HTMLファイルなど）には引き続きアクセスできます。 たとえば、ブログ記事の1つがエラーで表示されなくても、トップページや他の記事は問題なく表示される、といった状況です。
  • 一時的な遅延: ワーカプロセスのクラッシュと再起動の瞬間に、ごく短時間だけ該当リクエストの処理が遅れる可能性はありますが、サーバー全体が停止するような事態にはなりにくいです。

まとめると:

項目	mod_php	PHP-FPM
PHPクラッシュの影響	Apacheプロセス全体に波及し、サーバー停止のリスクが高い	特定のPHP-FPMワーカプロセスに限定され、全体への影響が少ない
クライアント画面	特定ページでエラー、またはサイト全体が利用不能になることがある	特定ページでエラーになるが、サイト全体は利用可能なことが多い

PHP-FPMの方が、障害が起きた際の「サービスの可用性（サービスが利用できる状態であること）」が高いと言えます。

---

PHP-FPMは、WebサーバーとPHPの間を仲介して動く役割のようなものですか？これはPHPモジュール？Apacheモジュール？それともそれ以外の第三者？（別のソフトウェア？）

はい、まさにその通りです。

PHP-FPMは、ウェブサーバーとPHPの間を仲介して動く役割を担います。

そして、これは「Apacheモジュール」でも「PHPモジュール」でもありません。PHP-FPMは、独立した「別のソフトウェア（サービス）」です。

• Apacheモジュールではない: Apacheに直接組み込まれてPHPを実行するものではありません。Apache側には、PHP-FPMとFastCGIプロトコルで通信するための別のモジュール（mod_proxy_fcgiなど）が必要ですが、これはあくまで「橋渡し」の役割で、PHP自体を実行するものではありません。
• PHPモジュールではない: PHP自体が持つモジュールというよりは、PHPの実行環境を管理する「プロセスマネージャー」としての役割が強いです。もちろんPHPのコア機能と密接に連携していますが、PHPインタプリタとは別の独立したプログラム（サービス）として動作します。

PHP-FPMは、OSのサービスとして起動します。

Linuxの場合、systemctl start php-fpm（またはPHPのバージョンに応じてphp8.2-fpmなど）といったコマンドで起動・停止・再起動を行います。これはApacheやNginxといったウェブサーバーと同様に、OS上でバックグラウンドで動作し続ける独立したプロセスです。

したがって、PHP-FPMはウェブサーバーとは別の第三者的な役割（独立したソフトウェア）として、PHPスクリプトの実行を専門に管理する、という認識が最も適切です。