PHPを掌握する極限の知見：IGBinary vs JSON――巨大オブジェクトのデシリアライズにおけるCPUキャッシュ効率の真実
コードレビュー中、JSONとIGBinaryのどちらを選ぶべきかという議論になったとき、「JSONは人間が読めるからデバッグしやすい」「IGBinaryはバイナリだから速いんでしょ」という表面的な理由で決裁を下すシニアエンジニアは、私のチームにはいらない。
Webアプリケーションのパフォーマンスボトルネックが、I/OバウンドからCPUバウンド、さらには「CPUキャッシュミス（Cache Miss）」にシフトしている現実を直視すべきだ。数メガバイトに及ぶ巨大なドメインオブジェクトやエンティティグラフをキャッシュストア（RedisやMemcachedなど）から引き剥がし、PHPのメモリ空間へ復元するデシリアライズ処理。この瞬間、Zend VMの内部とCPUのL1/L2/L3キャッシュの間で何が起きているか。
今日は、シリアライズ形式のメモリレイアウトがCPUキャッシュ効率に与える影響を低レイヤの視点から解剖し、実務で絶対に踏み抜いてはならない設計の極意を伝授する。
—
1. Zend VMのメモリ空間とシリアライズの宿命
PHPのオブジェクトや配列の本質は、`zval`（Zend Value）構造体と、動的なキー・バリューを管理する`HashTable`（BUCKET構造体）の塊である。
JSONはテキストベースのフォーマットだ。`{“id”:1, “name”:”foo”}` のような文字列をパースする際、JSON拡張（`ext-json`）は文字をスキャンし、数値をパースし、動的に`zval`を割り当て、`HashTable`のハッシュ関数を叩いてバケットをスロットにねじ込んでいく。
このプロセスにおける最大の問題は、「ポインタの奔流（Pointer Chasing）」である。
[JSON String]
↓ (Parser)
[バラバラのヒープ領域に散らばった zval] ←→ [ポインタを辿る] ←→ [HashTableのバケット]
テキストをパースした結果生成されるメモリ上のオブジェクトグラフは、ヒープ領域（zend_mm_heap）のあちこちに散らばる。ポインタが指す先はメモリの連続領域ではなく、ランダムなアドレスだ。
CPUキャッシュラインの残酷な現実
現代のCPU（x86_64やARM64）は、メインメモリ（DRAM）からデータを読み込む際、通常64バイトの「キャッシュライン」単位でL1/L2キャッシュに読み込む。
しかし、JSONデシリアライズによって生成されたオブジェクト群のメモリレイアウトがバラバラ（ポインタがあちこちを向いている）であると、CPUが次に処理すべきデータをフェッチしようとしたときに「L1/L2キャッシュミス」が頻発する。CPUはキャッシュにデータがないため、レイテンシの塊であるメインメモリからのロードを待たされ、パイプラインが完全にストップする（Stall）。
これが、巨大なJSONをデシリアライズした際にCPU使用率が跳ね上がり、想定以上にスループットが伸びない根本原因だ。
—
2. IGBinaryのバイナリレイアウトと空間局所性
一方、`ext-igbinary` は、PHPの内部データ構造（`zval`、`HashTable`）をそのままバイナリとしてシリアライズする。
IGBinaryの真骨頂は、オブジェクトのプロパティ名（文字列）の重複を排除する内部辞書（String Table）を持ちつつ、データ構造を「メモリ上で連続したバイト列」としてシリアライズ・デシリアライズする点にある。
デシリアライズ時、IGBinaryはヒープ上で連続したメモリブロックを一度に確保し、そこにバイナリデータを一気に流し込む。結果として、生成される`zval`や`HashTable`のバケットは、メモリ空間上で極めて近接した位置（空間局所性：Spatial Locality）に配置される。
[IGBinary Payload]
↓ (Sequential Unpacking)
[連続したメモリブロック上に並んだ zval / HashTable] → (L1/L2キャッシュヒット率 爆発的向上)
この違いは、数万件の要素を持つ巨大なオブジェクトグラフを処理する際、数倍から十数倍の実行速度の差、そしてCPUのストールサイクルの圧倒的な差となって現れる。
—
3. 実務で検証する：JSON vs IGBinary ベンチマーク＆メモリ解析
百聞は一見に如かず。実際に巨大な構造体（10,000要素を持つ連想配列とオブジェクトの混在グラフ）を用いて、メモリ消費量とデシリアライズ効率を比較する実用的なコードを提示する。
以下のコードは、本番環境のキャッシュレイヤ（Redis等）へ投入するデータを模したものである。
/
class PerformanceInspector
{
private array $largePayload = [];
public function __construct(int $itemCount = 10000)
{
// 意図的にネストの深い複雑なオブジェクトグラフを構築
for ($i = 0; $i < $itemCount; $i++) {
$this->largePayload[] = [
‘id’ => $i,
‘uuid’ => md5((string)$i),
‘attributes’ => [
‘score’ => mt_rand(0, 100000) / 100,
‘is_active’ => ($i % 2 === 0),
‘tags’ => [‘alpha’, ‘beta’, ‘gamma’, ‘delta’],
],
‘metadata’ => ‘Server_’ . ($i % 16) . ‘_Region_AP_Northeast_1’,
];
}
}
public function inspect(): void
{
// 1. JSON シリアライズ / デシリアライズ
$startMemory = memory_get_usage(true);
$startTime = hrtime(true);
$jsonSerialized = json_encode($this->largePayload, JSON_THROW_ON_ERROR);
$jsonRestored = json_decode($jsonSerialized, true, 512, JSON_THROW_ON_ERROR);
$jsonTime = (hrtime(true) – $startTime) / 1e6; // ミリ秒
$jsonMemory = memory_get_usage(true) – $startMemory;
$jsonPayloadSize = strlen($jsonSerialized);
// 2. IGBinary シリアライズ / デシリアライズ（要 ext-igbinary）
if (!extension_loaded(‘igbinary’)) {
echo “igbinary extension is not loaded.\n”;
return;
}
// ガベージコレクションを強制実行し、公平なメモリ測定を行う
gc_collect_cycles();
$startMemory = memory_get_usage(true);
$startTime = hrtime(true);
$igSerialized = igbinary_serialize($this->largePayload);
$igRestored = igbinary_unserialize($igSerialized);
$igTime = (hrtime(true) – $startTime) / 1e6;
$igMemory = memory_get_usage(true) – $startMemory;
$igPayloadSize = strlen($igSerialized);
// 結果出力
$this->formatOutput(‘JSON’, $jsonPayloadSize, $jsonTime, $jsonMemory);
$this->formatOutput(‘IGBinary’, $igPayloadSize, $igTime, $igMemory);
}
private function formatOutput(string $driver, int $sizeBytes, float $timeMs, int $memoryBytes): void
{
echo “=== [Driver: {$driver}] ===\n”;
echo sprintf(” Payload Size : %.2f KB\n”, $sizeBytes / 1024);
echo sprintf(” Execution Time : %.4f ms\n”, $timeMs);
echo sprintf(” Memory Usage : %.2f KB (VM Heap delta)\n”, $memoryBytes / 1024);
echo “————————————————–\n”;
}
}
// 実行
(new PerformanceInspector(15000))->inspect();
このコードから読み解くべき技術的示唆
1. ペイロードサイズ（ネットワークI/Oの削減）: `igbinary` はテキストベースのJSONに比べ、オーバーヘッドが極めて少なく、シリアライズ後のバイナリサイズが小さくなる傾向にある（特にキー名の重複排除が効くため）。これにより、Redisなどのネットワーク転送量を劇的に削減できる。
2. CPUキャッシュ効率（処理速度の差）: 数万件のループやハッシュテーブル構築をPHPの汎用パーサにやらせるJSONに対し、C言語レベルでメモリブロックを連続確保して復元するIGBinaryは、CPUキャッシュヒット率の高さから処理時間が数分の一に短縮される。
—
4. アーキテクチャ設計における厳格なルール：JSONか、IGBinaryか
リードアーキテクトとして、プロジェクトのデータ永続化層（Cache / Queue）を設計する際、以下の厳格なトレードオフルールをチームに徹底させている。
ルール A: 外部システム連携・APIレスポンスは「JSON」を強制する
- 理由: 他言語（Go, Node.js, Python）との相互運用性、および人間によるデバッグの容易性が最優先されるため。API境界においてパフォーマンス最適化を理由に独自バイナリを持ち込むのは、疎結合の原則に反する技術的負債となる。
ルール B: 内部キャッシュ（Redis / APCu）の巨大オブジェクトストアには「IGBinary」を採用する
- 理由: アプリケーション内部だけで完結するキャッシュストアに数メガバイトのドメインモデル配列やオブジェクトグラフを格納する場合、JSONのパースコストとCPUキャッシュミスはスケーラビリティの致命的なボトルネックになる。
- 条件: デプロイ時に全Web/Workerサーバーで `ext-igbinary` が確実に有効化されていることをコンテナビルドパイプライン（Dockerfile）で保証すること。
—
5. 堅牢なキャッシュリポジトリの実装例（実務仕様）
上記の方針をコードに落とし込み、シリアライズドライバを切り替え可能にしつつ、メモリ安全性に配慮したリポジトリパターンの実装例を示す。
/
class RobustCacheManager
{
private \Redis $redis;
private SerializerInterface $serializer;
public function __construct(\Redis $redis, SerializerInterface $serializer)
{
$this->redis = $redis;
$this->serializer = $serializer;
}
public function set(string $key, mixed $value, int $ttl = 3600): void
{
// 内部でバイナリシリアライズを行い、CPUキャッシュ効率と転送量を最適化
$payload = $this->serializer->serialize($value);
$this->redis->setex($key, $ttl, $payload);
}
public function get(string $key): mixed
{
$payload = $this->redis->get($key);
if ($payload === false) {
return null; // Cache Miss
}
// 高速かつメモリ連続性を保ったままデシリアライズを実行
return $this->serializer->unserialize($payload);
}
}
// — 使用例 —
// $redis = new \Redis();
// $redis->connect(‘127.0.0.1’, 6379);
// $cacheManager = new RobustCacheManager($redis, new IgbinarySerializer());
// $cacheManager->set(‘user_domain_graph_9982’, $hugeDomainObject);
—
結びにかえて：低レイヤへの視座を持て
PHPは「動的言語だから遅い」「メモリ管理を意識しなくてよい」という神話は、何年も前に崩れ去っている。数百万リクエストを捌く高負荷なWebシステムにおいて、フレームワークの薄皮を剥くよりも、シリアライズ形式の選定によるCPUキャッシュ効率の最適化の方が、サーバーのCPU負荷を根本から引き下げる特効薬となる。
コードを書くとき、あなたの脳裏に「今、このデータ構造はZend VMのヒープ上でどう配置され、CPUキャッシュラインをどれだけ汚しているか」が描かれているか。その解像度こそが、一流のWebシステムアーキテクトと、ただコードを動かしているだけのプログラマーを分ける境界線だ。設計の根拠をロジカルに突き詰め、圧倒的なパフォーマンスのシステムを構築してほしい。