share facebook facebook twitter menu hatena pocket slack

2017.01.31 TUE

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

那須隆

WRITTEN BY 那須隆

ナスです。

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

明けましておめでとうございます!ナスです。 今年も適度に頑張って記事を書いていきます。 今日は 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などでスクリプトを組んで、インフラ運用の効率化を目指している。

cloudpack

cloudpackは、Amazon EC2やAmazon S3をはじめとするAWSの各種プロダクトを利用する際の、導入・設計から運用保守を含んだフルマネージドのサービスを提供し、バックアップや24時間365日の監視/障害対応、技術的な問い合わせに対するサポートなどを行っております。
AWS上のインフラ構築およびAWSを活用したシステム開発など、案件のご相談はcloudpack.jpよりご連絡ください。