dbt本番デプロイのベストプラクティス（失敗時ロールバック含む）

本番デプロイは「成功前提」で設計すると痛い目を見ます。dbtは宣言的かつ再現性の高いツールですが、スキーマ変更や増分処理、下流依存の多いマートでは、計画的なリリース戦略と即時ロールバックの仕組みが不可欠です。

この記事では、dbt Cloud/Coreに共通する安定したプラクティスだけを抜粋し、試験対策（dbt Analytics Engineer）で問われやすい観点と、実運用で役立つ手順の両方をまとめます。

全体像：環境分離、Blue/Green、state活用による安全デプロイ

本番の安定運用には、環境分離（dev/staging/prod）、スキーマのBlue/Green切替、そしてdbtのstate（前回アーティファクト）を使った差分実行が基本です。PR段階でstagingに対して検証し、マイグレーションが安全であることを確認してから、本番のGreen側を更新し、スワップや切替で露出を制御します。

dbtではtarget.nameでスキーマを分け、マートはテーブル、ステージングはビューにするのが典型です。CIではstate:modified+で差分のみを検証し、本番では一括ではなく段階的に切り替えます。

• 環境：dev → staging → prod（Blue/Greenの二重化を推奨）
• アーティファクト：manifest.jsonとrun_results.jsonを保存し差分判定に利用
• モデルの素材化：stagingはview、martsはtable/incrementalで計画的に
• 安全策：後方互換優先（列追加はOK、削除・型変更は分岐やv2化）

パイプライン全体像（Blue/Greenとstate活用）

dbt_project.ymlで環境ごとにスキーマ分離（Blue/Green構成の土台）

name: analytics
config-version: 2
profile: analytics
models:
  +schema: "analytics_{{ target.name }}"
  staging:
    +materialized: view
    +tags: ["staging"]
  marts:
    +materialized: table
    +tags: ["marts"]

# 例: prod_blue / prod_green の2ターゲットをprofiles.ymlで用意し、切替で露出を制御

CI/CD：Slim CIとdeferで安全に差分検証

PRでの検証は、stateファイル（前回のmanifest）に基づくSlim CIが定石です。--select state:modified+で変更波及のみを対象にし、--deferで未変更上流は本番の成果物に委譲します。これによりCI時間を短縮しつつ、変更の実効影響を正確に捉えられます。

マージ後はリリースジョブでGreen環境に適用し、品質ゲート（tests/freshness/契約）を全通過したらエイリアス（ビュー）または名前スワップで切り替えます。

• PR CI: dbt build --select state:modified+ --defer --state path/to/prod_artifacts
• 失敗時は早期中断（--fail-fast）でフィードバックを短縮
• アーティファクト永続化（S3/GCS/Blob/Artifacts）で再現性確保
• マージ後はGreen適用→検証→スワップ→監視

dbt Core + GitHub ActionsのSlim CI例

name: dbt-ci
on:
  pull_request:
    branches: [ main ]
jobs:
  slim-ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - name: Install dbt (Snowflake例)
        run: |
          pip install dbt-core dbt-snowflake
      - name: Restore prod artifacts (previous manifest)
        uses: actions/download-artifact@v4
        with:
          name: prod_artifacts
          path: ./prod_state
      - name: Dependencies
        run: dbt deps
      - name: Slim CI build
        run: |
          dbt build \
            --profiles-dir . \
            --target staging \
            --select state:modified+ \
            --defer \
            --state ./prod_state \
            --fail-fast

スキーマ設計と不可逆変更を避けるための指針

本番での障害は大抵、不可逆なスキーマ変更が原因です。列の削除・型縮小・語義変更は避け、段階的移行（追加→並走→切替→削除）を採用します。dbtではv2モデルを並走させ、ビューやエイリアスで露出を制御します。

増分モデルはon_schema_changeを活用し、互換性を壊さない設定（append_new_columnsなど）を選択します。モデル契約（contractのenforce）は対応アダプタで有効化し、型/列の逸脱を早期に検知します。

• 後方互換の原則：add first, remove later
• v2モデルの並走とエイリアス切替でノーダウンタイム化
• incrementalのon_schema_changeで列追加を許容
• 契約（contract enforce）で型逸脱を検知（対応アダプタのみ）

models/fct_orders_v2.sql（安全なv2移行と契約の例）

{{ config(
    materialized='incremental',
    on_schema_change='append_new_columns',
    tags=['marts','v2'],
    contract={'enforce': true}
) }}

select
  order_id::integer as order_id,
  customer_id,
  order_ts,
  -- 新規列は後方互換に配慮してNULL許容で追加
  cast(null as string) as order_channel
from {{ ref('stg_orders') }}

-- schema.yml 側で型・必須列を明示し、testsでnot_null/unique/relationshipsを付与

失敗時ロールバック：戦略比較と具体手順

ロールバックは「切替の速さ」「データ完全性」「依存影響」のバランスで選びます。Blue/Greenのエイリアス切替、データベースのクローン/タイムトラベル（SnowflakeのTime Travel/Zero-copy Clone、Delta LakeのTime Travel/RESTOREなど）、最後の手段として前回グリーンのコミットへ戻して再ビルド、の順に検討します。

テーブルスワップは極めて短時間で切替可能ですが、対象テーブルを事前に並行ビルドしておく体制が必要です。クローン/タイムトラベルはストレージ効率が良く迅速ですが、エンジン機能に依存します。dbtの再ビルドはエンジン非依存で確実ですが、RTOは長くなります。

• 即時切替が必要: Blue/Green + エイリアス/スワップ
• 広範な破壊を戻す: クローン/タイムトラベル
• 構成を確実に巻き戻す: 前回グリーンSHAでdbt再実行

代表的なロールバック手順（例）

# 1) Blue/Green: Snowflakeでテーブル名スワップ（適用は要審査・権限）
-- 事前に BLUE 側で並行ビルド済みとする
ALTER TABLE analytics_prod.orders SWAP WITH analytics_green.orders;

# 2) Delta Lake（Databricks等）: 時点復元（環境により構文・可否が異なる）
-- 例: RESTORE TABLE catalog.schema.orders TO VERSION AS OF 123;

# 3) dbt: 前回グリーンのコミットへ戻して再ビルド
LAST_GREEN_SHA="<保存しているリリースSHA>"
git checkout "$LAST_GREEN_SHA"
dbt deps
# 影響モデルのみを選択しつつ、本番は参照先を既存に委譲
# （必要に応じて --defer/--state で選別）
dbt build --target prod --fail-fast

品質ゲートと監視：落ちたら出さない、出したら監視する

dbtのgeneric/カスタムテスト、source freshness、モデル契約は、本番前の強力なゲートです。PR段階で落とせるものは全て落とす設計にして、マージ後のGreen適用でも全量テストを実施します。

本番切替後は、監視用のアサーションモデル（行数差分、分布逸脱など）を定期実行し、ジョブアラートで検知します。dbt Cloudのジョブ通知や、各エンジンの監査ログと併用すると実務での発見が速くなります。

• テスト優先度: スキーマ契約 > キー整合 > 重要KPI整合
• freshnessで上流遅延を検知し、遅延時はdeployを保留
• 切替後のスモークテスト（小計一致・NULL率・件数範囲）
• Artifacts/run_resultsの長期保存で監査可能に

schema.ymlのテストとfreshnessの例

version: 2
models:
  - name: fct_orders_v2
    tests:
      - not_null:
          column_name: order_id
      - unique:
          column_name: order_id
      - relationships:
          to: ref('dim_customers')
          field: customer_id
sources:
  - name: app
    freshness:
      warn_after: {count: 24, period: hour}
      error_after: {count: 48, period: hour}
    tables:
      - name: orders_raw

運用Runbook：判断と実行の最短経路を用意する

インシデント時は、迷わず動けるRunbookが鍵です。事前に「どの条件でどの戦略を使うか」を決め、コマンドもコピペで走る形に準備します。RTO/RPO目標を定め、Blue/Greenの切替権限やスキーマ命名規則、アーティファクト保管先を共有しておきます。

試験対策では、環境分離、stateを用いた差分実行、後方互換の原則、Blue/Greenやクローン/タイムトラベルの特徴を選べるかが頻出です。

• まずジョブ停止→影響範囲特定→最短復旧（Blue/Green or クローン）→恒久対策
• スキーマ契約やテスト失敗は自動でデプロイ中断
• リリースごとにartifactとLAST_GREEN_SHAを保存
• 手戻りは必ずpost-mortemと手順更新へ反映

Runbook断片（シェル手順サンプル）

# 影響範囲の特定
FAILED_MODEL="{{ this }}"
# 1) 直ちに本番ジョブを一時停止（ツールに応じて操作）
# 2) Blue/Green切替 or クローン復旧
#    例: Snowflake swap / Delta RESTORE を適用
# 3) 最後のグリーンへ戻す場合
LAST_GREEN_SHA=$(cat last_green.sha)
git checkout "$LAST_GREEN_SHA" && dbt deps && dbt build --target prod --fail-fast
# 4) スモークテスト実行、ジョブ再開、監視強化

問題で確認

よくある質問