ディザスタリカバリブループリントを備えたクロスリージョンリードレプリカを使用して、マルチリージョン Amazon RDS for SQL Server をデプロイする – 第 2 部

前回の投稿では、Amazon Route 53、Amazon Relational Database Service (Amazon RDS) for SQL Server、Amazon Simple Storage Service (Amazon S3) を使用して、マルチリージョンのディザスタリカバリブループリントをデプロイしました。この記事では、AWS セカンダリリージョンで RDS for SQL Server を昇格させ、デプロイしたブループリントを使用してクロスリージョンフェイルオーバーを実行するプロセスについて説明します。

前回の投稿の簡単な振り返り

大まかに説明すると、次の手順を実行しました。

クロスリージョンリードレプリカで実行されている Amazon RDS for SQL Server データベースを確認します。
RDS インスタンスとのアプリケーション接続を設定するために Amazon Route 53 プライベートホストゾーン CNAME レコードを作成しました。
プライマリ AWS リージョンとセカンダリ AWS リージョン間のインターネットトラフィックを管理するように Amazon Route53 パブリックホストゾーンを設定しました。
ディザスタリカバリファイルをホストするために、両方のリージョンに個別の Amazon S3 バケットを作成しました。
パブリックドメイン名を使用してインターネットトラフィックの接続をテストしました。

このソリューションのアーキテクチャは、次の図に示されています。プライマリリージョンとセカンダリリージョンの両方が稼働している場合、Amazon Route53 はインターネットトラフィックをアクティブリージョン (この例では us-east-1) にルーティングします。インターネットトラフィックはパッシブリージョン (この例では us-east-2) にルーティングされません。

クロスリージョンフェイルオーバーに関する主な考慮事項:

クロスリージョンフェイルオーバーを開始するには、さまざまな要因を十分に考慮する必要があります。考慮すべき重要な点をいくつか紹介します。

プライマリリージョンでアプリケーションが依存している 1 つ以上の AWS サービスが応答していないこと
セカンダリリージョンにデプロイされたアプリケーション層は完全に更新され、主要な役割を引き受ける準備ができていること。Amazon Route 53 アプリケーションリカバリーコントローラーには、マルチリージョンの準備状況チェック機能があります。詳細については、Amazon Route 53 アプリケーションリカバリーコントローラーの準備状況チェックを参照してください。
カスタマーサービスを回復する唯一の方法は、ライブトラフィックをセカンダリージョンに切り替えること
セカンダリリージョンの RDS for SQL Server リードレプリカのレプリカラグは、ビジネスにとって許容可能な範囲 (RPO) を下回っていること。レプリカラグがゼロでない状態でクロスリージョンフェイルオーバーを開始すると、データが失われる可能性があります。詳細については、「SQL Server リードレプリカの問題のトラブルシューティング」を参照してください。

次の図は、ディザスタリカバリイベント中のアーキテクチャを示しています。

クロスリージョンフェイルオーバーの手順:

イベントの順序に従って、このソリューションがどのように機能するかを見てみましょう。

ディザスタリカバリイベントを宣言し、SQL Server インスタンスのプライマリ RDS への書き込みを無効にします。
RDS for SQL Server クロスリージョンリードレプリカをセカンダリージョンのスタンドアロン DB インスタンスに昇格させます。
RDS for SQL Server リードレプリカの昇格が成功したら、スモークテストと呼ばれることが多いエンドツーエンドの検証を実施します。この検証プロセスにより、アプリケーションが正しく機能し、セカンダリ AWS リージョンで外部トラフィックを受け入れる準備ができていることを確認します。
ディザスタリカバリブループリントとともにデプロイされた Amazon S3 バケットにディザスタリカバリファイルを作成してアップロードします。Route53 パブリックレコードヘルスチェックの HTTP エンドポイントで指定されているのと同じファイル名を使用してください。このファイルをアップロードすると、プライマリリージョンの Route 53 ヘルスチェックが失敗し、セカンダリリージョンへのフェイルオーバーが開始されます。
セカンダリリージョンへのフェイルオーバーが完了したら、アプリケーションスタックとデータベースの正常性を確認し、それらが正しく機能していて外部トラフィックを受信していることを確認します。このステップで、アプリケーションのダウンタイムは完了です。
セカンダリリージョンの RDS インスタンスを変更し、マルチ AZ オプションを有効にして、リージョン内の高可用性を再度有効にします。これは、RDS for SQL Server インスタンスにクロスリージョンリードレプリカを作成する際の前提条件でもあります。
AWS リージョンのプライマリリージョンが利用可能になったら、新しい RDS for SQL Server クロスリージョンレプリカを手動で作成して、クロスリージョンディザスタリカバリソリューションを再作成します。
Route53 のプライベートホストゾーン rds_sqlserver_private_hosted_zone を変更し、rdsprimarydb.rds_sqlserver_private_hosted_zone CNAME レコードを更新して、プライマリリージョンに新しく作成されたリードレプリカを指すようにします。

フェイルオーバーの実装

クロスリージョンフェイルオーバーを開始するには、次の手順に従います。

ディザスタリカバリイベントを宣言し、プライマリリージョンの SQL Server インスタンスの RDS への書き込みを無効にします。アプリケーションがアクセスできる場合は、DR のフェイルオーバー中に現在のプライマリデータベースに誤って書き込まれないようにアプリケーションを停止します。
セカンダリリージョンでは、Amazon CloudWatch メトリックスの Replica Lag を使用して SQL Server の RDS リードレプリカの遅延（ラグ）を確認します。このクエリをプライマリデータベースで実行して、すべてのリードレプリカのレプリケーションラグに関する情報を取得することもできます。クロスリージョンのレプリケーションラグがゼロか、ビジネスで許容できる範囲 (RPO) を下回っている場合にのみ、次のステップに進んでください。レプリケーションラグがゼロでない状態でクロスリージョンフェイルオーバーを開始すると、データが失われる可能性があります。
Amazon Route 53 コンソールに移動します。
パブリックホストゾーンを選択し、ルーティングポリシーを確認します。
Amazon Route 53 ヘルスチェックダッシュボードに移動します。
プライマリリージョンのヘルスチェックレコード用の S3 ファイルエンドポイントの URL を書き留めておきます。この段階では、両方のリージョンのヘルスチェックの状態が正常である必要があります。
プライベートホストゾーン rds_sqlserver_private_hosted_zone に移動して CNAME エントリを確認します。セカンドリージョンのアプリケーションスタックは rdssecondarydb.rds_sqlserver_private_hosted_zone の CNAME レコードを使って RDS インスタンスに接続します。
セカンドリージョンで、RDS for SQL Server クロスリージョンリードレプリカを昇格させます。

AWS Lambda 関数を作成して、このステップを自動化することもできます。参考となる Python コードは、この GitHub リポジトリで見つけることができます。関数の作成手順については、AWS Lambda 開発者ガイドを参照してください。
RDS for SQL Server インスタンスを昇格しても、RDS エンドポイント URL は変更されません。したがって、Route53 プライベートホストゾーンの CNAME レコードを更新する必要はありません。アプリケーションは、rdssecondarydb.rds_sqlserver_private_hosted_zone レコードを使用して、昇格した RDS for SQL Server インスタンスに接続できます。
内部スモークテストまたはアプリケーションの健全性チェックを実行してアプリケーションが正しく機能し、セカンダリリージョンでインターネットトラフィックを受け入れる準備ができていることを確認します。
セカンダリリージョンのアプリケーションスタックがインターネットトラフィックを受け入れる準備ができたら、フェールフェイルオーバープロセスを開始します。
手順 6 を参照してリカバリファイルの URL を取得します。このリカバリファイルをセカンダリリージョンの Amazon S3 バケットにアップロードします。この例では、ファイル名は initiate_failover.dr です。

このファイルを Amazon S3 バケットにアップロードすると、プライマリリージョンの Route53 ヘルスチェックが失敗します (Route 53 ヘルスチェックでヘルスチェックステータスを反転するオプションを有効にしたことを思い出してください)。プライマリリージョンが異常とマークされると、Route53 はインターネットトラフィックのセカンダリリージョンへのフェイルオーバーを開始します。フェイルオーバーの遅延は、ヘルスチェック設定、リクエスト間隔、および失敗しきい値によって異なります。

フェイルオーバーが完了すると、アプリケーションはセカンダリ AWS リージョンでインターネットトラフィックの受信を開始します。
このステップではアプリケーションはダウンタイムから回復しますが、単一の AWS アベイラビリティゾーンで実行されます。リージョン内の高可用性をセットアップするには、セカンダリリージョンの RDS インスタンスを変更し、Amazon RDS for SQL Server のマルチ AZ を有効にします。
AWS プライマリリージョンが再び利用可能になったら、新しい RDS for SQL Server クロスリージョンリードレプリカを手動で作成して、クロスリージョンの災害復旧ソリューションを再作成します。
Route 53 プライベートホストゾーン rds_sqlserver_private_hosted_zone を更新し、新しい RDS for SQLServer クロスリージョンリードレプリカエンドポイントを使用して CNAME レコード値 rdsprimarydb.rds_sqlserver_private_hosted_zone を編集します。

次の図は、フェイルオーバー後の最終的なアーキテクチャを示しています。

後片付け

このソリューションを実装するために作成されたリソースを削除するには、次の手順を実行します。

作成したパブリックおよびプライベートのホストゾーンを削除します。
アプリケーション構成を元の状態に変更します。
作成した Amazon S3 バケットを削除します。

まとめ

この投稿では、アクティブ/パッシブ戦略を採用したマルチリージョン構成でデプロイされたアプリケーションのフェイルオーバープロセスについて説明しました。 Amazon Route 53 パブリックホストゾーンポリシーは、プライマリリージョンとセカンダリリージョン間のトラフィックをフェイルオーバーします。 Amazon Route53 プライベートホストゾーンポリシーは、適切なデータベースエンドポイントへのトラフィックのルーティングを処理します。これにより、アプリケーションが使用する統一された共通エンドポイントが提供され、障害時にアプリケーション構成を変更する必要がなくなります。 AWS Lambda 関数を使用して、RDS インスタンスの昇格に必要な手動タスクのスクリプトを作成できます。関数を手動でトリガーすることも、イベントを使用することもできます。

AWS アカウントでこのソリューションを試してください。

著者について

Ravi Mathur は、AWS のシニアソリューションアーキテクトです。彼はお客様と連携して、さまざまな AWS サービスに関する技術支援やアーキテクチャに関するガイダンスを提供しています。彼は、さまざまな大規模企業でソフトウェアエンジニアリングとアーキテクチャの役割に数年間携わった経験を持っています。

翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文はこちらです。

Amazon Web Services ブログ