share facebook facebook twitter menu hatena pocket slack

2017.01.31 TUE

Auto Scaling で EC2 インスタンスをメンテナンスする時の注意点2 [cloudpack OSAKA blog]

那須隆

WRITTEN BY 那須隆

ナスです。

先日、こんな記事を書きました。

Auto Scaling で EC2 インスタンスをメンテナンスする時の注意点 [cloudpack OSAKA blog] - sorta kinda...
明けましておめでとうございます!ナスです。 今年も適度に頑張って記事を書いていきます。 今日は Auto Scaling でヒヤリとしたことを書きます。 事の発端 とある作業で、Auto Scaling グループ内の EC2 インスタンスを再起動しないといけなくなりました。Auto Scal...

nasrinjp1.hatenablog.com

結論から書くと、私が間違ってました。AWSのバグとか疑ってごめんなさい…

で、結局なんだったの?

Auto Scaling の設定の中に、スケーリングポリシーというものがあります。これは、例えば Auto Scaling グループ内の EC2 インスタンスの CPU 負荷が xx% 超えたら EC2 インスタンスを追加するとか、逆に xx% 以下になったら EC2 インスタンスを削除するとかするものです。負荷によって、動的に EC2 インスタンスの数を増減できるのが特徴です。

こんなのです。

で、私、このポリシーの動きを理解していませんでした。

スケーリングポリシーを設定していると、

1.最小値を -1 する
2.スケーリングポリシーに設定した CloudWatch アラームを見て条件に合致している、と判断する
3.希望値が -1 される
4.EC2 インスタンスが 1 台削除される

ということが起こっていました。しかも最小値を変更した瞬間に。1 を実施した後にアクティビティ履歴をみると、こうなってました。

こういう状況でもデタッチしたい時はある!

メンテナンスせざるを得ない時もあると思いますので、下記のように対処すれば大丈夫です。

最小値を減らす時に、「停止したプロセス」に AlarmNotification を追加します。これで、最小値を減らしても、CloudWatch からのアラームを受け取ることをやめます。

上の画像でも、実際に希望値は最小値と同じになっていません。これで安心してデタッチなりスタンバイ設定なりできますね。

元記事はこちら

Auto Scaling で EC2 インスタンスをメンテナンスする時の注意点2 [cloudpack OSAKA blog]

那須隆

那須隆

ネットワークエンジニア、SAPコンサルタントを経て、cloudpackにJOIN。Webサイトや基幹システムのインフラ構築および運用を主に行い、シェルやPythonなどでスクリプトを組んで、インフラ運用の効率化を目指している。