Argon2idの物理制約：Zend VMとLinuxカーネルの境界線で何が起きているのか
Webシステムのスケールにおいて、認証レイヤーの堅牢性はシステムの生死を分ける。現代のパスワードハッシュのデファクトスタンダードである「Argon2id」は、サイドチャネル攻撃とGPUによる並行ブルートフォース攻撃の両方に対する最強の盾である。
しかし、この「メモリハードネス（Memory-hardness）」という強力な特性こそが、PHPの単一プロセスモデル、Zend VMのメモリ管理、そしてLinuxカーネルのOOM（Out-Of-Memory）Killerとの間で、最も危険なリソース競合を引き起こす爆弾となり得る。
本稿では、Argon2idのメモリ消費がPHPのプロセス空間にどのような物理的負荷を強いるのか、Zend VMのメモリ管理機構およびOSカーネルの挙動を低レイヤから解き明かし、高負荷環境を生き抜くための極限のチューニング手法を提示する。
—
1. Argon2idのメモリハードネスとZend VMのメモリ管理の衝突
構造化されたメモリ確保とZend Memory Manager (ZMM)
PHPで `password_hash()` を呼び出し、アルゴリズムに `PASSWORD_ARGON2ID` を指定した瞬間、Zend Engine内部では何が起きているのか。
Argon2idは、指定されたメモリサイズ（デフォルトでは数MiBから数十MiB単位）の連続したメモリ領域（ブロックマトリクス）を確保し、CPUキャッシュを意図的にヒットさせないメモリアクセスパターン（Data-dependent indexing）を高速に繰り返すことで、ASICやFPGAによる並行計算コストを跳ね上げる。
ここで問題となるのが、Zend Memory Manager（ZMM）とOSのアロケータ（glibcの `ptmalloc` 等）の関係だ。
1. ZMMのチャンク管理: PHPはリクエスト開始時にOSからまとまったメモリ（チャンク：通常2MB単位）を `emalloc()` 用に確保する。
2. 巨大な一時バッファ: Argon2idが要求するメモリ（例: `memory_cost = 65536`（64MB）など）は、ZMMのヒープ内だけで完結しない場合がある。ZMMは一定サイズを超えるアロケーションを `emalloc()` から直接 `malloc()`（OSへのシステムコール）へとバイパスする。
3. リクエスト終了時の解放遅延: リクエストが終われば `efree()` によってメモリは解放されるが、高スループットなAPIサーバー環境（PHP-FPMの `pm.max_children = 100` 等）において、複数のリクエストが同時に64MB以上のバッファを要求・破棄し続けると、メモリアリーナの断片化（Fragmentation）が急速に進行する。
`memory_limit` との不可避な数学的矛盾
PHPの `php.ini` における `memory_limit` は、ZMMが追跡する `emalloc()` の総量を制限するものであり、OSレベルの物理メモリ消費量（RSS: Resident Set Size）そのものではない。
しかし、Argon2idの内部計算用バッファは `emalloc()` 経由、あるいはネイティブの `malloc()` 経由で動的に確保される。もし `memory_limit = 128M` に設定されている環境で、複数のリクエストが同時に重なり、かつ誤った巨大な `memory_cost` を設定した場合、Zend VMの制限に到達する前に、PHP-FPMプロセス全体のRSSが膨れ上がり、LinuxカーネルのOOM Killerの標的となる。
—
2. LinuxカーネルのOOM KillerとPHP-FPMプロセスの非対称性
高負荷時における最悪のシナリオは、単なるHTTP 500エラーではない。Linuxカーネルがメモリ不足を検知し、最もメモリを食っているプロセスを無慈悲に殺害（OOM Kill）する現象である。
oom_score_adj の罠
PHP-FPMのマスタープロセスおよびワーカープロセスは、通常、親プロセスから環境を引き継ぐ。もしシステム全体のメモリが枯渇しかけたとき、カーネルは `/proc/[pid]/oom_score_adj` の値に基づいてどのプロセスを屠るかを決定する。
厄介なことに、動的な負荷分散環境において、ログイン集中（Login Storm）が発生した瞬間、特定のFPMワーカーがArgon2idの計算でピークメモリを叩き出し、その瞬間を狙われたかのようにFPMワーカーが次々とカーネルに殺害される。
マスタープロセスが巻き込まれなくとも、ワーカーが突然SIGKILLで強制終了させられた場合、Nginxなどのリバースプロキシ側では「502 Bad Gateway」が返り、クライアントの認証セッションは宙に浮く。
—
3. 実践：高負荷環境におけるArgon2idパラメータの極限最適化
セキュリティ（耐ブルートフォース性）とスループット（CPU/メモリリソースの許容量）の均衡点（Sweet Spot）をコードと設定で導き出さなければならない。
以下のPHPコードは、現在のマシンスペックとPHP-FPMのコンカレンシーを動的に考慮し、安全かつ堅牢にArgon2idを実行するためのラッパー実装の断片である。
/
public static function hash(string $password): string
{
// サーバーの物理メモリとFPMの並行数から動的にコストを制限する
// 例: memory_cost = 65536 (64MB) は、同時リクエスト数が多い環境では危険を伴う
$options = [
‘memory_cost’ => 1 << 16, // 64 MiB (Zend VMおよびOSのRSSバジェットを考慮)
'time_cost' => 4, // 反復回数
‘threads’ => 2, // 並行スレッド数（CPUコア数とFPMプロセス数で調停）
];
// 実行前のメモリ制限チェック（防衛的プログラミング）
self::assertMemorySafety($options[‘memory_cost’]);
$hash = password_hash($password, PASSWORD_ARGON2ID, $options);
if ($hash === false) {
throw new \RuntimeException(‘Argon2id hashing failed due to internal engine constraints.’);
}
return $hash;
}
private static function assertMemorySafety(int $requiredMemoryBytes): void
{
// 現在のmemory_limitを取得し、バイトに変換
$memoryLimit = ini_get(‘memory_limit’);
$limitBytes = self::toBytes($memoryLimit);
if ($limitBytes !== -1) {
// Zend VMのメモリ制限の50%以上を単一のハッシュ計算が消費しないようガード
$currentUsage = memory_get_usage(true);
if (($currentUsage + $requiredMemoryBytes) > ($limitBytes 0.75)) {
// ログに深刻な警告を出力し、処理を拒否または縮退させる
error_log(‘CRITICAL: Argon2id memory cost exceeds safe threshold of memory_limit.’);
throw new \RuntimeException(‘System is under high memory pressure. Authentication deferred.’);
}
}
}
private static function toBytes(string $val): int
{
$val = trim($val);
$last = strtolower($val[strlen($val) – 1] ?? ”);
$num = (int)$val;
switch ($last) {
case ‘g’:
$num = 1024;
// no break
case ‘m’:
$num = 1024;
// no break
case ‘k’:
$num = 1024;
}
return $num;
}
}
パラメータチューニングの指針
RFCやOWASPが推奨するデフォルト値（例: `memory_cost = 65536` [64MB]）は、単一のCLIスクリプトや低トラフィックなサイトにおいては完璧だが、数千〜数万の同時接続を捌くPHP-FPM環境では凶器になり得る。
1. `memory_cost` の下方調整:
もしFPMの `pm.max_children` が `200` であり、すべてのワーカーが同時にログイン要求を受け付けた場合、$200 \times 64\text{MB} = 12.8\text{GB}$ のメモリが瞬時に要求される。実メモリがこれを下回っていれば即座にOOM Killerが発動する。
高負荷環境では `32768` (32MB) あるいは `16384` (16MB) に落とし、その分 `time_cost`（反復回数）を増やすことで、メモリ負荷を抑えつつCPUコストでセキュリティを担保するトレードオフが極めて有効である。
2. PHP-FPMのプロセスプールの分離:
認証処理（ログイン・パスワード変更）を行うエンドポイントを、通常のWebリクエストとは別の独立したPHP-FPMプール（例: `www-auth.sock`）に切り出すべきだ。これにより、認証処理の重いメモリ消費やCPUバウンドな処理が、通常の軽量なAPIや静的レンダリングのレスポンスタイムに影響を与えるのを物理的に隔離できる。
—
4. アーキテクトの結論
Argon2idのメモリハードネスはセキュリティの要石であると同時に、PHPのプロセスモデルとメモリ管理機構にとっては最もアグレッシブな負荷要因の一つである。
「なぜか特定時間帯にFPMワーカーがクラッシュする」「謎の502エラーが多発する」という現象の裏には、Zend VMのヒープ外で展開される巨大なハッシュバッファと、Linuxカーネルの冷徹なOOMのアルゴリズムが存在している。
フレームワークのデフォルト値を盲信するのではなく、自社システムのトラフィックパターン、FPMのプロセス数、そしてカーネルのメモリ境界を正確に逆算し、コードとインフラストラクチャの両面からリソース境界を支配すること。それこそが、真に堅牢なWebシステムアーキテクチャの条件である。