Amazon SOA-C02: コンピューティングと Auto Scaling — 学習ガイド

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

こちらの一部です： AWS SysOps Administrator Associate SOA-C02 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

インスタンスの配置、キャパシティプランニング、スケーリングメトリクス

配置の決定は、レイテンシーと障害ドメインに影響します。プレイスメントグループは、クラスター (低レイテンシーネットワーク)、スプレッド (重要なインスタンスをラックごとに1つずつ配置)、パーティション (障害から分離されたパーティション) の戦略を提供します。ASGはデフォルトでインスタンスをAZ間で均等に分散します。単一AZのホットスポットを避けるために、AZを意識したキャパシティプランニングが推奨されます。CLIの場合: aws ec2 create-placement-group --strategy cluster|spread|partition。

キャパシティプランニングでは、インスタンスタイプ、購入オプション、メトリクスを考慮します。

インスタンスタイプ: ワークロードに基づいて、CPU/メモリ/ネットワークに最適化されたファミリー (M/C/R/T/D/I) を選択します。代表的な負荷テストで測定します。
購入オプション: 予測可能性のためにはオンデマンド、定常状態でのコスト削減のためにはリザーブドインスタンスまたはSavings Plans、一時的なワークロードでのコスト効率のためにはスポットを使用します。インスタンスタイプと購入オプションを組み合わせるには MixedInstancesPolicy を使用します。
スケーリングメトリクス: デフォルトのASGメトリクスはグループ全体の平均CPU使用率を使用します。ターゲット追跡には、ALB RequestCountPerTarget のようなアプリケーションレベルのメトリクスや、カスタムCloudWatchメトリクス (例: キューの深さ) の使用が推奨されます。一般的なパターンは以下の通りです。
インスタンスあたりのリクエスト数を一定に保ちたい場合は、ALBの request-count-per-target を使用したターゲット追跡を使用します。
定義された復旧ステップを伴う、突発的で大規模なスパイクにはステップスケーリングを使用します。
日次の周期的なワークロードには予測スケーリングを検討します。

インスタンスの復旧、終了時の動作、メンテナンス

ハードウェア問題に対する自動復旧 (EC2の復旧アクションを伴うCloudWatchアラーム) を有効にし、スケジュールされたイベント (describe-instance-status) を処理することで、インスタンスの障害とメンテナンスに備えます。ボリュームのライフサイクルを制御するために instance-initiated-shutdown-behavior とEBSの DeleteOnTermination フラグを設定します。調整には aws ec2 modify-instance-attribute --instance-id i-xxx --block-device-mappings を使用します。

ASGにおける終了時の動作: ASGの終了ポリシーが、どのインスタンスを最初に終了するかを決定します (デフォルト: 最も古い起動設定、またはインスタンスのヘルス状態とAZバランシングのヒューリスティック)。運用上の重要な詳細は以下の通りです。

ローカルの状態はエフェメラルです: インスタンスストアボリュームとインメモリキャッシュは終了時に失われます。インスタンスの置き換えがローカルの状態を保持すると仮定してはいけません。重要なデータはEBS (適切なスナップショット/バックアップと共に)、S3、または外部キャッシュ (ElastiCache) に永続化します。
ライフサイクルフックを使用して、終了前にトラフィックをドレインし、状態をオフロードします。
メンテナンスでインスタンスを安全に置き換えるには、インスタンスの更新またはブルー/グリーンデプロイを使用します。aws autoscaling start-instance-refresh --auto-scaling-group-name my-asg --preferences file://prefs.json。

よくある落とし穴と判断基準

デフォルトのクールダウンとCPUのみのメトリクスに依存する: アプリケーションの動作に合わせたメトリクス (ALB RequestCountPerTarget、キューの深さ) を選択します。オシレーション (スケーリングの繰り返し) を避けるため、起動時間と HealthCheckGracePeriod を考慮してクールダウンを設定します。
グレースフルターミネーションのためにライフサイクルフックを使用しない: フックがないと、処理中のリクエストやローカルキャッシュが失われます。SNS/SQS/Lambdaでフックを実装し、状態をドレインして永続化します。
インスタンスの置き換えがローカルの状態を保持すると仮定する: ローカルのインスタンスストアとインメモリキャッシュはエフェメラルです。ステートレスなインスタンスとして設計するか、状態を耐久性のあるストアに複製します。
スティッキネス (セッション維持機能) の過度な使用: スティッキネスは不均一な負荷分散を助長し、スケーリングや更新を複雑にします。スケールアウトのためには外部のセッションストア (ElastiCache, DynamoDB) の使用が推奨されます。
AZバランシングとプレイスメントグループを無視する: 1つのAZやクラスターグループにインスタンスを配置しすぎると、単一障害点が生じる可能性があります。ASGのマルチAZ分散と適切なプレイスメントグループ戦略を使用します。
ヘルスチェック統合の設定ミス: ASGの health-check-type はELB/ターゲットグループのヘルスチェックと一致させる必要があります。また、HealthCheckGracePeriod はアプリケーションの初期化に十分な長さに設定しないと、正常なインスタンスが終了されてしまいます。

実践的な問題: ユースケースシナリオ

StreamingCoは、日次のトラフィックスパイクが発生する動画サムネイルAPIを運用しており、EC2インスタンス上のローカルディスクキャッシュを使用しています。最近、スケールアップが遅く、終了したインスタンスがキャッシュを失うため、レスポンスタイムが悪化しています。

起動設定を起動テンプレートに移行し、ランタイム依存関係を含む軽量なAMIをベイク (作成) します。イミュータブルなデプロイのために aws ec2 create-launch-template とバージョニングを使用します。
複数のインスタンスタイプと、コストとキャパシティのバランスを取るためのスポット+オンデマンドの割り当てをリストした MixedInstancesPolicy を持つASGを設定します。
ALBをアタッチし、ALBの RequestCountPerTarget メトリクスでターゲット追跡スケーリングを使用します。HealthCheckGracePeriod はアプリケーションのブートストラップ時間に設定します。
ASGの終了処理にライフサイクルフックを実装し、終了前にコネクションをドレインし、必要なキャッシュキーをElastiCacheやS3に永続化するためのLambda/SNSフローを実行します。
セッションとキャッシュの状態をElastiCacheやS3に外部化し、プレイスメントグループやAZ分散を使用してレイテンシーと障害ドメインの要件を満たします。

論理的根拠: 起動テンプレートとイミュータブルなデプロイを使用することで、起動時間のばらつきが減少します。ALBをターゲットにしたターゲット追跡は、スケーリングをCPUではなくリクエスト負荷に連動させます。ライフサイクルフックは終了時のデータ損失を防ぎます。キャッシュを外部化することで、エフェメラルなローカル状態への依存がなくなり、混合インスタンス/購入戦略によるコスト削減と、迅速で安全なスケーリングが可能になります。

← ストレージとデータ管理 · すべてのドメイン · データベースとキャッシング →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →