IaC 原則を使用して Amazon Aurora Global Database のブルー/グリーンデプロイを自動化する

ブルークラスターからスナップショットバックアップを作成します。

ブルー/グリーンデプロイでは、グリーン環境は現在の (ブルー) データベース環境と同一の新バージョンを表します。グリーン環境を使用して、更新を安全にテストし、変更を検証し、安定性を確保してから、本番環境のトラフィックを切り替えます。これは、ライブ環境の中断を最小限に抑えながらデータベースの変更を実装するためのステージング基盤として機能します。

グリーン環境を作成するには、まず Aurora MySQL 互換 Global Database にプライマリ (ブルー) クラスターのスナップショットを作成します。このスナップショットは、グリーン環境を作成するための基盤として機能します。

スナップショットを作成するために以下を実行します:

または、 AWS Command Line Interface (AWS CLI) を使用してスナップショットを作成することもできます。

aws rds create-db-cluster-snapshot --db-cluster-snapshot-identifier blue-green-demo --db-cluster-identifier ex-global-cluster --region eu-west-1

スナップショットが正常に完了したことを確認してから、次のステップに進みます。

グローバルデータベースとそのリソースの CloudFormation テンプレートを生成します。

CloudFormation IaC ジェネレーターは、既存の AWS リソースから CloudFormation テンプレートを生成するのに役立ちます。この機能を使用して、既存の Aurora MySQL 互換グローバルデータベースとその関連リソースの CloudFormation テンプレートを作成します。このテンプレートは、サブネットグループ、セキュリティグループ、パラメータグループ、およびその他の設定を構成します。

グリーン環境の CloudFormation テンプレートを変更します。

グリーン環境の設定を反映するように CloudFormation テンプレートをカスタマイズします。これには、グリーン環境がブルークラスターとは独立して動作するようにリソース名と識別子を更新することが含まれます。

CloudFormation スタックをデプロイして、グリーン環境のリソースを作成します。

このステップでは、カスタマイズされた CloudFormation テンプレートをデプロイして、グリーン環境のリソースを作成します。

CloudFormation スタックをデプロイするために以下を実行します:

CloudFormation で、グリーン環境リソースを作成するプロセスが開始されます。このプロセスは完了までに数分かかることがあります。

CloudFormation のスタックとリソースを検証します。

CloudFormation スタックのデプロイが完了したら、グリーン環境が正常に作成されたことを確認する必要があります。

検証後、ブルー環境からのレプリケーションなど、グリーン環境の設定を進める準備が整います。

ブルークラスターの GTID 設定を確認します。

GTID は、ブルー環境とグリーン環境間でデータをレプリケートするための信頼性の高い方法を提供します。GTID ベースのレプリケーションは、ブルー環境内のすべてのトランザクションに一意の識別子を割り当てることで、回復力の高い簡素化されたアプローチを提供します。この方法により、環境間のデータ同期がシームレスで一貫性があり、従来のバイナリログレプリケーションよりも容易に管理できるものになります。

レプリケーションを設定する前に、ブルークラスターで確実に GTID ベースのレプリケーションが適切に有効になっているようにする必要があります。このステップにより、ブルー環境の各トランザクションが一意に追跡され、グリーン環境でレプリケートできることが保証されます。

GTID が有効であることを確認するため以下を実行します。

これらの設定により、ブルー環境での今後のすべてのトランザクションの GTID 追跡が有効になります。これらの設定の確認後に、レプリケーションの設定を開始できます。

レプリケーションユーザーを作成します。

ブルー環境からグリーン環境にデータをレプリケートするには、ブルークラスターに専用のレプリケーションユーザーを作成する必要があります。このユーザーは、レプリケーションプロセスの管理を担当します。

レプリケーションユーザーを設定するため以下を実行します:

このユーザーは、2 つの環境間でデータをレプリケートするために必要なアクセス許可を持つようになりました。

グリーンクラスターで GTID ベースのレプリケーションを設定します。

次のステップでは、GTID ベースのレプリケーション用にグリーンクラスターを設定します。この設定により、グリーン環境は確実に、ブルー環境で発生するすべてのトランザクションを継続的にミラーリングするようになります。

グリーンクラスターを設定するため以下を実行します。

グリーンクラスターでレプリケーションを開始します。

これで、レプリケーションプロセスを開始できます。グリーンクラスターで、次のコマンドを実行します。

START SLAVE;

これで、グリーン環境はデータの同期と、ブルー環境からのトランザクションの受信と適用を開始できるようになります。

レプリケーションプロセスを検証します。

グリーン環境がブルークラスターからデータを正確にレプリケートしていることを検証するため以下を実行します。

すべてのインジケータが正しい場合、GTID ベースのレプリケーションはスムーズに機能し、グリーン環境はブルー環境と完全に同期されています。

Route 53 加重ルーティングポリシーを設定します。

ブルー環境とグリーン環境間のデータ整合性を検証したら、ブルークラスターからグリーンクラスターへトラフィックを切り替えることができます。この移行はスムーズである必要があります。また、ダウンタイムを最小限に抑え、アプリケーションのデータベースの整合性を確保する必要もあります。これらの要件を満たすため、DNS ルーティングに Route 53 を使用し、Lambda を使用してトラフィックの切り替えを自動化します。さらに、明確に定義されたロールバックプランにより、問題が発生した場合にブルークラスターに戻すことができるようにします。

最初のステップは、Route 53 で加重ルーティングを設定することです。加重ルーティングを使用すると、ブルークラスターとグリーンクラスター間のトラフィックの分散を制御し、ある環境から別の環境にトラフィックを徐々に移行できます。

加重ルーティングを設定するために以下を実行します。

加重ルーティングポリシーの詳細については、Route 53 ドキュメントを参照してください。

Lambda 関数をデプロイして、レプリケーションラグをモニタリングします。

グリーン環境がブルー環境と完全に同期されるようにするため、クラスター間のレプリケーションラグをモニタリングする Lambda 関数をデプロイします。この関数で、レプリケーションステータス、特に Seconds_Behind_Master メトリクスをチェックして、グリーンクラスターがすべてのトラフィックを処理する準備ができているかどうかを判断できます。

使用できる Lambda 関数の例を次に示します。

import boto3

def check_replication_lag(event, context):
    client = boto3.client('rds')
    response = client.describe_db_instances(DBInstanceIdentifier='green-cluster-instance')
    replication_status = response['DBInstances'][0]['ReadReplicaDBInstanceIdentifiers']
    if replication_status:
        lag = replication_status[0]['ReplicationLag']
        return lag
    return -1

この関数はレプリケーションのラグをチェックし、値を返します。ラグがゼロの場合、グリーンクラスターはブルークラスターと完全に同期しています。

Lambda を使用して DNS の重み調整を自動化します。

レプリケーションのラグがゼロになったら、いよいよすべてのトラフィックをグリーンクラスターに切り替えます。この移行を自動化するには、トラフィックの 100% をグリーンクラスターに送信するように Route 53 の DNS 重みを調整する別の Lambda 関数を使用します。

トラフィックの切り替えを自動化する Lambda 関数の例を次に示します。

import boto3

def switch_traffic(event, context):
    route53 = boto3.client('route53')
    lag = check_replication_lag(event, context)
    if lag == 0:
        response = route53.change_resource_record_sets(
            HostedZoneId='YOUR_HOSTED_ZONE_ID',
            ChangeBatch={
                'Changes': [
                    {
                        'Action': 'UPSERT',
                        'ResourceRecordSet': {
                            'Name': 'db.example.com',
                            'Type': 'CNAME',
                            'SetIdentifier': 'GreenCluster',
                            'Weight': 100,
                            'TTL': 60,
                            'ResourceRecords': [{'Value': 'green-cluster-endpoint'}]
                        }
                    },
                    {
                        'Action': 'UPSERT',
                        'ResourceRecordSet': {
                            'Name': 'db.example.com',
                            'Type': 'CNAME',
                            'SetIdentifier': 'BlueCluster',
                            'Weight': 0,
                            'TTL': 60,
                            'ResourceRecords': [{'Value': 'blue-cluster-endpoint'}]
                        }
                    }
                ]
            }
        )
        return response

この関数はレプリケーションラグをチェックし、ラグがゼロのときに Route 53 DNS の重みを更新して、トラフィックを完全にグリーンクラスターに切り替えます。

トラフィックの切り替えを検証します。

Lambda 関数が DNS の重みを調整した後、すべてのトラフィックがグリーンクラスターに転送され、切り替えが成功したことを確認する必要があります。

検証するために以下を実行します。

すべてが期待どおりに動作していたら、トラフィックの切り替えは完了です。

問題が発生した場合は、変更をロールバックします。

トラフィックの切り替え後に問題が発生した場合に備えて、ロールバック計画を立てることが不可欠です。必要に応じてブルークラスターにすばやく戻る方法は、次のとおりです。

このロールバック計画を実装することで、予期しない問題が発生した場合にユーザーの中断を最小限に抑えることができます。

グリーンクラスターで GTID ベースのレプリケーションを停止します。

ブルー環境からグリーン環境にトラフィックを切り替えたら、移行の成功を検証し、グリーンクラスターが期待どおりに機能していることを確認する必要があります。さらに、グリーン環境がプライマリデータベースとして機能するようになったため、ブルークラスターとグリーンクラスター間の GTID ベースのレプリケーションを停止する必要もあります。これらのタスクを完了することで、環境が安全で、合理化された、継続的な運用向けに最適化されたものになります。

レプリケーションを停止するには、以下を実行します。

レプリケーションを停止すると、グリーンクラスターは完全に独立した状態になり、ワークロードのプライマリデータベース環境として機能します。

リソースをクリーンアップします。

ブルークラスターからグリーンクラスターへの移行中に作成された一時的または未使用のリソースをクリーンアップすることで、環境は最適化された、安全な、コスト効率の高い状態を維持できます。クリーンアップには、セキュリティ設定の調整、最終バックアップの取得、不要なリソースの廃止などが含まれます。

リソースをクリーンアップするには、以下を実行します。

リソースをクリーンアップすることで、安全で合理化された環境を維持し、コストを削減し、必要なインフラストラクチャだけが残るようにします。