助け合いフォーラム

AWS

AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 30322
問題を開く
ALB配下にあるEC2インスタンスでアプリケーションを実行している。インスタンスは複数のAZ(AZ-a、AZ-b、AZ-c)にわたるAuto Scalingグループで実行されており、常時6台以上のインスタンスの稼働が求められている。
AZのうちいずれか1つが使用不能になった場合でもフォールトトレランス(耐障害性)を確保できる、もっともコスト効率が高いインスタンスの配置はどれか。

正解

AZ-a内にインスタンスを3台、AZ-b内にインスタンスを3台、AZ-c内にインスタンスを3台

解説

EC2インスタンスを複数のAZに配置することにより、フォールトトレランス(耐障害性)を確保することができます。
常時6台のインスタンスの稼働が求められているため、あるAZが使用不能になった場合でも、他のAZで合計6台のインスタンスが稼働できるように設計します。また必要最低限のコストにするため、フォールトトレランスを確保した上で稼働中のインスタンスを最小数にします。

各選択肢を確認していきます。

・AZ-a内にインスタンスを3台、AZ-b内にインスタンスを3台、AZ-c内にインスタンスを3台
どのAZが使用不能になっても常時6台のインスタンスが稼働できるので、フォールトトレランスを確保できます。本選択肢が正解です。

・AZ-a内にインスタンスを2台、AZ-b内にインスタンスを2台、AZ-c内にインスタンスを2台
いずれかのAZが使用不能になった場合に、インスタンスが6台未満となるので、誤りです。

・AZ-a内にインスタンスを4台、AZ-b内にインスタンスを2台、AZ-c内にインスタンスを2台
AZ-aが使用不能になった場合に、インスタンスが6台未満となるので、誤りです。

・AZ-a内にインスタンスを6台、AZ-b内にインスタンスを6台、AZ-c内にインスタンスなし
フォールトトレランスは確保できていますが、常時稼働しているインスタンスは合計12台です。
各AZに3台ずつ配置するパターン(合計インスタンス数が9台)の方が稼働インスタンスが少なく、よりコスト効率が高いので、誤りです。

学習テキスト

【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と問題の解答との関係について

投稿日 2024/09/09

この問題の問題文「Auto Scalingグループで実行されており、常時6台のインスタンスの稼働が求められている」は
auto scalingで、最小キャパシティ 6台、最大キャパシティ 6台と設定すればよい様に思えたのですが
解答からしますと、そうではないということになりますでしょうか。
私は
「auto scalingで、最小キャパシティ 6台、最大キャパシティ 6台」とすると、ひとつのAZが障害と
なった場合に、6台から不足した数のインスタンスを自動で、他のAZで起動できると思っておりました。
その様に考えた場合、正解は
「AZ-a内にインスタンスを2台、AZ-b内にインスタンスを2台、AZ-c内にインスタンスを2台」
になると思ったのですが、誤りの様なので、auto scalingの理解が誤っているとは思うのですが
どの様に誤っているかがわからないでおります。

上記の疑問点について、ご存じの方がおられましたら、教えて下さい。
宜しくお願いいたします。

2024/09/11 20:05

私も同じ疑問を持ちました。回答者がいらっしゃらないようなので、ChatGPTに聞いたところ、やはり3台3台3台の構成が正解とのことでした。
どうやら6台のインスタンスを「常時」維持することがポイントらしく、1つAZダウン後auto scalingが動いて残りのAZに2インスタンス作るまでにタイムラグが生じることがNGの理由のようです。
ある意味auto scalingのひっかけ問題でしょうか。


コメント

k kz5835

2024/09/11 23:11

lucie9n様 ご回答、有難うございます。 おかげさまで理解できました。

s sota-aws

2025/10/23 15:21

自分も同じことを疑問に思ったので助かります。 なるほど、確かにタイムラグが発生するから妥当といえば妥当ですね、、、

この返信に対して
コメントを記入できます

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