PHPシリアライズの極限最適化：IGBinary vs JSON の低レイヤ解析とメモリ空間防衛
PHPにおけるデータ永続化やプロセス間通信（IPC）、あるいはRedisやMemcachedといったKVSへのデータ載せ替えにおいて、シリアライズ処理は避けて通れないボトルネックである。
多くのWebエンジニアは、単に「可読性が高いからJSON」「何となく速そうだからigbinary」という曖昧な基準で選択しがちだ。しかし、Zend VMのメモリ管理構造（`zend_string` や `HashTable`）や、CPUのキャッシュライン効率、そしてセキュリティ境界の観点から見れば、両者の選択はシステムのスループットを決定づける致命的な分岐点となる。
本稿では、IGBinaryとJSONのシリアライズ形式がPHPエンジンの内部でどのようなメモリ消費とCPU負荷を引き起こすのか、Zend VMの低レイヤ挙動から徹底的に解剖する。
—
1. Zend VM内部におけるデータ構造とシリアライズの宿命
PHPの変数実体は、すべて `zval`（Zend Value）という16バイトの構造体に収められている。文字列や配列といった複合データ型は、ポインタを介してヒープメモリ上の実体（`zend_string`, `HashTable` など）を参照する。
JSONシリアライズの低レイヤコスト
JSONはテキストベースのシリアライズ形式である。そのため、次のような重い処理サイクルがZend VM内部で強制される。
1. 型変換とフォーマットのオーバーヘッド:
内部のバイナリ表現（IEEE 754倍精度浮動小数点数や64ビット整数）を、一度人間が読めるASCII/UTF-8の文字列へアスキー変換（`dtostre` や `zend_itoa` 等）しなければならない。
2. `zend_string` の動的アロケーション:
シリアライズされた結果の文字列は、都度 `emalloc()` を経由してヒープ上にバッファを確保される。大規模な配列やオブジェクトをJSON化する場合、このメモリ断片化（Memory Fragmentation）がZend Memory Manager（ZMM）に重度の負荷を与える。
3. デシリアライズ時のパース負荷:
JSON文字列を戻す際、レキサー（字句解析器）とパーサーが文字列を1文字ずつ走査し、再び `zval` 構造体を再構築する。このCPUサイクル消費量は、特に数万件の要素を持つ巨大な多次元配列において無視できないレイテンシを生む。
IGBinaryシリアライズの低レイヤ優位性
一方、`igbinary` はPHPの内部構造（`zval`）に特化したバイナリシリアライザである。
1. 型情報のコンパクトな保持:
PHPの型情報（`IS_LONG`, `IS_STRING`, `IS_ARRAY` 等）を最小限のバイト長でバイナリ化するため、JSONのような文字列表現への変換コストがゼロに近い。
2. キーの重複排除（Header Dictionary）:
これがigbinaryの真骨頂である。連想配列のキー（文字列）が重複している場合、最初の出現時に文字列を保存し、2回目以降はポインタ（ID参照）に置き換える。これにより、特に構造化されたオブジェクトやデータベースのフェッチ結果（同じカラム名が並ぶ配列）において、メモリ消費量を劇的に圧縮する。
—
2. ベンチマークとメモリフットプリントの実測的検証
百聞は一見に如かず。10,000件の複雑な連想配列（オブジェクト含む）を生成し、それぞれのメモリ消費量と実行時間を計測するコードを通じて、エンジンの挙動を確認する。
/
// 厳密なメモリ計測のためガベージコレクションを無効化
gc_disable();
$sampleData = [];
for ($i = 0; $i < 10000; $i++) {
$sampleData[] = [
'id' => $i,
‘uuid’ => ‘a1b2c3d4-e5f6-7890-abcd-ef0123456789’,
‘status_code’ => 200,
‘message’ => ‘The quick brown fox jumps over the lazy dog.’,
‘payload’ => [
‘user_id’ => $i 123,
‘roles’ => [‘ROLE_ADMIN’, ‘ROLE_USER’, ‘ROLE_API’],
‘metadata’ => [‘ip’ => ‘192.168.1.1’, ‘agent’ => ‘ZendEngine/8.3’]
]
];
}
// — JSON Serializer Test —
$jsonStartMemory = memory_get_usage(true);
$jsonStartTime = hrtime(true);
$jsonSerialized = json_encode($sampleData, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE);
$jsonUnserialized = json_decode($jsonSerialized, true);
$jsonEndTime = hrtime(true);
$jsonEndMemory = memory_get_usage(true);
$jsonTimeNs = $jsonEndTime – $jsonStartTime;
$jsonMemDiff = $jsonEndMemory – $jsonStartMemory;
// — IGBinary Serializer Test —
// IGBinaryが有効かチェック
if (!extension_loaded(‘igbinary’)) {
die(“ext-igbinary is not loaded.\n”);
}
$igStartMemory = memory_get_usage(true);
$igStartTime = hrtime(true);
$igSerialized = igbinary_serialize($sampleData);
$igUnserialized = igbinary_unserialize($igSerialized);
$igEndTime = hrtime(true);
$igEndMemory = memory_get_usage(true);
$igTimeNs = $igEndTime – $igStartTime;
$igMemDiff = $igEndMemory – $igStartMemory;
// — 結果出力 —
echo “=== 実行結果比較 (要素数: 10,000) ===\n”;
echo “【JSON】\n”;
echo ” – シリアライズ後バイト長: ” . strlen($jsonSerialized) . ” bytes\n”;
echo ” – 処理時間 (NS): ” . number_format($jsonTimeNs) . ” ns\n”;
echo ” – 内部メモリ変動: ” . number_format($jsonMemDiff) . ” bytes\n\n”;
echo “【IGBinary】\n”;
echo ” – シリアライズ後バイト長: ” . strlen($igSerialized) . ” bytes\n”;
echo ” – 処理時間 (NS): ” . number_format($igTimeNs) . ” ns\n”;
echo ” – 内部メモリ変動: ” . number_format($igMemDiff) . ” bytes\n”;
アーキテククトによる考察
このコードを実行すると、大規模データ（特に配列やオブジェクトの入れ子構造が深いデータ）において、IGBinaryはJSONと比較してデータサイズが30%〜50%程度に縮小し、CPUの処理時間も大幅に短縮されることが確認できる。
理由は明確である。JSONはすべての数値や真偽値までもがテキストの文字列表現（例: `200` は3バイトの文字列）になるが、igbinaryはネイティブの数値型（int64など）のままパッキングするため、ネットワーク帯域（RedisやKVSとの通信）およびZendメモリマネージャのフットプリントを劇的に軽減できるからだ。
—
3. セキュリティハック：オブジェクトインジェクションの脅威と防御
パフォーマンスの観点からIGBinaryは圧倒的優位にあるが、システムアーキテククトとしてセキュリティ上の重大なリスクを無視して採用することはできない。
古くから存在するPHPのネイティブ `serialize()` と同様に、`igbinary_unserialize()` もまた、PHPオブジェクトインジェクション（PHP Object Injection）の脆弱性の標的になり得る。
脆弱性のメカニズム (Gadget Chain)
攻撃者が信頼できない外部入力（悪意あるユーザーが改ざんしたRedisのキャッシュデータなど）を `igbinary_unserialize()` に流し込んだ場合、次のようなプロセスで実行権が奪われる。
1. バイナリデータ内に特定のクラス名とプロパティがエンコードされている。
2. デシリアライズの過程で、Zendエンジンはクラスのインスタンスを復元し、マジックメソッド（`__wakeup()` や `__destruct()` など）を自動的に発火させる。
3. 既存のフレームワークやライブラリ内に存在する「ガジェット（Gadget）」と呼ばれるコード片が連鎖的に呼び出され（Gadget Chain）、最終的にリモートコード実行（RCE）や任意のファイル読み込みを引き起こす。
堅牢な対策コード
信頼できないデータをデシリアライズする際は、必ず `allowed_classes` オプションを指定し、意図しないクラスのインスタンス化をハードウェアレベルでブロックしなければならない。
/
// 信頼できないバイナリデータ（例：Redisから取得）
$taintedPayload = get_untrusted_data_from_redis();
try {
// 【極めて重要】allowed_classesを制限する
// true: すべて許可（危険）
// false: すべて不許可（__PHP_Incomplete_Class として安全にフォールバック、またはエラー）
// array: 許可するクラス名のホワイトリストを指定
$options = [
‘allowed_classes’ => [
SafeValueObject::class,
AnotherAllowedDTO::class
]
];
$data = igbinary_unserialize($taintedPayload, $options);
if ($data instanceof __PHP_Incomplete_Class) {
throw new SecurityException(“不正なクラスのデシリアライズを検知しました。”);
}
} catch (\Throwable $e) {
// ログ記録とインシデント検知システムへの通知
error_log(“Serialization Attack Detected: ” . $e->getMessage());
// フォールバック処理
$data = null;
}
—
4. 大規模データ転送における最適解の選択基準
システムアーキテクチャを設計する際、JSONとIGBinaryのどちらを選択すべきかの境界線は以下の通りである。
| 評価軸 | JSON (`ext-json`) | IGBinary (`ext-igbinary`) |
| :— | :— | :— |
| 可読性・デバッグ容易性 | 高（テキストエディタで直接確認可能） | 低（完全にバイナリ） |
| 相互運用性 (Polyglot) | 極めて高（他言語 Node.js, Python 等と共有可能） | PHP専用（他言語からの読み書きは困難） |
| CPU負荷 (シリアライズ) | 中〜高（文字列変換コスト大） | 低（ネイティブバイナリ変換） |
| メモリ消費量 | 高（文字列バッファの増大） | 極めて低（重複キーの圧縮・最適化） |
| セキュリティリスク | 低（データ構造のみのパース） | 中〜高（オブジェクトインジェクションの危険性あり） |
結論：アーキテククトの布陣
1. APIレスポンスやマイクロサービス間の異言語間通信:
迷わず JSON を選択すべきである。相互運用性とデバッグのしやすさが勝る。
2. 内部KVS（Redis等）のキャッシュ、あるいはPHPプロセス間での巨大なセッション・データ構造の永続化:
セキュリティ境界が同一であり、パフォーマンスとメモリ効率がボトルネックになる環境では、`allowed_classes` を厳格に制御した上で IGBinary を採用するのが、Zend VMの性能を極限まで引き出す唯一の解である。
低レイヤのメモリ構造を支配する者だけが、高負荷に耐えうる真のWebシステムを構築できる。感覚的なコーディングを捨て、Zendエンジンの鼓動を感じながらコードを紡ぎだせ。