Amazon RDS ブルー/グリーンデプロイの概要 - Amazon Relational Database Service

Amazon RDS ブルー/グリーンデプロイの概要

Amazon RDS ブルー/グリーンデプロイを使用すると、データベースに加えた変更をテストしてから、本番稼働環境に実装できます。ブルー/グリーンのデプロイは、本稼働環境をコピーするステージング環境を作成します。ブルー/グリーンデプロイでは、ブルー環境が現在の本稼働環境です。グリーン環境はステージング環境であり、現在の本番環境との同期を維持します。

本稼働環境のワークロードに影響を与えずに、グリーン環境の RDS DB インスタンスに変更を加えることができます。例えば、DB エンジンのメジャーまたはマイナーバージョンのアップグレード、基礎となるファイルシステム設定のアップグレード、またはデータベースパラメータの変更をステージング環境で行うことができます。グリーン環境での変化を徹底的にテストできます。準備ができたら、環境をスイッチオーバーして、グリーン環境を新しい本番稼働環境に移行できます。切り替えには通常 1 分もかからず、データが失われることはなく、アプリケーションを変更する必要もありません。

グリーン環境は本稼働環境のトポロジのコピーであるため、グリーン環境には DB インスタンスが使用する機能が含まれます。これらの機能には、リードレプリカ、ストレージ設定、DB スナップショット、自動バックアップ、パフォーマンスインサイト、拡張モニタリングが含まれます。ブルー DB インスタンスがマルチ AZ DB インスタンスデプロイの場合、グリーン DB インスタンスも、マルチ AZ DB インスタンスデプロイです。

注記

現在、ブルー/グリーンデプロイは、RDS for MariaDB、RDS for MySQL、および RDS for PostgreSQL でのみサポートされています。Amazon Aurora の可用性については、「Amazon Aurora ユーザーガイド」の「Amazon Aurora ブルー/グリーンデプロイの概要」を参照してください。

特定の条件下では、RDS for PostgreSQL は物理レプリケーションの代わりに論理レプリケーションを使用して、グリーン環境とブルー環境の同期を維持します。詳細については、「ブルー/グリーンデプロイの PostgreSQL レプリケーション方法」を参照してください。

リージョンとバージョンの可用性

機能の利用可能性とサポートは、各データベースエンジンの特定のバージョン、および AWS リージョン によって異なります。詳細については、「Amazon RDS のブルー/グリーンデプロイでサポートされているリージョンと DB エンジン」を参照してください。

Amazon RDS ブルー/グリーンデプロイを使用する利点

Amazon RDS ブルー/グリーンデプロイを使用すると、セキュリティパッチを最新の状態に保ち、データベースのパフォーマンスを向上させ、短い予測可能なダウンタイムで新しいデータベース機能を導入できます。ブルー/グリーンデプロイでは、エンジンのメジャーバージョンまたはマイナーバージョンのアップグレードなど、データベース更新のリスクとダウンタイムが軽減されます。

ブルー/グリーンデプロイには次の利点があります。

  • 本稼働環境に対応したステージング環境を簡単に作成できます。

  • データベースの変更を本稼働環境からステージング環境に自動的にレプリケートします。

  • 本稼働環境に影響を与えずに、安全なステージング環境でデータベースの変更をテストします。

  • データベースパッチとシステムアップデートを最新の状態に保ちます。

  • 新しいデータベース機能を実装してテストします。

  • アプリケーションを変更することなく、ステージング環境を新しい本稼働環境に切り替えます。

  • 組み込みの切り替えガードレールを使用して安全に切り替えることができます。

  • 切り替え中のデータ損失をなくします。

  • ワークロードにもよりますが、通常は 1 分以内にすばやく切り替えることができます。

ブルー/グリーンデプロイのワークフロー

データベースの更新にブルー/グリーンデプロイを使用する場合は、次の主要なステップを実行します。

  1. 更新が必要な本稼働環境を特定します。

    例えば、この画像の本稼働環境には、マルチ AZ DB インスタンスデプロイ (mydb1) とリードレプリカ (mydb2) があります。

    ブルー/グリーンデプロイでの本稼働 (ブルー) 環境
  2. ブルー/グリーンデプロイを作成します。手順については、Amazon RDS でのブルー/グリーンデプロイの作成 を参照してください。

    以下の図は、ステップ 1 の本稼働環境のブルー/グリーンデプロイの例を示しています。ブルー/グリーンデプロイを作成する際、RDS はプライマリ DB インスタンスのトポロジと設定の全体をコピーしてグリーン環境を作成します。コピーされた DB インスタンス名には -green-random-characters が付加されます。図のステージング環境には、マルチ AZ DB インスタンスデプロイ (mydb1-green-abc123) とリードレプリカ (mydb2-green-abc123) が含まれています。

    ブルー/グリーンデプロイ

    ブルー/グリーンデプロイを作成すると、DB エンジンのバージョンをアップグレードして、グリーン環境の DB インスタンスに別の DB パラメータグループを指定できます。RDS は、ブルー環境のプライマリ DB インスタンスからグリーン環境のプライマリ DB インスタンスへのレプリケーションも設定します。

    ブルー/グリーンデプロイを作成すると、グリーン環境の DB インスタンスはデフォルトで読み取り専用になります。

  3. 必要に応じて、ステージング環境をさらに変更します。例えば、グリーン環境の 1 つ以上の DB インスタンスが使用する DB インスタンスクラスを変更できます。

    DB インスタンスの変更については、「Amazon RDS DB インスタンスを変更する」を参照してください。

  4. ステージング環境をテストします。

    テスト中は、グリーン環境のデータベースを読み取り専用に保つことをお勧めします。グリーン環境ではレプリケーションの競合が発生する可能性があるため、書き込み操作を有効にする場合は注意してください。また、スイッチオーバー後に本稼働データベースに意図しないデータが発生する可能性もあります。RDS for MySQL の書き込み操作を有効にするには、read_only パラメータを 0 に設定し、DB インスタンスを再起動します。論理レプリケーションを使用する RDS for PostgreSQL デプロイの場合、セッションレベルで default_transaction_read_only パラメータを off に設定します。物理レプリケーションを使用するデプロイの場合、グリーン環境で書き込みオペレーションを有効にすることはできません。

  5. 準備ができたら、スイッチオーバーして、ステージング環境を新しい本番稼働環境に移行します。手順については、Amazon RDS でのブルー/グリーンデプロイの切り替え を参照してください。

    切り替えによりダウンタイムが発生します。ダウンタイムは通常 1 分未満ですが、ワークロードによってはさらに長くなることもあります。

    次の図は、切り替え後の DB インスタンスを示しています。

    ブルー/グリーンデプロイの切り替え後の DB インスタンス

    切り替え後、グリーン環境にあった DB インスタンスが新しい本稼働 DB インスタンスになります。現在の本番稼働環境内の名前とエンドポイントは、スイッチオーバー後の新しい本番稼働環境に割り当てられるため、アプリケーションを変更する必要はありません。その結果、本稼働トラフィックが新しい本稼働環境に流れるようになります。以前のブルー環境の DB インスタンスは、現在の名前に -oldn を付加することで名前が変更されます (n は数字です)。例えば、ブルー環境の DB インスタンスの名前が mydb1 であるとします。スイッチオーバー後、DB インスタンス名は mydb1-old1 になります。

    図の例では、切り替え中に次の変更が行われます。

    • mydb1-green-abc123 という名前のグリーン環境のマルチ AZ DB インスタンスデプロイが、mydb1 という名前の本稼働マルチ AZ DB インスタンスデプロイになります。

    • mydb2-green-abc123 という名前が付けられたグリーン環境のリードレプリカが本稼働リードレプリカ mydb2 になります。

    • mydb1 という名前のブルー環境のマルチ AZ DB インスタンスデプロイは、mydb1-old1 になります。

    • mydb2 という名前のブルー環境リードレプリカは mydb2-old1 になります。

  6. 不要になったブルー/グリーンデプロイは削除できます。手順については、Amazon RDS でのブルー/グリーンデプロイの削除 を参照してください。

    切り替え後も以前の本稼働環境は削除されないため、必要に応じてリグレッションテストに使用できます。