Argon2idのメモリハードネスとPHP：OOM Killerの断末魔を回避するリソース制御の極意
テックリードの私たちがコードレビューにおいて最も恐れるべきは、文法エラーやLinterの警告ではない。本番環境の深夜、突如としてログから姿を消すPHP-FPMワーカー、そして内核（Kernel）が冷徹に吐き出す「Out of Memory: Kill process / OOM Killer」というシステムログだ。
現代のWebアプリケーションにおいて、パスワードハッシュのゴールドスタンダードである「Argon2id」は強固なセキュリティをもたらす。しかし、その裏でZend Engineのメモリ空間とOSの仮想メモリ管理機構を激しく揺さぶる時限爆弾になり得ることを理解しているエンジニアはどれほどいるだろうか。
今回は、Argon2idのメモリハードネス（Memory Hardness）がPHPの `memory_limit` およびOSのリソース管理にどのような負荷を強いるのか、その低レイヤの挙動から逆算した最適なパラメータチューニングの極意を解説する。
—
1. 内部挙動の解剖：なぜArgon2idはPHPのメモリを暴食するのか
PHP 7.2以降、`password_hash()` を通じてネイティブサポートされたArgon2idは、GPUやASICを用いた並列攻撃（Side-channel attack / Brute-force）を防ぐために「メモリハード」な設計を採用している。
Zend VMのメモリ空間とC言語ヒープの乖離
PHPエンジニアは `memory_limit` ディレクティブを「PHPスクリプトが消費できる総メモリの上限」として認識している。しかし、ここで大きな落とし穴がある。
`password_hash(…, PASSWORD_ARGON2ID, [‘memory_cost’ => 65536])` が実行された瞬間、内部で何が起きているか。
1. Zend MM（Zend Memory Manager）のバイパス: Argon2のC言語による実装（libsodiumやPHP標準のext/standard/argon2）は、Zend VMの管理下にあるエディタブルなヒープ領域ではなく、OSの `malloc()`（あるいは `mmap()`）を直接叩いて大規模なメモリ領域（ブロック）を確保する。
2. `memory_limit` の死角: つまり、`memory_limit = 128M` と設定されていたとしても、Argon2idが確保するメモリは、Zend MMのカウンターをすり抜けてプロセス全体のRSS（Resident Set Size）を急増させる。
メモリ制限の多重防壁
高負荷なAPIエンドポイント（例えば、数千人の同時ログイン試行）において、各リクエストが勝手に数十MB〜数百MBのCヒープを確保し始めたらどうなるか？
- PHP-FPMの `pm.max_children` × Argon2idの確保メモリ ＝ 物理メモリの枯渇
- 容易にOSのOOM Killerが発動し、最もメモリを食っている（あるいは運悪くヒットした）PHP-FPMの親または子プロセスが無慈悲に刈り取られる。502 Bad Gatewayの嵐である。
—
2. 最適パラメータの導出方程式
OWASP（Open Worldwide Application Security Project）やRFCが推奨するArgon2idのデフォルトパラメータは、一般的なWebサーバーのキャパシティに対してオーバースペックであるケースが非常に多い。
パラメータの構成要素は以下の3つだ。
- `memory_cost` (Kibibytes): 消費メモリ量（例: `65536` = 64MiB）
- `time_cost`: 計算反復回数（CPU負荷）
- `threads`: 並列スレッド数
許容メモリコストの計算ロジック
本番環境のサーバースペック（例: RAM 8GB、`pm.max_children = 50`）を基準に逆算する。
1. OSやNginx、MySQLクライアントバッファ等に割り当てる安全マージンを引く（例: 4GB）。
2. 残りの4GBをPHP-FPMの同時実行数（`pm.max_children = 50`）で割る。
$$4096 \text{ MB} \div 50 = \text{約} 81 \text{ MB/process}$$
3. 1リクエストあたり最大でも80MBを超えないよう、`memory_cost` は最大でも `65536`（64MiB）に制限すべきである。高トラフィックなAPIであれば、あえて `32768`（32MiB）まで下げる決断もアーキテクトとしては極めて正しい。
—
3. 実務で耐えうる堅牢なパスワードハッシュ・サービス実装
ここからは、上記の理論を完全に踏まえ、メモリ不足による例外やシステムダウンを防ぐ安全装置を備えたPHPクラスの実装例を示す。
declare(strict_types=1);
namespace App\Security;
use RuntimeException;
use InvalidArgumentException;
/
- 脆弱性とリソース枯渇を防ぐ、堅牢なパスワードハッシュ管理クラス
/
final class SecurePasswordManager
{
// OWASP推奨をベースにしつつ、PHP-FPMのOOMリスクを抑えた実用的なデフォルト値
private const ARGON2_OPTIONS = [
‘memory_cost’ => 32768, // 32 MiB (高負荷時のOOM Killer発動を抑制)
‘time_cost’ => 4, // 計算コスト
‘threads’ => 2, // 並列スレッド数
];
/
- パスワードのハッシュ化（メモリ消費と例外を完全にコントロール）
- @throws RuntimeException システムリソース不足やハッシュ生成失敗時
/
public function hash(string $plainPassword): string
{
// 念のため、実行時のメモリ空き状況を推測する防衛的コード
$this->assertSystemCanHandleMemory();
// パスワードの長大攻撃（DoS）を防ぐプレチェック
if (mb_strlen($plainPassword, ‘8bit’) > 72) {
throw new InvalidArgumentException(‘パスワードが長すぎます（最大72バイト）。’);
}
// password_hashにArgon2idを指定
$hash = password_hash(
$plainPassword,
PASSWORD_ARGON2ID,
self::ARGON2_OPTIONS
);
if ($hash === false) {
throw new RuntimeException(‘Argon2idによるハッシュ生成に失敗しました。’);
}
return $hash;
}
/
- パスワードの検証
/
public function verify(string $plainPassword, string $hashedPassword): bool
{
// ハッシュアルゴリズムが古くなっている場合や、
// パラメータが強化された場合に自動再ハッシュ（Re-hashing）を促す判定もここで行う
if (password_needs_rehash($hashedPassword, PASSWORD_ARGON2ID, self::ARGON2_OPTIONS)) {
// TODO: 必要に応じてユーザーのバックグラウンド処理でハッシュを更新するロジックを呼ぶ
}
return password_verify($plainPassword, $hashedPassword);
}
/
- 防衛的プログラミング：メモリ枯渇の兆候がある場合に処理を弾く
/
private function assertSystemCanHandleMemory(): void
{
// 現在のスクリプトが消費しているメモリ（バイト）
$currentMemoryUsage = memory_get_usage(true);
// php.iniの memory_limit をバイト数に変換して取得
$memoryLimitStr = ini_get(‘memory_limit’);
$memoryLimit = $this->convertToBytes($memoryLimitStr);
// memory_limit が無限 (-1) でない場合のガード
if ($memoryLimit > 0) {
// Argon2idが要求するメモリ（32MiB = 33,554,432バイト）の余白があるかチェック
$requiredHeadroom = 33554432;
if (($currentMemoryUsage + $requiredHeadroom) >= $memoryLimit) {
// ログに重大な警告を残す
error_log(sprintf(
‘CRITICAL: Memory limit threshold approaching. Usage: %d bytes, Limit: %s’,
$currentMemoryUsage,
$memoryLimitStr
));
throw new RuntimeException(‘サーバーリソースが一時的にひっ迫しています。しばらくしてから再度お試しください。’);
}
}
}
/
- memory_limitの文字列（例: “128M”, “1G”）をバイト数に変換する
/
private function convertToBytes(string $val): int
{
$val = trim($val);
if ($val === ‘-1’) {
return -1;
}
$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;
}
}
—
4. チューニングのまとめとインフラ・アーキテクトとしての心得
コードレベルでの対策を施した上で、インフラ・コンテナ層においても以下の原則を必ず守ること。
1. Kubernetes環境での注意点:
K8sのPodに対して設定する `requests` と `limits` の `memory` は、PHP-FPMの `pm.max_children` × (ベースメモリ ＋ Argon2idの `memory_cost`) を十分に余裕を持たせた値に設定しなければならない。ここをケチると、コンテナごとK8sのOOM Killerに強制終了（Exit Code 137）させられる。
2. キューワーカーの分離:
ログイン処理やパスワードリセットなどの高負荷なハッシュ生成処理がWebリクエストの同期処理として実行されすぎる場合、認証基盤を非同期キュー（RabbitMQ / Redisなど）へオフロードし、専用のPHPワーカープロセス群として切り離すアーキテクチャが極めて有効である。これにより、WebフロントエンドのAPIサーバーがOOMの巻き添えを食らうリスクを物理的に隔離できる。
セキュリティの強度は、リソースの限界を無視して無限に高めることはできない。ハードウェアの物理法則とZend Engine、そしてOSカーネルのメモリ管理の境界線を正しく見極めることこそが、真にプロフェッショナルなWebシステムアーキテクトの仕事である。