起動テンプレートと ASG の設定

Launch Templateは、Auto Scalingグループ（およびEC2に直接）に対して、インスタンスの起動方法を指示するバージョン管理された設計図です。AMI ID、インスタンスタイプ、キーペア、セキュリティグループ、任意のユーザーデータを、再利用可能な1つのドキュメントにまとめます。以前のLaunch Configurationとは異なり、Launch Templateは複数のバージョンをサポートしており、ASGを置き換えずに更新できます。

AWS CLIではcreate-launch-templateを使用してLaunch Templateを作成できます。--launch-template-dataパラメータには、すべてのインスタンス設定を定義するJSONオブジェクトを指定します。バージョン管理により、実行中のインスタンスに影響を与えずにテンプレートを更新し、準備が整った時点でデプロイできます。

すべてのLaunch Templateはバージョン1から始まります。新しいバージョンを作成するときは、変更したフィールドだけを上書きでき、その他の設定は元のバージョンから継承されます。ASGには、$Latestバージョン（常に最新）または$Defaultバージョン（明示的に指定したバージョン）を使用するように設定できます。$Defaultを使用すると段階的なロールアウトを制御でき、$Latestは開発環境で便利です。

Auto Scaling Group（ASG）は、定義した範囲内でEC2インスタンス群を維持します。範囲には最小容量（下限）、最大容量（上限）、希望容量（その時点での目標台数）が含まれます。インスタンスのヘルスチェックに失敗した場合やスケーリングポリシーが実行された場合、ASGはインスタンスを自動的に起動または終了し、最小容量から最大容量までの範囲で希望容量を維持します。

ASGを作成するときは、特定のAMIを直接指定するのではなく、Launch Templateを参照します。また、インスタンスを起動するVPCサブネットも指定します。複数のサブネット（各AZに1つ）に分散すると、組み込みのマルチAZ冗長性を確保できます。1つのAZに障害が発生した場合、ASGは残りのAZで代替インスタンスを自動的に起動します。

デフォルトでは、ASGはEC2ヘルスチェックを使用します。このチェックでインスタンスが異常と判定されるのは、停止または終了している場合、あるいはハイパーバイザーが障害を報告した場合だけです。ロードバランサーを関連付ける場合は、ELBヘルスチェックに切り替え、稼働中であってもHTTP 5xxエラーを返しているインスタンスをASGが置き換えられるようにします。これは試験でよく問われる内容です。アーキテクチャにロードバランサーがある場合は、必ずELBヘルスチェックを選択してください。

適切な容量範囲を設定することは非常に重要です。最小容量によって、アプリケーションが常にトラフィックを処理できる状態を維持します（この値を下回ることはありません）。最大容量は、サービスの上限や予算を使い果たすような過剰なスケーリングを防ぎます。希望容量は初期目標であり、スケーリングポリシーによって動的に調整されます。min=max=desiredに設定すると、ASGは固定サイズのグループとして動作します。これは、Launch Templateのデプロイや容量を固定したい場合に便利です。

Web層のアプリケーションでは、ASGをApplication Load Balancerのターゲットグループに関連付けます。ASGが起動した各新規インスタンスはターゲットグループに自動登録され、終了したインスタンスは自動的に登録解除されます。これにより、正常に稼働しているインスタンスにのみトラフィックが流れます。また、ASGがロードバランサーレベルの障害を認識できるよう、ヘルスチェックのタイプをELBに設定する必要があります。

User dataは、インスタンスの初回起動時に一度実行されるシェルスクリプト（Base64エンコード）です。Launch Templateでは、パッケージのインストール、エージェント（CloudWatch、SSM）の設定、アプリケーションコードの取得に使用するのが適切です。インスタンスの更新時に問題が発生しないよう、User dataは冪等にしてください。つまり、複数回実行しても安全なスクリプトにします。複雑な構成では、大規模なスクリプトを埋め込むのではなく、AWS Systems Managerや構成管理ツールを呼び出してください。

Warm Poolは、ASGの外部に、すぐに使用できる状態の停止済み（または稼働中の）EC2インスタンス群を事前に初期化しておきます。ASGがスケールアウトする必要がある場合、コールド状態のインスタンスを起動する代わりにWarm Poolから取得するため、容量の追加にかかる時間を大幅に短縮できます。Warm Pool内のインスタンスには停止状態の料金（EBSのみで、CPU料金はなし）が発生するため、完全に稼働させた予備インスタンスを維持するよりも大幅に低コストです。

ASGがスケールインするときは、どのインスタンスを終了するかを決める必要があります。デフォルトの終了ポリシーでは、まずインスタンス数が最も多いAZを選択して再分散し、次に最も古いLaunch Templateを選択し、その後、請求時間に最も近いインスタンスを選択します。この順序はカスタマイズできます。たとえば、OldestLaunchTemplateを選択すると、古い設定で稼働しているインスタンスから削除できます。ASGは、サブネットが利用可能になった後や手動変更の後にも、AZの再分散を自動的に実行します。

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

このレッスンでは、次のことを学びました。Launch Templatesは、複数のバージョンと$Latest/$Defaultバージョンポインターをサポートする、バージョン管理可能で再利用できるインスタンスの設計図です。ASGの容量範囲（最小/最大/希望）はフリートのサイズを管理し、サブネット全体に自動的にマルチAZ分散します。また、ASGをロードバランサーの背後に配置する場合は、アプリケーションレベルの障害でインスタンスが置き換えられるよう、ELBヘルスチェックを有効にする必要があります。次は、ターゲット追跡やステップスケーリングなどのスケーリングポリシーについて学びます。