本記事は 2026 年 1 月 6 日 に公開された「Implement multi-Region endpoint routing for Amazon Aurora DSQL」を翻訳したものです。
Amazon Aurora DSQL は、事実上無制限のスケール、最高レベルの可用性、ゼロインフラストラクチャ管理を実現する、サーバーレスの分散 PostgreSQL 互換データベースです。Aurora DSQL は、データベースシャーディングやインスタンスのアップグレードの必要性を軽減し、シングルリージョンとマルチリージョンの両方のデプロイメントをサポートします。Aurora DSQL は、マルチリージョンクラスターの各リージョンに専用のリージョナルエンドポイントを提供し、アプリケーションが最適なリージョンに直接接続して可能な限り低いレイテンシーを実現できるようにします。そのアーキテクチャは、アクティブ-アクティブ分散設計により、読み取りと書き込みに対して強力なデータ整合性を提供し、シングルリージョンデプロイメントでは 99.99% の可用性、マルチリージョンデプロイメントでは 99.999% の可用性を実現します。
Aurora DSQL マルチリージョンクラスターを使用するアプリケーションは、DNS ベースのルーティングソリューション (Amazon Route 53 など) を実装して、AWS リージョン間でトラフィックを自動的にリダイレクトする必要があります。これにより、Aurora DSQL クラスターまたは AWS リージョン全体が到達不能になった場合でも、運用の継続性が確保されます。
ベストプラクティスでは、リージョナルフェイルオーバーを包括的に管理するために、アプリケーションレベルのルーティングロジックを実装することを推奨しています。ただし、アプリケーションが Aurora DSQL を含む複数のデータストアに依存している場合、Aurora DSQL リージョナルエンドポイントが到達不能になる状況を処理するための特定の戦略が必要です。この記事では、手動での設定変更を必要とせずに、データベーストラフィックを代替リージョナルエンドポイントに自動的にリダイレクトするソリューションを紹介します。特に、混在データストア環境において有効です。
マルチリージョン Aurora DSQL クラスターのエンドポイント管理
Amazon Aurora DSQL を永続化層として使用する、マルチリージョンアプリケーションアーキテクチャを見てみましょう。
Aurora DSQL マルチリージョンクラスターは、同期クロスリージョンレプリケーションを使用して、リージョン間 (および図には示されていない DSQL ウィットネスリージョン間) で強力な整合性を維持します。DSQL は、どちらのリージョナルエンドポイントでも読み取りと書き込みを受け入れることができ、Aurora DSQL の強力な整合性のおかげで、リージョン A のリーダーはリージョン B でコミットされた書き込みをすぐに確認でき、その逆も可能です。DSQL のこの特性により、マルチリージョンアクティブ-アクティブアプリケーションの構築がはるかに簡単になります。
DSQL がクロスリージョンの調整やメッセージングを実⾏するため、アプリケーションは他のリージョンを考慮する必要はありません。
Aurora DSQL では、サービスがこれらの操作を自動的に処理するため、データベースのフェイルオーバーやスイッチオーバー操作を心配する必要はありません。ただし、アプリケーションが異なる API コールに対して複数のデータストアを使用する特定のシナリオや、外部データセンターからマルチリージョン DSQL クラスターに接続するアプリケーションの場合、DSQL エンドポイント間を直接切り替える方が、アプリケーションサーバーエンドポイント全体をリダイレクトするよりも効率的です。このアプローチは、完全なアプリケーションスタックを移動するのではなく、影響を受けるデータベース接続のみをターゲットにすることで、運用の複雑さを軽減し、サービス中断時に必要な労力を最小限に抑えます。DSQL リージョナルクラスターに中断を引き起こすイベントは、影響を受けるリージョンのアプリケーションの可用性にも影響を与える可能性があります。マルチリージョン DSQL クラスターセットアップでリージョナルエンドポイント障害が発生した場合に、アプリケーションを到達可能なリージョナルエンドポイントに接続する自動化されたソリューションを紹介します。
この記事で説明するソリューションは、GitHub でサンプルコードとして入手できます。
ソリューション概要
このソリューションでは、カスタム Python クライアント側ライブラリを使用して、アプリケーションから Aurora DSQL エンドポイント間の接続の自動リダイレクトを実装する方法を示します。デプロイされると、Amazon Route 53 API を通じて Aurora DSQL エンドポイントを監視します。ライブラリは、まずこれらのヘルスチェックを通じて正常なエンドポイントを識別し、次にクライアントと各正常なエンドポイント間のレイテンシーを測定します。クライアント接続を、最も低いレイテンシーを持つ正常なエンドポイントに自動的にルーティングし、リージョナルエンドポイントが到達不能になるまれなイベントが発生した場合でも、クライアント接続が最も低いレイテンシーを持つ正常な Aurora DSQL エンドポイントにルーティングされることを保証します。そして、Aurora DSQL の強力な整合性のおかげで、クライアントは任意のエンドポイントで正常にコミットされたすべてのトランザクションの結果をすぐに確認できます。
このソリューションの主な機能を見てみましょう。
- 自動エンドポイント選択 – 最適な接続性を提供するために、このソリューションは利用可能なデータベースクラスターエンドポイントの動的リストを維持し、利用可能なエンドポイントに対して定期的にレイテンシーテストを実行し、応答時間に基づいてランク付けされたリストを作成します。このランキングは、設定ファイルで事前定義された優先度設定と組み合わされます。各エンドポイントへのレイテンシーに基づいて、各接続に最適なエンドポイントを選択します。
- Route 53 ヘルスチェック – このソリューションは、Route 53 ヘルスチェックと統合され、AWS グローバルインフラストラクチャを使用して包括的なヘルス監視を行います。このアプローチは、エンドポイントのヘルスを維持し、ルーティングの決定に情報を提供するための堅牢で柔軟なシステムを提供します。
- 自動接続フェイルオーバーサポート – 高可用性を維持し、アプリケーションのダウンタイムを最小限に抑えるために、ソリューションは各リージョナルデータベースクラスターエンドポイントのヘルスを継続的に監視します。現在のエンドポイントで問題が検出されると、クライアント接続を正常な代替エンドポイントに自動的にリダイレクトします。これにより、特定のエンドポイントが到達不能な場合でも、クライアントアプリケーションは継続的なデータベースアクセスを維持します。このソリューションは、クライアントがデータベース接続を確立するリージョンを管理します。その結果、アプリケーションが手動介入なしに利用可能なエンドポイントにスムーズに移行するため、ユーザーエクスペリエンスへの中断が最小限に抑えられます。
次の図は、ソリューションのワークフローを示しています。
ワークフローには次のステップが含まれます。
- クライアント (クラスターがデプロイされているいずれかのリージョンで実行) は、
get_connection() を呼び出して接続を開始します。その後、ライブラリは利用可能な DSQL エンドポイントを評価し、ヘルスとパフォーマンスメトリクスに基づいて最適な接続を確立します。
- ライブラリは、リアルタイムのエンドポイントステータスについて Route 53 ヘルスチェックを参照します。これらのヘルスチェックは 30 秒間隔で実行され、エンドポイントの可用性に関するほぼ最新の情報を提供し、劣化または障害の兆候を継続的に監視します。
- ヘルスチェックデータを使用して、ライブラリは正常なエンドポイントに接続します。プライマリエンドポイントが失敗した場合、システムは自動的に正常な代替エンドポイントにリダイレクトします。
前提条件
このソリューションをデプロイするには、次の前提条件を完了する必要があります。
Python と依存パッケージのインストール、および AWS CLI の設定
次のステップを完了します。
- リポジトリをクローンします。
git clone https://github.com/aws-samples/sample-multi-region-Endpoint-Routing-for-Aurora-DSQL.git
cd sample-multi-region-Endpoint-Routing-for-Aurora-DSQL
- Python 環境をセットアップし、
venv という名前の新しい仮想環境を作成します。
python3 -m venv venv
source venv/bin/activate # Windows の場合: venv\Scripts\activate
- このソリューションを実行するために必要な、ファイル
requirements.txt 内の必要な依存関係をインストールします。
pip install -r requirements.txt
- AWS CLI を設定します。これにより、認証情報をグローバルに設定する便利な方法が提供されます。
- ターミナルのプロンプトに従います。コマンドは自動的にデフォルトのブラウザを開き、認証プロセスをガイドします。認証が成功すると、AWS CLI セッションは最大 12 時間有効になります。
設定ファイルと Route 53 ヘルスチェックのセットアップ
GitHub リポジトリには、dsql_config_with_healthchecks.json という名前の設定ファイルが含まれています。このファイルには、次の例のような構造があります。次のフィールドを変更する必要があります。
- 両方のリージョンについて、前提条件で記録したクラスター ID を使用して
cluster_id フィールドを更新します。
hostname フィールドを、以前にキャプチャしたリージョナル DSQL エンドポイントに置き換えます。
{
"endpoints": [
{
"cluster_id": "<Your-cluster-id>",
"region": "<cluster-region-1>",
"hostname": "<Your-Cluster-endpoint>",
"port": 5432,
"health_check_id": ""
},
{
"cluster_id": "<Your-cluster-id>",
"region": "<cluster-region-2>",
"hostname": "<Your-Cluster-endpoint>",
"port": 5432,
"health_check_id": ""
}
],
"connection_settings": {
"connect_timeout": 5,
"application_name": "dsql-hybrid-router",
"keepalives": 1,
"keepalives_idle": 30,
"keepalives_interval": 10,
"keepalives_count": 3
}
}
ターミナルで次のコマンドを実行して、エンドポイントの Route 53 ヘルスチェックを作成します。
python3 hybrid_failover_approach.py --setup --config dsql_config_with_healthchecks.json
このスクリプトのパラメータには次のものが含まれます。
- –config – このパラメータは、設定ファイルへのパスを指定します。設定ファイルは、DSQL エンドポイントと接続設定に関する情報を含む JSON ファイル
dsql_config_with_healthchecks.json です。
- –setup – このパラメータは、Route 53 ヘルスチェックを作成し、設定ファイル
dsql_config_with_healthchecks.json 内の各エンドポイントの health_check_id を更新します。
- –test – このパラメータは、接続テストを実行するためのものです。
このスクリプトは、設定ファイルを読み取り、各エンドポイントの Route 53 にヘルスチェックを作成し、新しく作成されたヘルスチェック ID で設定ファイルを更新します。health_check_id は、各エンドポイントに関連付けられた Route 53 ヘルスチェックの一意の識別子です。
{
"endpoints": [
{
"cluster_id": "<your-cluster-id-1>",
"region": "us-east-1",
"hostname": "<your-hostname-1.dsql.us-east-1.on.aws>",
"port": 5432,
"health_check_id": "57a713b9-a58f-4ae5-baaa-70cf62ca78eb"
},
{
"cluster_id": "<your-cluster-id-2>",
"region": "us-east-2",
"hostname": "<your-hostname-2.dsql.us-east-1.on.aws>",
"port": 5432,
"health_check_id": "37d3a545-2917-4e8f-9e44-f7d5e9b966a7"
}
],
"connection_settings": {
"connect_timeout": 5,
"application_name": "dsql-hybrid-router",
"keepalives": 1,
"keepalives_idle": 30,
"keepalives_interval": 10,
"keepalives_count": 3
}
}
Route 53 ヘルスチェックとクライアント側レイテンシールーティングによる接続テスト
DSQL エンドポイントへの基本的な接続をテストするには、次のコマンドを実行します。このスクリプトは、最適なエンドポイント選択のためのクライアント側レイテンシー測定、信頼性の高いヘルス監視のための Route 53 ヘルスチェック、および継続的なサービス可用性を提供する自動フェイルオーバー機能を組み合わせています。
python3 hybrid_failover_approach.py --test --config dsql_config_with_healthchecks.json --database postgres --user admin
Route 53 ヘルスチェックによるフェイルオーバーのテスト
このテストは、障害シナリオをシミュレートし、システムが適切に応答することを検証します。次のコマンドでテストスクリプトを実行します。
python3 test_route53_failover.py --config dsql_config_with_healthchecks.json --database postgres --user admin
このスクリプトは、アプリケーション (またはクライアント接続) のフェイルオーバーメカニズムを検証するための一連の操作を実行します。
- まず、設定の優先順位によって決定された最適な利用可能なエンドポイントへの接続を確立します。
- 接続後、スクリプトは意図的にこのプライマリエンドポイントに関連付けられた Route 53 ヘルスチェックを無効にし、障害をシミュレートします。
- 次に、スクリプトはヘルスチェックステータスが AWS ネットワークを通じて伝播するのを待ち、実際の障害状態を再現します。
- その後、スクリプトは新しい接続の作成を試み、プライマリの障害シミュレーションにより、セカンダリエンドポイントにフェイルオーバーするはずです。
- この期間中、システムがセカンダリエンドポイントへのフェイルオーバーに成功したことを検証し、プライマリエンドポイントのシミュレートされた障害にもかかわらず、継続的な動作を確認します。
- フェイルオーバーの成功を確認した後、スクリプトはプライマリエンドポイントのヘルスチェックを再度有効にし、復元されたプライマリエンドポイントへの接続が再び確立できることを検証します。
python3 test_route53_failover.py --config dsql_config_with_healthchecks.json --database postgres --user admin;
2025-05-21 19:03:52,864 - main - INFO -
=== STEP 1: Testing connection under normal conditions ===
2025-05-21 19:03:52,866 - dsql_hybrid_manager - INFO - Loaded configuration from dsql_config_with_healthchecks.json
2025-05-21 19:03:52,879 - botocore.credentials - INFO - Found credentials in environment variables.
2025-05-21 19:03:52,982 - dsql_hybrid_manager - INFO - Initialized DSQL Hybrid Connection Manager with 2 endpoints
2025-05-21 19:03:54,055 - dsql_hybrid_manager - INFO - Route 53 health check a4709bfe-bc41-4afc-9f55-4919ee884b7c: 16/16 healthy observations
2025-05-21 19:03:54,055 - dsql_hybrid_manager - INFO - Route 53 health check a4709bfe-bc41-4afc-9f55-4919ee884b7c: Healthy
2025-05-21 19:03:55,011 - dsql_hybrid_manager - INFO - Route 53 health check 46eca8a2-6a07-43e6-94fb-21f95fb11d5a: 16/16 healthy observations
2025-05-21 19:03:55,011 - dsql_hybrid_manager - INFO - Route 53 health check 46eca8a2-6a07-43e6-94fb-21f95fb11d5a: Healthy
2025-05-21 19:03:55,011 - dsql_hybrid_manager - INFO - Found 2 healthy endpoints out of 2
2025-05-21 19:03:55,057 - dsql_hybrid_manager - INFO - Endpoint latency comparison:
2025-05-21 19:03:55,057 - dsql_hybrid_manager - INFO - 1. xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws - Latency: 0.002422s, Priority: 1, Region: us-east-2
2025-05-21 19:03:55,057 - dsql_hybrid_manager - INFO - 2. yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws - Latency: 0.012726s, Priority: 2, Region: us-east-1
2025-05-21 19:03:55,057 - dsql_hybrid_manager - INFO - Selected best endpoint: xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws (latency: 0.002422s, priority: 1)
2025-05-21 19:03:55,058 - main - INFO - Best endpoint selected: xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws (latency: 0.002422s)
2025-05-21 19:03:55,058 - main - INFO - Health check ID: a4709bfe-bc41-4afc-9f55-4919ee884b7c
2025-05-21 19:03:55,058 - dsql_hybrid_manager - INFO - Found 2 healthy endpoints out of 2
2025-05-21 19:03:55,100 - dsql_hybrid_manager - INFO - Generating DSQL admin auth token for xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws in us-east-2
2025-05-21 19:03:55,101 - dsql_hybrid_manager - INFO - Generated token preview: jiabuacbso...a4e75aa0f9
2025-05-21 19:03:55,101 - dsql_hybrid_manager - INFO - Connecting to xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws (latency: 0.001538s, region: us-east-2, priority: 1)
2025-05-21 19:03:55,344 - dsql_hybrid_manager - INFO - Successfully connected to xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws
2025-05-21 19:03:55,344 - main - INFO - Connected to: xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws
2025-05-21 19:03:55,344 - main - INFO - Running query iteration 1/1
2025-05-21 19:03:55,451 - main - INFO - Result: ('PostgreSQL 16',)
2025-05-21 19:03:55,451 - main - INFO - Query execution time: 106.33ms
2025-05-21 19:03:55,451 - main - INFO - Average query execution time over 1 iterations: 106.33ms
2025-05-21 19:03:55,451 - main - INFO - Connection closed
2025-05-21 19:03:55,452 - main - INFO -
=== STEP 2: Simulating failure of the primary endpoint's health check: a4709bfe-bc41-4afc-9f55-4919ee884b7c ===
2025-05-21 19:03:55,627 - main - INFO - Disabled health check a4709bfe-bc41-4afc-9f55-4919ee884b7c to simulate failure
2025-05-21 19:03:55,628 - main - INFO - Waiting 60 seconds for health check status to propagate...
2025-05-21 19:04:55,674 - main - INFO -
=== STEP 3: Testing connection with primary endpoint health check failure ===
2025-05-21 19:04:55,674 - dsql_hybrid_manager - INFO - Loaded configuration from dsql_config_with_healthchecks.json
2025-05-21 19:04:55,684 - dsql_hybrid_manager - INFO - Initialized DSQL Hybrid Connection Manager with 2 endpoints
2025-05-21 19:04:55,796 - dsql_hybrid_manager - ERROR - Error checking Route 53 health status for a4709bfe-bc41-4afc-9f55-4919ee884b7c: An error occurred (InvalidInput) when calling the GetHealthCheckStatus operation: Invalid parameter : The specified health check has a special status of always healthy. GetHealthCheckStatus can't return the status of one of these special health checks.
2025-05-21 19:04:56,797 - dsql_hybrid_manager - INFO - Route 53 health check 46eca8a2-6a07-43e6-94fb-21f95fb11d5a: 16/16 healthy observations
2025-05-21 19:04:56,797 - dsql_hybrid_manager - INFO - Route 53 health check 46eca8a2-6a07-43e6-94fb-21f95fb11d5a: Healthy
2025-05-21 19:04:56,797 - dsql_hybrid_manager - INFO - Found 1 healthy endpoints out of 2
2025-05-21 19:04:56,837 - dsql_hybrid_manager - INFO - Endpoint latency comparison:
2025-05-21 19:04:56,837 - dsql_hybrid_manager - INFO - 1. yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws - Latency: 0.013187s, Priority: 2, Region: us-east-1
2025-05-21 19:04:56,837 - dsql_hybrid_manager - INFO - Selected best endpoint: yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws (latency: 0.013187s, priority: 2)
2025-05-21 19:04:56,837 - main - INFO - Best endpoint selected: yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws (latency: 0.013187s)
2025-05-21 19:04:56,837 - main - INFO - Health check ID: 46eca8a2-6a07-43e6-94fb-21f95fb11d5a
2025-05-21 19:04:56,878 - dsql_hybrid_manager - ERROR - Error checking Route 53 health status for a4709bfe-bc41-4afc-9f55-4919ee884b7c: An error occurred (InvalidInput) when calling the GetHealthCheckStatus operation: Invalid parameter : The specified health check has a special status of always healthy. GetHealthCheckStatus can't return the status of one of these special health checks.
2025-05-21 19:04:56,879 - dsql_hybrid_manager - INFO - Found 1 healthy endpoints out of 2
2025-05-21 19:04:56,918 - dsql_hybrid_manager - INFO - Generating DSQL admin auth token for yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws in us-east-1
2025-05-21 19:04:56,919 - dsql_hybrid_manager - INFO - Generated token preview: e4abuacbso...238cb4c5fe
2025-05-21 19:04:56,919 - dsql_hybrid_manager - INFO - Connecting to yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws (latency: 0.011756s, region: us-east-1, priority: 2)
2025-05-21 19:04:57,234 - dsql_hybrid_manager - INFO - Successfully connected to yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws
2025-05-21 19:04:57,234 - main - INFO - Connected to: yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws
2025-05-21 19:04:57,234 - main - INFO - Running query iteration 1/1
2025-05-21 19:04:57,368 - main - INFO - Result: ('PostgreSQL 16',)
2025-05-21 19:04:57,368 - main - INFO - Query execution time: 133.73ms
2025-05-21 19:04:57,368 - main - INFO - Average query execution time over 1 iterations: 133.73ms
2025-05-21 19:04:57,368 - main - INFO - Connection closed
2025-05-21 19:04:57,369 - main - INFO - Failover successful! Switched from xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws to yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws
2025-05-21 19:04:57,369 - main - INFO -
=== STEP 4: Restoring original health check configuration ===
2025-05-21 19:04:57,500 - main - INFO - Re-enabled health check a4709bfe-bc41-4afc-9f55-4919ee884b7c
2025-05-21 19:04:57,502 - main - INFO - Waiting 60 seconds for health check status to propagate...
2025-05-21 19:05:57,553 - main - INFO -
=== STEP 5: Testing connection after restoring health check ===
2025-05-21 19:05:57,554 - dsql_hybrid_manager - INFO - Loaded configuration from dsql_config_with_healthchecks.json
2025-05-21 19:05:57,561 - dsql_hybrid_manager - INFO - Initialized DSQL Hybrid Connection Manager with 2 endpoints
2025-05-21 19:05:58,571 - dsql_hybrid_manager - INFO - Route 53 health check a4709bfe-bc41-4afc-9f55-4919ee884b7c: 16/16 healthy observations
2025-05-21 19:05:58,571 - dsql_hybrid_manager - INFO - Route 53 health check a4709bfe-bc41-4afc-9f55-4919ee884b7c: Healthy
2025-05-21 19:05:59,775 - dsql_hybrid_manager - INFO - Route 53 health check 46eca8a2-6a07-43e6-94fb-21f95fb11d5a: 16/16 healthy observations
2025-05-21 19:05:59,775 - dsql_hybrid_manager - INFO - Route 53 health check 46eca8a2-6a07-43e6-94fb-21f95fb11d5a: Healthy
2025-05-21 19:05:59,775 - dsql_hybrid_manager - INFO - Found 2 healthy endpoints out of 2
2025-05-21 19:05:59,815 - dsql_hybrid_manager - INFO - Endpoint latency comparison:
2025-05-21 19:05:59,815 - dsql_hybrid_manager - INFO - 1. xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws - Latency: 0.001920s, Priority: 1, Region: us-east-2
2025-05-21 19:05:59,815 - dsql_hybrid_manager - INFO - 2. yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws - Latency: 0.011219s, Priority: 2, Region: us-east-1
2025-05-21 19:05:59,815 - dsql_hybrid_manager - INFO - Selected best endpoint: xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws (latency: 0.001920s, priority: 1)
2025-05-21 19:05:59,815 - main - INFO - Best endpoint selected: xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws (latency: 0.001920s)
2025-05-21 19:05:59,815 - main - INFO - Health check ID: a4709bfe-bc41-4afc-9f55-4919ee884b7c
2025-05-21 19:05:59,815 - dsql_hybrid_manager - INFO - Found 2 healthy endpoints out of 2
2025-05-21 19:05:59,862 - dsql_hybrid_manager - INFO - Generating DSQL admin auth token for.dsql.us-east-2.on.aws in us-east-2
2025-05-21 19:05:59,864 - dsql_hybrid_manager - INFO - Generated token preview: jiabuacbso...f42f2e31ea
2025-05-21 19:05:59,865 - dsql_hybrid_manager - INFO - Connecting to xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws (latency: 0.001445s, region: us-east-2, priority: 1)
2025-05-21 19:06:00,099 - dsql_hybrid_manager - INFO - Successfully connected to xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws
2025-05-21 19:06:00,099 - main - INFO - Connected to: xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws
2025-05-21 19:06:00,099 - main - INFO - Running query iteration 1/1
2025-05-21 19:06:00,210 - main - INFO - Result: ('PostgreSQL 16',)
2025-05-21 19:06:00,210 - main - INFO - Query execution time: 110.73ms
2025-05-21 19:06:00,210 - main - INFO - Average query execution time over 1 iterations: 110.73ms
2025-05-21 19:06:00,211 - main - INFO - Connection closed
2025-05-21 19:06:00,211 - main - INFO -
=== ROUTE 53 FAILOVER TEST SUMMARY ===
2025-05-21 19:06:00,211 - main - INFO - Primary endpoint: xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws
2025-05-21 19:06:00,212 - main - INFO - Failover endpoint: yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws
2025-05-21 19:06:00,212 - main - INFO - Restored endpoint: xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws
2025-05-21 19:06:00,212 - main - INFO - RESULT: Route 53 failover test SUCCESSFUL!
アプリケーションでの DSQL 接続マネージャーの使用
hybrid_failover_approach.py ファイルを入手したら、アプリケーションへの統合は簡単です。接続マネージャーは、データベース接続のドロップイン置換として設計されており、バックグラウンドプロセスや複雑なセットアップは必要ありません。
次のコードは、アプリケーションで接続マネージャーを使用する方法の一般的な例です。
from hybrid_failover_approach import DSQLHybridConnectionManager
# アプリケーション起動時に一度初期化
db_manager = DSQLHybridConnectionManager(config_file="dsql_config_with_healthchecks.json")
# 接続が必要な場所で使用
conn = db_manager.get_connection("postgres", "admin")
まず、dsql_config_with_healthchecks.json ファイルを変更して DSQL エンドポイントを設定します。
次のコードは、Flask アプリケーションでの実際の例を示しています。
from flask import Flask, jsonify
from hybrid_failover_approach import DSQLHybridConnectionManager
app = Flask(__name__)
db_manager = DSQLHybridConnectionManager(config_file="dsql_config_with_healthchecks.json")
@app.route('/users')
def get_users():
# 最速で最も正常なエンドポイントに自動的に接続
conn = db_manager.get_connection("postgres", "admin")
try:
with conn.cursor() as cursor:
cursor.execute("SELECT id, name, email FROM users")
return jsonify(cursor.fetchall())
finally:
conn.close()
このアプローチの美しさはそのシンプルさにあります。バックグラウンドプロセスや複雑なインフラストラクチャを管理することなく、インテリジェントなルーティング、自動フェイルオーバー、ヘルス監視を実現できます。これは、DSQL クラスターに接続するためのよりスマートな方法です。
クリーンアップ
ヘルスチェックを削除するには、セットアップ中に設定ファイルに追加されたヘルスチェック ID を使用して AWS CLI を使用します。
aws route53 delete-health-check --health-check-id <health-check-id>
ヘルスチェック ID は、dsql_config_with_healthchecks.json ファイルの各エンドポイントの health_check_id フィールドで確認できます。設定内の各ヘルスチェック ID に対して削除コマンドを実行します。
ヘルスチェック設定
DSQL 接続マネージャーでヘルスチェックの頻度をカスタマイズできます。
health_check_ttl=60, # ヘルスチェック結果を 60 秒間キャッシュ
health_check_ttl パラメータは、指定された期間ヘルスチェック結果をキャッシュします。低い値 (< 60 秒) はより高速なフェイルオーバーを可能にしますが、Route 53 への API コールが増加します。一方、高い値は API 負荷を軽減しますが、問題の検出が遅れる可能性があります。60 秒から始めて、必要に応じて調整してください。
まとめ
この記事では、自動クロスリージョン接続フェイルオーバーサポートを備えた Aurora DSQL 接続を管理する効果的な方法を提供するカスタムソリューションについて説明しました。このソリューションをデプロイすることで、最適なパフォーマンスと可用性を維持しながら、アプリケーションに信頼性の高いデータベース接続を提供できます。
ご自身のユースケースでこのソリューションを試して、コメントでフィードバックを共有してください。
著者について
Rajesh Kantamani Rajesh は、シニアデータベーススペシャリストソリューションアーキテクトです。お客様と協力して、Amazon Web Services 上でデータベースソリューションの設計、移行、最適化を行い、スケーラビリティ、セキュリティ、パフォーマンスに焦点を当てています。分散データベースへの情熱を持ち、組織がデータインフラストラクチャを変革するのを支援しています。
Sukhpreet Kaur Bedi Sukhpreet は、Amazon RDS/Aurora PostgreSQL エンジンに焦点を当てた AWS のシニアデータベーススペシャリストソリューションアーキテクトです。お客様が高可用性でスケーラブル、かつ安全なデータベースアーキテクチャを構築することで、AWS プラットフォーム上でイノベーションを起こすのを支援しています。
Raluca Constantin Raluca は、Amazon Aurora DSQL を専門とする AWS のシニアデータベースエンジニアです。18 年間のデータベース専門知識は、Oracle、MySQL、PostgreSQL、クラウドネイティブソリューションにわたり、データベースのスケーラビリティ、パフォーマンス、リアルタイムデータ処理に焦点を当てています。