助け合いフォーラム
AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 34932
問題を開く
ある企業は、オンプレミスにあるWebサイトをAWSへ移行する計画を立てている。WebサイトはEC2インスタンス上で動作させることが決まっている。Webサイトの可用性を向上させるために、HTTPエラーが発生したときでもサービスを継続できるようにしたい。
要件を満たすために、ソリューションアーキテクトはどうすればよいか。
要件を満たすために、ソリューションアーキテクトはどうすればよいか。
正解
ALBとAuto Scalingグループを構成し、複数のEC2インスタンスを配置する。ALBのヘルスチェックで指定したURLに対して応答確認されるように設定する。Auto Scalingのヘルスチェックの設定でELBのヘルスチェックを有効にする
解説
ALBとAuto Scalingグループを組み合わせると、ALBのターゲットグループ配下のEC2インスタンスに障害が発生した時や負荷が増大した時に、Auto Scalingが自動的に新規のインスタンスを立ち上げてALBのターゲットグループに追加します。
複数のEC2インスタンスをALB配下のAuto Scalingグループに配置することで、可用性が向上します。
リソースがEC2インスタンスの場合、Auto Scalingのヘルスチェックのタイプには「EC2」と「ELB」があります。「EC2」はインスタンスのステータスチェックの結果を確認し、「ELB」は指定した接続先への応答確認をします。Auto Scalingのヘルスチェックで異常となったリソースは、自動的に終了されます。
デフォルトでは「EC2」が有効、「ELB」は無効になっていますが、「EC2」「ELB」ともに有効にすることが推奨されています。
Auto Scalingグループのヘルスチェックの設定で「EC2」が有効、「ELB」が無効になっている場合、ELBからのヘルスチェックに応答がないインスタンスは負荷分散先からは除外されますが、EC2のステータスチェック(ハードウェアやネットワーク)が正常であればインスタンスは起動した状態が続きます。例えば、ELBヘルスチェックで指定したURLに異常(HTTP404エラーなど)が発生しても、インスタンス自体は正常に動作している場合、ALBから負荷分散されなくなりますが、インスタンスは終了しません。インスタンスが終了しないと新規インスタンスも起動しないので、サービスを継続できなくなる恐れがあります。
ヘルスチェックの設定で「ELB」も有効にすることで、ELBからのヘルスチェックに応答がないインスタンスが終了し、新たに正常なインスタンスが起動します。
設問の場合では、ALBのヘルスチェックで指定したURLに対して応答確認されるように設定し、Auto Scalingグループのヘルスチェックの設定でELBのヘルスチェックを有効にすることで、HTTPエラーが発生しても正常にサービスを継続できるようになります。
したがって正解は
・ALBとAuto Scalingグループを構成し、複数のEC2インスタンスを配置する。ALBのヘルスチェックで指定したURLに対して応答確認されるように設定する。Auto Scalingのヘルスチェックの設定でELBのヘルスチェックを有効にする
です。
その他の選択肢については、以下のとおりです。
・ALBとAuto Scalingグループを構成し、複数のEC2インスタンスを配置する。Auto ScalingのヘルスチェックでEC2のヘルスチェックを有効にして、EC2のステータスが確認されるように設定する
・ALBとAuto Scalingグループを構成し、複数のEC2インスタンスを配置する。Auto ScalingのヘルスチェックでEC2のヘルスチェックを有効にして、指定したURLに対して応答確認されるように設定する
Auto ScalingのEC2のヘルスチェックは、EC2インスタンスのハードウェアとネットワークの状態を確認します。HTTPエラーは検出できないので、誤りです。
また、EC2のヘルスチェックは強制的に有効になっているので、設定する必要がありません。
・ALBとAuto Scalingグループを構成し、複数のEC2インスタンスを配置する。ALBのヘルスチェックで指定したURLに対して応答確認されるように設定する。Auto Scalingのヘルスチェックの設定でEC2のヘルスチェックを有効にして、EC2のステータスが確認されるように設定する
ALBでHTTPエラーの検出ができるようになりますが、Auto Scalingのヘルスチェックでは検出できません。Auto ScalingでHTTPエラーを検出するにはヘルスチェックの設定で、ELBのヘルスチェックを有効にする必要があります。よって、誤りです。
複数のEC2インスタンスをALB配下のAuto Scalingグループに配置することで、可用性が向上します。
リソースがEC2インスタンスの場合、Auto Scalingのヘルスチェックのタイプには「EC2」と「ELB」があります。「EC2」はインスタンスのステータスチェックの結果を確認し、「ELB」は指定した接続先への応答確認をします。Auto Scalingのヘルスチェックで異常となったリソースは、自動的に終了されます。
デフォルトでは「EC2」が有効、「ELB」は無効になっていますが、「EC2」「ELB」ともに有効にすることが推奨されています。
Auto Scalingグループのヘルスチェックの設定で「EC2」が有効、「ELB」が無効になっている場合、ELBからのヘルスチェックに応答がないインスタンスは負荷分散先からは除外されますが、EC2のステータスチェック(ハードウェアやネットワーク)が正常であればインスタンスは起動した状態が続きます。例えば、ELBヘルスチェックで指定したURLに異常(HTTP404エラーなど)が発生しても、インスタンス自体は正常に動作している場合、ALBから負荷分散されなくなりますが、インスタンスは終了しません。インスタンスが終了しないと新規インスタンスも起動しないので、サービスを継続できなくなる恐れがあります。
ヘルスチェックの設定で「ELB」も有効にすることで、ELBからのヘルスチェックに応答がないインスタンスが終了し、新たに正常なインスタンスが起動します。
設問の場合では、ALBのヘルスチェックで指定したURLに対して応答確認されるように設定し、Auto Scalingグループのヘルスチェックの設定でELBのヘルスチェックを有効にすることで、HTTPエラーが発生しても正常にサービスを継続できるようになります。
したがって正解は
・ALBとAuto Scalingグループを構成し、複数のEC2インスタンスを配置する。ALBのヘルスチェックで指定したURLに対して応答確認されるように設定する。Auto Scalingのヘルスチェックの設定でELBのヘルスチェックを有効にする
です。
その他の選択肢については、以下のとおりです。
・ALBとAuto Scalingグループを構成し、複数のEC2インスタンスを配置する。Auto ScalingのヘルスチェックでEC2のヘルスチェックを有効にして、EC2のステータスが確認されるように設定する
・ALBとAuto Scalingグループを構成し、複数のEC2インスタンスを配置する。Auto ScalingのヘルスチェックでEC2のヘルスチェックを有効にして、指定したURLに対して応答確認されるように設定する
Auto ScalingのEC2のヘルスチェックは、EC2インスタンスのハードウェアとネットワークの状態を確認します。HTTPエラーは検出できないので、誤りです。
また、EC2のヘルスチェックは強制的に有効になっているので、設定する必要がありません。
・ALBとAuto Scalingグループを構成し、複数のEC2インスタンスを配置する。ALBのヘルスチェックで指定したURLに対して応答確認されるように設定する。Auto Scalingのヘルスチェックの設定でEC2のヘルスチェックを有効にして、EC2のステータスが確認されるように設定する
ALBでHTTPエラーの検出ができるようになりますが、Auto Scalingのヘルスチェックでは検出できません。Auto ScalingでHTTPエラーを検出するにはヘルスチェックの設定で、ELBのヘルスチェックを有効にする必要があります。よって、誤りです。
参考
【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インスタンスの起動または終了時に任意の処理を実行する機能です。例えば、スケールアウトによって新たに追加したインスタンスに初期化スクリプトを実行させたり、スケールインによって終了するインスタンスのログを収集・退避させるといった処理を行えます。
デフォルト設定
K
Kurojun
投稿日 2024/03/29
お世話になります。
問題解答の是非ではないですが、
デフォルトでは「EC2」が有効、「ELB」は無効になっていますが、「EC2」「ELB」ともに有効にすることが推奨されています。
であればデフォルトでそれぞれ有効にすれば良いのに、と思うのですが、現状のデフォルト設定はどんなユースケースを想定しているのでしょう?
b
birdpixy
2024/04/01 11:44
Auto ScalingヘルスチェックのELBを有効にしたときに、注意書きで
EC2 Auto Scaling は、Elastic Load Balancing によって実行されるヘルスチェックの検出と対応を開始します。予期しない終了を回避するには、まず以下でこれらのヘルスチェックの設定を確認します ロードバランサーコンソール
と出てくるので、インスタンスの終了が想定外に発生するかもしれないから、念のためELBのヘルスチェックの設定を確認させるためなのかもしれません。
コメント
この投稿に対して返信しませんか?