WEB問題集
ある企業はリアルタイム画像分類モデル（数百MB）を10ミリ秒以内のレイテンシで提供する必要があります。トラフィックは平日9-18時に集中し、夜間と週末はほぼゼロです。コストとレイテンシ要件を両立する推論方式はどれですか。
正解：A
正解の根拠
10ミリ秒級のリアルタイム要件には、Real-timeエンドポイントが基本選択になります。トラフィック変動はApplication Auto ScalingのTarget Tracking（SageMakerVariantInvocationsPerInstance）で吸収し、最小キャパシティを1に設定することでコールドスタートを回避しつつ夜間コストを最小化できます。
推論オプション比較
| 方式 | レイテンシ | コールドスタート | 用途 |
|---|---|---|---|
| Real-time | ミリ秒 | なし（min=1） | 低レイテンシAPI |
| Serverless | 数百msに増加 | あり | 断続的・低頻度 |
| Async | 秒〜分 | あり | 大きなペイロード |
| Batch | 分〜時間 | — | 定期一括処理 |
不正解の理由
- C: Batch Transformは非リアルタイムで、10msSLAを満たせません。
- D: Serverlessはコールドスタートで数百ms〜数秒の遅延が発生し、10ms要件に不適合です。
- B: Asyncは大型ペイロード向けで、即時応答用途ではありません。
あるSaaS企業は数百のテナントごとに個別のXGBoostモデルを学習し、推論を提供しています。各テナントのトラフィックは小さく断続的です。コストを最小化しつつ低レイテンシを保つ推論アーキテクチャはどれですか。
正解：A
正解の根拠
SageMaker Multi-Model Endpoint（MME）は、共通コンテナ・共通インスタンス上で複数モデルをS3から動的ロード・アンロードし、単一エンドポイントで提供する機能です。テナントが多く・各々のトラフィックが小さい場合に、エンドポイント数とアイドルコストを劇的に削減できます。
マルチテナント推論オプション比較
| 方式 | 適合シナリオ | コスト |
|---|---|---|
| 個別Real-time | テナント数少・高負荷 | 高 |
| MME | 多数モデル・断続トラフィック | 低 |
| Multi-Container | 異なるFW・少数モデル | 中 |
| Inference Components | 大規模モデル混在 | 中 |
呼び出し例
response = client.invoke_endpoint(
EndpointName='mme-tenant',
TargetModel='tenant-123/model.tar.gz',
Body=payload)不正解の理由
- C: テナントごとエンドポイントはアイドル時もインスタンス課金が発生し非経済的です。
- B: Lambdaは大型モデルや起動レイテンシで制約があり、数百モデル運用には不向きです。
- D: Batch Transformはリアルタイム推論ではありません。
あるグローバル企業は、機密データを扱うSageMakerリアルタイム推論をクライアントVPCからインターネット経由で呼び出さずに利用する必要があります。最も適切な構成はどれですか。
正解：B
正解の根拠
com.amazonaws.<region>.sagemaker.runtime のInterface Endpoint（AWS PrivateLink）を作成すると、VPC内のENIにプライベートIPが割り当てられ、トラフィックがインターネットを経由せずにSageMaker推論APIへ到達します。これにより機密データの暴露リスクと外向き通信を排除できます。
接続方式比較
| 方式 | インターネット経由 | 適合性 |
|---|---|---|
| VPC Endpoint (PrivateLink) | なし | 最適 |
| NAT Gateway | あり | 不適 |
| Direct Connect (Public VIF) | AWSパブリック網経由 | 機密用途では非推奨 |
| Internet Gateway | あり | 不適 |
不正解の理由
- C: NAT Gatewayはアウトバウンドのインターネット通信を許可してしまいます。
- D: Public VIFはAWSパブリックエンドポイントに到達しますが内部VPC接続ではなく、PrivateLinkのほうが要件適合します。
- A: Bedrock Agentは推論オーケストレーション機能で、ネットワーク隔離手段ではありません。
あるチームは新モデルを本番投入する際に、まず10%のトラフィックでKPIを観察し、問題なければ100%へ段階的に切り替えたいと考えています。SageMakerでの実現方法はどれですか。
正解：D
正解の根拠
SageMakerエンドポイントは複数のProduction Variantを保持でき、InitialVariantWeightで送信割合を調整できます。新Variantを10%、旧を90%で開始し、UpdateEndpointWeightsAndCapacitiesで段階的に重みを変更することでカナリア/ブルーグリーン的な切替が可能です。
段階デプロイ手段比較
| 手段 | 特徴 |
|---|---|
| Production Variants | 同一エンドポイント内で重み制御 |
| Deployment Guardrails (Linear/Canary) | UpdateEndpoint時に自動段階移行＋自動ロールバック |
| Route 53加重 | DNSキャッシュで切替に時間遅延 |
API例
client.update_endpoint_weights_and_capacities(
EndpointName='ep',
DesiredWeightsAndCapacities=[{'VariantName':'new','DesiredWeight':100}])不正解の理由
- A: Route 53のTTLによる切替遅延と、複数エンドポイント運用コストが発生します。
- C: 比較ロジックは段階展開そのものではなくシャドウ評価向けです。
- B: Pipelinesは学習ワークフロー用であり、推論トラフィック分割の主機能ではありません。
あるIoTメーカーは、工場の現場ゲートウェイ上で軽量化した画像検査モデルを動かす必要があります。SageMakerで学習したモデルをエッジ向けに最適化・配布する組み合わせはどれですか。
正解：C
正解の根拠
SageMaker Neoは学習済みモデルをターゲットHW（Jetson/Intel/ARM等）向けにコンパイルし、最大2倍程度の推論高速化と最適化バイナリ生成が可能です。AWS IoT Greengrassの推論コンポーネントとしてデプロイすれば、エッジゲートウェイ上で実行・更新管理ができます。
エッジ展開ステップ
| ステップ | サービス |
|---|---|
| 学習 | SageMaker |
| コンパイル | SageMaker Neo |
| 配布 | IoT Greengrass |
| 監視 | IoT Device Defender / CloudWatch |
不正解の理由
- D: VPN経由のクラウド推論はネットワーク断時に停止し、現場で要求される低レイテンシ要件を継続的に満たせません。
- B: Lambda@EdgeはCloudFrontのエッジロケーション内で動く仕組みで、工場ゲートウェイ機器の推論実行基盤としては利用できません。
- A: Transfer Accelerationは S3 への高速アップロード機能で、モデル最適化や統合的なエッジ更新管理は提供しません。