014-AWS SAP AWS 「理論・実践・一問道場」 Auto Scalingライフサイクルフック

type

status

date

slug

summary

理論

Amazon EC2、Auto Scaling、S3に関する基礎知識と関連技術の解説

1. Amazon EC2

Amazon EC2は、クラウド上で仮想サーバーを提供するサービスです。ユーザーは必要に応じてインスタンスを作成し、アプリケーションを実行することができます。

特徴:

可変性: インスタンスを柔軟に増減可能。
拡張性: 自動スケーリングで需要に応じた対応が可能。
ログ管理: システムログやアプリケーションログを生成。

2. Amazon S3

Amazon S3は、安全で耐久性のあるクラウドストレージを提供します。ログファイルのバックアップやアーカイブ、集中管理に利用されます。

用途:

ログデータの保存と分析。
アプリケーション間でのデータ共有。
自動化されたバックアップシステムの構築。

3. Auto Scaling

Auto Scalingは、EC2インスタンスを需要に応じて自動的にスケールイン・スケールアウトする機能を提供します。

ライフサイクル:

スケールアウト (増加): 負荷が高まった場合にインスタンスを追加。
スケールイン (減少): 負荷が低下した場合にインスタンスを削除。

4. Auto Scalingライフサイクルフック

ライフサイクルフックは、インスタンスの状態遷移中にカスタムアクションを実行できる機能です。

例:

インスタンス終了前にログをS3にアップロード。
起動後に設定スクリプトを実行。

主な状態遷移:

Pending -> InService: 起動プロセス。
Terminating -> Terminated: 終了プロセス。

ABANDONアクションの動作

概要: ライフサイクルフックを設定した場合、インスタンスは遷移中の状態 (Pending:Wait または Terminating:Wait) に留まり、指定された処理が完了するのを待ちます。この状態で ABANDON アクションを実行すると、以下の動作が行われます。

動作内容:

Auto Scalingはインスタンスの状態遷移を中止します。
インスタンスが終了プロセス中の場合 (Terminating:Wait)、そのインスタンスは終了されません。
スケーリンググループのサイズは調整されないため、期待されるスケールアウトまたはスケールインの動作に影響を与える可能性があります。

具体例: ログ保存処理におけるABANDON

インスタンスが終了する際に、ログデータをS3にコピーする処理が必要な場合、ABANDONを使用すると次のように機能します。

シナリオ:

Auto Scalingでインスタンスが終了プロセスに入る。

ライフサイクルフックでインスタンスを Terminating:Wait に設定。

S3にログをアップロードするスクリプトが失敗する。

ABANDONの活用:

スクリプトの失敗を検出し、ABANDON アクションを送信。

インスタンスの終了を防ぎ、手動でログを回収したり修正を行う猶予を得る。

注意点

スケーリンググループの整合性: ABANDONを使用すると、スケーリンググループのインスタンス数が期待する状態と異なる場合があるため、適切に管理する必要があります。

通常の終了との違い: 通常は CONTINUE アクションを送信して、スケーリングプロセスを再開させますが、ABANDONはその代わりにインスタンスの遷移を停止します。

5. AWS Systems Manager

AWS Systems Managerは、クラウド環境やオンプレミス環境の管理を簡素化するツールセットです。特にスクリプト実行やタスクの自動化で役立ちます。

機能:

Run Command: スクリプトやコマンドをインスタンスで実行。
Automation: 定型的なタスクを自動化。
セッション管理: リアルタイムでインスタンスに接続。

6. Amazon EventBridge

EventBridgeはAWS内外のサービスイベントをトリガーとして活用することができます。

特徴:

自動化されたイベント駆動型アクションを実行。
AWSサービスとシームレスに統合。
インスタンスの終了やスケーリングイベントを検知。

7. システム構築の例

以下は、Auto Scalingグループ内でのEC2インスタンス終了時にログを確実にS3に保存するための一例です。

ライフサイクルフックを設定:

インスタンスの終了時に処理を遅延させる。

遷移中 (Terminating:Wait) の状態でログ保存処理を実行。

EventBridgeルールを設定:

インスタンス終了イベントを検知。

Lambda関数やSystems Managerのコマンド実行をトリガー。

AWS Systems Managerでログをコピー:

EC2インスタンス内のログファイルをS3にアップロードするスクリプトを作成。

ライフサイクルフックからこの処理を呼び出し、完了後にインスタンスを終了。

8. メリットとベストプラクティス

信頼性向上: インスタンス終了時のデータ喪失防止。

スケーリングへの影響最小化: 処理完了後に速やかに終了。

コスト最適化: インスタンスの無駄なリソース消費を抑制。

これらの知識を基に、スケーラブルで信頼性の高いログ管理システムを構築できます。A

実践

AutoScallingのライフサイクルフックを使用してスケールイン時にEC2インスタンス内のログを退避させる | DevelopersIO

EC2 AutoScalling環境下でEC2インスタンスがターミネートする際のログ退避についてライフサイクルフックを使用したアーキテクチャーを検討したのでまとめておきたいと思います。今回検討したアーキテクチャーはザックリ下図のイメージです。

https://dev.classmethod.jp/articles/autoscalling-terminating-log-upload/

アーキテクチャの概要

目的:

EC2 Auto Scalingにおいて、インスタンスがターミネートされる際に、重要なログデータを退避させる仕組みを構築する。

主な要素:

EC2 Auto Scaling: 動的にインスタンスをスケールさせる。

ライフサイクルフック: インスタンスの終了プロセス中に処理を挟む。

ログ退避ストレージ: Amazon S3や他のストレージサービス。

通知と実行管理: Amazon SNS、AWS Lambda、またはStep Functionsを利用。

今回のアーキテクチャのフロー

ライフサイクルフックの設定

Auto Scalingグループにライフサイクルフックを設定。

インスタンスの終了時にイベントが発生し、EventBridgeに通知。

EventBridgeによるトリガー

ライフサイクルフックのイベントを受けて、EventBridgeがLambda関数をトリガー。

SSMドキュメントの実行

Lambda関数が、事前に準備されたSSMドキュメントを利用して、対象のEC2インスタンスにRun Commandを実行。

インスタンス内の必要なログを収集し、S3へ転送。

ログ退避

インスタンスがターミネートされる前に、退避が必要なログデータをS3に安全に保存。

構成要素

Auto Scalingグループ

インスタンスの動的なスケーリングと管理。

ライフサイクルフック

インスタンス終了時の「Terminating:Wait」状態で退避処理を実行。

EventBridge

ライフサイクルフックのイベントを監視し、Lambda関数をトリガー。

AWS Lambda

ログ退避の実行管理。SSMドキュメントを実行。

Amazon S3

退避されたログデータの保存先。

AWS Systems Manager (SSM)

Run Commandを利用してインスタンス内の操作を実行。

メリット

自動化されたログ退避プロセスにより、手作業を削減。

重要なログを確実に保存し、可用性とセキュリティを向上。

EventBridgeとLambdaを活用した柔軟な設計。

注意点

ライフサイクルフックでの処理がタイムアウトしないように、十分な時間を設定。

S3のバケットポリシーやIAMロールの権限設定を適切に構成。

Lambda関数のエラー処理と監視を実装。

ハンズオン

ログ格納用S3バケットの準備

まずは下記構成図の赤点線部分のS3バケットを作っていきます。

ログ格納用のS3バケットはデフォルトの設定で問題ありません。次の工程で「バケット名」を使うのでバケット名は控えておいてください。

SSM Documentの準備

次に、下記構成図の赤点線部分のSSM Documentを作成していきます。

Systems Managerのダッシュボードから「共有リソース」-「ドキュメント」を選択し「Create document」-「Command or Session」を選択します。

任意の名前を入力し、ターゲットオプションに「/AWS::EC2::Instance」を選択、ドキュメントタイプに「コマンドドキュメント」を選択します。

コンテンツエリアで「YAML」を選択し下記のコマンドをコピペします。対象のログは実際の環境で対象としたいログファイル/ログファイルのパスに置き換えてください。また、「バケット名」には前工程で作成したログ格納用S3バケットの名前を指定します。

SSM Documentが作成されたことを確認します。

Lambdaの準備

次に、下記構成図の赤点線部分のLambda関数を作成していきます。

コードはPython3.9で作成しています。コード自体はシンプルでEventBridge経由で受け取ったイベントのデータからインスタンスIDを抽出して、Run Command実行時の対象EC2として指定をしています。

Lambda関数からSSM Documentを叩くため、Lambda関数にアタッチされているロールに必要な権限を付与しておきます。「設定」-「アクセス権限」からアタッチされているロールを選択します。

今回はAmazonSSMFullAccessを割り当てておきます。

Lambda関数の準備が完了しました。

EventBridgeの準備

次に、下記構成図の赤点線部分赤点線部分のEventBridgeのルールを作成していきます。

EventBridgeのダッシュボードから「ルールを作成」を選択します。

任意の名前と説明を入力します。

パターン定義で「イベントパターン」-「カスタムパターン」を選択し、イベントパターンに下記のパターンをコピペし「保存」します。

ターゲットに「Lambda関数」を選択し、前の工程で作成したLambda関数を指定します。

その他はデフォルトで作成します。

Auto Scalingグループを作成

まずは下記構成図の黒枠部分のをAuto Scaling作っていきます。

Auto Scalingグループを作成するには、まずインスタンステンプレートを作成する必要があります。その後、Auto Scalingグループを作成して、スケーリングポリシーやターゲット設定を行います。以下にその手順を詳細に説明します。

1. EC2ダッシュボードに移動

AWS Management Consoleにログインし、EC2ダッシュボードに移動します。

左側のナビゲーションペインから「Auto Scaling Groups」を選択します。

2. Auto Scalingグループの作成

「Create Auto Scaling group」ボタンをクリックします。

3. インスタンステンプレートの作成

Auto Scalingグループに使用するインスタンステンプレートを作成します。このテンプレートは、Auto Scalingグループがインスタンスを起動する際に使用する設定を定義します。

左側のメニューから「Launch Templates」を選択し、「Create launch template」をクリックします。

Launch Template Name（例: my-auto-scaling-template）を入力します。

AMI (Amazon Machine Image)を選択します。例えば、Amazon Linux 2023など、アプリケーションに適したAMIを選びます。

インスタンスタイプ（例: t2.micro）を選択します。

その他の設定（ネットワーク、セキュリティグループ、IAMロールなど）を設定します。これらは、アプリケーションに必要なアクセス権やネットワークの設定を反映させるために重要です。

ユーザーデータ - オプション

4. Auto Scalingグループを作成

インスタンステンプレートが作成されたら、これを使用してAuto Scalingグループを作成します。

「Create Auto Scaling group」ボタンをクリックし、作成したインスタンステンプレートを選択します。

Auto Scalingグループ名を入力します（例: my-auto-scaling-group）。

ターゲットグループとして、ALB（Application Load Balancer）を選択します。ALBは、トラフィックをAuto Scalingグループ内のインスタンスに分散します。

新しいロードバランサーにアタッチすると設定します。新しいロードバランサーのスキームはInternet-facingに設定

新しいターゲットグループ名と設定します。

5. Auto Scalingポリシーの設定

Auto Scalingの設定を行います。これには、インスタンスの最小数、最大数、スケーリングのポリシーを含みます。

最小インスタンス数と最大インスタンス数を設定します。例えば、最小インスタンス数を0、最大インスタンス数を1に設定することができます。

スケーリングポリシーを設定します。これには、CPU使用率やネットワークトラフィックなどに基づいてインスタンス数をスケーリングするルールを作成します。

6. 必要なネットワーク設定を行う

Auto Scalingグループが使用するVPC（仮想プライベートクラウド）とサブネットを選択します。これにより、インスタンスが配置されるネットワーク環境が決定されます。

VPCとサブネットを選択します。通常は、ALBと同じVPC内のサブネットを選ぶことが一般的です。

必要に応じて、セキュリティグループやIAMロールを設定します。

7. Auto Scalingグループの作成

設定が完了したら、「Create Auto Scaling group」ボタンをクリックして、Auto Scalingグループの作成を完了します。

これで、Auto Scalingグループが作成され、インスタンステンプレートに基づいて自動的にインスタンスが起動されるようになります。また、ALBと連携してトラフィックを効率的に分散させることができます。

8. ALBのURLでアクセスしてみる

ライフサイクルフックの設定

最後に、下記構成図の赤点線部分のライフサイクルフックの設定を実施していきます。

EC2のダッシュボードから「Auto Scalling Groups」を選択し、対象となるAuto Scallingグループ名を選択します。

「インスタンス管理」タブを選択し「ライフサイクルフックを作成」を選択します。

上記部分のパラメータについて補足をしておきます。

ライフサイクル移行

ライフサイクルフックには「起動ライフサイクルフック」と「終了ライフサイクルフック」の2種類があり、今回は「終了ライフサイクルフック（インスタンス終了）」を使用してインスタンスのターミネートを遅らせ、その間にログの退避をする構成としています。もう一方の「起動ライフサイクルフック」を使用するケースとしては、AutoScallingの起動設定やベースAMIに組み込めない設定や作業をスケールアウトのタイミングに行うケースなどが考えられます。

ハートビートタイムアウト

EC2インスタンスの起動またはターミネートを遅らせる時間を「ハートビートタイムアウト」の時間として設定します。この「ハートビートタイムアウト」の秒数は設計が必要になる部分なのですが、必要な作業が完了する十分な時間を割り当てておくと良いでしょう。「ハートビートタイムアウト」は下図の青色部分を指し、起動またはターミネートの「Wait」として設定されることとなります。

最後にIAM権限を適切に修正、Autoscalingのキャパシティーを2→1に調整することで、テストする

要素	設定が必要なIAM権限
AutoScaling	特に設定なし
EventBridge	検出を開始
Lambda	`SSMManagedInstanceCore` `ssm:SendCommand`
SSM Run Command	特になし
S3	特になし
EC2	`SSMManagedInstanceCore` `s3:PutObject`

一問道場

ある企業が、複数のAmazon EC2インスタンスをAuto Scalingグループで運用しており、これらのインスタンスはApplication Load Balancerの背後で実行されています。アプリケーションの負荷は時間帯によって変動し、EC2インスタンスは定期的にスケールイン・スケールアウトしています。ログファイルは15分ごとに中央のAmazon S3バケットにコピーされていますが、セキュリティチームは、終了したEC2インスタンスからログファイルが欠落していることに気付きました。

終了したEC2インスタンスからログファイルを確実にS3バケットにコピーするためには、どのアクションが必要ですか？

ログファイルをAmazon S3にコピーするスクリプトを作成し、EC2インスタンスに保存する

Auto ScalingライフサイクルフックとAmazon EventBridgeルールを作成して、Auto Scalingグループのライフサイクルイベントを検出

autoscaling:EC2_INSTANCE_TERMINATING トランジションでAWS Lambda関数を呼び出し、Auto ScalingグループにABANDONを送信してインスタンスの終了を防止

スクリプトを実行してログファイルをS3にコピーし、AWS SDKを使ってインスタンスを終了する

ログファイルをS3にコピーするスクリプトを含むAWS Systems Managerドキュメントを作成

Auto ScalingライフサイクルフックとAmazon EventBridgeルールを作成して、ライフサイクルイベントを検出

autoscaling:EC2_INSTANCE_TERMINATING トランジションでAWS Lambda関数を呼び出し、AWS Systems ManagerのSendCommand操作でスクリプトを実行

ログファイルをコピーし、Auto ScalingグループにCONTINUEを送信してインスタンスを終了

ログ配信レートを5分ごとに変更

ログファイルをS3にコピーするスクリプトを作成し、EC2インスタンスのユーザーデータに追加

EC2インスタンス終了を検出するAmazon EventBridgeルールを作成

EventBridgeルールからAWS Lambda関数を呼び出し、AWS CLIを使ってユーザーデータスクリプトを実行してログファイルをコピーし、インスタンスを終了

ログファイルをS3にコピーするスクリプトを含むAWS Systems Managerドキュメントを作成

Auto Scalingライフサイクルフックを作成し、メッセージをAmazon SNSに送信

SNS通知をトリガーに、AWS Systems ManagerのSendCommand操作でスクリプトを実行

ログファイルをコピーし、Auto ScalingグループにABANDONを送信してインスタンスを終了

解説

この問題は、Amazon EC2インスタンスがAuto Scalingグループの一部として稼働している状況で、インスタンス終了時にログファイルがS3にコピーされないという問題に関するものです。問題の目的は、EC2インスタンスが終了する際にもログファイルを確実にS3に保存するための解決策を選択することです。

以下は、各選択肢の詳細な解説です。

A. スクリプトを作成してEC2インスタンスからログをS3にコピーし、Auto ScalingライフサイクルフックとEventBridgeを使用して処理を管理する

問題点: この方法では、インスタンスが終了する際に「ABANDON」アクションを使ってインスタンスの終了を防ぐことが前提です。しかし、インスタンスの終了を防ぐことは、リソースの過剰使用やスケールインの遅延を引き起こし、最適な解決策ではありません。

理由: インスタンスの終了を待ってから作業を行うと、他のスケーリング操作に影響を与える可能性があります。

B. AWS Systems Managerを使用してスクリプトを実行し、ログファイルをS3にコピーする

解説: Systems Managerの「SendCommand」を使用して、EC2インスタンスでスクリプトを実行し、ログファイルをS3にコピーします。ライフサイクルフックを使用してインスタンスが終了する前に処理を行い、終了後には「CONTINUE」アクションを使って正常に終了させます。

理由: Systems Managerを使うことで、インスタンスの終了を中断することなく、ログファイルを確実にバックアップできます。この方法は、AWSの推奨される実装方法です【16†source】。

C. ユーザーデータスクリプトを使い、インスタンス終了時にログをコピーする

解説: ユーザーデータスクリプトは、インスタンス起動時に自動的に実行されるスクリプトです。この方法では、インスタンスが終了する際にイベントを検出して処理を行いますが、ログを確実にコピーするための管理が難しくなる可能性があります。

理由: ユーザーデータはインスタンスの起動時に処理を行うため、終了時にログをバックアップするためには追加の仕組みが必要となります【16†source】。

D. SNSを使って通知を送信し、Systems Managerでログをコピーする

解説: SNS通知を使用して、インスタンス終了時に必要な作業をトリガーし、その後AWS Systems Managerを使ってログをコピーします。これにより、通知を受け取って処理を実行できますが、「ABANDON」を使用してインスタンスを中断する必要があるため、スケーリングに影響を与える可能性があります。

理由: SNSを利用する方法は、設定が少し複雑で、インスタンスの終了を中断する必要があるため、最適な方法とは言えません【15†source】。

まとめ

正しい解決策は B の「AWS Systems Managerを使用したスクリプトの実行」です。この方法は、インスタンスの終了をスムーズに行いながら、確実にログをS3にバックアップするための最適なアプローチです。