デプロイ

検証済み成果物へ環境設定と秘密情報を与え、正常性確認後にトラフィックへ加えるローリング・ブルーグリーン・カナリア、データベース移行、切り戻し、リリース判定を分ける

配備に含める要素

ビルド・配備・リリース

ビルドで生成した同一成果物を試験・検証環境・本番環境へ昇格させます。本番だけ別ビルドにすると、試験していない依存先や設定が混ざります。

配備後に機能フラグを閉じたまま内部利用者だけで確認し、業務タイミングに合わせてリリースできます。配備障害と機能動作障害を分けて戻せます。

Recreate

旧バージョンを止めてから新バージョンを起動する最も単純な方式です。二バージョン同時稼働を避けられますが、起動中はサービスgapが生じます。

短い停止を許せる内部システムや、同時稼働できないsingle-writer処理で使われます。メンテナンス表示と切り戻し時間を準備します。

Rolling更新

複数インスタンスを少しずつ新バージョンへ置き換えます。最低稼働数と同時追加数を設定し、準備完了状態合格後に旧インスタンスをドレイニングします。

更新中は旧・新バージョンが同時に要求を処理します。API、セッション、キャッシュ、メッセージ、データベーススキーマが前後互換である必要があります。

Blue-green

旧環境と新環境を二組用意し、試験後にトラフィックスイッチを新側へ切り替えます。戻すときは旧側へ経路を戻せます。

二環境分の容量とデータ同期が必要です。データベースを共有すると、アプリケーションだけ戻してもスキーマ・データが戻らない点に注意します。

Canary

小さな割合の利用者や要求だけ新バージョンへ流し、エラー・遅延・業務指標を比較しながら割合を増やします。影響範囲を限定できます。

利用者を安定して同じバージョンへ割り当てる必要がある処理、低トラフィックで統計が集まらないサービス、rare障害では判定設計が難しくなります。

準備完了状態・稼働確認・起動時

処理が存在することと、要求を正しく処理できることは別です。準備完了状態はトラフィックを受けられるか、稼働確認は再起動が必要な停止状態か、起動時は長い初期化中かを分けます。

依存先すべてを稼働確認へ含めると、データベース障害時に全インスタンスが再起動を繰り返すことがあります。試験通信の目的と失敗時操作を合わせます。

ドレイニングで安全に旧版を外す

旧インスタンスを対象から外す前に新要求を止め、進行中要求やWebSocket、ジョブを完了させます。grace期間より長い処理はチェックポイントや待ち行列へ移します。

信号受信、準備完了状態false、ドレイニング、終了の順序をアプリケーションとプラットフォームで揃えます。

データベース移行

スキーマ変更はアプリケーションバージョンより長く残ります。新列を追加し両バージョンから扱えるようにしてからbackfillし、後の配備で古い列を削除する段階方式を使います。

移行を各インスタンス起動時に同時実行するとロック競合します。専用ジョブ、リーダー election、バージョン表で一度だけ実行します。

静的サイトの配備

静的サイトでも、ビルド出力のアップロード、キャッシュヘッダー、原子的なスイッチ、CDN削除、sitemap確認、404、切り戻しが必要です。ファイルを一つずつ上書きすると新旧資産参照が混ざります。

バージョンディレクトリーへ全ファイルを置き、項目点を最後に切り替える等、利用者から一まとまりで見える方法を選びます。

監視して完了を判定する

配備コマンドの終了コードだけで成功としません。準備完了状態、エラー率、遅延、飽和度、重要な業務トランザクションを一定時間確認します。

変更annotationを監視時系列へ記録すると、異常と配備の相関を追えます。自動切り戻し条件は一時的なノイズで振動しないよう持続時間と最低サンプルを持たせます。

デプロイは成果物を環境へ置き、正しく起動し、正常性確認後にトラフィックへ加える工程です。公開方式、データ互換性、監視、切り戻しを一続きで設計します。

rolling update、rollout監視とrevisionへのundoの実装例：Kubernetes documentation「Update a Deployment Without Downtime」