こんにちは。普段から「どうすればPHPを限界まで速くできるか」ばかり考えているシニアアーキテクトです。
他のモダンな言語、例えばNode.jsやGo、あるいはJavaなどの経験がある方ほど、PHPの「1リクエストごとにプロセスが完結する（シェアード・ナッシング）」というアーキテクチャに触れたとき、セッション管理の設計で壁にぶつかりがちです。「毎リクエスト、ストレージからセッションデータを引いてきてデシリアライズするのって、物理的に非効率じゃないか？」って思いますよね。その直感、完全に正しいです。
今回は、高並行環境（High-Concurrency）におけるPHPのセッション管理に焦点を当て、「Redis」と「共有メモリ（SHM）」の物理的レイテンシと、Zendエンジン内部のメモリ管理がどう連動しているのかを、低レイヤの視点から紐解いていきましょう。ここを理解すると、PHPの裏側が驚くほどクリアに見えてきますよ。
—
1. セッションデータ裏側の現実：なぜシリアライズコストを甘く見てはいけないのか
PHPで `$_SESSION[‘user’] = $userData;` と書いた瞬間、内部では何が起きているでしょうか？
リクエストの終端（RSHUTDOWNフェーズ）において、Zendエンジンはアクティブなセッションデータを文字列へと変換（シリアライズ）します。標準では `php` シリアライザが使われますが、複雑なオブジェクトグラフを持つデータ構造をシリアライズする場合、Zend VMのメモリ空間（zend_execute_dataやヒープ領域）を舐め回すように走査し、連続したバイト列へと再構築するコストが発生します。
そして、次のリクエストが来ると、今度は逆の処理――デシリアライズが走ります。
[Webクライアント]
↓ (HTTP Request)
[Nginx + PHP-FPM]
↓ (1. セッションID受信)
[ストレージ層 (Redis / 共有メモリ)]
↓ (2. 生のバイト列を取得)
[Zend VM ヒープ領域]
↓ (3. igbinary_unserialize または デフォルト復元)
[HashTable ($_SESSION) の構築]
この「シリアライズ → ネットワーク転送 or メモリコピー → デシリアライズ」という一連のパイプラインは、CPUキャッシュのヒット率を容赦なく下げ、高並行時には確実にボトルネックになります。では、このデータをどこに、どう置くべきか。物理的なレイテンシの差を見ていきましょう。
—
2. Redis vs 共有メモリ（SHM）：物理的レイテンシの正体
セッションストレージとして最も一般的な「Redis」と、極限のパフォーマンスを狙う「共有メモリ（APCuやshmop等）」を、物理層から比較します。
Redis：ネットワーク・プロセス間通信の壁
Redisは非常に高速なインメモリKVSですが、WebサーバーとRedisサーバーが別ホスト（あるいは同一ホスト内でも別コンテナ/別ループバックインターフェース）である場合、必ず以下のオーバーヘッドが生じます。
1. TCP/IPソケット（またはUnixドメインソケット）のシステムコール (`send`/`recv`)
2. カーネル空間とユーザー空間のコンテキストスイッチ
3. シリアライズされたバイト列のネットワークバッファコピー
数千QPSを超える高並行環境では、このソケット通信の往復（RTT）とカーネルのスケジューリング遅延が積み重なり、CPU待ちの時間が増加します。
共有メモリ（SHM）：物理メモリ直結の圧倒的優位性
一方で、同一OSカーネル内で管理される「共有メモリ（System V IPCやAPCuの基盤）」は、プロセス間のデータ共有においてプロセス境界を完全にバイパスします。
PHP-FPMの各子プロセスは、OSの仮想記憶空間上で共有メモリ領域を直接マッピング（`mmap`など）しています。つまり、ネットワークスタックを通らず、メモリ上のポインタを直接読み書きする感覚でセッションデータにアクセスできるのです。
ただし、共有メモリには「クラスタリング（複数台のWebサーバ構成）しにくい」という致命的なトレードオフがあります。ロードバランサーの後ろに複数台のPHP-FPMサーバが控える構成では、ステートフルな共有メモリは使えず、実質的にRedisのような外部KVSに頼らざるを得ないのが現実です。
—
3. 実践：高負荷に耐えるセッションハンドラのチューニング
では、単一ホストでの極限の高速化（あるいはRedisを使う場合の最適解）として、実際のコードと設定の勘所を見ていきましょう。
① デフォルトのシリアライザを捨てて `igbinary` を使う
PHP標準のシリアライザは可読性が高い反面、データサイズが大きくなりやすく、CPUのパースコストも高いです。C言語レベルで最適化された `igbinary` を導入すると、バイナリサイズが劇的に縮小し、メモリ転送コストが激減します。
`php.ini` での設定例です：
; セッションのシリアライザを igbinary に変更し、バイト列を最小化する
session.serialize_handler = igbinary
これだけで、Redisに流れるネットワークトラフィックや、メモリ上の消費量を20〜50%削減できるケースが多々あります。
② Redisを使う場合の極限最適化（phpiredis や Persistent Connection）
もしRedisを使う場合でも、接続の確立（TCP 3-way handshake）を毎リクエスト行っていては話になりません。持続的接続（Persistent Connection）を使用します。
// 概念的なカスタムセッションハンドラのイメージ（Redis拡張を使用）
class OptimizedRedisSessionHandler implements SessionHandlerInterface {
private \Redis $redis;
public function __construct(string $host, int $port) {
$this->redis = new \Redis();
// pconnect を使ってプロセスプール内でソケットを永続化・再利用する
$this->redis->pconnect($host, $port, 0.05, ‘php_session_pool’);
// シリアライズに igbinary が有効であることを前提とする
// Redis側のTCPバッファ遅延を防ぐため、NO_DELAYを有効にすることも検討
$this->redis->setOption(\Redis::OPT_SERIALIZER, \Redis::SERIALIZER_NONE);
}
public function read($id): string|false {
// ネットワーク往復を最小限にするため、GETのみを高速に実行
$data = $this->redis->get(“sess:” . $id);
return $data === false ? “” : $data;
}
public function write($id, $data): bool {
// TTL（有効期限）をアトミックに設定しつつ書き込み
return $this->redis->setex(“sess:” . $id, 3600, $data);
}
public function destroy($id): bool {
return $this->redis->del(“sess:” . $id) > 0;
}
// その他のインターフェースメソッドは省略…
}
このアプローチでは、`pconnect` によりPHP-FPMの各プロセスがRedisへのTCPコネクションを維持するため、リクエストごとの接続コストが完全にゼロになります。
—
4. アーキテクトからの提言：設計のジャッジメント
最後に、現場でどのように技術選定を行うべきかの指針をお伝えします。
1. スケールアウトが前提のWebシステム（複数台構成）
- 迷わず Redis（またはMemcached） を選択してください。ただし、上述の通り `igbinary` の導入と、`pconnect` によるコネクションプールの維持、そして可能であればセッションデータは「本当に必要な最小限のプリミティブな値」に絞り込み、巨大なオブジェクトを突っ込まないことが鉄則です。
2. 単体サーバで極限のスループットを絞り出す場合（モノリスな垂直スケール）
- APCuや共有メモリベースのカスタムセッションハンドラ を検討する価値があります。ネットワークレイテンシを完全に排除できるため、QPSの限界値を跳ね上げることができます。
PHPは「遅い言語」ではありません。「何も考えずにデフォルト設定のまま重いデータを雑にストレージに投げている状態」が遅いだけなのです。Zendエンジンのメモリ挙動と、データが通過する物理的レイヤーを意識できるようになれば、PHPはあなたの期待を超える爆速なエンジンとして応えてくれますよ。
日々のアーキテクチャ設計の参考にしていただければ幸いです。