1. はじめに
今回は コスト最適化の勘所で記載した「6.持続したコスト管理の重要性」を疎かにしてしまったが故の失敗事例になります。
失敗事例というのは外部公開を忌避する事が多いかと思います。
しかし、失敗事例にこそ多くの学びがあるという思想の下、そういった事例もなるべく隠さず公開していこうと思います。
2. 背景
弊社の某システム（仮称：Aシステム）ではWebサーバをホストするEC2にオートスケールを採用しています。
スケールアウトしたEC2に対しても監視/通知が必要な為、スケールアウトしたEC2のカスタムメトリクスに対するアラーム定義を追加する処理を実装しています。このアラーム定義はEC2がスケールインすると不要になりますので、削除する処理も実装していました。
処理自体は AutoScalingGroup のイベントを EventBridge でフックし、Lambdaでアラーム定義を操作する形で実装しています。
3. 異変の気付き
AWSコスト管理を本格開始した頃、リリースから1年近く経つAシステムのCloudWatch費用がリリース直後から緩やかに上昇を続けている事に気が付きました。
スケールアウト/インに伴ってCloudWatch費用が変動することはありますが、上昇をずっと続けるのは違和感があります。
調べてみると、アラーム定義が検証環境では 約25,000 件、本番環境では 約7,000 件と膨大な数になっており、これがCloudWatch費用を押し上げていました。
4. 原因
4.1. アラーム定義削除が正常に動いていない
ここまで増殖した原因は、先述したアラーム定義削除処理が正常に動いていない事でした。
4.2. 何故動いていなかったのか
4.2.1. 検証環境
検証環境が複数存在する為、本番環境に比してEC2がかなりの台数存在します。
検証環境にある多数のサーバに対してスケールインが一斉に行われる運用が存在し、呼び出されたLambdaが処理を実施したものの、CloudWatchのクォータ（※1）に引っ掛かってしまい処理が失敗していました。
この処理自体にはリトライ処理が含まれておらず、実行結果監視も行われていなかった為、削除処理失敗が検知されず不要なアラームがひたすら積みあがっていました。
※1…CloudWatch のクォータ自体は こちら に情報がまとまっております
恐らく下記の記述部分に引っ掛かったようです。
DeleteAlarms リクエスト
オペレーションごとに、リージョンあたり 3 TPS
スロットリングなしで 1 秒あたりに実行できるオペレーションリクエストの最大数。
これらのクォータは変更できません。
4.2.2. 本番環境
本番環境では処理中のセッションに影響が出ないよう、事前にAutoScalingGroupからスケールインするEC2のデタッチを実施していました。
しかし、デタッチした事で本来EventBridgeが検知するスケールインイベントが発生せず、用意されたアラーム定義削除処理がそもそも実行されないという事態が発生しており、こちらも不要なアラーム定義がひたすら積みあがっていました。
5. 対処
5.1. 暫定対処
幸い、Aシステムの提供するサービスに直結するようなトラブルではありませんでした。
しかし、AWSコストを押し上げているのは間違いありませんので、本来は削除されているべき不要なアラーム定義の削除を暫定対処として実施しました。
5.2. 根本対処
Aシステムは本番環境にせよ、検証環境にせよ、運用上多数のサーバを同時にスケールインすることが考えられるシステムとなっています。
この為、以下2点を根本対処として行いました
- アラーム定義削除処理に対してリトライ処理を追加
- スケールインの後続処理とは別に、アラーム定義削除処理を実施するバッチ処理の実装
6. 振り返りと教訓
6.1. スケールアウトに伴う処理
スケールアウトに伴ってアラーム定義を増やすことは認識していましたが、削除処理が失敗するパターンを想定できていませんでした。そのため、リトライ処理や不要アラーム定義を検知して定期削除するバッチ処理等、処理が失敗した場合のリカバリ対応が構築できておらず、今回の問題が発生してしいました。
6.2. AWSコストの継続的管理
Aシステムリリースから1年近く時間が経っていたこともあり、結果として軽自動車を購入できる程の余計なAWSコストを発生させてしまいました。
上昇幅が非常に緩やかだったため異変に気付くのが遅れた面もありますが、AWSコスト管理・運用がしっかりと実施出来ていればもっと早期に発見し、対策が打てていたかと思います。
CloudWatchに限らず、AWSサービス単位もしくはサービス毎の課金科目単位でAWSコスト変動の状況を捉えて原因を分析し、対策を講ずるというAWSコスト管理の重要性を痛感した失敗でした。
オートスケールを実装し、スケールしたリソースのアラーム定義追加/削除を実装しているシステムでは是非同じ観点での確認をお勧めします。