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 でのみサポートされています。Amazon Aurora の可用性については、「Amazon Aurora ユーザーガイド」の「データベースの更新のために Amazon RDS ブルー/グリーンデプロイを使用する」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    ブルー/グリーンデプロイでの本稼働 (ブルー) 環境

  2. ブルー/グリーンデプロイを作成します。手順については、「ブルー/グリーンデプロイの作成」を参照してください。

    以下の図は、ステップ 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. ステージング環境をテストします。

    テスト中は、グリーン環境のデータベースを読み取り専用に保つことをお勧めします。グリーン環境ではレプリケーションの競合が発生する可能性があるため、グリーン環境での書き込み操作の有効化には注意することをお勧めします。また、切り替え後に本稼働データベースに意図しないデータが発生する可能性もあります。

  5. 準備ができたら切り替えて、ステージング環境を昇格させ、新しい本稼働データベース環境にします。手順については、「ブルー/グリーンデプロイの切り替え」を参照してください。

    切り替えによりダウンタイムが発生します。ダウンタイムは通常 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. 不要になったブルー/グリーンデプロイは削除できます。手順については、「ブルー/グリーンデプロイの削除」を参照してください。

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

ブルー/グリーンデプロイオペレーションへのアクセスの承認

ブルー/グリーンデプロイに関連する操作を実行するには、ユーザーは必要なアクセス許可があることが求められます。指定されたリソースに対して特定の API 操作を実行するために必要なアクセス許可をユーザーとロールに付与する IAM ポリシーを作成できます。その後、これらのポリシーを、それらのアクセス許可を必要とする IAM アクセス許可セットまたはロールにアタッチできます。詳細については、「Amazon RDS での Identity and Access Management」を参照してください。

ブルー/グリーンデプロイを作成するユーザーには、次の RDS オペレーションを実行するアクセス許可が必要です。

  • rds:AddTagsToResource

  • rds:CreateDBInstanceReadReplica

ブルー/グリーンデプロイを切り替えるユーザーには、次の RDS オペレーションを実行するアクセス許可が必要です。

  • rds:ModifyDBInstance

  • rds:PromoteDBInstance

ブルー/グリーンデプロイを削除するユーザーには、次の RDS オペレーション () を実行するアクセス許可が必要です。

  • rds:DeleteDBInstance

ブルー/グリーンデプロイの考慮事項

Amazon RDS は、ブルー/グリーンデプロイのリソースを各リソースの DbiResourceId で追跡します。このリソース ID は、リソースの AWS リージョン 固有のイミュータブルな識別子です。

リソース ID は、DB インスタンス ID とは異なります。

ブルー/グリーンデプロイを作成する

ブルー/グリーンデプロイを切り替えると、リソースの名前 (インスタンス ID) は変わりますが、各リソースは同じリソース ID を保持します。例えば、DB インスタンス識別子はブルー環境で mydb である可能性があります。切り替え後、同じ DB インスタンスの名前が mydb-old1 になる場合があります。ただし、DB インスタンスのリソース ID は切り替え中に変更されません。そのため、グリーンリソースを新しい本稼働用リソースに昇格しても、そのリソース ID は以前に本稼働にあったブルーリソース ID と一致しません。

ブルー/グリーンデプロイに切り替えたら、本稼働用リソースで使用していた統合機能やサービスのリソース ID を新たにプロモートされた本稼働用リソースのものに更新することを検討してください。具体的には、次のような更新を検討してください。

  • RDS API とリソース ID を使用してフィルタリングを実行する場合は、切り替え後にフィルタリングに使用されるリソース ID を調整します。

  • CloudTrail をリソースの監査に使用する場合は、切り替え後に新しいリソース ID を追跡するように CloudTrail のコンシューマーを調整します。詳細については、「AWS CloudTrail での Amazon RDS API コールのモニタリング」を参照してください。

  • パフォーマンスインサイト API を使用する場合は、切り替え後に API への呼び出しでリソース ID を調整します。詳細については、「Amazon RDS での Performance Insights を使用したDB 負荷のモニタリング」を参照してください。

    切り替え後に同じ名前のデータベースをモニタリングできますが、切り替え前のデータは含まれていません。

  • IAM ポリシーでリソース ID を使用する場合は、必要に応じて新しく昇格したリソースのリソース ID を追加します。詳細については、「Amazon RDS での Identity and Access Management」を参照してください。

  • AWS Backup を使用してブルー/グリーンデプロイのリソースの自動バックアップを管理する場合は、切り替え後に AWS Backup で使用するリソース ID を調整します。詳細については、「自動バックアップの管理に AWS Backup を使用する」を参照してください。

  • ブルー/グリーンデプロイに含まれていた DB インスタンスの手動または自動 DB スナップショットを復元する場合は、スナップショットが取られた時間を調べて、正しい DB スナップショットを復元します。詳細については、「DB スナップショットからの復元」を参照してください。

  • 以前のブルー環境 DB インスタンスの自動バックアップを記述する場合や、ある時点に復元する場合は、操作のリソース ID を使用します。

    DB インスタンスの名前は切り替え中に変更されるため、以前の名前を DescribeDBInstanceAutomatedBackups または RestoreDBInstanceToPointInTime 操作に使用することはできません。

    詳細については、「特定の時点への DB インスタンスの復元」を参照してください。

  • ブルー/グリーンデプロイのグリーン環境の DB インスタンスにリードレプリカを追加する場合、切り替え時にブルー環境のリードレプリカが新しいリードレプリカに置き換えられることはありません。ただし、新しいリードレプリカは、切り替え後も新しい本稼働環境に保持されます。

  • ブルー/グリーンデプロイのグリーン環境の DB インスタンスを削除すると、ブルー/グリーンデプロイで代わりになる新しい DB インスタンスを作成することはできません。

    削除した DB インスタンスと同じ名前と Amazon リソースネーム (ARN) で新しい DB インスタンスを作成した場合、DbiResourceId が異なるため、グリーン環境には含まれません。

    グリーン環境で DB インスタンスを削除すると、次のような動作になります。

    • ブルー環境に同じ名前の DB インスタンスが存在する場合、グリーン環境の DB インスタンスに切り替わりません。この DB インスタンスの名前は、DB インスタンス名に -oldn を付加することによって変更されません。

    • ブルー環境の DB インスタンスを参照するアプリケーションは、切り替え後も同じ DB インスタンスを引き続き使用します。

    同じ動作が DB インスタンスとリードレプリカにも当てはまります。

ブルー/グリーンデプロイのベストプラクティス

ブルー/グリーンデプロイのベストプラクティスを以下に示します。

  • MyISAM など、レプリケーション用に最適化されていない非トランザクションストレージエンジンの使用は避けてください。

  • リードレプリカをバイナリログレプリケーション用に最適化します。

    例えば、お使いの DB エンジンバージョンがサポートしている場合は、ブルー/グリーンデプロイをデプロイする前に、本稼働環境で GTID レプリケーション、並列レプリケーション、およびクラッシュセーフレプリケーションを使用することを検討してください。これらのオプションにより、ブルー/グリーンデプロイを切り替える前にデータの一貫性と耐久性が向上します。リードレプリカの GTID レプリケーションの詳細については、「Amazon RDS for MySQL の GTID ベースレプリケーションを使用する」を参照してください。

  • 切り替える前に、DB インスタンスをグリーン環境で十分にテストしてください。

  • グリーン環境のデータベースは読み取り専用のまま維持してください。グリーン環境ではレプリケーションの競合が発生する可能性があるため、グリーン環境での書き込み操作の有効化には注意することをお勧めします。また、切り替え後に本稼働データベースに意図しないデータが発生する可能性もあります。

  • 切り替えに最適なタイミングを特定します。

    切り替え中は、両方の環境でデータベースからの書き込みが遮断されます。本稼働環境でトラフィックが最も少ない時間を特定します。アクティブな DDL など、トランザクションの実行時間が長い場合、切り替え時間が長くなり、本稼働環境のワークロードのダウンタイムが長くなる可能性があります。

  • ブルー/グリーンデプロイを使用してスキーマの変更を実装する場合は、レプリケーション互換の変更のみを行ってください。

    例えば、ブルーデプロイからグリーンデプロイへのレプリケーションを中断することなく、テーブルの最後に新しい列を追加する、インデックスを作成する、またはインデックスを削除することができます。ただし、列名の変更やテーブル名の変更などのスキーマの変更は、グリーンデプロイへのバイナリログのレプリケーションを中断させます。

    レプリケーションと互換性のある変更の詳細については、MySQL ドキュメントの「ソースとレプリカのテーブル定義が異なるレプリケーション」を参照してください。

  • ブルー/グリーンデプロイを作成した後、必要に応じて遅延読み込みを処理します。切り替える前に、データの読み込みが完了していることを確認してください。詳細については、「ブルー/グリーンデプロイを作成する際の遅延読み込みの処理」を参照してください。

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

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

ブルー/グリーンデプロイの制限事項

ブルー/グリーンデプロイには、次の制約事項が適用されます。

  • MySQL バージョン 8.0.11 から 8.0.13 には、RDS がブルー/グリーンデプロイをサポートできないというコミュニティバグがあります。

  • ブルー/グリーンデプロイは、以下の機能ではサポートされていません。

    • Amazon RDS Proxy

    • カスケードリードレプリカ

    • クロスリージョンリードレプリカ

    • AWS CloudFormation

    • マルチ AZ DB クラスター配置

      マルチ AZ DB インスタンスのデプロイでは、ブルー/グリーンデプロイがサポートされます。マルチ AZ 配置については、「マルチ AZ 配置の設定と管理」を参照してください。

  • ブルー/グリーンデプロイの変更に関する制約事項を次に示します。

    • 暗号化されていない DB インスタンスを暗号化された DB インスタンスに変更することはできません。

    • 暗号化された DB インスタンスを暗号化されていない DB インスタンスに変更することはできません。

    • ブルー環境の DB インスタンスを、対応するグリーン環境の DB インスタンスよりも上位のエンジンバージョンに変更することはできません。

    • ブルー環境とグリーン環境のリソースは同じ AWS アカウント にある必要があります。

    • 切り替え時、ブループライマリ DB インスタンス を外部レプリケーションのターゲットにすることはできません。

    • ソースデータベースがカスタムオプショングループに関連付けられている場合、ブルー/グリーンデプロイを作成するときにメジャーバージョンアップグレードを指定することはできません。

      この場合、メジャーバージョンアップグレードを指定せずにブルー/グリーンデプロイを作成できます。その後、グリーン環境のデータベースをアップグレードできます。詳細については、「DB インスタンスのエンジンバージョンのアップグレード」を参照してください。