EC2をAutoScalingグループで運用している際、アプリケーションの更新やパッチの適用時にどのようにインスタンスを更新して新たなAMIを取得するか検討した。
検討した軸としては、更新対象インスタンスの決め方と、テスト方法。なお、ALBを利用する前提で検討した。
先に個人的見解としての結論
- 更新対象インスタンスの決め方
対象インスタンスのみ通常時からスケールイン保護しておく手もあるが、対象のインスタンスに異常が発生した場合などにはスケールイン保護していてもスケールインが発生する可能性がある。そのため、スケールイン保護による特定は行わず、更新時に対象インスタンスを決め打ちし、Standbyか、AutoScalingからのデタッチにより更新するのが良いと判断。（下記案2）
- テスト方法について
更新時には、更新したAMIを展開する前に、更新したインスタンスに対して、ユーザと同様のALB経由でアクセスして動作確認したいところ。また、極力更新時の設定変更を減らしたい。
上記を満たす案としては、予め、ALBのリスナーポートにテスト用ポートとそこに紐づけるターゲットグループを作成しておく。更新時にはターゲットグループに更新対象のインスタンスを登録してテストするのが良いと考える。
更新対象インスタンスの決め方
案1：通常時からスケールイン保護により更新インスタンスを特定
- 通常時から特定のインスタンスのみスケールイン保護しておき、更新時には該当のインスタンスをStandbyまたは、デタッチして、AutoScalingから切り離す。(切り離すことで、システム利用者からの通信を遮断した上でインスタンスを更新することができる。)
- インスタンスを更新後に、AMIを取得。
- AMI取得後、Standbyであれば、InService。デタッチであれば、 AutoScalingグループにアタッチすることで、AutoScalingグループに戻す。
案1 注意点
スケールイン保護していても、スケールインする場合がある。特にヘルスチェックに失敗した場合など、インスタンスに異常が発生した場合にはスケールインが発生する。
インスタンスのスケールイン保護を使用する – 考慮事項
https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html#instance-protection-considerations
— 抜粋ここから —
・インスタンスのスケールイン保護は、次の状況から Auto Scaling インスタンスを保護することはできません。
・インスタンスがヘルスチェックに失敗した場合のヘルスチェックの置換。詳細については、「Auto Scaling グループ内のインスタンスのヘルスチェック」を参照してください。
・スポットインスタンスの中断。キャパシティーが使用できなくなった場合、またはスポット料金が上限価格を超えた場合、スポットインスタンスは終了されます。
・キャパシティブロック予約は終了します。Amazon EC2 は、スケールインから保護されている場合でも、キャパシティブロックインスタンスを再利用します。
・terminate-instance-in-auto-scaling-groupコマンドによる手動終了。詳細については、「Auto Scaling グループのインスタンスを終了する (AWS CLI)」を参照してください。
・Amazon EC2 コンソール、CLI コマンド、および API オペレーションによる手動終了。Auto Scaling インスタンスを手動の終了から保護するには、Amazon EC2 の終了保護を有効にします。(これによって、Amazon EC2 Auto Scaling がインスタンスを終了したり、terminate-instance-in-auto-scaling-groupコマンドを使用して手動で終了したりすることを防ぐことはできません。) 起動テンプレートで Amazon EC2 終了保護を有効にする方法については、を参照してください詳細設定を使用して起動テンプレートを作成する。
— 抜粋ここまで —
案2 ：更新時に対象インスタンスを特定
- 更新時に更新する対象インスタンスを決め打ちし、StandbyかデタッチによりAutoScalingから切り離す。
- インスタンスを更新し、更新後AMIを取得。
- AMI取得後、Standbyであれば、InService。デタッチであれば、 AutoScalingグループにアタッチすることで、AutoScalingグループに戻す。
案3：更新用インスタンスを予め別に用意（構築）しておく
- 通常時から更新用のインスタンスを別に用意しておき、更新するタイミング以外は停止しておく。
- 更新時には別に用意しておいたインスタンスを起動して更新。
- AMIを取得。
- インスタンスを停止。
案3 注意点
停止していても、EBSなどの料金がかかるため、コストは若干増加する。
テスト方法について
ALBのリスナーポートにユーザからリクエストを受ける443ポート以外に、テスト用のポート(例：1443など)を用意して、ターゲットグループと対象インスタンスを紐づける。
案1、案2の場合はStandbyにするか、デタッチのタイミングで対象のインスタンスをテスト用リスナーポートのターゲットグループに登録する。
案3の場合は、常時テスト用のEC2をテスト用リスナーポートのターゲットグループに登録しておく。(更新時の作業が少ないのが案3の良いところ。)
また、ALBには、セキュリティグループでテスト用ポートへのアクセス許可が必要だが、開発拠点などに限定しておくとよい。
更新時にはテスト用ポートへの通信を行って試す。
