助け合いフォーラム

AWS

AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 30589
問題を開く
Auto Scalingのライフサイクルフックで実現可能なことはどれか。(2つ選択)

正解

スケールアウトによって新たに追加したインスタンスに初期化スクリプトを実行させる

スケールインによって終了するインスタンスのログを収集・退避させる

解説

ライフサイクルフックは、スケーリング発生によるEC2インスタンスの起動または終了時に任意の処理を実行する機能です。例えば、スケールアウト(リソースの増加)によって新たに追加したインスタンスに初期化スクリプトを実行させたり、スケールイン(リソースの削減)によって終了するインスタンスのログを収集・退避させるといった処理を行えます。

したがって正解は
・スケールアウトによって新たに追加したインスタンスに初期化スクリプトを実行させる
・スケールインによって終了するインスタンスのログを収集・退避させる
です。

その他の選択肢については、以下のとおりです。

・スケールアウトが発生した際に起動するリソースを設定する
「起動テンプレート」で実現可能なことなので、誤りです。

・平均CPU使用率が30%になるように自動的にスケーリングする
「ターゲット追跡スケーリング」で実現可能なことなので、誤りです。

・スケジュールした日時に1回のみ、または定期的なスケジュールで自動的にスケーリングする
「スケジュールに基づくスケーリング」で実現可能なことなので、誤りです。

参考

【Auto Scaling】
Auto Scalingは、EC2インスタンスなどのAWSリソースを負荷状況や設定されたスケジュールに基づいて、自動的にスケールアウト(リソース増加)やスケールイン(リソース削減)を実施するサービスです。Auto Scalingを利用すると、AWSリソースの負荷状況に応じて自動的に稼働台数を調整するので、リソース使用率の変動に柔軟に対応できます。

Auto ScalingはELBと組み合わせて使用されることが多く、ELBのターゲットグループ配下のリソースに障害が発生した時や負荷が増大した時に、Auto Scalingが自動的に新規のリソースを立ち上げてELBのターゲットグループに追加します。逆に負荷が低くなっている時は、ターゲットグループ内のリソースを減らすこともできます。
Auto Scalingを利用することによって、システムの可用性やコストパフォーマンスの向上に繋がります。


【Auto Scalingグループ】
Auto Scalingグループは、スケーリング対象となるAWSリソースを管理するためのグループです。最小・最大・希望リソース数などのパラメータに基づいて、AWSリソースのスケーリング(スケールアウト/イン)を自動的に行います。Auto ScalingのヘルスチェックによりAuto Scalingグループ内の正常なリソース数が必要なリソース数より下回った場合や、AWSリソースの負荷状況に応じて自動的に新しいリソースが起動されます。

[Auto Scalingグループの主な設定項目]


【スケーリングポリシー】
スケーリングはAWSリソースの負荷状況(パフォーマンス)やスケジュールに基づいて自動的に実施させる他、手動で実施することもできます。スケーリングの発生条件とスケールアウト/インのアクションを「スケーリングポリシー」に設定します。
本項では下記のスケーリングポリシーについて説明します:
・動的スケーリング
・スケジュールに基づくスケーリング
・予測スケーリング
・手動スケーリング

■動的スケーリング
リアルタイムのパフォーマンスに基づいて自動的にスケーリングを実施します。スケーリングの発生条件によって「シンプルスケーリング」「ステップスケーリング」「ターゲット追跡スケーリング」の3つのタイプに分かれています。

○シンプルスケーリング
特定のメトリクス(CPU使用率などシステムのパフォーマンスに関するデータ)に対する1つのしきい値に基づいてスケーリングを実施します。
下記の例では、300秒間の平均CPU使用率が50%を超えたら、インスタンスを1台追加するように設定しています。


○ステップスケーリング
特定のメトリクスに対する複数のしきい値に基づいてスケーリングを段階的に実施します。
下記の例では、300秒間の平均CPU使用率が50%を超えたらインスタンスを1台追加し、90%を超えたら2台追加するように設定しています。


○ターゲット追跡スケーリング
特定のメトリクスが指定した目標値になるようにスケーリングを実施します。増減するインスタンス数はAWS側で調整されます。
下記の例では、平均CPU使用率が30%になるように設定しています。


■予測スケーリング
過去のパフォーマンスデータから未来のリソース需要を予測し、最適なリソース数になるようにスケーリングを実施します。
下記の例では、過去1週間のCPU使用率のデータを元にインスタンス数を調整するよう設定しています。


■スケジュールに基づくスケーリング
スケジュールした日時に1回のみ、または定期的なスケジュールでスケーリングを実施します。
下記の例では、毎日午前8時30分からインスタンス数を4台にするように設定しています。


■手動スケーリング
ユーザーが手動でスケーリングを実施します。
下記の例では、インスタンス数が3台になるように設定しています。


【Auto Scalingのヘルスチェック】
リソースがEC2インスタンスの場合、Auto Scalingのヘルスチェックのタイプには「EC2」と「ELB」があります。「EC2」はインスタンスのステータスチェックの結果を確認し、「ELB」は指定した接続先への応答確認をします。Auto Scalingのヘルスチェックで異常となったリソースは、自動的に終了されます。
デフォルトでは「EC2」が有効、「ELB」は無効になっていますが、「EC2」「ELB」ともに有効にすることが推奨されています。


Auto Scalingのヘルスチェックでは、リソースが起動してから初回のヘルスチェックまでの待機時間として「ヘルスチェックの猶予期間」を設定できます。ヘルスチェックの猶予期間を設定することにより、リソースが起動してアプリケーションなどが立ち上がる前にヘルスチェックが実行されてしまい、ヘルスチェックが異常になってしまうのを防ぎます。

【Auto Scalingの起動テンプレート】
Auto Scalingグループで、スケールアウトが発生した時に起動するリソースを設定します。例えばEC2インスタンスの場合は、AMIやインスタンスタイプ、セキュリティグループなどEC2インスタンスを作成するための設定と同じ項目を指定します。

【スケールインの終了ポリシー】
Auto Scalingグループでスケールインが発生した時に、どの優先順位でリソースを終了するかを設定します。リソース数が最も多いAZ内で、以下の中から選択した優先順位でリソースが削除されます。
・最も起動時刻が古いリソース
・最も起動時刻が新しいリソース
・最も作成時刻が古い起動テンプレートを利用して起動されたリソース
・次の課金タイミングが最も早いリソース
デフォルトの場合は「最も作成時刻が古い起動テンプレートを利用して起動されたリソース」が選択されます。
スケールイン時に特定のリソースが終了されないようにするには、「インスタンスの保護」を有効にする必要があります。

【ライフサイクルフック】
ライフサイクルフックは、スケーリング発生によるEC2インスタンスの起動または終了時に任意の処理を実行する機能です。例えば、スケールアウトによって新たに追加したインスタンスに初期化スクリプトを実行させたり、スケールインによって終了するインスタンスのログを収集・退避させるといった処理を行えます。

上に戻る

イメージができないです

公開日 2023/07/01

Auto Scalingのライフサイクルフックで実現可能なことはどれか? という設問に対して
「スケールインによって終了するインスタンスにログを収集・退避させる」が回答の一つとして挙げられています。

ですが、わざわざスケールインによって終了するインスタンス内へ、ログを収集したり退避させる場面や
要件がイメージできません。

どなたか解説いただけますと幸いです。

個人的には、以下のような記事を見つけたこともあり、
「スケールインによって終了するインスタンス"の"ログを収集・退避させる」の誤記なのかなと感じております。
参考:https://dev.classmethod.jp/articles/autoscalling-terminating-log-upload/
 

スタッフからの返信

s staff_satomi

2023/07/03 10:22

PooDuck様 ご指摘の点を修正いたしました。 ご報告いただきまして、誠にありがとうございます。

この投稿に対して返信しませんか?