AWS認定資格 WEB問題集＆徹底解説
機械学習エンジニア–アソシエイト
問題文と選択肢
- SageMakerエンドポイントのサービスクォータを上限まで引き上げ、CloudWatchアラームを設定してCPU使用率が90%を超過した際に通知を受け取るようにする。
- SageMakerエンドポイントのオートスケーリング機能を有効にし、ターゲット使用率に基づいてインスタンス数を自動調整する。同時に、AWS Budgetsで予測コストアラートを設定し、予算超過を事前に把握する。
- SageMakerエンドポイントのインスタンスタイプをより高性能なものへ変更し、単一インスタンスあたりの処理能力を向上させる。コストとパフォーマンスの状況はAmazon CloudWatchのメトリクスを定期的に確認し、必要に応じて手動で調整する。
- 推論サービスをAmazon API GatewayとAWS Lambdaの構成へ完全に移行し、Lambdaのプロビジョンドコンカレンシーを使用してコールドスタートを回避する。Lambdaの最大同時実行数を制限してコストを管理する。
A. SageMakerエンドポイントのサービスクォータを上限まで引き上げ、CloudWatchアラームを設定してCPU使用率が90%を超過した際に通知を受け取るようにする。
サービスクォータの引き上げは「インスタンスを増やせる上限を上げる」だけで、実際に増やす動作は何も起きません。ピーク時に台数が自動で増えなければ、レイテンシ悪化とタイムアウトはそのまま残ります。
CloudWatch アラームも通知するだけで、容量調整は人手に委ねられます。急なトラフィック増に人間の対応速度で追随するのは非現実的で、リアルタイム診断という低レイテンシ要件を満たせません。
B. SageMakerエンドポイントのオートスケーリング機能を有効にし、ターゲット使用率に基づいてインスタンス数を自動調整する。同時に、AWS Budgetsで予測コストアラートを設定し、予算超過を事前に把握する。
SageMaker エンドポイントのオートスケーリングは、インスタンスあたりの呼び出し数（InvocationsPerInstance）などのターゲット使用率に基づいてインスタンス数を自動的に増減させます。トラフィック急増時にはスケールアウトしてレイテンシとタイムアウトを解消し、閑散時にはスケールインして無駄なインスタンス費用を削ります。
これが「パフォーマンス要件を満たしつつコストも最適化する」という要求に対する需要追従型の正攻法です。加えて AWS Budgets の予測コストアラートで支出の増加を事前に把握できるため、スタートアップとしてのコスト抑制要件にも応えます。
既存アーキテクチャを変えずに設定だけで導入でき、運用負荷も増えません。これが正解です。
C. SageMakerエンドポイントのインスタンスタイプをより高性能なものへ変更し、単一インスタンスあたりの処理能力を向上させる。コストとパフォーマンスの状況はAmazon CloudWatchのメトリクスを定期的に確認し、必要に応じて手動で調整する。
より高性能なインスタンスへのスケールアップは、ピークをしのげたとしても閑散時にもその高額なインスタンスを稼働させ続けるため、コスト効率が悪化します。
また単一インスタンスの性能には上限があり、利用者が増え続ける状況ではいずれ再び頭打ちになります。CloudWatch を見ながら手動調整するという運用も、時間帯によるトラフィック変動への追随が遅く、運用負荷も高いままです。
D. 推論サービスをAmazon API GatewayとAWS Lambdaの構成へ完全に移行し、Lambdaのプロビジョンドコンカレンシーを使用してコールドスタートを回避する。Lambdaの最大同時実行数を制限してコストを管理する。
API Gateway と Lambda への全面移行は大規模なアーキテクチャ変更であり、現在のエンドポイントの容量問題に対する直接的な解決策ではありません。
さらに Lambda にはデプロイパッケージやメモリの制約があり、大きな ML モデルのホスティングには不向きです。コールドスタート回避のためのプロビジョンドコンカレンシーは常時課金となり、コスト抑制の要件とも噛み合いません。同時実行数の上限設定はコストを守る代わりにスロットリングを招き、タイムアウト解消という目的にも逆行します。
変動するトラフィックには「自動で増減」。クォータ引き上げも大きいインスタンスも、余剰か手動対応が残る。
正解への思考ルート
問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。| 要件 | 判断ポイント |
|---|---|
| 時間帯によってトラフィックが急増する（変動する需要） | 需要変動には台数の自動増減で追随するのが定石。固定容量の強化では過不足が残る →選択肢（B）が正解 |
| 低レイテンシで大量リクエストを処理し、タイムアウトを解消したい | 通知だけのアラームや手動調整ではピークに間に合わない →選択肢（A・C）を消す |
| 運用コストを抑制する必要がある（スタートアップ） | 閑散時にスケールインして課金を止められるか。常時高性能インスタンスは無駄が出る →選択肢（C）を消す |
| 既存の SageMaker エンドポイントの容量問題を解決する | アーキテクチャの全面移行は問題の解決手段として過大。ML モデルのホスティングは SageMaker が本職 →選択肢（D）を消す |
| パフォーマンスとコストの「バランス」を最も効果的に実現 | ターゲット追跡によるオートスケーリング＋AWS Budgets の予測コストアラートで両立できる →選択肢（B）が正解 |
ひっかけポイント
- 選択肢 A の「サービスクォータの引き上げ」は容量問題に効きそうに見えるが、上限を上げるだけで実際の台数は増えない。オートスケーリングの前提条件にすぎない
- 「CloudWatch アラームを設定する」は監視・通知であって自動的な容量調整ではない。アラーム＝解決策と読み違えない
- 選択肢 C のスケールアップ（垂直）は一時しのぎになるが、閑散時のアイドルコストと上限という 2 つの壁が残る。変動需要には水平スケールで応える
- 選択肢 D の「プロビジョンドコンカレンシー」はコールドスタート対策として正しい用語だが、常時課金でコスト抑制の要件に逆行する。用語の正しさと要件適合は別物
出題バリエーション
同じ知識が本番では条件を変えて出題されます。| 問題文がこう変わったら | 正解はこう変わる |
|---|---|
| 「トラフィックが断続的で、数分の待ち時間は許容できる（アイドル時は課金ゼロにしたい）」 | SageMaker サーバーレス推論が正解軸に。オートスケーリングより先にこちらを検討。 |
| 「リアルタイム性は不要で、大量データを一括で推論したい」 | バッチ変換（Batch Transform）が正解軸に。エンドポイントの常時稼働自体が不要。 |
| 「ピークの時間帯があらかじめ分かっている」 | スケジュールされたスケーリングで事前にスケールアウトしておく構成が正解軸に。 |
| 「複数の小さなモデルをコストを抑えて同居させたい」 | マルチモデルエンドポイント／推論コンポーネントによるインスタンス共有が正解軸に。 |
リファレンス
この問題を解くために必要な知識を扱う公式ドキュメントです。| 知識項目 | 公式ドキュメント |
|---|---|
| SageMaker 推論エンドポイントの自動スケーリング | Amazon SageMaker AI モデルの自動スケーリング - Amazon SageMaker AI |
- SageMakerエンドポイントのサービスクォータを上限まで引き上げ、CloudWatchアラームを設定してCPU使用率が90%を超過した際に通知を受け取るようにする。
- SageMakerエンドポイントのオートスケーリング機能を有効にし、ターゲット使用率に基づいてインスタンス数を自動調整する。同時に、AWS Budgetsで予測コストアラートを設定し、予算超過を事前に把握する。
- SageMakerエンドポイントのインスタンスタイプをより高性能なものへ変更し、単一インスタンスあたりの処理能力を向上させる。コストとパフォーマンスの状況はAmazon CloudWatchのメトリクスを定期的に確認し、必要に応じて手動で調整する。
- 推論サービスをAmazon API GatewayとAWS Lambdaの構成へ完全に移行し、Lambdaのプロビジョンドコンカレンシーを使用してコールドスタートを回避する。Lambdaの最大同時実行数を制限してコストを管理する。