助け合いフォーラム
AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 30360
問題を開く
Auto Scalingのヘルスチェックの設定で「EC2」が有効、「ELB」が無効になっている時、可能性のある挙動は次のうちどれか。
正解
最小キャパシティ未満のインスタンスで負荷分散することがある
解説
Auto Scalingのヘルスチェックには、リソースがEC2インスタンスの場合「EC2」と「ELB」のオプションがあります。「EC2」はインスタンスのステータスチェックの結果を確認し、「ELB」は指定した接続先への応答確認をします。Auto Scalingのヘルスチェックで異常となったリソースは、自動的に終了されます。
デフォルトでは「EC2」が有効、「ELB」は無効になっていますが、「EC2」「ELB」ともに有効にすることが推奨されています。

Auto Scalingグループのヘルスチェックの設定で「EC2」が有効、「ELB」が無効になっている場合、ELBからのヘルスチェックに応答がないインスタンスは負荷分散先からは除外されますが、EC2のステータスチェック(ハードウェアやネットワーク)が正常であればインスタンスは起動した状態が続きます。例えば、ALBのヘルスチェックで指定したURLに異常(HTTP404エラーなど)が発生しても、インスタンス自体は正常に動作している場合、ALBから負荷分散されなくなりますが、インスタンスは終了しません。
インスタンスが終了しないと新規インスタンスも起動しないため、Auto Scalingグループの設定項目にある最小キャパシティ未満のインスタンスで負荷分散することがあります。
ヘルスチェックの設定で「ELB」も有効にすることで、ELBからのヘルスチェックに応答がないインスタンスが終了し、新たに正常なインスタンスが起動します。
したがって正解は
・最小キャパシティ未満のインスタンスで負荷分散することがある
です。
その他の選択肢について、Auto Scalingの仕様上そのような挙動はありません。
デフォルトでは「EC2」が有効、「ELB」は無効になっていますが、「EC2」「ELB」ともに有効にすることが推奨されています。

Auto Scalingグループのヘルスチェックの設定で「EC2」が有効、「ELB」が無効になっている場合、ELBからのヘルスチェックに応答がないインスタンスは負荷分散先からは除外されますが、EC2のステータスチェック(ハードウェアやネットワーク)が正常であればインスタンスは起動した状態が続きます。例えば、ALBのヘルスチェックで指定したURLに異常(HTTP404エラーなど)が発生しても、インスタンス自体は正常に動作している場合、ALBから負荷分散されなくなりますが、インスタンスは終了しません。
インスタンスが終了しないと新規インスタンスも起動しないため、Auto Scalingグループの設定項目にある最小キャパシティ未満のインスタンスで負荷分散することがあります。
ヘルスチェックの設定で「ELB」も有効にすることで、ELBからのヘルスチェックに応答がないインスタンスが終了し、新たに正常なインスタンスが起動します。
したがって正解は
・最小キャパシティ未満のインスタンスで負荷分散することがある
です。
その他の選択肢について、Auto Scalingの仕様上そのような挙動はありません。
学習テキスト
【Auto Scaling】
Auto Scalingは、AWSリソースを負荷状況や設定されたスケジュールに基づいて、自動的にスケールアウト(リソース増加)やスケールイン(リソース削減)するサービスです。対象のAWSリソースには、EC2インスタンスやAuroraレプリカ(リレーショナルデータベースであるAuroraの読み取り専用のコピー)などがあります。Auto Scalingを利用すると、AWSリソースの負荷状況に応じて自動的に稼働台数や処理能力などを調整するので、リソース使用率の変動に柔軟に対応できます。
【EC2 Auto Scaling】
EC2 Auto Scalingは、Auto ScalingのうちEC2インスタンスを対象とするサービスです。以下はEC2 Auto Scalingについての説明です。
EC2 Auto ScalingはElastic Load Balancing(ELB)と組み合わせて使用されることが多く、ELBのターゲットグループ配下のインスタンスに障害が発生した時や負荷が増大した時に、EC2 Auto Scalingが自動的に新規のインスタンスを立ち上げてELBのターゲットグループに追加します。逆に負荷が低くなっている時は、ターゲットグループ内のインスタンスを減らすこともできます。
EC2 Auto Scalingを利用することによって、システムの可用性やコストパフォーマンスの向上に繋がります。

【Auto Scalingグループ】
Auto Scalingグループは、スケーリング対象となるEC2インスタンスを管理するためのグループです。最小・最大・希望インスタンス数などのパラメータに基づいて、EC2インスタンスのスケーリング(スケールアウト/スケールイン)を自動的に行います。Auto Scalingグループでは、ヘルスチェックで異常と判定されたインスタンスを自動的に終了し、希望する容量を維持するために新しいインスタンスを起動します。
[Auto Scalingグループの主な設定項目]

【スケーリング方法】
スケーリングはAWSリソースの負荷状況(パフォーマンス)やスケジュールに基づいて自動的に実施させる他、手動で実施することもできます。
本項では下記のスケーリング方法について説明します。
・動的スケーリング
・予測スケーリング
・スケジュールに基づくスケーリング
・手動スケーリング
■動的スケーリング
動的スケーリングは、CPU使用率やリクエスト数などのメトリクスに基づいて、自動的にスケーリングを実施する方法です。メトリクスは、AWSやオンプレミスのリソースを監視するサービスであるAmazon CloudWatchで収集します。動的スケーリングはCloudWatchアラームを用いて実現されます。CloudWatchアラームは、メトリクスがしきい値を超えた、または下回った場合に、あらかじめ設定したアクションを自動的に実行する機能です。
動的スケーリングは、スケーリングの調整方法によって「シンプルスケーリング」「ステップスケーリング」「ターゲット追跡スケーリング」の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インスタンスの予備群(プール)です。インスタンスを停止状態または実行状態であらかじめ保持しておくことで、スケールアウト時にゼロからインスタンスを起動・初期化する必要がなくなり、起動時間を大幅に短縮できます。
【EC2 Auto Scalingのヘルスチェック】
EC2 Auto Scalingのヘルスチェックのタイプには「EC2」と「ELB」があります。「EC2」はEC2インスタンスのステータスチェックの結果を確認し、「ELB」は指定した接続先への応答確認をします。ヘルスチェックで異常となったインスタンスは、自動的に終了されます。
デフォルトでは「EC2」が有効、「ELB」は無効になっていますが、「EC2」「ELB」ともに有効にすることが推奨されています。

EC2 Auto Scalingのヘルスチェックでは、インスタンスが起動してから初回のヘルスチェックまでの待機時間として「ヘルスチェックの猶予期間」を設定できます。ヘルスチェックの猶予期間を設定することにより、インスタンスが起動してアプリケーションなどが立ち上がる前にヘルスチェックが実行されてしまい、ヘルスチェックが異常になってしまうのを防ぎます。
【EC2 Auto Scalingの起動テンプレート】
Auto Scalingグループで、スケールアウトが発生した時に起動するEC2インスタンスを設定します。AMIやインスタンスタイプ、セキュリティグループなどインスタンスを作成するための設定と同じ項目を指定します。
【スケールインの終了ポリシー】
Auto Scalingグループでスケールインが発生した時に、どの優先順位でEC2インスタンスを終了するかを設定します。インスタンス数が最も多いAZ内で、以下の中から選択した優先順位でインスタンスが終了されます。
・最も起動時刻が古いインスタンス
・最も起動時刻が新しいインスタンス
・最も作成時刻が古い起動テンプレートを利用して起動されたインスタンス
・次の課金タイミングが最も早いインスタンス
デフォルトの場合は「最も作成時刻が古い起動テンプレートを利用して起動されたインスタンス」が選択されます。
スケールイン時に特定のインスタンスが終了されないようにするには、「インスタンスの保護」を有効にする必要があります。
【ライフサイクルフック】
ライフサイクルフックは、スケーリング発生によるEC2インスタンスの起動または終了時に任意の処理を実行する機能です。例えば、スケールアウトによって新たに追加したインスタンスに初期化スクリプトを実行させたり、スケールインによって終了するインスタンスのログを収集・退避させるといった処理を行えます。
Auto Scalingは、AWSリソースを負荷状況や設定されたスケジュールに基づいて、自動的にスケールアウト(リソース増加)やスケールイン(リソース削減)するサービスです。対象のAWSリソースには、EC2インスタンスやAuroraレプリカ(リレーショナルデータベースであるAuroraの読み取り専用のコピー)などがあります。Auto Scalingを利用すると、AWSリソースの負荷状況に応じて自動的に稼働台数や処理能力などを調整するので、リソース使用率の変動に柔軟に対応できます。
【EC2 Auto Scaling】
EC2 Auto Scalingは、Auto ScalingのうちEC2インスタンスを対象とするサービスです。以下はEC2 Auto Scalingについての説明です。
EC2 Auto ScalingはElastic Load Balancing(ELB)と組み合わせて使用されることが多く、ELBのターゲットグループ配下のインスタンスに障害が発生した時や負荷が増大した時に、EC2 Auto Scalingが自動的に新規のインスタンスを立ち上げてELBのターゲットグループに追加します。逆に負荷が低くなっている時は、ターゲットグループ内のインスタンスを減らすこともできます。
EC2 Auto Scalingを利用することによって、システムの可用性やコストパフォーマンスの向上に繋がります。

【Auto Scalingグループ】
Auto Scalingグループは、スケーリング対象となるEC2インスタンスを管理するためのグループです。最小・最大・希望インスタンス数などのパラメータに基づいて、EC2インスタンスのスケーリング(スケールアウト/スケールイン)を自動的に行います。Auto Scalingグループでは、ヘルスチェックで異常と判定されたインスタンスを自動的に終了し、希望する容量を維持するために新しいインスタンスを起動します。
[Auto Scalingグループの主な設定項目]

【スケーリング方法】
スケーリングはAWSリソースの負荷状況(パフォーマンス)やスケジュールに基づいて自動的に実施させる他、手動で実施することもできます。
本項では下記のスケーリング方法について説明します。
・動的スケーリング
・予測スケーリング
・スケジュールに基づくスケーリング
・手動スケーリング
■動的スケーリング
動的スケーリングは、CPU使用率やリクエスト数などのメトリクスに基づいて、自動的にスケーリングを実施する方法です。メトリクスは、AWSやオンプレミスのリソースを監視するサービスであるAmazon CloudWatchで収集します。動的スケーリングはCloudWatchアラームを用いて実現されます。CloudWatchアラームは、メトリクスがしきい値を超えた、または下回った場合に、あらかじめ設定したアクションを自動的に実行する機能です。
動的スケーリングは、スケーリングの調整方法によって「シンプルスケーリング」「ステップスケーリング」「ターゲット追跡スケーリング」の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インスタンスの予備群(プール)です。インスタンスを停止状態または実行状態であらかじめ保持しておくことで、スケールアウト時にゼロからインスタンスを起動・初期化する必要がなくなり、起動時間を大幅に短縮できます。
【EC2 Auto Scalingのヘルスチェック】
EC2 Auto Scalingのヘルスチェックのタイプには「EC2」と「ELB」があります。「EC2」はEC2インスタンスのステータスチェックの結果を確認し、「ELB」は指定した接続先への応答確認をします。ヘルスチェックで異常となったインスタンスは、自動的に終了されます。
デフォルトでは「EC2」が有効、「ELB」は無効になっていますが、「EC2」「ELB」ともに有効にすることが推奨されています。

EC2 Auto Scalingのヘルスチェックでは、インスタンスが起動してから初回のヘルスチェックまでの待機時間として「ヘルスチェックの猶予期間」を設定できます。ヘルスチェックの猶予期間を設定することにより、インスタンスが起動してアプリケーションなどが立ち上がる前にヘルスチェックが実行されてしまい、ヘルスチェックが異常になってしまうのを防ぎます。
【EC2 Auto Scalingの起動テンプレート】
Auto Scalingグループで、スケールアウトが発生した時に起動するEC2インスタンスを設定します。AMIやインスタンスタイプ、セキュリティグループなどインスタンスを作成するための設定と同じ項目を指定します。
【スケールインの終了ポリシー】
Auto Scalingグループでスケールインが発生した時に、どの優先順位でEC2インスタンスを終了するかを設定します。インスタンス数が最も多いAZ内で、以下の中から選択した優先順位でインスタンスが終了されます。
・最も起動時刻が古いインスタンス
・最も起動時刻が新しいインスタンス
・最も作成時刻が古い起動テンプレートを利用して起動されたインスタンス
・次の課金タイミングが最も早いインスタンス
デフォルトの場合は「最も作成時刻が古い起動テンプレートを利用して起動されたインスタンス」が選択されます。
スケールイン時に特定のインスタンスが終了されないようにするには、「インスタンスの保護」を有効にする必要があります。
【ライフサイクルフック】
ライフサイクルフックは、スケーリング発生によるEC2インスタンスの起動または終了時に任意の処理を実行する機能です。例えば、スケールアウトによって新たに追加したインスタンスに初期化スクリプトを実行させたり、スケールインによって終了するインスタンスのログを収集・退避させるといった処理を行えます。
ELBのヘルスチェックについて
k
kaginote
投稿日 2024/02/04
正解の解説の中に下記文言がありますが、
ELBのヘルスチェックを無効にしているのであれば、「ELBからのヘルスチェックに応答がないインスタンスは負荷分散先からは除外されます」の動作はないと思うので誤記だと思うのですが、、、、
それとも私が何か思い違いしてるんでしょうか。
Auto Scalingグループのヘルスチェックの設定で「EC2」が有効、「ELB」が無効になっている場合、ELBからのヘルスチェックに応答がないインスタンスは負荷分散先からは除外されますが、EC2のステータスチェック(ハードウェアやネットワーク)が正常であればインスタンスは起動した状態が続きます。
2024/02/04 11:48
ややこしいですが、ここではあくまでもAuto Scalingグループの設定について設問のため、「Auto Scalingグループのヘルスチェック設定でELBが無効」というのは、「Auto Scalingの判定を行う際、ELBが行っているヘルスチェック結果をスケーリングの判定に使わない」という意味になると思います。
(おそらく、ELB自体はヘルスチェックを行っている状態だと思います)
だとすると、今回は「ELBはインスタンスからの応答有無を確認しているが、AutoScalingはインスタンスからの応答有無を確認しない」という状態です。
ELBのヘルスチェックは有効なため、「ELBからのヘルスチェックに応答がないインスタンスは負荷分散先からは除外されます」はあり得ると思います。
コメント
この投稿に対して返信しませんか?
k kaginote
2024/02/06 21:04
なるほど。判定が無効という意味なら確かにそうですね。 回答ありがとうございました。