Tech Learning Daily

デプロイ方式とは「新旧バージョンの共存のさせ方」の設計である

デプロイとは古いバージョンを新しいバージョンに置き換える作業だが、置き換えの瞬間には必ず新旧が同時に存在する時間がある。Kubernetes の Deployment が標準で使う RollingUpdate はこの時間を「土台は 1 つのまま、中身を少しずつ入れ替える」方式で処理する。maxSurge（一時的に増やせる上限）と maxUnavailable（同時に減らせる上限）の 2 つのパラメータが、この入れ替えの速さとリスクの両方を決める。

ここで見落とされがちなのは、「ロールバック」という操作がこの入れ替えの仕組みそのものに縛られるという点だ。ロールバックは特別な巻き戻し機能ではなく、同じ入れ替えメカニズムを逆方向に走らせているにすぎない。だからこそ、入れ替えの設計が違えばロールバックの体感速度も方式ごとに全く違う結果になる。

Rolling Update: ロールバックは「もう一度ロールする」こと

kubectl rollout undo を叩くと、Kubernetes は 1 世代前の ReplicaSet を新しい目標として、通常のデプロイと同じ手順で新しい Pod を起動し古い Pod を終了させていく。つまり「戻す」と言っても瞬時に切り替わるわけではなく、maxSurge / maxUnavailable の制約に従って 1 台ずつ入れ替わる、通常のロールアウトと同じ所要時間がかかる。

途中で不具合が起きているとロールバック中にも新しい Pod の起動と旧 Pod の終了が交互に発生し、Pod 削除時のエンドポイント除去と SIGTERM 送信のタイミングずれによる一時的な 502 が、ロールバックのたびに再発しうる。「戻せば安全」と思って待っている間も、進行中のロールアウトと同じリスクを踏み続けていることになる。

Blue-Green: 舞台を 2 つ用意し、経路を一括で切り替える

Blue-Green デプロイは、稼働中の環境（Blue）とは別に新バージョンの環境（Green）を丸ごと用意し、ヘルスチェックを通過したらロードバランサーの向き先を Blue から Green へ一括で切り替える。新旧が同時にリクエストを受けることはなく、切り替えは経路の付け替え 1 回で完了する。

ロールバックが速いのは、切り替え後もしばらく旧環境（Blue）を残しておくからだ。たとえば AWS CodeDeploy の BlueInstanceTerminationOption は、切り替え成功後に旧インスタンスを何分後に終了するかを設定できる猶予時間（デフォルト値が存在する）を持つ。この猶予時間の内側なら、ロールバックは経路をもう一度 Blue に向けるだけで済む。猶予時間が過ぎて旧環境が終了された後は、Rolling Update と同じく新しい環境をもう一度作り直すデプロイになる。

Blue-Green（舞台が 2 つ）
LB ─┬─▶[Blue v1] 100%（現行）
    └─▶[Green v2] 0%（待機・検証中）

  切替後
LB ─┬─▶[Blue v1] 0%（猶予時間だけ残存）
    └─▶[Green v2] 100%（現行）

ロールバック＝経路をもう一度 Blue へ

Canary: 少数のトラフィックだけ流し、比率を段階的に上げる

Canary デプロイは Blue-Green と同じく新旧 2 系統を並行稼働させるが、切り替えを一括ではなく比率で行う。Argo Rollouts では setWeight ステップで新バージョンに流すトラフィックの割合を指定し、pause で様子を見ながら段階的に比率を上げていく。トラフィック管理機構（サービスメッシュや Ingress）を使わない基本的な Canary では、この比率をレプリカ数の割合で近似する——10 レプリカで重み 20% を指定すると、新バージョンには約 2 レプリカが割り当てられる形だ。

ロールバックは重みを 0 に戻すだけなので数秒〜数分で終わるが、これを自動化するには「何をもって異常とするか」を先に決めておく必要がある。Argo Rollouts の AnalysisRun はメトリクスがしきい値を超えたことを検知すると、canary のレプリカを 0 にスケールしトラフィックを stable 側へ戻す。逆に言えば、メトリクスもアラートしきい値も無ければ、異常を検知する主体が存在せず「一部のユーザーだけが壊れたバージョンを使い続ける」時間が長引くだけになる。

それでも一瞬で戻せないもの: 状態を持つ変更

Blue-Green も Canary も、新旧のアプリケーションコードは瞬時に切り替えられる。しかし両者が同じデータベースを共有している場合、DB のスキーマ変更まで含めてロールバックが一瞬で終わるとは限らない。新バージョンのデプロイでカラムを削除したり型を変えたりすると、切り戻した旧バージョンのコードがそのスキーマを読めずに壊れる可能性がある。

この問題を避けるための定石が expand/contract パターンだ。まず新しい列や構造を追加するだけで既存の列は残す「expand」、新旧両方のコードが動く期間を経て新コードへの移行を終えたら不要になった旧構造を削除する「contract」という 2 段階に分け、その間は常に新旧どちらのバージョンからもスキーマが読める状態を保つ。アプリのロールバックが速くても、DB の変更が後方互換でなければロールバックできる保証は消える。