2026 年 5 月 14 日、InfoQ が Pinterest Engineers Eliminate CPU Zombies to Resolve Production Bottlenecks を報じました。Pinterest のエンジニアリングチームが発見した 「CPU Zombies」は、CPU 使用率は低いのに スレッドが意図せず眠ったまま停滞し、スループットが頭打ちになる現象です。古典的なボトルネック解析（CPU / メモリ / I/O 監視）では見つからない 「サイレントな停滞」を、継続プロファイリングと根本原因分析で根絶しました。
受託で中堅企業のサービスサイトや基幹システムを運用する立場では、これは 「ハード増設しても効かない遅延」として頻発する症状です。これまで Pyroscope 2 継続プロファイリング受託 で扱った 観測コストを抑える継続プロファイリングの技術スタックが、CPU Zombies 検出のためにも価値を発揮します。本記事では弊社が提供する 「パフォーマンス SRE 監査 + ボトルネック解消代行」 パッケージを整理します。
なぜ「CPU 使用率は低いのに遅い」が中堅企業で頻発するか
| 構造 | 古典的ボトルネック | CPU Zombies |
|---|---|---|
| 検知方法 | CPU / メモリ / I/O のメトリクス | スレッドダンプ + プロファイル |
| 症状 | リソース 100% に張り付く | リソースは余裕、スループットだけ低下 |
| 誤判断 | 「スケールアップで解決」 | スケールアップで悪化することも |
| 発症条件 | 高負荷 | 中負荷でも発症 |
| 原因の多くは | DB / ネットワーク | ロック / 待ち / コンテキスト切替 |
| 修正コスト | インスタンス追加 | コード修正 + プロファイル分析 |
つまり 「サーバ増設では解決しない遅延」は CPU Zombies の典型です。受託会社にとっては 「サーバを増やしてください」と言われたら本当の原因を見抜く」ことが最大の付加価値になります。Core Web Vitals 改善と組み合わせる場合は Core Web Vitals 改善ガイド と統合可能です。
CPU Zombies 解析が変える 3 つの構造
構造 1: 「メトリクス監視」から「継続プロファイリング」へ
CPU 使用率や RPS だけでは捕まりません。コール スタック レベルの継続観測が必要です。これは Pyroscope 2 継続プロファイリング受託 で扱った技術スタックの延長で実装可能です。
構造 2: 「サーバ増設」から「コード修正」へ
ボトルネックが ロック / 待ち / 非同期処理ミスに起因する場合、サーバ増設はコストを増やすだけです。受託契約には 「スケールアップ判断より先にプロファイル分析」を盛り込みます。
構造 3: 「リリース後監視」から「リリース前プロファイル」へ
CPU Zombies は本番だけ発症することが多いですが、ステージング負荷試験 + プロファイル比較で予兆を捕捉できます。CI 標準化が次の差別化です。
受託で提供する「パフォーマンス SRE 監査 + ボトルネック解消」5 フェーズ
フェーズ 1: 現状観測体制の棚卸し（2 週間）
顧客環境の **「メトリクス / トレース / プロファイル / ログ」の 4 種類を棚卸しし、「どこに穴があるか」**を明らかにします。多くの中堅企業はプロファイル系が未整備です。
フェーズ 2: 継続プロファイリング基盤構築（3〜4 週間）
Pyroscope / Cloud Profiler を導入し、Java / Go / Node.js / Python全プロセスでプロファイル取得を開始します。
フェーズ 3: ベースライン構築 + CPU Zombies 検出（4〜6 週間）
通常時のコールスタック分布を ベースライン化し、「使用率が低いのに待ちが長い」異常を自動検出するルールを構築します。
フェーズ 4: 修正サイクル運用化（6〜8 週間）
検出された Zombies を 「重要度 × 修正コスト」でマトリクス化し、スプリントに組み込みます。ロック競合・接続プール枯渇・非同期処理ミスが主な原因です。
フェーズ 5: 月次パフォーマンスレビュー（継続）
月次で 「P50/P95/P99 レイテンシ / スループット / Zombies 件数 / 改善率」を顧客経営層に報告します。
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| 継続プロファイリング | Pyroscope 2 / Cloud Profiler | Datadog Continuous Profiler |
| 分散トレース | OpenTelemetry + Tempo | Datadog APM |
| メトリクス | Prometheus + Grafana | Datadog Metrics |
| ログ | Loki / Cloud Logging | Datadog Logs |
| 負荷試験 | k6 / Locust | JMeter |
| アラート | Grafana + PagerDuty | Opsgenie |
| ダッシュボード | Grafana + Looker Studio | Datadog Dashboards |
これは Netflix Model Lifecycle Graph 受託 MLOps ガバナンス で扱った 「モデル × インフラ」横断観測ともシームレスに繋がります。
どの案件に必要か / 不要か
| 必要な案件 | 不要な案件 |
|---|---|
| 月間 PV 30 万以上 / 月間処理数 100 万件以上 | 内部限定システム |
| Web / API のレイテンシが SLA に直結 | 非リアルタイム処理のみ |
| Java / Node.js / Go / Python の本番運用 | 完全マネージド SaaS のみ |
| サーバ増設しても遅延が改善しない | リソース余裕大 |
| 経営層がパフォーマンスを KPI 化 | KPI 未整備 |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 対象サービス | 監査対象システム一覧 | 範囲外の責任 |
| SLO（P95 レイテンシ） | 月次レイテンシ目標 | 未達時の対応 |
| プロファイル保持期間 | 30 日 / 90 日 | コスト試算 |
| 修正 PR の承認権 | 顧客承認の要否 | 自動マージの可否 |
| インシデント時の連絡網 | 24h / 営業時間 | 経営層直通の要否 |
| 退会時の引き渡し | プロファイル設定 + IaC | 著作物としての帰属 |
価格モデル — パフォーマンス SRE 監査 + ボトルネック解消代行パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 診断 | 80 万円〜（4 週間） | 観測体制棚卸し + プロファイル基盤試験導入 | レポート |
| Lite | 30 万円〜 / 月 | 1〜2 サービス | 月次レビュー |
| Standard | 70 万円〜 / 月 | 3〜5 サービス | + 24h 体制 + 修正 PR 月 5 件まで |
| Enterprise | 150 万円〜 / 月 | 6+ サービス | + 専任担当 + 修正 PR 月 15 件まで |
別途 Pyroscope / Grafana Cloud などの利用料（顧客実費 + マネジメントフィー 10〜15%）。
顧客側 ROI 試算（月間 PV 100 万 / API 月間 1 億リクエスト想定）
| 項目 | 監査なし | 監査あり | 差分 |
|---|---|---|---|
| P95 レイテンシ | 850ms | 290ms | -560ms |
| サーバ台数 | 24 台 | 14 台 | -10 台 |
| インフラ月額 | 180 万円 | 90 万円 | -90 万円 |
| 障害対応工数 | 月 60 時間 | 月 10 時間 | -50h |
| CV 率（速度起因の改善） | 基準 | +5〜12% | — |
| 年間効果 | — | — | 約 1,800〜 3,000 万円 |
Standard プラン（年額 840 万円）でも 初年度から黒字化が射程です。
ハマりやすい 5 つの落とし穴
落とし穴 1: 「サーバを足してみる」が先に来る
CPU Zombies が原因の場合、サーバ増設は悪化することもあります。まずプロファイルが原則です。
落とし穴 2: プロファイルコストを軽視する
常時プロファイルは ストレージとネットワークが積み上がります。サンプリング率と保持期間を契約時に合意します。
落とし穴 3: 修正 PR の承認フローが遅い
検出してもマージされなければ意味がありません。「軽微な修正は自動マージ可」を契約に盛り込みます。
落とし穴 4: ベースラインを取らずに監視を始める
「異常」が判定できません。最低 4 週間のベースライン取得を必須とします。
落とし穴 5: 経営層への可視化を後回し
技術用語のダッシュボードでは 「改善している実感」が伝わりません。「P95 / コスト / CV 率」の 3 指標で経営層向け化します。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1〜2 | 観測体制棚卸し |
| Week 3〜6 | 継続プロファイリング基盤導入 |
| Week 7〜10 | ベースライン取得 + Zombies 検出ルール構築 |
| Week 11〜13 | 修正 PR サイクル開始 + 月次会議立ち上げ |
まとめ — 「CPU 使用率は低いのに遅い」を見抜く受託 SRE が次世代標準
Pinterest CPU Zombies の事例は、「サーバを足しても遅い」症状の正体を世界に示しました。中堅企業の受託インフラを預かる立場では、継続プロファイリング × 根本原因分析を組み合わせた SRE 監査が 次世代の標準サービスになります。
弊社では 診断 / Lite / Standard / Enterprise の 4 段階で パフォーマンス SRE 監査 + ボトルネック解消代行パッケージを提供しています。「サーバを増やしても速くならない」「夜間バッチが終わらなくなってきた」「CV 率が低下している」というご相談は お問い合わせフォーム からお気軽にどうぞ。
