助け合いフォーラム
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は、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インスタンスの起動または終了時に任意の処理を実行する機能です。例えば、スケールアウトによって新たに追加したインスタンスに初期化スクリプトを実行させたり、スケールインによって終了するインスタンスのログを収集・退避させるといった処理を行えます。
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インスタンスの起動または終了時に任意の処理を実行する機能です。例えば、スケールアウトによって新たに追加したインスタンスに初期化スクリプトを実行させたり、スケールインによって終了するインスタンスのログを収集・退避させるといった処理を行えます。
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
なるほど。判定が無効という意味なら確かにそうですね。 回答ありがとうございました。