Cloud SQL の Blue/Green デプロイについて

このドキュメントでは、ダウンタイムを最小限に抑えながら、メジャー バージョンのアップグレードやハードウェアの変更などのデータベース アップデートを実行できる Cloud SQL のブルー / グリーン デプロイの概要について説明します。

デプロイの目的とユースケース

メジャー バージョンのアップグレードを行うかどうかに関係なく、Blue/Green デプロイを作成できます。

  • インテントを使用して作成（メジャー バージョンのアップグレード）: データベース エンジンを新しいメジャー バージョンにアップグレードします。デプロイの作成中に、Cloud SQL はメジャー バージョン アップグレードの事前チェック API を実行して、アップグレード ワークフローに進む前に互換性を検証します。
  • インテントなしで作成（構成またはハードウェアの変更）: 現在のデータベース バージョンで変更をステージングします。ユースケースには、マシンタイプ（CPU/RAM スケーリング）の変更、データベース フラグのテスト、エンジン バージョンをアップグレードせずにストレージ変更の評価などがあります。

Blue/Green デプロイの仕組み

Cloud SQL の Blue/Green デプロイでは、ライブ トラフィックを切り替える前に一時的なセカンダリ環境で変更をステージングすることで、自動化されたワークフローが提供されます。

Blue/Green デプロイ中、Cloud SQL は既存の本番環境（青）をミラーリングする別のステージング環境（緑）を作成します。このサービスは、青から緑への継続的な論理レプリケーションを維持します。本番環境のトラフィックに影響を与えることなく、グリーン環境でアプリケーションの互換性とパフォーマンスを徹底的にテストできます。準備ができたら、迅速な切り替えをトリガーします。これにより、緑色の環境が本番環境の読み取り / 書き込みステータスに割り当てられ、アプリケーションのダウンタイムが最小限に抑えられます（通常は数秒）。

Blue/Green デプロイのコンポーネント

Blue/Green デプロイは、次のコンポーネントで構成されます。

  • Blue 環境（移行元）: アプリケーション トラフィックをアクティブに処理している既存の本番環境。これには、ソースの読み取り / 書き込みインスタンスと関連する構成が含まれます。
  • 緑の環境（ターゲット）: Cloud SQL によって青の環境のクローンとして作成された一時的な分離されたステージング環境。Green 環境には、リクエストされた変更（新しいデータベース バージョンなど）が組み込まれ、継続的レプリケーションを使用して Blue 環境と同期されます。Cloud SQL は、パターン BLUE_INSTANCE_NAME-green-UNIQUE_ID を使用して、グリーン ステージング インスタンスに自動的に名前を付けます（BLUE_INSTANCE_NAME は最大 48 文字に切り捨てられ、UNIQUE_ID は 8 文字の 16 進数識別子です）。

  • 切り替え: グリーン環境を新しい本番環境の読み取り / 書き込みインスタンスに変換する、ユーザーが開始する計画的なプロセス。切り替え中に、Cloud SQL は接続エンドポイントを入れ替えるため、アプリケーションは接続が一時的に切断された後（通常は数秒以内）、緑色の環境に接続します。切り替え中の想定されるダウンタイムは、Cloud SQL のエディションによって異なります。

    • Cloud SQL Enterprise Plus エディション: スイッチオーバーのダウンタイムは通常 1 秒未満です。
    • Cloud SQL Enterprise エディション: ワークロードとレプリケーションの遅延に応じて、通常、切り替えのダウンタイムは 60 秒未満です。

    計画外のフェイルオーバー（停止中に自動的にトリガーされる）とは異なり、切り替えは計画的な変更管理に使用される制御されたオペレーションです。

  • 削除: Blue/Green デプロイ リソースを削除するプロセス。削除の動作は、切り替えが行われたかどうかによって異なります。

    • 切り替え前: デプロイを削除すると、緑色のステージング インスタンスとデプロイ リソースが削除されます。Blue 本番環境インスタンスは影響を受けず、引き続きトラフィックを処理します。
    • 切り替え後: デプロイを削除すると、デプロイ メタデータが削除されます。デフォルトでは、変換されたインスタンス（緑）と青いインスタンスの両方が保持されます。継続的な課金を避けるため、必要に応じて青色のインスタンスを削除できます。

Deployment のライフサイクルと状態

Blue/Green デプロイは、次の 4 つのライフサイクル フェーズを移行します。

  1. 作成とステージング（PROVISIONING）: ブルー / グリーン デプロイをリクエストすると、Cloud SQL はブルーの本番環境を複製する一時的なグリーン ターゲット インスタンスをプロビジョニングします。メジャー バージョンのアップグレードの場合、Cloud SQL はメジャー バージョンのアップグレード事前チェック API も実行して、アップグレード ワークフローに進む前にデータベースの互換性を検証します。Cloud SQL は、リクエストされたアップグレードまたは構成の変更を緑色の環境に適用し、青色から緑色への継続的な論理レプリケーションを開始します。
  2. ステージング検証（SWITCHOVER_READY または SWITCHOVER_NOT_READY）: 初期レプリケーションが完了すると、デプロイは SWITCHOVER_READY に移行します（レプリケーションが中断された場合やエラーが発生した場合は SWITCHOVER_NOT_READY に移行します）。Blue は引き続き本番環境のライブ トラフィックを処理します。緑色の環境に接続して、検証テストを実行し、アプリケーションの互換性を確認し、クエリのパフォーマンスをテストします。
  3. 切り替えの実行（SWITCHOVER_IN_PROGRESS または SWITCHOVER_COMPLETED）: 切り替えをトリガーすると、Cloud SQL は安全性の事前チェックを実行し、接続エンドポイントを入れ替え、緑色のインスタンスをアクティブな本番環境の読み取り / 書き込みインスタンス（SWITCHOVER_COMPLETED）として設定し、青色のインスタンスをスタンドアロンの読み取り / 書き込みインスタンスに移行します。アクティブな読み取りオペレーションと書き込みオペレーションは、緑色のインスタンスにのみ転送され、青色から緑色への論理レプリケーションは終了します。詳細については、Blue/Green デプロイの切り替えを行うをご覧ください。

  4. 削除（DELETING）: テストが完了したとき、または本番環境のオペレーションを確認した後に、デプロイ リソースを削除します。削除の動作は、デプロイの状態によって異なります。

    • 切り替え前（キャンセル）: デプロイを続行しない場合や、検証で問題が発生した場合は、デプロイを削除すると、緑色のステージング インスタンスが削除され、デプロイ メタデータが削除されます。元の青色の本番環境インスタンスは変更されず、中断することなくトラフィックの処理を続行します。
    • スイッチオーバー後（クリーンアップ）: スイッチオーバーが完了し、新しい本番環境インスタンスでのオペレーションを確認したら、デプロイを削除してデプロイ メタデータを削除します。デフォルトでは、新しい本番環境インスタンス（緑）と青いインスタンスの両方が、スタンドアロンの読み取り / 書き込みインスタンスとして保持されます。必要に応じて、--delete-old-source フラグを指定して、ブルー インスタンスを完全に削除し、その課金を停止できます。

    詳細については、Blue/Green デプロイを削除するをご覧ください。

Deployment リソースの状態

Blue/Green デプロイを検査すると、state フィールドに現在のライフサイクル ステータスが表示されます。

  • PROVISIONING: デプロイの作成中です。メジャー バージョンのアップグレードの場合、Cloud SQL は事前チェック API を実行して互換性を検証してから続行します。Cloud SQL は、グリーン環境をプロビジョニングし、リクエストされたアップグレードを適用して、継続的な論理レプリケーションを設定します。
  • SWITCHOVER_READY: 緑色の環境がプロビジョニングされ、青から緑への論理レプリケーションが正常で、デプロイが切り替えの準備ができている。
  • SWITCHOVER_NOT_READY: デプロイはプロビジョニングされていますが、切り替えを開始できません。これは、論理レプリケーションが中断または停止した場合、初期レプリケーションが完了していない場合、またはペア設定されたノードでエラーが発生した場合に発生します。
  • SWITCHOVER_IN_PROGRESS: スイッチオーバー オペレーションがアクティブに実行されています。Cloud SQL は接続エンドポイントを入れ替え、緑色のインスタンスをアクティブな本番環境の読み取り / 書き込みインスタンスに変換します。
  • SWITCHOVER_COMPLETED: スイッチオーバー オペレーションが正常に完了しました。緑色のインスタンスがアクティブな本番環境の読み取り / 書き込みインスタンスになり、青色のインスタンスはスタンドアロンの読み取り / 書き込みインスタンスとして保持されます。
  • DELETING: デプロイが削除されています。切り替え前に削除すると、Cloud SQL は緑色のステージング インスタンスを削除し、デプロイ メタデータを削除します。切り替え後に削除する場合、Cloud SQL はデプロイのメタデータを削除し、--delete-old-source フラグが指定されている場合は、必要に応じてブルー インスタンスを削除します。
  • STATE_UNSPECIFIED: デプロイの状態が不明です。

切り替えの状態と準備状況

切り替えの準備状況は、レプリケーションの健全性とノードのステータスによって決まります。これにより、本番環境データベースをデータ損失や長時間のダウンタイムから保護します。

  • レプリケーションの健全性と遅延: Blue と Green 間の論理レプリケーションが中断、一時停止、または失敗した場合、デプロイ ステータスは SWITCHOVER_NOT_READY に移行します。デプロイの state と説明の出力ではレプリケーション ラグが報告されず、Cloud SQL はデプロイ ステータスの判定時にレプリケーション ラグを事前チェックとして評価しません。ただし、切り替えが開始されたときにレプリケーションの遅延が大きすぎると、切り替えオペレーションは失敗します。スイッチオーバーを確実に成功させるため、スイッチオーバーを開始する前にレプリケーションの遅延が最小限であることを確認してください。レプリケーションの遅延は、Cloud Monitoring でモニタリングできます（Cloud SQL 指標リストの replica_lag などの指標を確認します）。または、グリーン インスタンスで直接モニタリングすることもできます。詳細については、レプリケーション ラグをモニタリングするをご覧ください。
  • ペア設定されたノードのステータス: deploymentMappings で、ペア設定された各ノードは独自のノード状態（PROVISIONED、UPGRADED、UPGRADE_FAILED、SWITCHOVER_IN_PROGRESS、SWITCHOVER_SUCCEEDED、SWITCHOVER_FAILED など）を報告します。ペア設定されたノードでエラー（UPGRADE_FAILED または SWITCHOVER_FAILED）が発生すると、デプロイ全体の状態が SWITCHOVER_NOT_READY に移行します。切り替えが失敗した場合、ルーティングは青色のインスタンスに残り、データ損失は発生しません。
  • 切り替えの準備状況のトラブルシューティング: デプロイで SWITCHOVER_NOT_READY が報告された場合は、errorDetail フィールドを調べて、レプリケーション エラーまたはノードエラーを診断します。切り替えを開始する前に、レプリケーションの遅延が最小限であることを確認し、ブルー インスタンスでアクティブなバッチ DDL オペレーションまたは長時間実行されている書き込みトランザクションが完了していることを確認します。

制限事項

Blue/Green デプロイを使用する前に、次の制限事項を確認してください。

  • サポートされているエンジンとバージョン: MySQL 5.7 以降の Cloud SQL for MySQL インスタンスは、構成ステージング（インテントなしで作成）でサポートされています。メジャー バージョンのアップグレード ターゲット（インテントで作成）は、MySQL 8.0 から 8.4 でサポートされています。MySQL 8.0.18 は Blue/Green デプロイでサポートされていません。
  • サポートされていないデータベース エンジン: Cloud SQL for PostgreSQL と Cloud SQL for SQL Server はサポートされていません。
  • リードレプリカがあるインスタンス: Blue/Green デプロイは、リードレプリカがあるインスタンスをサポートしていません。
  • サポートされていないネットワーク構成: Blue/Green デプロイでは、Private Service Connect アウトバウンド構成はサポートされていません。
  • IAM グループ認証: Blue/Green デプロイは、MySQL の IAM グループ認証と互換性がなく、切り替えの失敗を引き起こす可能性があります。
  • ネットワーク アーキテクチャの要件: Cloud SQL インスタンスは新しいネットワーク アーキテクチャを使用する必要があります。以前のネットワーク アーキテクチャを使用するインスタンスはサポートされていません。
  • バイナリ ロギングの要件: グリーン環境への継続的な論理レプリケーションをサポートするには、MySQL インスタンスで自動バックアップとバイナリ ロギングを有効にする必要があります。
  • メンテナンス バージョンの要件: Blue/Green デプロイを作成する前に、Blue ソース インスタンスで最新のメンテナンス バージョンを実行する必要があります。インスタンスのメンテナンス バージョンを確認または更新するには、セルフサービス メンテナンスを実施するをご覧ください。
  • リソースの可用性: Blue/Green デプロイ ワークフロー中のインスタンス プロビジョニング（緑色のステージング インスタンスの作成や、切り替え後の青色のインスタンスの作成など）は、選択したリージョンまたはゾーンのコンピューティング リソースの制約の影響を受ける可能性があります。
  • 計画外の停止とフェイルオーバー: Blue/Green デプロイの切り替えは、正常な RUNNING 青色のソース インスタンスを必要とする計画されたオペレーションです。緑色のステージング インスタンスは、特殊なリードレプリカとして機能します。標準のリードレプリカと同様に、緑色のインスタンスは、ソース インスタンスの計画外の停止時にフェイルオーバー ターゲットとして使用できません。停止の自動復旧を行うには、高可用性向けにインスタンスを構成するか、障害復旧（DR）レプリカを使用します。

課金と料金

Blue/Green デプロイの使用に追加料金はかかりません。ただし、デプロイ時に完全な並列の Green 環境がプロビジョニングされるため、両方の環境が存在する期間全体にわたって、Blue インスタンスと Green インスタンスの両方に対して標準料金が課金されます。

不要な料金が発生しないように、デプロイと関連するインスタンスを削除します。

  • 切り替え前: デプロイをキャンセルする場合は、デプロイを削除して、緑色のステージング インスタンスを削除し、その課金を停止します。
  • 切り替え後: 新しい本番環境インスタンスを確認したら、Deployment を削除し、--delete-old-source フラグを指定して、ブルー インスタンスを完全に削除します。青色のインスタンスを削除しないと、両方のインスタンスに対して引き続き課金されます。

次のステップ