メインコンテンツにスキップ
自媒科技企業向けAI・開発から導入まで
日本語JA
プロジェクト相談

企業AIプロジェクトWiki · 環境・バージョン・リリース

デプロイ

別名Deployment · ソフトウェア配備 · Application Deployment · 本番配備

定義

デプロイとは、識別可能なSoftware/System Versionを、管理された手順で指定対象環境へ導入、設定、更新し、依存、DB、権限、起動、Health、記録を確認して期待する実行状態を作る過程です。完全なデプロイは入力Artifact、Target、実行手順、変更結果、検証証拠、失敗時の停止・復旧を説明でき、「FileをUploadした」だけでは完了しません。

デプロイが変えるもの

BuildはArtifactを作り、デプロイはArtifactと対象環境を結び付けます。同じImageでも設定、ID、DB、Networkが違えば実行結果は変わるため、Softwareだけでなく関連する環境状態も変更対象です。

Command成功や画面表示だけでは完了しません。新InstanceのReady、依存接続、DB版、主要業務Smoke、Log・Metric、環境記録を確認します。

デプロイと利用者公開は分けられます。Zero TrafficやFeature Flagの後、Release判断で公開すれば、技術導入と業務公開を一つの高Risk Eventにせずに済みます。

開始前に確定する入力・条件

  1. どの不変Artifactか

    製品・Component版、Build、保管先、Digestを指定し、Branch、Working Directory、可動`latest`を正式入力にしません。

    入力:Release Manifest、署名、Digest。

  2. どのTargetか

    環境、Account、Region、Cluster、Namespace、Host、SlotとTarget IDを確認し、似た名称の手選択に依存しません。

    入力:Target ID、環境一覧、Pipeline Binding。

  3. 同時に何を変えるか

    設定、Secret参照、証明書、DB Migration、Cache、Queue、Schedule、Flag、外部Endpointを列挙します。

    入力:Change Set、変更前後状態。

  4. どのEntry Gateか

    前段Test、Artifact Scan、承認、時間帯、Backup/Restore Point、Capacity、依存可用性を確認します。

    入力:Gate結果、承認者、Window。

  5. 成功をどう判断するか

    Health、主要業務Smoke、Data確認、性能傾向、Error率、Alert、観測時間を事前定義します。

    入力:Check、Threshold、証拠先。

  6. いつ停止・復旧するか

    Migration、Readiness、Error、Data、依存障害の停止点とRollback、Roll-forward、Restore担当を決めます。

    入力:停止条件、復旧計画、連絡先。

管理されたデプロイの流れ

  1. Window・TargetをLock

    権限、Target、現版、並行変更、担当を照合し、複数配備や手修正の衝突を防ぎます。

  2. Artifact取得・検証

    信頼済みRepositoryからDigest指定で取得し、署名、Provenance、依存、Scanを確認してTargetで再Buildしません。

  3. 現状態を保存

    Application、設定、DB、Traffic、Instance、Healthを記録し、Riskに応じBackup、Snapshot、旧Planeを保持します。

  4. 基盤・設定を適用

    IaCと設定管理でResource、ID、Network、Secret参照、Runtime Parameterを適用します。

  5. 互換Data変更

    Schema・Data Migrationを順序実行し、Lock、Batch、Timeoutを制御し、不可逆処理前に停止・復旧条件を再確認します。

  6. 配備・起動

    In-place、Rolling、Blue-green、段階方式で更新し、Warm-up、Startup、Readiness、Livenessを通します。

  7. 技術・業務を検証

    自動検証、主要Smoke、Log、Metric、Trace、Queue、DB、外部連携を観測WindowでBaseline比較します。

  8. 確定・記録・復旧

    完了条件を満たせば状態を確定し、未達なら影響拡大を止め、Traffic復元、Rollback、Roll-forward、Restoreを実行します。

主なデプロイ方式

方式使い方と主な代償
In-place現Instanceを直接更新しResourceは少ない一方、失敗時の停止、旧状態上書き、再配備/復元Riskがあります。
Recreate旧Instance停止後に新規作成し状態は明確ですが、容量低下や中断が生じます。
Rolling一部容量を維持して順次交換します。新旧版の短期共存互換性とBatch観測・停止が重要です。
Blue-green別Planeへ配備・検証後にTraffic切替し、旧Planeへ早く戻せます。追加ResourceとDB、Session、非同期整合が課題です。
Canary/Wave少数Instance、Region、RequestからMetricにより拡大します。Routing、代表Traffic、成功条件、自動停止が必要です。
Shadow実Requestを複製して結果を返さず比較します。Write、通知、課金Callなど実副作用を遮断します。

Data・設定・Trafficを別に扱う理由

App RollbackはData Rollbackではない

旧Codeが新Schemaを読めず、書込み済みDataもあります。後方互換のExpand、Backfill、Switch、Contractを優先し、不可逆処理は別承認します。

設定も配備状態

Endpoint、Role、Flag、Limitが違えば同一Artifactでも別Systemです。設定をVersion化、Review、検証、記録し、Secretは管理参照で注入します。

配備とTrafficを分離

Zero Trafficで作成し、Healthと直接Test後に段階Routingします。Traffic変更にもMetric、停止、復旧記録が必要です。

非同期は新旧共存

Message、長Transaction、Job、Consumerが旧Codeを継続するため、Schemaと冪等性は移行期間を許容します。

Healthは層別

Process Liveness、Traffic Readiness、依存、業務Read/Write、End-to-endは別問題です。一つの`200 OK`で代替しません。

戻した後も検証

旧Instanceへ戻すだけでは復旧証明になりません。DB、Message、Cache、外部Action、Error、Backlogを再確認します。

残すべきデプロイ記録

  1. 配備ID

    固有ID、Pipeline Run、人/Workload ID、承認者、開始終了、Target。

  2. 入力・変更

    製品・Component版、Build、Digest、設定、Migration、基盤、依存先。

  3. 実行履歴

    Step状態、Log、Retry、手動介入、差異、方式。

  4. 検証証拠

    Probe、Smoke、Data Check、Metric、Alert、観測時間、実結果。

  5. Traffic・Feature状態

    新旧Traffic比率、Flag、対象利用者、変更時刻。

  6. 最終環境状態

    稼働Version・Digest、Instance、設定、Schema、既知問題、次担当。

  7. 失敗・復旧

    Trigger、影響、停止、Rollback/Roll-forward、復旧検証、Follow-up Issue。

企業AIで追加する配備管理

ModelだけがArtifactではない

Model、Inference Code、Runtime Image、System Prompt、Filter、Knowledge Index、Tool定義、評価設定を一つのManifestへ関連付けます。

Model配備とEndpoint Trafficを分離

新ModelをZero Trafficで配備し、直接Call、Mirror、少量Trafficで検証後に拡大します。

Knowledgeは独自Lifecycle

Ingestion、権限同期、Embedding、Index、CacheはApp配備なしに変わります。Batch、追加削除、Retry、可視権限、Rollback Pointerを記録します。

Prompt・Guardrailを整合切替

新Promptと旧Tool/Schemaの混在を避け、関連設定をAtomicに配備するか互換順序と中間状態を定義します。

Agent副作用を先に遮断

Zero Traffic、Shadow、TestはRead-only、Sandbox、Allowlist、最小権限で、引数、承認、冪等、Timeout、人への移管を確認します。

可用性以外の品質を観測

拒否、根拠なし回答、検索、Tool失敗、人移管、Hard Stop、Latency、Error、Resource、Costを追跡します。

托管Model変更を再評価

Aliasや挙動が配備なしに変わる場合、具体版を固定/観測し、Provider更新を監視、再評価、復旧へ含めます。

デプロイと混同しやすい概念

関連概念違い
BuildSourceと依存からArtifactを作ります。デプロイは既存ArtifactをTargetへ適用し、そこで正式Artifactを再Buildしません。
Release準備済みVersionをTraffic、Flag、Channelで誰へ提供するか決めます。デプロイは実行状態を作ります。
Go-live業務利用開始Eventで、配備、Data Cutover、利用者公開、連絡、運用引継ぎを含み得ます。
Data MigrationData位置、構造、内容を変え、配備Stepにも独立作業にもなります。整合・復旧を別設計します。
Configuration Management継続的に状態を識別・統制し、デプロイはある時点で承認状態をTargetへ適用・検証します。
Delivery成果物、文書、Access、責任を受領側へ移します。デプロイは一部の場合も、受領後に顧客が行う場合もあります。

出典と適用範囲

ここでいうデプロイは、指定Softwareと設定を対象環境で実行・検証できる状態へ変える技術的変更です。Build、Release、Go-live、Traffic切替、Feature公開、Data Migration、Deliveryそのものではありませんが、一回のデプロイに一部を含む場合があります。開発、テスト、UAT、ステージング、本番のどこでも行われ、本番へデプロイしても直ちに全利用者へ公開する必要はありません。