インスタンスリフレッシュとライフサイクルフック

Launch Templateを更新しても（新しいAMI、新しいユーザーデータ、新しいインスタンスタイプなど）、ASG内ですでに実行中のインスタンスは自動的には置き換えられず、古い設定のまま動作し続けます。変更を反映するには、インスタンスを置き換える必要があります。インスタンスを手動で終了して再起動する方法は、リスクが高く、エラーも発生しやすくなります。Instance Refreshを使用すると、安全性を制御する設定付きで、このプロセスを自動化できます。

Instance Refreshは、ASG内のインスタンスをローリング方式でバッチごとに置き換えます。各ステップで古いインスタンスのバッチを終了し、新しいインスタンスがヘルスチェックに合格するのを待ってから、次のバッチに進みます。MinHealthyPercentage（Refresh中に正常な状態を維持する必要があるキャパシティの最小割合）と、オプションのInstanceWarmup時間によって、更新のペースを制御できます。

MinHealthyPercentageは、Refresh中に維持する正常なキャパシティの下限を定義します。90%に設定すると、一度に置き換えられるフリートは10%だけとなり、遅くなりますが安全性は高まります。50%に設定すると、フリートの半分を一度に置き換えるため、速くなりますが冗長性は低下します。ASGは、この割合と現在のdesired capacityに基づいてバッチサイズを自動的に計算します。可用性を維持するため、本番ワークロードではより高い割合を選択してください。

チェックポイントを使用すると、あらかじめ定義した割合の到達時点でInstance Refreshを一時停止できます。たとえば、インスタンスの20%を更新した後、10分間停止してスモークテストを実行し、その後続行できます。チェックポイントで問題を検出した場合はRefreshをキャンセルできます。ASGは追加のインスタンス置き換えを停止しますが、すでに置き換えたインスタンスはそのまま稼働させます（すでに新しいテンプレートを使用しているためです）。これは、EC2でのカナリアデプロイパターンに相当します。

進行中のInstance Refreshはいつでもキャンセルできます。キャンセルすると、それ以降の置き換えは停止しますが、完了済みの置き換えはロールバックされません。describe-instance-refreshesを使用すると、ステータス、進捗率、起動に失敗したインスタンスを確認できます。Instance RefreshをCI/CDパイプラインと統合し、Launch Templateに新しいAMIを登録した後にRefreshを自動的に開始すれば、完全に自動化されたブルー/グリーン形式のデプロイを実現できます。

Lifecycle Hooksは、ASG内のインスタンス状態が重要なタイミングで遷移する際に一時停止させ、インスタンスがアクティブになる前や終了する前にカスタム処理を実行できるようにします。フックポイントは2つあります。EC2_INSTANCE_LAUNCHING（起動後、インスタンスがInServiceになる前）と、EC2_INSTANCE_TERMINATING（終了決定後、実際にインスタンスが終了する前）です。フックの実行中、インスタンスはPending:WaitまたはTerminating:Wait状態になります。

launching hookは、インスタンスがトラフィックを処理する前に完了させる必要があるタスクに適しています。たとえば、追加ソフトウェアのインストール、Parameter Storeからの設定の取得、サービスディスカバリレジストリへの登録、統合テストの実行などです。フックが完了するかタイムアウトするまで、ASGはそのインスタンスをロードバランサーのターゲットグループに追加しません。これにより、設定が不完全なインスタンスにトラフィックが到達するのを防げます。

termination hookは、インスタンスが実際に終了する前に実行されます。ユースケースには、アプリケーションレベルのキューにある処理中のリクエストのドレイン、キャッシュデータの永続ストアへの書き出し、サービスレジストリからの登録解除、ログファイルのS3へのコピーなどがあります。終了フックがない場合、終了対象のインスタンスで処理中の作業が失われる可能性があります。このフックを使用すると、グレースフルシャットダウンのタスクを完了するために、最大2時間（ハートビートタイムアウト）が与えられます。

インスタンス上で実行される、またはインスタンスによってトリガーされるカスタムロジックは、処理が完了したときにフックへ通知する必要があります。complete-lifecycle-actionを使用し、CONTINUE（通常どおり続行）またはABANDON（起動フックではインスタンスを終了し、終了フックでは無視して続行）のいずれかを指定します。また、最大継続時間に達するまで一定間隔でheartbeatを送信し、フックのタイムアウトを延長することもできます。フックがタイムアウトすると、DefaultResultが適用されます。

Lifecycle Hooksに応答する最もすっきりした方法は、Amazon EventBridgeを使用することです。Lifecycle Hookが実行されると、ASGはEventBridgeにイベントを送信します。EventBridgeルールはこのイベントをLambda functionにルーティングし、Lambda functionが必要な処理を実行した後、complete-lifecycle-actionを呼び出します。このアーキテクチャは完全にサーバーレスで、ポーリングが不要であり、自動的にスケールします。SQSとSNSによる通知は以前からある代替手段ですが、新しい設計ではEventBridgeが推奨されます。

Instance Refreshがインスタンスを置き換える際にも、両方のLifecycle Hooksが実行されます。つまり、古いインスタンスでは終了フックが、新しいインスタンスでは起動フックが実行されます。そのため、通常のスケールイベントだけでなく、ローリング更新中にもグレースフルシャットダウンと初期化のロジックが自動的に実行されます。本番環境にロールアウトする前に、段階的なInstance Refresh中にLifecycle Hookのロジックを必ずテストし、正しく動作することを確認してください。

このレッスンで学んだAWS Solutions Architect（SAA-C03）の概念について、理解度を確認しましょう。

このレッスンでは、Instance RefreshがMinHealthyPercentageとオプションのチェックポイントによって制御されたローリングバッチでASGのインスタンスを置き換え、カナリア方式の検証を可能にすること、Lifecycle Hooksが起動時または終了時にインスタンスの状態遷移を一時停止して、カスタムの初期化処理やグレースフルシャットダウン処理を実行できること、そしてEventBridge + LambdaがポーリングなしでLifecycle Hookイベントに応答する推奨パターンであることを学びました。次は、AWS Lambdaの関数、ランタイム、トリガー、ハンドラーについて説明します。