章: 第8章: パフォーマンスと本番運用実践
アプリの更新とDB変更、どちらを先にやっていますか？
「コードを更新してからマイグレーションを実行する」「マイグレーション後にコードを反映する」——どちらの順番を選ぶかで、デプロイ中の短時間障害が発生するかどうかが変わります。
ゼロダウンタイムデプロイは「止めない」ための技術ではなく、互換性を保ちながら段階的に変更を積み上げる設計思想です。
問題の本質と解決策
問題: アプリコードとDB変更の順番が誤っていると、新旧コードが同時に走る瞬間に不整合が起き、エラーが発生します。また、マイグレーションとワーカー再起動のタイミングも重要です。
解決策: デプロイ手順を固定化し、互換性のある変更を小さく積み上げます。新コード配置 → マイグレーション → キャッシュ更新 → ワーカー再起動の順番を守ることが基本です。
デプロイ手順あり・なし 比較
| 観点 | 手順なし（その都度判断） | 手順あり（順序固定） |
| デプロイ中のエラーリスク | 手順ミスで頻発 | 互換性設計で最小化 |
| ワーカーの不整合 | 古いコードのまま動き続ける | queue:restart で確実に更新 |
| ロールバック | 手順が曖昧で時間がかかる | 手順書通りに即時実行 |
| 属人化 | 担当者によって手順が変わる | チーム全員が同じ手順 |
チェックポイント: デプロイ後に
php artisan queue:restartを実行していますか？ワーカーは自動では再起動されないため、古いコードのまま動き続けることがあります。
デプロイ手順サンプル
# 例: デプロイ順序
# 1) 新コード配置
# 2) composer install --no-dev
# 3) php artisan migrate --force
# 4) php artisan config:cache && php artisan route:cache
# 5) ワーカー再起動
php artisan queue:restart
まとめ & 次のステップ
- ゼロダウンタイムデプロイは互換性のある変更を小さく積み上げる設計思想です
- デプロイ手順（コード→マイグレーション→キャッシュ→ワーカー再起動）を固定化します
- DBとアプリコードの互換性を常に2バージョン分維持することが原則です
queue:restartはデプロイ後の必須手順として自動化に組み込みましょう- まずはデプロイ手順書を1つ作ることから始めましょう
次回は 本番DBマイグレーション戦略 を学びます。巨大テーブルへの変更をサービス影響なく行うための段階設計を解説します。
