実際にサービスでなんかやったというのじゃなく、こういうこと考えてるんだけどみんなどうしてます?って話です。
まずオンプレ時代はサーバのスペックダウンはけっこう大変だったし、頑張ってメモリやCPU引っこ抜いてもそんなに節約にならなかった。
※CPUやメモリはサーバ価格の一部でしかないし、ラック費用(消費電力)もあるし。
でもクラウド前提だとスペックダウンはとても簡単で、スペック半分にすると価格も半分になる。
そうすると、
『イベントで一時的にc4.4xlarge(8万/月)にして、そのまま最大CPU使用率10%とかで数ヶ月放置されている』
みたいなのはビジネス的な損失という意味で明らかに障害で、監視すべきじゃないだろうか?
みんななんかやってますか?
というようなことを参加者に聞いてみました。
参加者の中では、AutoScalingしているところは当然対応できているけど、それ以外については特に監視してないな、という感じでした。
AutoScalingは確実に最終的な解の1つなんですが、現状なかなか全てをそうするのは難しい。
現状のままサクッと監視できないかなぁ。
というわけで
例えばこういうコマンドを作って定期的に監視するのは1つの手かな、と思います。
中ではこういうことやってます。
- AWS SDKで稼働中EC2インスタンスのIPアドレス、インスタンスサイズを取得する
- 各インスタンスにSSHして昨日のCPU使用率、メモリ使用量の最大値を取得する
- 各インスタンスの既存負荷に耐えうる最適な(最も安い)インスタンスサイズを求める
- 合計の既存コスト、最適コストの差が30%以上になったら警告する
デモ用のネタ実装なので、EC2のみ対応でReservedやSpotは無視とか実用性は全くないです。
監視ツールと連携して、もっと簡単にやる方法はないかな。
Zabbixとかならサクッとできそうだけど。
ちなみに
AWS Trusted Advisorにそういう機能があるらしいんだけど、
毎日の CPU 使用率が 10 %以下およびネットワーク I/O が 4 日以上 5 MB 以下となる場合、最後の 14 日間、常に稼働している Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを確認し、お客様へ警告します。
とのこと。イマイチすなぁ。
まとめ
クラウド化でスペックダウンが容易になり、効果も大きくなったので、
『負荷高すぎ』だけじゃなく『負荷低すぎ』も障害として監視すべきじゃないのかな。
でもどうやって監視するか迷い中。って話でした!