【MLA-C01】CI/CDパイプライン｜CodePipeline・SageMaker Pipelinesとblue/green・canary・linearを図解

モデルを安全に・繰り返しデプロイするには、自動化されたパイプライン（CI/CD）が欠かせません。コードのコミットを契機に、ビルド・テスト・デプロイ・再学習までを自動で流す仕組みです。MLA-C01では、AWSのCodeサービスとSageMaker Pipelines、そしてblue/green・canary・linearといったデプロイ戦略の使い分けが問われます。前の記事は M3-2、全体像はシラバスマップをどうぞ。

ビルド・テスト・デプロイを自動化するCI/CDパイプラインのイメージ図 — 図：CI/CDは「人手の作業を自動化のレールに乗せる」こと。コミットから本番反映までを安全・反復可能にします。

CI/CDパイプラインを支えるサービス
デプロイ戦略：blue/green・canary・linear
自動テストと再学習の仕組み
確認クイズ
よくある質問（FAQ）
まとめ

CI/CDパイプラインを支えるサービス

AWSのCodeサービスは役割で分かれています。全体を束ねるのがCodePipelineです。

サービス	役割
CodePipeline	全体のオーケストレーション（各ステージをつなぐ）
CodeBuild	ソースのビルドとテストを実行
CodeDeploy	成果物のデプロイを実行
SageMaker Pipelines	ML向けのワークフロー（前処理・学習・評価・登録）を自動化

CodePipelineが全体を束ね、CodeBuild・CodeDeploy・SageMaker PipelinesがCI/CDの役割を分担することを示す図 — 図：CodePipelineが全体をオーケストレーションし、CodeBuildがビルド・テスト、CodeDeployがデプロイを担当。MLワークフローはSageMaker Pipelines（前処理→学習→評価→登録）が自動化します。

さらに Amazon EventBridge のルールで、新データの到着などを契機に再学習を自動起動できます。Gitなどのコードリポジトリと連携し、コミットからパイプラインが走ります。

ソース・ビルド・テスト・デプロイをCodePipelineがつなぐCI/CDパイプラインの図 — 図：ソース→ビルド→テスト→デプロイの各ステージをCodePipelineがつなぎ、自動テストに通ったものだけを次へ進めます。

デプロイ戦略：blue/green・canary・linear

新バージョンへの切り替え方には、リスクの抑え方で複数の戦略があります。

blue/green・canary・linearの3つのデプロイ戦略の違いを示す図 — 図：blue/greenは新旧2環境を用意して一気に切替（即ロールバック可）、canaryは少数に先行リリースして段階拡大、linearは一定割合ずつ段階的に移行します。

blue/green：現行（blue）と新（green）の2環境を用意し、一気に切り替える。問題があれば即座に旧環境へロールバックできる
canary：まず少数のトラフィックに新バージョンを出し、問題なければ徐々に拡大。リスクを早期に検知
linear：一定の割合ずつ段階的にトラフィックを移していく

自動テストと再学習の仕組み

自動テスト：パイプラインに単体・結合・エンドツーエンドのテストを組み込み、品質を満たしたものだけデプロイする
再学習の自動化：EventBridgeやスケジュールで再学習を起動し、評価に通ればModel Registry経由で承認・デプロイへつなぐ
ロールバック：問題検知時に前のバージョンへ戻す手順を、戦略に応じて用意しておく

確認クイズ

Q1. あなたは推論サービスを新バージョンへ更新します。切り替えは素早く行い、万一問題が起きた場合は即座に元のバージョンへ戻せるようにして、ダウンタイムを最小化したいと考えています。最も適切なデプロイ戦略はどれですか。

A. 計画やロールバック手段を用意せず、本番を直接上書きで更新する。

B. 新バージョンを一定割合ずつ何日もかけて少しずつ移行する。

C. blue/greenデプロイで新旧2環境を用意し、一気に切り替え、問題時は即座に旧環境へ戻す。

D. 旧環境を削除してから新環境を一から構築する。

Q2. あなたは新しいモデルを本番に出す前に、リスクをできるだけ抑えたいと考えています。まずごく一部の実トラフィックに新バージョンを適用して問題がないかを確認し、異常がなければ段階的に対象を広げたい状況です。最も適切なデプロイ戦略はどれですか。

A. すべてのトラフィックを一度に新バージョンへ切り替える。

B. canaryデプロイで少数のトラフィックにまず適用し、問題なければ徐々に拡大する。

C. テストを行わず、本番でそのまま全面リリースする。

D. 新バージョンをオフラインだけで確認し、本番には一切出さない。

Q3. あなたのチームは、コードのコミットを契機にビルド・テスト・デプロイの一連の流れを自動化し、各ステージをつないで実行したいと考えています。複数のステージを束ねて統制するために最も適切なサービスはどれですか。

A. CodePipelineで各ステージ（ソース・ビルド・テスト・デプロイ）をつなぎ、自動でオーケストレーションする。

B. 各ステージを担当者が手動で順番に実行する。

C. すべてのビルドとデプロイを1つのシェルスクリプトに書き、手元PCで実行する。

D. デプロイは行わず、ビルドの成果物を共有フォルダに置くだけにする。

あなたは、新しい学習データが届くたびに再学習を自動で起動し、評価テストに合格したモデルだけを承認してデプロイする仕組みを作りたいと考えています。最も適切な構成はどれですか。

A. 担当者が気づいたときに手動で再学習を実行し、目視で良ければデプロイする。

B. 評価テストは省略し、再学習したモデルをそのまま本番へ反映する。

C. 年に一度だけまとめて再学習し、それ以外は更新しない。

D. EventBridgeでデータ到着を契機にSageMaker Pipelinesの再学習・評価を起動し、合格したモデルをModel Registry経由で承認・デプロイする。

よくある質問（FAQ）

Q. CodePipelineとCodeBuild、CodeDeployの違いは？

A. CodePipelineが全体の流れを統制し、CodeBuildがビルド・テスト、CodeDeployがデプロイを担います。役割分担で覚えましょう。

Q. blue/greenとcanaryはどう使い分ける？

A. 素早く切り替えて即ロールバックしたいならblue/green、少数で先行検証してリスクを抑えたいならcanaryです。

Q. SageMaker PipelinesとCodePipelineの関係は？

A. SageMaker PipelinesはMLワークフロー（前処理・学習・評価）に特化し、CodePipelineはCI/CD全体を束ねます。組み合わせて使えます。

まとめ

CodePipelineが全体を統制し、CodeBuildがビルド・テスト、CodeDeployがデプロイ。MLワークフローはSageMaker Pipelines
デプロイ戦略はblue/green（即切替・即ロールバック）・canary（少数先行）・linear（段階移行）
自動テストで品質を担保し、EventBridge＋Pipelines＋Model Registryで再学習から承認・デプロイを自動化

🎯 次のステップ

➡ ここまででドメイン3（デプロイと運用自動化）が完了です。次はドメイン4 監視・保守・セキュリティ／M4-1 推論の監視とドリフト検知※準備中
➡ 前の記事：M3-2 インフラのコード化とオートスケール／シラバスマップ

※本記事はAWS公式試験ガイド(MLA-C01)および各サービスの公開ドキュメントに基づき、エンジニアKが作成しています。サービス仕様は更新されることがあるため、最新は必ずAWS公式でご確認ください。本サイトはAmazon Web Services, Inc.の公式サイトではありません。AWSは同社の商標です。