ローリングアップデート とは？

全台一斉更新だと、その間サービスが止まるよね。ローリングアップデートは例えば10台中2台ずつ更新して、残り8台でリクエストを捌き続ける。全部終わるまで時間はかかるけど、利用者はダウンタイムを感じないんだ。

Blue/Greenは旧環境と新環境を丸ごと用意して一気に切り替える方法。一瞬で切り替わるし戻すのも簡単だけど、環境が2倍必要だからコストがかかる。ローリングアップデートは追加のインフラが最小限で済むのがメリットだよ。

ヘルスチェックで新バージョンのサーバーが正常に動いているかを確認して、異常があれば更新を停止する。Kubernetesなら`maxUnavailable`と`maxSurge`を設定して「同時に止めていいのは何台まで」「追加していいのは何台まで」を制御できるよ。

ここがローリングアップデートで一番厄介なポイントなんだ。更新中はv1とv2のサーバーが同時にリクエストを受ける。もしv2でAPIのレスポンス形式が変わっていたら、フロントエンドがv1のサーバーとv2のサーバーで異なるレスポンスを受け取ることになる。DBのスキーマ変更も同様で、v2が新しいカラムに書き込むのにv1が古いスキーマを前提にしている、という不整合が起きる。だからローリングアップデートを安全にやるには「後方互換性」を保つ設計が必須で、APIの変更は追加のみ・削除は次のリリースで、DBマイグレーションは拡張のみ、という制約を受け入れる必要があるんだよ。