【テクニカル・上級編】PHPのシリアライズ形式（IGBinary vs JSON）のメモリ消費とCPU負荷の比較 – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

大規模データ構造転送の極限：IGBinary vs JSONのZend VMメモリ空間アロケーションとCPUオーバーヘッド解析

Webシステムのスケールアウトが頭打ちになる瞬間、そのボトルネックの多くはデータベースのI/Oでもネットワークの帯域幅でもなく、「PHPプロセス内部におけるデータシリアライズとメモリ管理のコスト」にある。数万件のオブジェクトグラフやネストした多次元連想配列をRedisやMemcachedへストアする、あるいはマイクロサービス間でペイロードを転送する際、われわれは何気なく `json_encode()` や `serialize()` を叩いていないだろうか。

Zend VMの内部構造とメモリ空間のアロケーション戦略を知り尽くしたアーキテクトであれば、データの「表現形式」がCPUキャッシュヒット率、Zend Allocatorの断片化、そしてガベージコレクション（GC）のライフサイクルに与える致命的な影響を無視することはできない。

本稿では、標準の `ext-json` とバイナリシリアライザーのデファクトである `igbinary` を題材に、Zend Engine内部のハッシュテーブル（HashTable）構造、CPUサイクル、そして実運用における極限の選択基準を低レイヤの視点から解き明かす。

—

1. Zend VMにおけるデータ構造の現実：なぜ「配列」は重いのか

PHPの配列（`array`）は、言語仕様上は連想配列であり、順序付きマップである。しかし、その実体はC言語レベルで実装された極めて洗練されたハイブリッドデータ構造、すなわち `HashTable` である。

Zend Engine（Zend VM）のメモリ空間において、PHPの変数は `zval`（Zend Value）という16バイトの構造体として表現される。

typedef union _zval_u {
zend_long lval; // 整数値
double dval; // 浮動小数点数
zend_string str; // 文字列ポインタ
zend_array arr; // 配列（HashTable）へのポインタ
zend_object obj; // オブジェクトへのポインタ
// … その他リソースや内部構造
} zval;

大規模なデータをシリアライズする場合、Zend VMはこの `HashTable` のリンクリストを走査し、キー名（文字列）と値（`zval`）のペアを直列化していく。ここに、JSONとバイナリフォーマットの運命的な分岐点が存在する。

—

2. JSON（`ext-json`）の内部挙動：文字列化の代償

`json_encode()` を実行した瞬間、Zend VMは以下の重い処理をCPUに強いる。

1. 型変換とエスケープ処理:
内部のバイナリ表現（数値や浮動小数点数、ブール値）を、すべて可読なUTF-8文字列へと文字列表現に変換（Marshal）する。例えば、整数 `123456789` は内部的には8バイトの `zend_long` だが、JSONでは9バイトのASCII文字列 `”123456789″` に変換される。
2. キー名の重複エンコード:
連想配列やオブジェクトをJSON化する際、すべてのキー名（文字列）がペイロード内にそのまま重複して出力される。キーが `”user_id”` であり、それが1万件のレコードに存在する場合、 `”user_id”` という文字列が1万回、ネットワークおよびメモリ上でシリアライズされることになる。
3. Zend Allocatorの断片化:
`ext-json` は、エンコード結果を保持するために動的なメモリバッファをグローバルなヒープからアロケートする。データサイズが巨大になると、メモリの再割り Allocate（`realloc`）が頻発し、Zend Memory Manager（ZMM）のチャンク管理に大きな負荷をかける。

—

3. IGBinaryの衝撃：Zval構造体をダイレクトにバイナリ化するメカニズム

一方、`igbinary` はPHPの拡張モジュールとして動作し、Zend Engineの内部構造を直接ハックするアプローチを取る。

• キー名のディクショナリ化（重複排除）:

`igbinary` は、シリアライズ対象のデータ構造内に出現するキー名やクラス名を一度スキャンし、一意な文字列テーブル（Dictionary）をペイロードのヘッダに構築する。以降の出現箇所では、その文字列全体ではなく、ディクショナリ内の「インデックス（整数）」だけを書き込む。これが、連想配列やオブジェクトが大量に含まれるデータ構造において、サイズを劇的に圧縮できる最大の理由である。

• Zval型の直列化:

値を文字列に変換するのではなく、`zval` の型情報（IS_LONG, IS_STRING, IS_ARRAYなど）と生データをそのままコンパクトなバイナリとしてパックする。これにより、CPUのエンコード/デコード時の型変換コストが極限まで削減される。

—

4. 実測とコード検証：メモリフットプリントとCPUサイクル

百聞は一見に如かず。実際に数千件の複雑なオブジェクト構造を持つデータを生成し、それぞれのメモリ消費量と処理時間を計測する実用的な検証スクリプトを以下に示す。

/

// テスト用のおよそ5000件の複雑な連想配列（ネスト構造）を生成
$complexData = [];
for ($i = 0; $i < 5000; $i++) { $complexData[] = [ 'user_id' => $i,
‘username’ => ‘architect_user_’ . $i,
‘email’ => ‘user_’ . $i . ‘@example.com’,
‘is_active’ => ($i % 2 === 0),
‘metadata’ => [
‘login_count’ => $i 3,
‘last_login’ => ‘202X-10-01 12:00:00’,
‘roles’ => [‘ROLE_USER’, ‘ROLE_API_CLIENT’]
]
];
}

// — 1. JSON シリアライズの計測 —
$memoryBeforeJson = memory_get_usage(true);
$timeStartJson = microtime(true);

$jsonPayload = json_encode($complexData, JSON_UNESCAPED_UNICODE);

$timeEndJson = microtime(true);
$memoryAfterJson = memory_get_usage(true);

$jsonSize = strlen($jsonPayload);
$jsonTime = ($timeEndJson – $timeStartJson) 1000;
$jsonMemory = $memoryAfterJson – $memoryBeforeJson;

// — 2. IGBinary シリアライズの計測 —
// ※ igbinaryがインストールされている環境を想定
if (!extension_loaded(‘igbinary’)) {
die(“Error: ext-igbinary is not loaded.\n”);
}

$memoryBeforeIgb = memory_get_usage(true);
$timeStartIgb = microtime(true);

$igbPayload = igbinary_serialize($complexData);

$timeEndIgb = microtime(true);
$memoryAfterIgb = memory_get_usage(true);

$igbSize = strlen($igbPayload);
$igbTime = ($timeEndIgb – $timeStartIgb) 1000;
$igbMemory = $memoryAfterIgb – $memoryBeforeIgb;

// — 結果出力 —
echo “=== シリアライズ性能比較結果 (要素数: 5000件) ===\n”;
echo sprintf(“JSON – サイズ: %8bytes | 処理時間: %6.2f ms | メモリ変動: %8bytes\n”, $jsonSize, $jsonTime, $jsonMemory);
echo sprintf(“IGBinary – サイズ: %8bytes | 処理時間: %6.2f ms | メモリ変動: %8bytes\n”, $igbSize, $igbTime, $igbMemory);
echo sprintf(“圧縮率(サイズ): %.2f%%\n”, ($igbSize / $jsonSize) 100);

このコードが示す低レイヤの真実

このスクリプトを実行すると、`igbinary` はペイロードサイズにおいてJSONの半分以下、あるいはそれ以上の圧縮率を叩き出し、CPUの処理時間においても（特にデコード時を含めると）圧倒的な優位性を示す。
なぜなら、JSONパーサーは文字列を1文字ずつスキャンしてトークナイザーを通し、AST（抽象構文木）を構築して `zval` にマッピングする気の遠くなるような処理を行うのに対し、`igbinary` はバイナリストリームをそのままZend Memoryにストリーミング復元するだけだからだ。

—

5. アーキテクチャ選定基準：いつ、どちらを使うべきか？

最高峰のアーキテクトとして、すべてのシステムで `igbinary` を盲目的the推しすることはしない。以下のトレードオフを厳密に見極める必要がある。

IGBinaryを採用すべき領域

1. PHP間（マイクロサービス間）の内部通信:
送信側も受信側も完全にPHP（Zend VM）で動いている場合。
2. キャッシュ層（Redis / Memcached）への巨大データストア:
ネットワーク帯域とキャッシュサーバーのRAM容量を極限まで節約したい場合。キー名の重複が多いデータ構造では圧倒的なROI（費用対効果）を発揮する。

JSON（ext-json）を死守すべき領域

1. 外部クライアント（ブラウザ、モバイルアプリ、サードパーティAPI）との通信:
言うまでもないが、HTTPの向こう側にいるクライアントはPHPのバイナリを理解できない。
2. ログ基盤や永続化アーカイバ（長期保存）:
PHPのバージョンアップや `igbinary` の拡張バージョンの差異によって、バイナリフォーマットの互換性が崩壊するリスクを排除したい場合。JSONはテキストであるため、人間が目視でデバッグできるという圧倒的な運用上の利点がある。

—

6. セキュリティの急所：シリアライズが生む「魔界」

最後に、シリアライズ形式を扱う上で絶対に避けて通れないセキュリティハック、PHPオブジェクトインジェクション（Object Injection）について言及しておく。

`serialize()` や `igbinary_serialize()` は、オブジェクトをシリアライズする際、そのクラス名とプロパティの値をバイナリに埋め込む。攻撃者が不正に改ざんされたシリアライズデータをアプリケーションに送り込み、それが `unserialize()` や `igbinary_unserialize()` に渡された場合、Zend VMは恐るべき挙動を示す。

1. マジックメソッドの自動実行:
Zend Engineはオブジェクト復元時に、対象クラスに定義されている `__wakeup()` や `__destruct()` などのマジックメソッドを自動的にコールする。
2. Gadget Chainの構築:
攻撃者は、アプリケーション内に存在する既存のクラス群（Vendor製ライブラリ含む）の中から、プロパティの値を意図的に書き換えることでデストラクタやウェイクアップ時に危険な処理（任意のファイル削除、RCEなど）を実行する「Gadget Chain」を綿密に組み立てる。

防御の極意

• `unserialize()` に信頼できない外部入力を絶対に渡さないこと。
• 代替として、型安全なデータ構造を保証できる JSON や MessagePack、あるいは安全なスキーマを持つプロトコル（Protocol Buffersなど）を使用する。
• もしやむを得ず `unserialize` を使う場合は、第2引数で明示的に許可されたクラス（`allowed_classes`）を指定する防衛的プログラミングを徹底せよ。

// 安全なアンシリアライズの例（クラスを完全に制限する）
$data = unserialize($payload, [‘allowed_classes’ => [MySafeDTO::class]]);

—

結言

PHPのパフォーマンスチューニングとは、突き詰めれば「Zend VMのメモリ空間をにいかに効率よく使わせるか」の戦いである。
`json_encode` と `igbinary_serialize` の選択は、単なる好みの問題ではない。CPUのクロックサイクル、メモリのヒープ断片化、そしてネットワーク帯域を支配する極めて重要なアーキテクチャ上の意思決定なのだ。

低レイヤの構造を掌握した者だけが、真にスケーラブルで頑健なWebシステムを構築できる。コードの向こう側にあるZend Engineの息吹を感じながら、次のシステム設計に臨んでほしい。