本記事は
AWSアワード受賞者祭り
4日目の記事です。
✨🏆
3日目
▶▶ 本記事 ▶▶
5日目
🏆✨
はじめに
こんにちは！林です！
この度、2025 Japan All AWS Certifications Engineers に選出いただきました。
努力がこうして評価されるのは非常にうれしいです。
ブログを書くのは2回目なので簡単に自己紹介させていただきます。私は入社後、インフラエンジニアとしてネットワークやサーバの構築・運用を行っていました。最近チームが変わり、この1〜2年の間はモバイルアプリエンジニアとしてアプリケーション運用を行っています。
インフラチームでもアプリチームでも、運用において監視設定は重要になってきます。 AWSではAmazon CloudWatch アラームという非常に便利な監視サービスがありますが、 設定するたびにアラームの閾値をどうすればいいか悩みます。
私は監視運用をしていく中で、閾値を超えていてほしくないのにアラーム状態になってしまう、 閾値を超えている気がするのにアラーム状態になってくれない、といった事象がありました。 そこで、リアル運用のなかで過去に発生した事象と合わせて、データポイントが評価されるタイミングについて整理しようと思います。
発生した事象
前提
・サーバ2台構成で、サーバの死活監視を実施。
・再起動運用を実施。再起動は1台に2分ほどかかる。1台が完了後、約3分後に2台目を再起動。
アラームの設定
一定期間（今回は15分）片系ダウンしていたら検知させたく、再起動などの短期間の一時的なダウンは検知させたくありませんでした。
あまり深くは考えず、期間はデフォルトの5分のままデータポイント数だけを変更して、以下のようなアラームを作成しました。
・しきい値：15 分内の3データポイントのHealthCheckCount < 2
・期間：5分
・アラームを実行するデータポイント：3/3
・統計：平均
検知した内容
各サーバの再起動のタイミングで、アラーム状態となってしまいました。
サーバがダウンしていた時間（メトリクスの値）と、各データポイントの評価は以下の通りです。
時間は例として、11:30の評価としています。
メトリクスの値
~11:18 -> 2
11:19 -> 1 ★サーバ再起動 1台目
11:20 -> 1 ★サーバ再起動 1台目
11:21~23 -> 2
11:24 -> 1 ★サーバ再起動 2台目
11:25 -> 1 ★サーバ再起動 2台目
11:26~ -> 2
データポイントの評価
11:15~19の平均値：1.8
11:20~24の平均値：1.6
11:25~29の平均値：1.8
メトリクスの値が1になっているタイミングは4回だけですが、各期間の平均をとると閾値を下回っています。
データポイントの評価の整理
上記の内容より、評価が実施された時間（11:30）から、アラームを実行するデータポイント（3回）分×期間（5分）をさかのぼって評価されることがわかります。 11:30であれば、11:15~19、11:20~11:24、11:25~11:29の3点が評価対象ということになります。
したがって、'統計: 平均, 期間: 5 分, アラームを実行するデータポイント: 3'という設定においては、最短で 7 分の間(11:19~11:25)にわたって閾値が下回っていればアラーム状態へ遷移することがあります。
整理してみれば理解しやすいかと思いますが、直観とは少しずれた結果となりました。
また、一定期間（今回は15分）片系ダウンしていたら通知したいという意図とは異なる内容となっていました。
(参考)対応方法
参考として、アラームへ遷移するまでの時間を延ばす例です。
案１）統計を 平均 (Average) ではなく、最大 (Maximum) とする
最大に変更すると、各地点の最大値を取得します。
そのため、期間: 5 分, アラームを実行するデータポイント: 3であれば、15分間ずっと2未満の状態が続かない限りアラーム状態とはなりません。
案２）データポイントの数を増やす
期間を短くし、データポイントを増やすことでもタイミングが変わります。
期間: 5 分, アラームを実行するデータポイント: 3から、期間: 3 分, アラームを実行するデータポイント: 5に変更した場合、
11:15~11:29の3分置きの5点が評価対象となります。
そのため、最短で11分の間にわたってしきい値が下回っていればアラーム状態へ遷移することがあります。
最後に
本例では、縮退状態がある程度続けば通知がほしいなーというざっくりとした思いから、なんとなくの値で設定をしていました。
細かい内容ではありますが、重要な点でもあると思っています。
最も大事なことは、監視したい内容を正しく把握することだと思います。
運用においてアラートを受け取ることは重要ですが、意図しないアラートは運用負荷になり得ます。
本内容が皆様のアラーム設定、よき運用ライフのお役に立てれば幸いです。
