なぜ、あなたのNode.jsは「突然」重くなるのか？Clinic.jsでイベントループの迷宮を可視化する
こんにちは。日々、コードという名の迷宮を解き明かしている皆さん。
Node.jsで開発をしていると、避けて通れないのが「なぜか特定のルートだけレスポンスが遅い」「高負荷時にCPU使用率が100%に張り付く」という怪現象です。多くのエンジニアはここで「とりあえずログを増やす」という対症療法に走りますが、それこそが泥沼の入り口です。
Node.jsの心臓部は「シングルスレッド」という非常に繊細な仕組みで動いています。このイベントループをたった一つの重い同期処理がブロックした瞬間、あなたのサービスは沈黙します。
今回は、この「見えないボトルネック」を白日の下に晒すための最強の武器、Clinic.jsについてお話ししましょう。
—
1. Clinic.jsとは何か？：勘に頼るデバッグからの脱却
Clinic.jsは、Node.jsの実行状態を「可視化」する診断ツール群です。特に今回紹介する `Clinic Flame` は、CPUの利用状況を「Flame Graph（火炎グラフ）」として描画します。
Flame Graphの凄いところは、「どの関数が、どれだけの時間を消費し、どの関数に呼び出されているか」を横幅の長さで直感的に教えてくれる点にあります。横幅が広い＝CPUを占有している、つまり「そこがボトルネックだ」と一目で分かるのです。
—
2. 導入：まずは「敵」を可視化する準備
まずは、あなたの環境にClinic.jsを迎え入れましょう。グローバルインストールが最も手軽です。
Clinic.js本体をインストール
npm install -g clinic
依存関係を確認（グラフ生成に必要）
内部でd3.js等を用いてブラウザ上でインタラクティブな描画を行います
次に、ボトルネックを意図的に作り出した「問題児」のサンプルコードを作成します。わざと重い計算（階乗計算など）を同期的に実行させてみましょう。
`server.js` というファイルを作成してください。
const http = require(‘http’);
// 意図的にCPUをブロックする重い同期処理
function heavyTask() {
let count = 0;
// 1億回ループする同期的な処理（イベントループを完全に止める）
for (let i = 0; i < 1e8; i++) {
count += i;
}
return count;
}
const server = http.createServer((req, res) => {
if (req.url === ‘/slow’) {
heavyTask(); // ここがボトルネック
res.end(‘Done!’);
} else {
res.end(‘Hello, Fast World!’);
}
});
server.listen(3000, () => console.log(‘Server running on port 3000’));
—
3. 実践：Flame Graphでボトルネックを特定する
では、このサーバーをClinic.jsの監視下で起動します。
clinic flameコマンドでサーバーを実行
clinic flame — node server.js
この状態で、別のターミナルから `curl http://localhost:3000/slow` を叩いて負荷をかけてください。その後、Ctrl+Cでサーバーを止めると、自動的に解析が始まり、ブラウザが立ち上がってグラフが表示されます。
グラフの読み方：
- 横軸の長さ： その関数がCPUを占有していた時間の長さ（ここが重要！）
- 縦軸の積み重なり： 関数の呼び出しスタック（一番上が実行中の関数）
もし、`heavyTask` の部分がグラフ上で横に大きく広がっていれば、成功です。それがあなたのアプリケーションの「最大の罪人」です。
—
4. 現場で役立つ最適化手法：非同期への逃避
ボトルネックを特定できたら、あとは改善するだけです。Node.jsでCPU負荷が高い処理を扱う際の鉄則は、「イベントループをブロックしないこと」です。
改善策：Worker Threadsの活用
重い処理は、メインのイベントループから切り離し、別スレッド（Worker Threads）に投げましょう。
const { Worker } = require(‘worker_threads’);
// heavyTaskを別ファイルに切り出し、Workerとして実行する
function runHeavyTask() {
return new Promise((resolve, reject) => {
const worker = new Worker(‘./worker.js’);
worker.on(‘message’, resolve);
worker.on(‘error’, reject);
});
}
このように設計を変えるだけで、メインスレッドは常に新しいリクエストをさばける状態を維持できます。Clinic.jsを再度実行してみれば、先ほどまで横に長かった `heavyTask` の棒が消え、アプリケーション全体が滑らかに動いていることが確認できるはずです。
—
最後に：なぜこれが必要なのか
エンジニアの仕事は、コードを書くことではなく「システムの健全性を維持すること」です。ツールを使わず、勘と経験だけで「ここが重いかな？」と推測するのは、真っ暗闇の中で針に糸を通すようなもの。
Clinic.jsという「懐中電灯」を持てば、迷う時間は激減します。そして浮いた時間で、あなたはもっとクリエイティブで楽しい機能の実装に集中できるのです。
「なぜか重い」を「ここが重い、だからこう直す」と言えるエンジニアへ。今日からその第一歩を踏み出しましょう。
何か詰まったら、いつでも聞いてください。あなたの開発効率が最大化されるその瞬間まで、私はここにいますから。