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

ディザスタリカバリ (災害復旧) と高可用性計画は、事業運営の回復力と継続性を確保する上で重要な役割を果たします。AWS でのディザスタリカバリ戦略を検討する場合、主要な選択肢は 2 つあります。リージョン内のディザスタリカバリとリージョン間のディザスタリカバリです。リージョン内ディザスタリカバリとリージョン間のディザスタリカバリのどちらを選択するかは、アプリケーションとデータの重要性、規制要件、ユーザーの地理的分布、コスト、複雑さなど、さまざまな要因によって異なります。

AWS にマルチリージョンのディザスタリカバリソリューションを実装するには、まずインフラストラクチャの重要なコンポーネントを特定し、各コンポーネントに必要な目標復旧時点 (RPO) と目標復旧時間 (RTO) を決定する必要があります。RPO は許容できる最大データ損失量であり、RTO はシステムを復元するために定められた時間までにかかる最大時間です。

2023 年 7 月現在、AWS クラウドは世界 31 の地理的リージョンにある 99 のアベイラビリティーゾーンにまたがっています。AWS はまた、カナダ、イスラエル、マレーシア、ニュージーランド、タイに 15 のアベイラビリティーゾーンと 5 つの AWS リージョンを追加する計画も発表しました。

Amazon Relational Database Service (Amazon RDS) は、クラウドでのデータベースのセットアップ、運用、スケーリングを簡単にするマネージドサービスです。MySQL、MariaDB、PostgreSQL、Oracle、SQL Server などの一般的なエンジンから選択できます。

このシリーズでは、さまざまな AWS リージョンで可能な限りの高可用性とディザスタリカバリを必要とする重要なアプリケーションのニーズに焦点を当てます。この最初の投稿では、2 つの AWS リージョンにまたがって Amazon RDS for SQL Server、Amazon Route53、Amazon Simple Storage Service(Amazon S3) を使用するアプリケーションのフェイルオーバー戦略を確立するプロセスをご案内します。次の投稿では、このプランを使用して実際にフェイルオーバーを実行する方法を示します。

ソーリューション概要

このソリューションは、アクティブ/パッシブ戦略を採用した 2 つの AWS リージョンにデプロイされて、プライマリ (アクティブ) リージョンがワークロードをホストしてトラフィックを処理します。セカンダリ (パッシブ) リージョンはディザスタリカバリに使用されます。フェイルオーバーポリシーが設定された Amazon Route53 パブリックホストゾーンは、プライマリリージョンとセカンダリリージョンの間でインターネットトラフィックをルーティングするために作成されます。Amazon Route 53 プライベートホストゾーン CNAME レコードは RDS for SQL Server エンドポイントを格納します。アプリケーションはこれらのレコードを使用してデータベースに接続します。

次の図は、このアーキテクチャの主要なコンポーネントを示しています。

この例では、プライマリ AWS リージョンは us-east-1、セカンダリ AWS リージョンは us-east-2 です。さらに、次の点にも注意してください。

Amazon RDS for SQL Server マルチ AZ DB インスタンスはプライマリ AWS リージョンにデプロイされ、クロスリージョンリードレプリカはセカンダリリージョンにあります。
Amazon RDS for SQL Server は、分散可用性グループを使用してクロスリージョンリードレプリカ (非同期レプリケーション) を設定します。
アプリケーションスタックは両方のリージョンにデプロイされ、リリースバージョンは同じです。
インターネットトラフィックを処理する Amazon Route53 パブリックホストゾーンには “フェイルオーバー” ルーティングポリシーが設定されています。
Amazon Route53 プライベートホストゾーンは、SQL Server インスタンス接続のための RDS へのアプリケーション用の “シンプル” ルーティングポリシーで設定されています。

スタンバイがプライマリを引き継ぐ

Amazon Route 53 パブリックホストゾーンのフェイルオーバーポリシーは、Standby takes over primary (スタンバイがプライマリを引き継ぐ) アプローチを使用して実装されます。この方法では、プライマリリージョンの Route53 ヘルスチェックが HTTP エンドポイントのアクセシビリティを検証します。そのエンドポイントはセカンダリリージョンに保存されている Amazon S3 ファイルになります。たとえば、AWS リージョン us-east-2 に examplebucket123 という名前の Amazon S3 バケットがあり、ファイル名が initiate_failover.dr の場合、この S3 ファイルにアクセスするための対応するエンドポイントは次のようになります。https://examplebucket123.s3.us-east-2.amazonaws.com/initiate_failover.dr

このヘルスチェックは、指定されたエンドポイントから受信した HTTP 応答が 4xx または 5xx のステータスコード (つまり、Route 53 ヘルスチェックエージェントがその Amazon S3 ファイルエンドポイントを解決できない) を返したときに正常と見なされます。逆に、レスポンスで 2xx または 3xx のステータスコードが返された場合、ヘルスチェックは失敗します (つまり、Route 53 ヘルスチェックエージェントは Amazon S3 ファイルエンドポイントを解決できたということです)。この方法は Route53 Invert ヘルスチェックと呼ばれます。この方法では、プライマリ AWS リージョンとセカンダリ AWS リージョン間のフェイルオーバーを手動で制御できるだけでなく、スタンバイリージョンのリソースに障害が発生した場合の偶発的なフェイルオーバーを防ぐこともできます。ディザスタリカバリ時には、このファイルをセカンダリリージョンの S3 バケットにアップロードしてください。これにより、プライマリリージョンの Route53 ヘルスチェックが意図的に失敗します。HTTP ステータスコードのリストについては、このドキュメントを参照してください。信頼性の高いフェイルオーバーメカニズムを設計するさまざまなアプローチを包括的に理解するには、「Amazon Route 53 を用いたディザスタリカバリ (DR) のメカニズム」を参照してください。

インターネットトラフィックをセカンダリリージョンに自動的にフェイルオーバーすることは推奨されないことに注意してください。プライマリリージョンのネットワーク障害が短時間発生したような状況では、自動フェイルオーバーによってダウンタイムが長くなる可能性があります。

前提条件

このソリューションを実装するには、次のものが必要です。

プライマリリージョンのアプリケーションスタックと Amazon RDS for SQL Server マルチ AZ インスタンス。
セカンダリリージョンのアプリケーションスタックと Amazon RDS for SQL Server リードレプリカインスタンス (クロスレプリケーション)。手順については、「Amazon Relational Database Service for SQL Server でクロスリージョンのリードレプリカを使用する」を参照してください。
リードレプリカの作成後にプライマリ DB インスタンスで作成されたサーバーレベルのオブジェクト (ログイン、SQL エージェントジョブなど) は自動的にレプリケートされないため、リードレプリカで手動で作成する必要がありす。そのため、これらのオブジェクトがプライマリリージョンとセカンダリリージョンの間で同期していることを確認してください。詳細については、Amazon RDS のドキュメントを参照してください。

ウォークスルー

このソリューションを導入するには、次の手順を実行します。

プライマリリージョンの Amazon Relational Database service (RDS) コンソールに移動します。
SQL Server インスタンスのプライマリ RDS のエンドポイントを書き留めておきます。
同様に、セカンダリリージョンの Amazon RDS コンソールに移動します。
RDS for SQL Server クロスリージョンリードレプリカのエンドポイントを書き留めておきます。
Amazon Route53 コンソールに移動します。
新しいプライベートホストゾーンを作成します。
両方のリージョンの VPC をプライベートホストゾーンに関連付けます。これはプライベートホストゾーンは Amazon VPC 内でトラフィックをルーティングするために必要です。
プライベートホストゾーンを作成したら、シンプルルーティングポリシーで 2 つの CNAME レコードを追加します。この例では、以下の CNAME レコードを作成しました。
1. rdsprimarydb.rds_sqlserver_private_hosted_zone – プライマリリージョンの RDS for SQL Server に接続します。
2. rdssecondarydb.rds_sqlserver_private_hosted_zone – クロスリージョンリードレプリカの RDS for SQL Server に接続します。
両方の CNAME レコードを追加すると、プライベートホストゾーンは次のスクリーンショットのようになります。
データベース接続文字列のデータベースホスト名として CNAME レコード rdsprimarydb.rds_sqlserver_private_hosted_zone を使用してプライマリリージョンのアプリケーション設定を更新してください。
同様に、CNAME レコード rdssecondarydb.rds_sqlserver_private_hosted_zone を使用して、セカンダリリージョンのアプリケーションを更新します。このステップにより、アプリケーションが RDS エンドポイントを直接使用していないことが保証されます。そのため、フェイルオーバー中にアプリケーションを変更する必要はありません。
次の Python コードは、プライベートホストゾーン CNAME レコードを使用して RDS for SQL Server インスタンスに接続するコードの例です。
プライマリリージョンとセカンダリリージョンの両方に新しい Amazon S3 バケットを作成します。これらの S3 バケットはホストディザスタリカバリファイル専用です。ヘルスチェックプロセスのセキュリティと整合性を確保するには、このバケットへのアクセスを権限のある担当者のみに制限することが重要です。プライマリリージョンとセカンダリリージョンの両方が正常であれば、この時点でこれらのバケットは空のままにしておくことができます。
Amazon Route53 コンソールに移動し、Route53 パブリックホストゾーンを作成して、パブリックドメインのインターネットトラフィックを管理します。
パブリックホストゾーンを作成したら、Amazon Route53 ヘルスチェックコンソールに移動します。
新しい Route53 ヘルスチェックを 2 つ作成します。1 つはプライマリリージョンのフェイルオーバー用、もう 1 つはセカンダリリージョンのフェイルオーバー用です。これらのヘルスチェックは、プライマリリージョンのフェイルオーバーレコードとセカンダリリージョンのフェイルオーバーレコードに紐付けられます。
「ヘルスチェックの作成」ページで、以下を行います。
- プライマリリージョンのヘルスチェック名を入力します。
- 次に、モニタリング対象の [エンドポイント] オプションを選択します。
- エンドポイントの監視のセクションで、[ドメイン名] に入力してプロトコルに [HTTPS] を選択します。
- [ドメイン名] で、セカンダリリージョンの Amazon S3 バケットエンドポイントを指定します。例 : examplebucket123.s3.us-east-2.amazonaws.com
- [パス] で、ディザスタリカバリファイル名を指定します。例 : initiate_failover.dr
- 「高度な設定」セクションで失敗しきい値とリクエスト間隔を指定します。
- [ヘルスチェックステータスを反転] のオプションにチェックを入れ、[次へ] をクリックします。
- [ヘルスチェックの作成] をクリックします。
同じ手順を繰り返して、セカンダリリージョンのヘルスチェックレコードを作成します。
プライマリリージョンのヘルスチェックでは、セカンダリリージョンの S3 ファイルエンドポイントを指定します。その逆も同様です。プライマリリージョンにアクセスできなくなった場合は、セカンダリリージョンの S3 ファイルを変更してフェイルオーバーを開始できます。
プライマリリージョンとセカンダリリージョンのヘルスチェックが作成されると、Amazon Route53 はヘルスチェックを開始してステータスを報告します。
ステップ 13 で作成した Route53 パブリックホストゾーンに移動して、以下の手順を実行します。
1. フェイルオーバールーティングポリシーを使用してレコードを作成します。
2. [フェイルオーバーレコードを定義] をクリックします。
3. このレコードをアプリケーションターゲットに関連付けます。たとえば、Route53 はアプリケーションロードバランサー、API ゲートウェイ、VPC エンドポイント、S3 エンドポイントなどをサポートしています。この例では、アプリケーション負荷分散ターゲットが選択されています。
4. プライマリリージョンを選択。
5. 対象のロードバランサーを選択します。
6. フェイルオーバーレコードタイプをプライマリに指定します。
7. プライマリリージョン用に作成されたヘルスチェックレコードを選択してください。
8. ターゲットヘルス評価オプションを無効にします。
9. サブミット
同様の手順を繰り返して、2 番目のレコードタイプ用に別のレコードを作成します。

パブリックホストゾーンの設定が完了すると、以下のスクリーンショットのようになります。

これで、Amazon Route53、Amazon S3、および Amazon RDS for SQL Server によるディザスタリカバリブループリントのデプロイが完了しました。この時点で、インターネットトラフィックを介してアプリケーションにアクセスできるはずです。

後片付け

このシリーズの次回の記事では、このブルーポイントを使用して、クロスリージョンフェイルオーバーを実行する方法を示します。したがって、継続する予定がある場合は、このデプロイで作成されたすべてのリソースを保存しておいてください。

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

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

まとめ

この記事では、クロスリージョンのディザスタリカバリブループリントを実施する方法についてのガイダンスを提供しました。Amazon Route53 のパブリックホストゾーンポリシーの「スタンバイがプライマリを引き継ぐ」アプローチにより、組織はフェイルオーバープロセスの制御を維持し、プライマリリージョンにアクセスできなくなったときに手動でフェイルオーバーを開始できます。

このシリーズの次回の記事では、AWS セカンダリリージョンで RDS for SQL Server を昇格するプロセスと、デプロイしたブループリントを使用してクロスリージョンフェイルオーバーを実行するプロセスについて詳しく説明します。

著者について

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

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

Amazon Web Services ブログ