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

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

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

まずオンプレ時代はサーバのスペックダウンはけっこう大変だったし、頑張ってメモリやCPU引っこ抜いてもそんなに節約にならなかった。
※CPUやメモリはサーバ価格の一部でしかないし、ラック費用(消費電力)もあるし。

でもクラウド前提だとスペックダウンはとても簡単で、スペック半分にすると価格も半分になる。

そうすると、
『イベントで一時的にc4.4xlarge(8万/月)にして、そのまま最大CPU使用率10%とかで数ヶ月放置されている』
みたいなのはビジネス的な損失という意味で明らかに障害で、監視すべきじゃないだろうか？
みんななんかやってますか？

というようなことを参加者に聞いてみました。

参加者の中では、AutoScalingしているところは当然対応できているけど、それ以外については特に監視してないな、という感じでした。

AutoScalingは確実に最終的な解の1つなんですが、現状なかなか全てをそうするのは難しい。
現状のままサクッと監視できないかなぁ。

というわけで

例えばこういうコマンドを作って定期的に監視するのは1つの手かな、と思います。

f:id:mikeda:20150201191036p:plain

中ではこういうことやってます。

  • 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） インスタンスを確認し、お客様へ警告します。

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

まとめ

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

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