rolling deployment とは?

rolling deployment は、サービスのインスタンスを少しずつ新しいバージョンへ置き換えることで更新し、ロールアウト全体を通じてサービスを利用可能に保ちます。

rolling deployment は最も一般的なゼロダウンタイム戦略の1つであり、多くのオーケストレーションプラットフォームにおけるデフォルトです。すべてを一度に入れ替えるのではなく、インスタンスを小さなバッチで更新し、各ステップで十分な健全なキャパシティがトラフィックを処理し続けるようにします。

どのように動作するか

rolling deployment は波状に進行します。古いインスタンスの小さなバッチを停止し、同じ数だけ新しいバージョンを実行するインスタンスを立ち上げ、それらがヘルスチェックを通過するのを待ち、次のバッチへ移ります。ロールアウトはフリート全体を掃くように進み、すべてのインスタンスが新しいバージョンを実行するまで続きます。

なぜダウンタイムを避けられるのか

どの瞬間もインスタンスの一部だけが置き換えられているため、残りはトラフィックを処理し続けます。残った健全なインスタンスが負荷を処理できる限り、ユーザーは中断を経験しません - サービスが稼働し続ける裏側で更新が進みます。

ロールアウトの調整

ペースを制御するツマミは2つあります。一度にいくつのインスタンスを置き換えるか、そして一時的にいくつ追加を許容するかです。バッチが大きいほどデプロイは速くなりますが安全マージンは減り、バッチが小さいほど安全ですが遅くなります。バッチ間のヘルスチェックにより、壊れたバージョンが拡散する前にロールアウトを止められます。

rolling 対 blue-green

rolling deployment では、移行中に古いバージョンと新しいバージョンがフリート全体で同時に動作します。一方 blue-green は2つの完全な環境を保持し、一度にすべてを切り替えます。rolling は予備キャパシティの消費が少なく段階的ですが、バージョンの混在が厄介になり得ます。blue-green はリソースが倍になる代わりに、クリーンなカットオーバーを提供します。

バージョンが混在する瞬間

rolling deployment の間、両方のバージョンが同時にトラフィックを処理するため、それらは互換性を保つ必要があります - 特に共有データベースやAPIの周辺で。これが主な微妙さです。後方互換性のない変更は、フリートが半分だけ更新された状態で壊れる可能性があるため、スキーマとAPIの進化は慎重に扱う必要があります。

重要なポイント

rolling deployment はインスタンスを小さなバッチで置き換え、サービスを稼働させ続けます。
バッチ間のヘルスチェックが、壊れたバージョンの拡散を止めます。
ロールアウト中は古いバージョンと新しいバージョンが共存するため、変更は後方互換性を保つ必要があります。