はじめに
AWS を触り始めたばかりの頃にやらかした初歩的なミスをまとめたアドベントカレンダー、題して「AWS初歩ミス図鑑」の 15 日目です。
今回は Auto Scaling の設定を間違えて、EC2 インスタンスが制御不能に増殖してしまった話 を書いていきます。
アドベントカレンダーもいよいよあと十日ですね！ 頑張って書き切り、今年もかわいいぬいぐるみをもらおうと思います。
やっていたこと
社内の検証環境で、負荷に応じて自動的にスケールするWebアプリの構築をしていました。
- 平常時は 2 台のインスタンスで運用
- アクセス数が増加したら最大 5 台まで自動でスケールアウト
- 負荷が下がったら元の台数に戻す
という感じで、特筆するべきことがないくらいのシンプルな構成です。
こちらは過去の記事と同様に、Auto Scaling を用いて構築を進めることになります。
一通りの設定を終え、試しに負荷テストツールである Gatling を用いてリクエストを送信し、CPU使用率が上がることを確認。これで Auto Scaling が動作するはずだと期待をして、コンソール上から様子を見ていました。
結果
二、三台インスタンスが増えたときには「想定通りだなー」なんてのんびりしていたのですが、時間が経つにつれてふと、「なんかインスタンスの数めっちゃ多くないか？」ということに気が付きます。
コンソール画面を確認してみると、案の定 EC2 インスタンスが 50 台ほど稼働しています。「まさか…この期に及んで最大容量を間違えるなんてミスを…？」と絶望しつつ、それにしてもどうしてこんなに増えているんだ？ と調査をした結果、以下のことが起きていました。
- 負荷テストで CPU使用率が 80% を超える
- Auto Scaling がスケールアウトを実行
- 新しいインスタンスの起動に数分かかる
- その間も負荷テストは継続
- CPU使用率が下がらないため、再度自動でスケールアウト
- クールダウンを特に設定していなかったため、同じように次々起動
- そもそも最大容量を間違えていた
つまり、インスタンス起動時間とスケーリング判定のタイムラグを全く考慮していなかったのです。（いや一番最後が根本的原因だし問題だろ、と思った方、その通りです。）
その後、クールダウンと最大容量を正しい数値に治すことで、無事に解決しました。
何を考えていたのか
Auto Scaling の起動タイミングを理解していませんでした。またクールダウンを設ける必要があるという観点が抜けていました。
インスタンス起動から実際にトラフィックが送信されるようになるまでのラグを理解していなかった、という部分もあります。
あとは、そもそも何故最大容量が 50 になっていたのか？ という問題ですが、こちらは数年たった今でも謎のままです。数値入力欄がスクロールで反応するやつだったのかな？ それで意図せず大き目の数字が入力されたのかも…と思い、昔の Auto Scaling のコンソール画面を調べて確認してみたのですが、どうやらそういうわけでもなさそうで…。
まとめ
Auto Scaling は細かな設定項目が多いです。特に最大容量については慎重に入力をしましょう。私のようになります。また、クールダウンの設定に気を配ることももちろん大切です。
本番運用をするなら、CloudWatch アラームでインスタンス数を監視して、想定外の増加を防ぐのもよいかもしれません。
余談ですが、このブログを書くにあたり久しぶりに AutoScaling のコンソール画面を見直したら良い感じの設定が追加されていて驚きました。これがあれば私にようにクールダウンを設定を忘れるなんてことは起こらなさそうですね。
