AWS CloudWatchでキャラクターのように監視する：メトリクスの性格分析【2025年版】
AWSにおける監視の主役はCloudWatchです。
CloudWatchは、EC2のCPU使用率やDBの応答時間など、サーバーから発せられる膨大なデータをメトリクス（Metrics）として集めてくれます。しかし、ただ数字を眺めるだけでは、何が正常で何が異常なのか判断できません。
ここで重要なのが、メトリクスを「キャラクターの性格」のように捉えるという視点です。
この記事では、僕自身の監視設定の失敗談を交えながら、主要なメトリクスをどのように「性格分析」し、適切なアラームを設定すればいいか、実務的な考え方をお伝えします。
🎨 主要メトリクスを「キャラクター」として分析する
主要なメトリクスには、それぞれ異なる「性格」があります。その性格を理解すると、異常を察知しやすくなります。
1 CPU使用率（常に元気でいたい「努力家」）
メトリクスの性格
普段は低く安定しているが、タスクが来ると急上昇する。理想は常に低空飛行。
アラーム設定の考え方
- 警戒ライン: 70%〜80%以上が5分以上継続（許容範囲を超えた）
- 異常ライン: 90%〜100%が1分以上継続（処理詰まりの可能性）
⚠️ 筆者経験
以前、バッチ処理を行うEC2で「CPU使用率が10%を超えたらアラーム」という設定をしたことがあります。結果、バッチが動くたびにアラームが鳴り響き、アラーム疲労で重要な警告を見逃すという地獄を見ました。「努力家」には、頑張りすぎた時（高負荷持続）だけ注意するのが正解でした。
2 レイテンシ（反応速度が遅い「遅刻魔」）
メトリクスの性格
APIやDBの応答時間。普段はコンマ数秒だが、負荷がかかると急激に遅延する。
アラーム設定の考え方
- 平均（Average）よりも、P90（90パーセンタイル）やP99（99パーセンタイル）に注目する。
- P99が普段の応答時間の2倍以上になったら警告。
📘 なぜP99が重要か
平均値だけを見ていても、一部のユーザーが「Webサイトが重い！」と感じていることに気づきません。P99（100人に1人は待たされている）を見ることで、エンドユーザー体験の悪化を敏感に察知できます。
3 ディスクI/O（地味だが重要な「裏方」）
メトリクスの性格
ディスクへの読み書き回数やバイト量。普段は目立たないが、急に忙しくなるとシステム全体の足を引っ張る。
アラーム設定の考え方
- EC2やRDSが使用するEBS（ストレージ）のIOPS（I/O Operations Per Second）が上限に達していないかをチェック。
- IOPSやスループットが上限の80%を超えたら警告。
⚠️ 見落としがちな失敗談
df -h（Linuxコマンド）でディスクの容量だけを監視していて、処理速度（IOPS）の上限を見落としていたことがあります。処理速度が上限に達すると、CPUに余裕があってもシステム全体が固まってしまいます。「裏方」の体調不良は、表には出にくいので注意が必要です。
🧠 アラーム設定の3つの鉄則（キャラクターの「トリガー」設定）
メトリクスの性格が分かったら、次はアラーム（CloudWatch Alarms）を設定します。
鉄則1：期間（Period）とデータポイント（Data Points）の組み合わせ
アラームは「閾値を超えたら即発動」ではありません。誤検知を防ぐため、「X分間のうち、Y回閾値を超え続けたら発動」という設定が必要です。
📘 設定例
「CPU使用率が80%を5分間のうち3回超えたらアラーム」
- Period (期間): 1分
- Data Points to Alarm (データポイント): 3/5（5回の評価で3回超過）
これにより、瞬間的なスパイク（ただの一時的な負荷）ではアラームが鳴らず、「これは本当に体調不良だ」と判断できたときだけ通知が来るようになります。
鉄則2：アラームアクションはSNSで一元管理
アラームが発動した際のアクション（通知先）は、SNS (Simple Notification Service) トピックで一元管理するのがベストプラクティスです。
💡 SNSのメリット
通知先（メール、Slack、Lambdaなど）を後からいくらでも追加・変更できるため、監視設定自体を触る必要がなくなります。
鉄則3：メトリクスとログを連携させる
CloudWatchはメトリクスだけでなく、ログ（Logs）も収集します。
- 異常時: アラームが発動したら、
grepやtailを駆使してログを分析します。CloudWatch Logs Insightを使って、エラーメッセージや特定のIPからのアクセスを検索すれば、迅速なデバッグが可能です。
📚 まとめ：サーバーの気持ちを理解しよう
CloudWatchの監視は、単なる数字遊びではありません。それは、あなたが構築したインフラという「キャラクター」たちの声を聞き、健康状態を維持する重要な仕事です。
3つのキャラクター特性
- CPU使用率: 高負荷が継続した場合のみ注意する「努力家」
- レイテンシ: P99を見て、遅延で苦しむユーザーを見逃さない「遅刻魔」
- ディスクI/O: IOPSの上限を監視する「裏方」
メトリクスの「性格」を理解し、適切なトリガー（閾値・期間）を設定することで、真に役立つ監視システムが構築できます。
コメント