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

ref. インプレースアップグレード

ドキュメント

データベース更新のために Amazon RDS ブルー/グリーンデプロイを使用する

※ 注意

Amazon Aurora のブルー/グリーンデプロイと RDS 全般のブルー/グリーンデプロイのドキュメントがある。 Amazon Aurora　ブルー/グリーンデプロイは上記を参照する
ドキュメントは ブルー/グリーンアップグレード と ブルー/グリーンデプロイ を同じ意味で使用している場合もある

ブルー/グリーンデプロイで Aurora 3 にアップグレード（概要）

本稼働データベース環境（ブルー： Aurora 2 ）から別の同期されたステージング環境（グリーン： Aurora 3 ）を作成する（ブルーからグリーンに論理レプリケーションを作成して同期する）
- ブルーの binlog_format が設定されていないとエラーになる（ドキュメントは ROW とあるが MIXED が無難なよう）
- グリーンはデータベースエンジンとして Aurora 3 を選択。パラメータグループ（クラスター・インスタンス）ともに MySQL 8 系を適用する
ステージング環境（グリーン： Aurora 3 ）を昇格させ、新しい本稼働データベース環境にする（Aurora 3 のグリーンが本稼働データベースに昇格）
- 切り替えによりダウンタイムが発生します。ダウンタイムは通常 1 分未満ですが、ワークロードによってはさらに長くなることもあります。
不要になったブルー/グリーンデプロイは削除する

注意事項

切り替え後、グリーン環境にあった DB インスタンスが新しい本稼働 DB インスタンスになります。現在の本稼働環境の名前とエンドポイントは、新しく昇格した本稼働環境に割り当てられるため、アプリケーションを変更する必要はありません。その結果、本稼働トラフィックが新しい本稼働環境に流れるようになります。
ref. ブルー/グリーンデプロイのワークフロー

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

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

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

rds:AddTagsToResource

rds:CreateDBCluster

rds:CreateDBInstance

rds:CreateDBClusterEndpoint

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

rds:ModifyDBCluster

rds:PromoteReadReplicaDBCluster

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

rds:DeleteDBCluster

rds:DeleteDBInstance

rds:DeleteDBClusterEndpoint

Aurora は、お客様に代わってステージング環境のリソースをプロビジョニングおよび変更します。これらのリソースには、内部で定義された命名規則を使用する DB インスタンスが含まれます。したがって、アタッチされた IAM ポリシーには、my-db-prefix-* のような部分的なリソース名パターンを含めることはできません。ワイルドカード (*) のみがサポートされています。一般的に、これらのリソースへのアクセスを制御するには、ワイルドカードではなく、リソースタグやその他のサポートされている属性を使用することをおすすめします。詳細については、「Amazon RDS のアクション、リソース、および条件キー」を参照してください。 ref. ブルー/グリーンデプロイオペレーションへのアクセスの承認

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

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

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

blue-green-deployment-resource-id-aurora

デプロイで昇格したグリーンのリソース名（クラスター ID ）は変わるがリソース ID は変わらない。　　
つまり「グリーンが本稼働に昇格してもリソース ID はブルーのリソース ID にならない。

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

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

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

ブルー環境のリソースにデータベースアクティビティストリームを使用する場合は、切り替え後に新しいストリームのデータベースイベントをモニタリングするようにアプリケーションを調整します。詳細については、「データベースアクティビティストリームでサポートされているリージョンと Aurora DB エンジン」を参照してください。

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

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

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

DB クラスターに IAM ロールが関連付けられている場合は、スイッチオーバー後にそれらを再度関連付けます。アタッチされたロールはグリーンの環境に自動的にコピーされません。

IAM データベース認証を使用して DB クラスターを認証する場合は、データベースアクセスに使用する IAM ポリシーの Resource 要素の下にブルーとグリーンのデータベースの両方が表示されていることを確認してください。これは、スイッチオーバー後にグリーンのデータベースに接続するために必要です。詳細については、「IAM データベースアクセス用の IAM ポリシーの作成と使用」を参照してください。

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

Amazon Aurora は、基盤となるブルー環境の Aurora ストレージボリュームをクローニングすることでグリーン環境を作成します。グリーンのクラスターボリュームには、グリーン環境に加えられた増分変更のみが保存されます。ブルー環境の DB クラスターを削除すると、グリーン環境の基盤となる Aurora ストレージボリュームのサイズは、フルサイズまで増大します。詳細については、「Amazon Aurora DB クラスターのボリュームのクローン作成」を参照してください。

ブルー/グリーンデプロイのグリーン環境の DB クラスターに DB インスタンスを追加すると、切り替え時にブルー環境の DB インスタンスが新しい DB インスタンスに置き換わることはありません。ただし、新しい DB インスタンスは DB クラスターに残り、新しい本稼働環境の DB インスタンスになります。

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

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

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

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

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

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

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

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

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

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

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

両方の環境のすべての接続に、クラスターエンドポイント、リーダーエンドポイント、またはカスタムエンドポイントを使用します。静的リストまたは除外リストのあるインスタンスエンドポイントやカスタムエンドポイントは使用しないでください。

ブルー/グリーンデプロイメントを切り替えるときは、切り替えのベストプラクティスに従ってください。詳細については、「切り替えのベストプラクティス」を参照してください。

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

ブルー/グリーンデプロイの一般的な制約事項

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

Aurora MySQL バージョン 2.08 と 2.09 は、アップグレードのソースバージョンまたはターゲットバージョンとしてはサポートされません。

ブルー/グリーンデプロイの一部であるクラスターを停止および開始することはできません。

ブルー/グリーンデプロイでは、AWS Secrets Manager を使用したマスターユーザーのパスワード管理はサポートされていません。

要確認

バックトラックが有効になっている Aurora MySQL ソース DB クラスターからブルー/グリーンデプロイを作成すると、グリーン DB クラスターはバックトラックのサポートなしで作成されます。バックトラックは、ブルー/グリーンデプロイに必須のバイナリログ (binlog) レプリケーションでは機能しないためです。詳細については、「Aurora DB クラスターのバックトラック」を参照してください。

ブルー DB クラスターでバックトラックを強制実行しようとすると、ブルー/グリーンデプロイが中断され、スイッチオーバーがブロックされます。

Aurora MySQL の場合、ソース DB クラスターには tmp という名前のデータベースを含めることはできません。この名前のデータベースはグリーン環境にコピーされません。

tmp データベースが無いことを確認

Aurora PostgreSQL では、ブルー DB クラスターで rds.logically_replicate_unlogged_tables パラメータが 1 に設定されていない限り、ログに記録されていないテーブルはグリーン環境にレプリケートされません。ブルー/グリーンデプロイを作成した後は、ログに記録されていないテーブルで発生する可能性のあるレプリケーションエラーを回避するために、このパラメータ値を変更しないことをお勧めします。

Aurora PostgreSQL では、ブルー環境の DB クラスターを自己管理の論理ソース (パブリッシャー) またはレプリカ (サブスクライバー) にすることはできません。Aurora MySQL では、ブルー環境の DB クラスターを外部バイナリログレプリカにすることはできません。

切り替え中、ブルー環境とグリーン環境では Amazon Redshift とのゼロ ETL 統合はできません。最初に統合を削除してから切り替えて、統合を再作成する必要があります。

ブルー/グリーンデプロイを作成するときには、グリーン環境でイベントスケジューラー (event_scheduler パラメーター) を無効にする必要があります。これにより、グリーン環境でイベントが生成されて不整合が発生するのを防ぐことができます。

event_scheduler

ブルーの DB クラスターで定義されている Aurora Auto Scaling ポリシーはグリーンの環境にコピーされません。

ブルー/グリーンデプロイは MySQL 用の AWS JDBC ドライバーをサポートしていません。詳細については、GitHub の「既知の制限事項」を参照してください。

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

Amazon RDS Proxy

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

Aurora Serverless v1 DB クラスター

Aurora Global Database の一部である DB クラスター。

Babelfish for Aurora PostgreSQL

AWS CloudFormation

CFn でブルー/グリーンデプロイを実行できない。

ブルー/グリーンデプロイの変更の制約事項

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

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

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

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

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

ブルー環境に Aurora Auto Scaling ポリシーが含まれている場合、これらのポリシーはグリーンの環境にコピーされません。グリーン環境にはポリシーを手動で再追加する必要があります。

ブルー/グリーンデプロイの作成

Aurora MySQL DB クラスターのブルー/グリーンデプロイを作成する前に、バイナリログ (binlog_format) がオンになっているカスタム DB クラスターパラメータグループにクラスターを関連付ける必要があります。ブルー環境からグリーン環境へのレプリケーションには、バイナリログが必要です。どのバイナリログ形式でも使用できますが、複製の不整合のリスクを減らすには、ROW をお勧めします。カスタム DB クラスターパラメータグループの作成とパラメータの設定については、「DB クラスターパラメータグループを使用する」を参照してください。

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