負荷低すぎはもはや障害じゃないのか

前のブログの続きで、もにかじ7で話した小ネタその2。

実際にサービスでなんかやったというのじゃなく、こういうこと考えてるんだけどみんなどうしてます？って話です。

まずオンプレ時代はサーバのスペックダウンはけっこう大変だったし、頑張ってメモリや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︶ インスタンスを確認し、お客様へ警告します。

とのこと。イマイチすなぁ。

まとめ

クラウド化でスペックダウンが容易になり、効果も大きくなったので、
﹃負荷高すぎ﹄だけじゃなく﹃負荷低すぎ﹄も障害として監視すべきじゃないのかな。

でもどうやって監視するか迷い中。って話でした！