EC2インスタンスのCPU使用率が突然上昇した際、闇雲にインスタンスサイズを上げる前に確認すべき調査手順をまとめました。
1. 現象の正確な切り分け（CloudWatch）
- 発生パターン：発生時刻と継続時間を確認する（瞬間的なスパイクか、持続的な高負荷か）。
- バースト型インスタンス（T系）：
CPUCreditBalance、CPUCreditUsageを確認する。StandardモードではCPUクレジット枯渇後の性能制約、Unlimitedモードではサープラスクレジットの使用状況や追加料金の発生も確認する。 - 他メトリクスとの同期確認：
NetworkIn/Out、DiskReadBytes/WriteBytes、StatusCheckFailedなどをCPU使用率と時系列で比較する。RDSを利用している場合は、DB側のCPU・接続数・スロークエリなども並行して確認する。 - マルチコアの偏り：CPU全体の平均だけでなく、1コアに負荷が集中していないか
mpstat等で確認する。
2. 直近の変更点との相関
- デプロイ履歴：CodeDeployやCodePipeline等のリリース履歴を確認する。
- インフラ変更：Auto ScalingやAMI更新など、直近のインフラ変更を確認する。セキュリティグループの変更についても、想定外の通信が新たに許可され、結果としてアクセス増加やCPU負荷の上昇につながっていないか確認する。
- 自動更新：
yum-cron/dnf-automatic等によるOS・ミドルウェアの自動アップデートが、CPU高騰のタイミングと一致していないか確認する。
3. プロセスレベルの特定（SSH/SSM接続可能な場合）
- プロセス確認：
topまたはhtopでCPU使用率の高いプロセスを確認する。事後調査ではsarや、事前に設定していたCloudWatch Agentのprocstatなども活用する。 - 負荷の分布：特定プロセスが単独でCPUを使用しているのか、Webサーバーのワーカープロセス等に分散しているのかを確認する。
- 不正プロセスの有無：見覚えのないバイナリや、暗号通貨マイニングなどのマルウェア感染を疑う兆候がないか確認する。
4. トラフィック起因の調査
- アクセス数の比較：Webサーバーのアクセスログを平常時（前日・前週の同時間帯）と比較する。
- リクエスト内容の分析：上位URL、ステータスコード、User-Agentなどを確認し、正規アクセスなのかbot・クローラーなどによるアクセスなのかを切り分ける。
- アクセス元IPの確認：アクセスが多数のIPに分散しているのか、特定のIP・IPレンジに偏っているのかを確認し、DDoS、スクレイピング、ブルートフォースなどの可能性を切り分ける材料とする。
- 事前準備の重要性：障害発生時にアクセス状況を追跡できるよう、利用している構成に応じてCloudFront、ALB、WAFなどのアクセスログを事前に有効化しておく。
5. スケジュール処理の重複
- 定期タスクの重なり：
cron、バッチ処理、ログローテーション、バックアップ、S3同期などが同じ時間帯に重複して実行されていないか確認する。 - 実行時間の変化：通常より処理時間が長くなっているバッチがないか、過去の実行時間と比較する。
6. セキュリティ・監視エージェントの負荷
- セキュリティソフト（EDR等）：CrowdStrikeやDeep Security等のリアルタイムスキャンが、高頻度で書き込まれるセッションやログファイルなどを対象として負荷を増加させていないか確認する。
- 監視エージェント：CloudWatch Agentなどの監視エージェント自体に異常が発生し、高いCPU負荷を発生させていないか確認する。
7. アプリケーション・DB側のボトルネック
- DBのボトルネック：スロークエリ、ロック待ち、N+1問題などによって、アプリケーション側の処理量や待機・リトライが増えていないか確認する。
- RDS側の確認：RDSを利用している場合は、RDS側のCPU、接続数、スロークエリ、Performance Insightsなども確認する。
- メモリ不足・スワップ：メモリ枯渇によるスワップが発生していないか確認する。スワップなどによるI/O待ちがCPUの
iowaitを増加させ、CPU使用率の見え方に影響している可能性もある。
8. 応急処置と根本対応の切り分け
- スケールアップの扱い：インスタンスタイプの引き上げは、あくまで一時的な応急処置として検討する。原因特定前のスケールアップだけでは根本解決にならない場合がある。
- 費用対効果：原因が特定の処理やアプリケーションのオーバーヘッドであれば、コードや構成を改修する方がコストパフォーマンスが高い場合がある。
- スケールアウトの検討：Webサーバーなど、負荷分散が可能な構成であれば、インスタンスサイズを上げるだけでなく、Auto Scalingによるスケールアウトも選択肢となる。
おわりに
EC2のCPU高騰時は、まずCloudWatchで全体像を把握してから、直近の変更・サーバー内部・アクセスログ・アプリケーション・DBへと段階的に深掘りしていくのが基本的な調査方法です。
一時的なスケールアップやスケールアウトでサービスへの影響を抑えつつ、CPU高騰の根本原因を特定し、適切なコスト・構成を維持することが重要です。
ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。
- 選考ではありません
- 履歴書不要
- 技術の話が中心
- 所要時間30分程度
- オンラインOK
関連リンク
AI・クラウド・データ分析のご相談はネクスト株式会社までお問い合わせください。
