Node.jsメモリ管理の「暗黒面」を攻略する：パフォーマンスを極限まで引き出すプロファイリングの技術
「なぜか時間が経つとコンテナが再起動する」「リクエスト数が増えるとレスポンスが徐々に遅延する」。これはNode.jsエンジニアが一度は直面する悪夢です。Node.jsはシングルスレッド故に、メモリリークが即座にイベントループのスタックを圧迫し、ガベージコレクション（GC）の暴走を引き起こします。
今回は、単なる入門を超えて、実務で遭遇する「見えないメモリリーク」を解体し、プロダクション環境の安定性を確保するための深層技術を伝授します。
—
1. なぜ「Heap Snapshot」だけでは足りないのか？
多くの開発者は、Chrome DevToolsでHeap Snapshotを1つ取って満足します。しかし、実務において真に重要なのは「時間の経過による変化（Delta）」です。
現場で実践すべき「2点比較法」
メモリリークを特定する際、必ず以下の手順を踏んでください。
1. ベースラインの取得: アプリ起動直後、アイドル状態で1回目を保存。
2. 負荷の再現: 該当のエンドポイントへ負荷テスト（`autocannon`等を使用）を数分間実行。
3. GCの強制発動: プロファイラからGCを手動実行し、不要なオブジェクトを解放させる。
4. 差分比較: 2回目のSnapshotを取得し、Chrome DevToolsの「Comparison」ビューで「Allocation Delta」を追う。
ここで増え続けているのは「クロージャ」か「グローバルな配列」か、あるいは「EventEmitterのリスナー」か。これを見極めるのがアーキテクトの仕事です。
—
2. 開発効率を異次元へ引き上げるツールセットと設定
必須のプロファイリングツールと設定
`v8-profiler-next` を使えば、コード内から任意のタイミングでヒープをダンプできます。
// heap-dump-util.js
const v8 = require(‘v8’);
const fs = require(‘fs’);
/
- 実務で必須の「条件付きダンプ」
- メモリ使用量が一定値を超えた瞬間に自動でダンプを吐かせることで、
- 再現困難なリークをキャッチする
/
const dumpHeap = () => {
const filename = `heap-${Date.now()}.heapsnapshot`;
// V8のネイティブ機能でヒープをファイルに書き出し
v8.writeHeapSnapshot(filename);
console.log(`Snapshot saved: ${filename}`);
};
// 閾値監視の例（実際にはPM2のイベント等と組み合わせるのがベスト）
if (process.memoryUsage().heapUsed / 1024 / 1024 > 1000) {
dumpHeap();
}
チーム開発を加速させる `.vscode/settings.json` の共有化
チームメンバー間でプロファイリング環境を統一するため、以下の設定をリポジトリの `.vscode/settings.json` に含めてください。
{
“javascript.suggest.completeFunctionCalls”: true,
“node-debug.sourceMaps.enabled”: true,
“debug.node.autoAttach”: “on”,
// 開発中のメモリ監視用ショートカットをチームで共通化
“tasks”: {
“tasks”: [
{
“label”: “Profile Memory”,
“type”: “shell”,
“command”: “node –inspect-brk server.js”,
“group”: “none”
}
]
}
}
—
3. 現場で震えるほど役立つ「リークの温床」ベスト3
① EventEmitterの墓場
最も多いのは、リクエストごとにリスナーを追加し、`removeListener`を忘れるパターンです。
- 症状: 接続数に応じてメモリが右肩上がりに増加。
- 解決: `once`を使用するか、`AbortController` を活用してクリーンアップ処理を確実に実装してください。
② 不当なグローバルキャッシュ
「あとで使うから」という理由で実装されたグローバルな `Map` や `Object`。
- 対策: `lru-cache` などのライブラリを導入し、最大サイズ（max）とTTL（有効期限）を必ず設定してください。キャッシュに上限がないシステムは、いずれ必ず死にます。
③ クロージャによるスコープの固定
関数内で定義された大きなオブジェクトを、内側の関数が保持し続けると、ガベージコレクタはそのメモリを解放できません。
- 対策: 不要になったタイミングで、該当の変数を `null` で上書きし、参照を断ち切る意識を持つこと。
—
4. チーフエンジニアからの提言：CI/CDでの「メモリ回帰テスト」
「メモリリークをリリース後に見つける」のは、もはや情弱の所業です。CIパイプラインに、以下のテストを組み込んでください。
.github/workflows/perf-test.yml
jobs:
memory-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Load Test
# autocannonで擬似的な負荷をかけ、終了後にメモリ消費量をチェック
run: |
npm install -g autocannon
node –max-old-space-size=512 server.js &
autocannon -d 30 http://localhost:3000
# プロセスのメモリ消費量が上限を超えたらExit 1で落とす設定を記述
最後に
メモリプロファイリングは「宝探し」です。Snapshotの中に隠れた「誰が参照を離さないのか」という真犯人を特定できた時の快感は、エンジニアにとって最高のご褒美です。
今日からあなたのIDEに「プロファイリング用のタスク」を仕込み、チーム全員が「メモリを意識してコードを書く」文化を醸成してください。安定した実行環境は、優れたアーキテクチャからではなく、地道なプロファイリングの積み重ねから生まれるのです。