0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

【EC2温故知新】AutoScalingグループの挙動をマネコンで観察してみる

Last updated at Posted at 2022-01-29

みんな大好きAutoScallingグループ。
商用利用時に特定のインスタンスの調子が悪いときなど、一定の稼働台数を維持したまま不良ノードを止めたいケースは割と発生しそうなので、有事に慌てないようオペレーション手順や実際の挙動を検証してみる。

想定ケース

2dai-koteiという名前のAutoScallingグループが稼働中。
EC2インスタンスが常時2台アクティブになるよう構成されている。
スクリーンショット 2022-01-29 15.07.30.png

その1:調子が悪いEC2を手動で停止する

リスト1番目のインスタンスを手動でシャットダウンしてみる。
インスタンスの状態操作はEC2コンソールから実施する必要がある。
スクリーンショット 2022-01-29 16.02.03.png

インスタンス一覧をASG名でフィルターし、2台が実行中であることを確認。
止めたいインスタンスを選択し「インスタンスを停止」を実行。
スクリーンショット 2022-01-29 16.05.39.png

すると、「こいつはASG内にいるから止めたら代替ノードが勝手に起動するかもよ」と教えてくれる。想定通りのためそのまま停止。
スクリーンショット 2022-01-29 16.07.14.png

しばらくすると、ASG側で当該インスタンスが「Terminating」ライフサイクルに移行。
同時に新規インスタンスが「Pending」状態で出現し稼働準備が開始された。
スクリーンショット 2022-01-29 16.10.47.png

まもなくして新規インスタンスは「InService」ライフサイクルに移行。
旧インスタンスの「Terminating」はさらに時間がかかる模様。
スクリーンショット 2022-01-29 16.12.50.png

EC2コンソール側で確認すると、「Terminating」中のインスタンスは既に停止(シャットダウン)済みで、終了(インスタンス削除)を実施中の様子。
スクリーンショット 2022-01-29 16.14.21.png

ほどなくして旧インスタンスの終了が完了し、ASG側でも「Terminating」状態だったインスタンスが一覧から消えた。
スクリーンショット 2022-01-29 16.16.17.png

このケースの結論として、台数固定のASG内で調子悪いインスタンスがいる場合、EC2コンソールから停止しちゃえばOK(代替ノードが自動で補充される)ということが分かる。

その2:ASG内のEC2全台をローリング再起動したい

ASGには「インスタンス更新(Refresh)」という機能がある。
こいつを使えばグループ内の稼働ノード台数をコントロールしつつ、ローリング方式で全台を順番にリブートしていくことが可能らしい。

ASGコンソール内に「インスタンスの更新」タブがあり、ここから「インスタンス更新の開始」をクリックするとローリング再起動を実施できるよう。
スクリーンショット 2022-01-29 16.24.05.png

実行しようとすると、「ローリング中も正常稼働させておきたい台数割合」などを指定できる。
今回は2台中1台を残しつつリブートしていきたいため、50%に設定し開始。
スクリーンショット 2022-01-29 16.33.04.png

すると1インスタンス目の置き換えが開始。稼働中のうち1ノードが「Terminating」になると同時に「Pending」状態の新規インスタンスが出現した。
スクリーンショット 2022-01-29 16.36.22.png

「インスタンスの更新」タブではタスクの進捗を確認できる。
新規インスタンスの起動後、ウォームアップ時間のぶん待機していることが分かる。
スクリーンショット 2022-01-29 16.37.32.png

そしてヘルスチェックが完了すると、2台目の既存インスタンスも「Terminating」に移行。2台目用の新規ノードが出現し「InService」状態となった。
スクリーンショット 2022-01-29 16.40.57.png

あとは「Terminating」中の旧インスタンスが順次ドロップしていくのを待つのみ。
スクリーンショット 2022-01-29 16.42.37.png

という便利な機能だったので、グループ内のノード全台をリフレッシュしたい場合は手動でのインスタンス停止ではなく「インスタンス更新」機能を活用するのが良さそう。

その3:EC2を稼働させたままASGから脱退させたい

ASGにはインスタンスの「デタッチ(取り外し)」機能もあるため試してみる。
稼働ノードのうち1台を選択しデタッチを実行。
スクリーンショット 2022-01-29 16.49.20.png

このとき、オプションとして「代替インスタンスを新規追加するか否か」を選択可能。
チェックを付けた場合、当該ノードは稼働状態のままASGから取り外され、新規ノードが1台補充される。
今回はチェックをつけない場合の挙動が気になる(Desired Capasityも連動して減る?)ためそちらを試してみると…。
スクリーンショット 2022-01-29 16.50.10.png

「台数指定と整合とれなくなるからダメ〜!」と怒られてしまった。
仕方なく代替ノード補充にチェックを入れてリトライしてみる。
スクリーンショット 2022-01-29 16.53.45.png

すると当該インスタンスが「Detaching」ライフサイクルに移行し、同時に「Pending」状態で新規インスタンスが出現。このまま待機すると2台とも「InService」になる。
スクリーンショット 2022-01-29 16.56.05.png

この実験により、稼働ノード数の設定に違反する形でのEC2デタッチはエラーとなり実行不可ということが分かった。

まとめ

ASG内のEC2が調子悪い場合、リフレッシュ(置き換え)する方法は…

  • ノード全台を置き換えたい →「インスタンス更新」機能を利用
  • 特定のノードのみを(起動させたまま)置き換えたい →「デタッチ」機能を利用
  • 特定のノードのみを(破棄する形で)置き換えたい →「インスタンスの停止」を利用

すればよいことが実機上で確認できた。

※ 上記に加えて「スタンバイへ移行」操作の挙動に関する記事も書いてみた。
 ASG内のEC2をスタンバイへ移行→デタッチする際のノード補充オプションが分かりにくい件

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?