Instiq
第3章 · ML ワークフローのデプロイとオーケストレーション·v2.1.0·更新 2026/6/14·読了目安 約8分

変更要約: in-scope サービス網羅: デプロイ/実行基盤/IaC(Lambda/ECS/EKS/ECR/API Gateway/Direct Connect/CloudFormation/CDK/CodeArtifact/CodeBuild/CodeDeploy/Service Catalog/SAR/X-Ray)を追加

3.3安全なモデルデプロイ戦略

この節の要点

Blue/Green デプロイ、カナリア/リニアによる段階的トラフィックシフト、シャドー/A-B テスト(マルチバリアントエンドポイント)といった、リスクを抑えたモデルデプロイを理解します。

新しいモデルへの切り替えは段階的に・監視しながら行い、問題があればすぐ戻せるようにします。SageMaker はこれらの戦略を標準サポートします。

3.3.1デプロイ戦略

Blue/Green(新フリートへトラフィックを切替・ロールバック容易・一括切替)、カナリア/リニア(割合で段階的にシフト・メトリクス監視・アラームで自動ロールバック)、シャドー/A-B テスト(影響なしでテスト・マルチバリアントエンドポイント・本番で比較)の3つのモデルデプロイ戦略を示した図。
安全なモデルデプロイ戦略
  • Blue/Green:新旧フリートを用意しトラフィックを切替。問題時は旧へ戻すだけでロールバック容易
  • カナリア/リニア:トラフィックを少量から段階的にシフトし、メトリクスを監視。アラームで自動ロールバック。
  • シャドー/A-B テスト:本番に影響を与えず比較(シャドー)、またはマルチバリアントエンドポイントで複数モデルを同時比較(A-B)。

モデル更新は「段階的に・監視しながら・すぐ戻せる」が原則です。SageMaker のエンドポイント更新は デプロイガードレール として標準サポートされ、Blue/Green(新旧フリートを用意し一括または段階で切替、問題時は旧へ戻すだけ)、カナリア(最初に少量トラフィックを新へ→健全なら拡大)、リニア(一定割合ずつ等間隔で増やす)を選べます。いずれも CloudWatch アラームベイクタイム(監視待機)で自動ロールバックを設定できます。本番に影響を与えず新モデルの挙動を見るのが シャドーテスト(本番トラフィックの複製を新モデルへ流すが応答は使わない)、実トラフィックで複数モデルを同時比較するのが 本番バリアント(マルチバリアント) の A-B テストです。デプロイ後は Model Monitor でデータ/モデル品質・バイアス・特徴量寄与のドリフトを監視し、劣化を検知したら再学習やロールバックへつなげます。判断軸は「段階+自動ロールバック=カナリア/リニア」「一括+容易な切り戻し=Blue/Green」「無影響検証=シャドー」「実トラフィック比較=A-B」。

要件戦略
段階的に切替+自動ロールバックカナリア / リニア
一括切替+容易な切り戻しBlue/Green
本番影響なしで検証シャドーテスト
実トラフィックで複数モデル比較本番バリアント(A-B)

シナリオ:新モデルを安全に本番投入したい。 まずシャドーテストで本番トラフィックの複製を流し、応答品質と遅延を無影響で確認。問題なければカナリアで 5%→25%→100% と段階シフトし、CloudWatch アラーム(エラー率/レイテンシ)とベイクタイム自動ロールバックを保険に。旧モデルとの優劣判断が要れば本番バリアント(A-B)で同時比較します。

補足

Q. 段階的+自動ロールバック? カナリア/リニア。Q. 一括+容易な切り戻し? Blue/Green。Q. 本番無影響で検証? シャドーテスト。Q. 実トラフィックで比較? 本番バリアント(A-B)。Q. デプロイ後の劣化検知? Model Monitor。

注意

混同に注意:
シャドーテストは応答をユーザーに返さない(A-B は実際に一部ユーザーへ提供)——目的が違う。
②自動ロールバックには CloudWatch アラーム+ベイクタイムの設定が必要。
③カナリア/リニアでも監視メトリクスが不適切だと不良を見逃す。
④Blue/Green は新フリート分のコストが一時的にかかる。

試験ポイント

「段階的に切替・問題時に自動ロールバック=カナリア/リニア」「即時切替・容易なロールバック=Blue/Green」「本番影響なしで新モデル検証=シャドーテスト」「複数モデルを実トラフィックで比較=マルチバリアント(A-B)」 は MLA で頻出です。

3.3.2デプロイ・実行基盤・IaC の in-scope サービス

推論の実行基盤として、サーバーレスは AWS Lambda、コンテナは Amazon Elastic Container Service(ECS・Fargate で最小運用)または Amazon Elastic Kubernetes Service(EKS・Kubernetes 標準)、イメージは Amazon Elastic Container Registry(ECR)に保管します。外部公開は Amazon API Gateway(認証/スロットリング付き HTTP API)、オンプレ接続は AWS Direct Connect。 インフラとリリースはコード化します。AWS CloudFormation(宣言的テンプレート)と AWS Cloud Development Kit(CDK・プログラム言語)で IaC、依存パッケージは AWS CodeArtifact、ビルドは AWS CodeBuild、制御デプロイは AWS CodeDeploy。承認済み環境のセルフサービス配布は AWS Service Catalog、再利用可能なサーバーレスアプリは AWS Serverless Application Repository、分散トレースは AWS X-Ray を使います。

3.3.3この節のまとめ

  • Blue/Green・カナリア/リニア・シャドー/A-B でリスクを抑える
  • メトリクス監視+アラームで自動ロールバック
  • 実行=Lambda/ECS/EKS/ECR、IaC=CloudFormation/CDK、CI/CD=CodeArtifact/Build/Deploy

進捗の記録にはログインが必要です。

理解度チェック

(軽い確認用)

Q1. 新モデルへトラフィックを少しずつ移し、メトリクス悪化時に自動で元へ戻したい。最も適すデプロイ戦略はどれですか?

Q2. 本番トラフィックに影響を与えずに新モデルの挙動を検証したい。最も適す方法はどれですか?

Q3. 実トラフィックで2つのモデルの性能を同時に比較したい。SageMaker で何を使いますか?

理解度を確認第3章「ML ワークフローのデプロイとオーケストレーション」の問題を解く