本記事は、2025 年 6 月 20 日に公開された Implement a rollback strategy for Amazon Aurora PostgreSQL upgrades using Amazon RDS Blue/Green deployments を翻訳したものです。翻訳は Cloud Support Engineer の野島 正就が担当しました。 Amazon Aurora PostgreSQL 互換エディション は、高いパフォーマンスと可用性を実現するために設計されたフルマネージドのリレーショナルデータベースエンジンで、更新時のダウンタイムの削減とリスクの最小化を支援する マネージドなブルー/グリーンデプロイ をサポートしています。ブルー/グリーンデプロイは、論理レプリケーションを使用してフルマネージドのステージング環境を作成し、本番環境の変更を安全にデプロイおよびテストできるようにします。ブルー環境は現在の本番データベースです。グリーン環境には必要な更新や変更が含まれていますが、アプリケーションエンドポイントを変更する必要はありません。このアプローチにより、エンジンバージョンのアップグレードやシステムパッチなどの更新に伴うリスクとダウンタイムを最小限に抑えることができます。検証が完了したら、アプリケーションエンドポイントの変更なしにグリーン環境をシームレスに本番環境に昇格させることができます。 非本番環境で入念に計画とテストを行ったとしても、バージョンアップグレード後に予期しない問題が発生することがあります。例えば、新しいスキーマ変更がステージング環境では完璧に動作しても、本番環境では実際のデータパターンの違いやテスト中に実行されなかったアプリケーションクエリが原因でエラーが発生する場合があります。また、実際のトラフィックやワークロードによってパフォーマンスが低下することもあります。このような場合、サービスの安定性を迅速に復旧するためにロールバック計画を用意しておくことが不可欠です。ブルー/グリーンデプロイ機能には現在組み込みのロールバック機能はありませんが、バージョン管理のための代替ソリューションを実装することができます。 この記事では、Amazon RDS ブルー/グリーンデプロイの切り替え後に、セルフマネージドな論理レプリケーションを使用してロールバッククラスターを手動でセットアップし、新しいバージョンとの同期を維持する方法を紹介します。ロールバッククラスターは、元のバージョンに戻す必要がある場合のバックアップオプションとして機能します。 ソリューションの概要 次の図は、このソリューションの高レベルなワークフローを示しています。 スイッチオーバーの前には、2 つのクラスターがあります: ブルークラスター – 既存の本番データベースクラスター グリーンクラスター – ブルークラスターからミラーリングおよび同期されたステージング環境 スイッチオーバー後、3 つのクラスターが存在します: 旧ブルークラスター – 元の本番クラスター (以前のブルークラスター) 新ブルークラスター – 本番クラスターの新バージョンで、ワークロードが実行される場所 (以前のグリーンクラスター) ブループライマリ (ロールバック) クラスター – 旧ブルークラスターのクローンで、新ブルークラスターのデータと同期されたもの (ロールバッククラスターとして使用されます) ワークフローのステップは以下のとおりです: ブルー/グリーンデプロイを作成 します ブルークラスターへのトラフィックを停止し グリーンクラスターへのスイッチオーバーを実行 します ブルー/グリーンデプロイを削除 します 旧ブルークラスターを クローン して、ブループライマリ (ロールバック) クラスターを作成します 新しいブルークラスターからブループライマリ (ロールバック) クラスターへの論理レプリケーションを設定します 新しいブルークラスターへのトラフィックを開始します この記事では、 Amazon Aurora PostgreSQL 互換エディション のメジャーバージョンアップグレード (バージョン 15.10 から 16.6 へ) をシミュレーションします。 制限事項 Aurora ブルー/グリーンデプロイは DDL、シーケンス、マテリアライズドビューのリフレッシュ、ラージオブジェクトの作成や変更、プライマリキーのないテーブルでのデータの更新や削除をレプリケートしません。詳細については、 Amazon Aurora のブルー/グリーンデプロイの制限と考慮事項 を参照してください。 Aurora ブルー/グリーンデプロイはスイッチオーバー後にプライマリクラスターエンドポイントを自動的に管理しますが、以前のバージョンへのロールバックが必要な場合は、アプリケーションまたは DNS レベルでエンドポイントの変更を処理する必要があります。 ロールバッククラスターのセットアップには追加のダウンタイムが発生します。 前提条件 このソリューションを実装するには、以下のコンポーネントが必要です: ブルー/グリーンデプロイのサポート – 既存の Aurora クラスターのバージョンがブルー/グリーンデプロイをサポートしていることを確認します。詳細については、 データベース更新のために Amazon RDS ブルー/グリーンデプロイを使用する および New – Fully managed Blue/Green Deployment in Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL を参照してください。 ソースデータベースクラスター (この記事では Aurora PostgreSQL v15) で論理レプリケーションを有効にします。 必要に応じてブルー/グリーンデプロイをサポートするバージョンへのインプレースマイナーバージョンアップグレードを 1 回実行します。 AWS CLI による操作。 注意: 論理レプリケーションパラメータを有効にするには、ライターインスタンスの再起動が必要です。詳細については、 Aurora PostgreSQL DB クラスターの論理レプリケーションの設定 を参照してください。 新しいバージョンのデータベース用のクラスターパラメータグループ : 新しいバージョンから古いバージョンへの論理レプリケーションを設定するため、新しいバージョン (Aurora PostgreSQL 16) で論理レプリケーションが有効になっていることを確認する必要があります。以下の AWS CLI コマンドでクラスターパラメータグループを作成し、論理レプリケーションパラメータを有効にします。 aws rds create-db-cluster-parameter-group \ --db-cluster-parameter-group-name pg16-blue-green \ --db-parameter-group-family aurora-postgresql16 \ --description "Parameter group that contains logical replication settings for Aurora PG 16" aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name pg16-blue-green \ --parameters "ParameterName='rds.logical_replication',ParameterValue=1,ApplyMethod=pending-reboot" Aurora のクローン機能については Amazon Aurora DB クラスターのボリュームのクローン作成 を参照してください。 ブルー/グリーンデプロイの作成 Amazon RDS ブルー/グリーンデプロイは AWS によって管理されます。内部的には、ブルー環境からグリーン環境にリソースを作成してミラーリングし、ネイティブの論理レプリケーションを使用してブルー環境からグリーン環境に DML の変更をレプリケートします。 AWS コマンドラインインターフェイス (AWS CLI) を使用して、以下のコマンドで RDS ブルー/グリーンデプロイを作成できます。ここで source は本番データベースの Amazon Resource Name (ARN) です。以下の RDS コンソールのスクリーンショットは、論理レプリケーションが有効になっている既存のクラスター (ブルークラスター) を示しています。 以下のコマンドを使用して、Amazon Aurora PostgreSQL バージョン 16 のグリーンクラスターを持つブルー/グリーンデプロイを作成します。グリーンクラスターには、事前に作成した論理レプリケーション用の適切なパラメータグループをアタッチする必要があります。 aws rds create-blue-green-deployment \ --blue-green-deployment-name my-blue-green-deployment \ --source arn:aws:rds: {REGION} : {ACCOUNT_NUMBER} :cluster: {CLUSTER_ID} \ --target-engine-version 16.6 \ --target-db-cluster-parameter-group-name pg16-blue-green すべてのインスタンスが利用可能になると、ブルークラスターとグリーンクラスターの両方がアタッチされたブルー/グリーンデプロイが完成します。 トラフィックの停止とスイッチオーバーの実行 グリーンクラスターを昇格させるには、 スイッチオーバー アクションを開始する必要があります。スイッチオーバーを開始する前に、ブループライマリの作成中のデータ整合性を確保するために、ブルークラスターのデータベーストラフィックを停止してください。VPC セキュリティグループを使用して、インバウンドおよびアウトバウンドのデータベーストラフィックをブロックできます。スイッチオーバーが完了したら、RDS ブルー/グリーンデプロイの更新されたラベルを確認してください。 aws rds switchover-blue-green-deployment \ --blue-green-deployment-identifier {BG_RESOURCE_ID} \ --switchover-timeout "300" ブルー/グリーンデプロイの削除 ブループライマリ (ロールバック) クラスターを設定する前に、ブルー/グリーンデプロイを削除する必要があります。RDS ブルー/グリーンデプロイを削除すると、マネージド環境からクラスターが解放され、Amazon RDS ブルー/グリーンデプロイによって生成されたレプリケーションスロット、パブリケーション、サブスクリプション、論理レプリケーションコンポーネントなどのオブジェクトがクリーンアップされます。 aws rds delete-blue-green-deployment \ --blue-green-deployment-identifier {BG_RESOURCE_ID} \ --no-delete-target 次のスクリーンショットに示すように、apg-blue-green-demo (v16.6) と apg-blue-green-demo-old1 (v15.10) の 2 つの独立したクラスターが作成されました。 新しいブルークラスターをクローンしてブループライマリ (ロールバック) クラスターを作成 コンプライアンスや監査の目的で、元のブルークラスターを保持する必要がある場合があります。ロールバッククラスターをセットアップするには: 元のブルークラスターをクローンしてセルフマネージドのブループライマリ (ロールバック) クラスターを作成します 利用可能になったら、クローンしたクラスターで簡単な読み取り専用クエリを実行して、クラスターとデータへのアクセスを確認します ロールバックが必要になった場合に備えて、DNS またはアプリケーションのエンドポイント更新用にブループライマリ (ロールバック) クラスターのエンドポイントを記録します aws rds restore-db-cluster-to-point-in-time \ --db-cluster-identifier "apg15-blue-prime" \ --restore-type copy-on-write \ --use-latest-restorable-time \ --source-db-cluster-identifier "apg-blue-green-demo-old1" \ --db-subnet-group-name " {DB_SUBNET} " \ --vpc-security-group-ids " {VPC_SECUITY_GROUP} " \ --db-cluster-parameter-group-name " pg15-blue-green " aws rds create-db-instance \ --db-instance-identifier "apg15-blue-prime" \ --db-instance-class "db.r6g.large" \ --db-cluster-identifier "apg15-blue-prime" \ --engine "aurora-postgresql" \ --engine-version "15.10" 次のスクリーンショットに示すように、ロールバック先となる新しい復元クラスター「apg15-blue-prime」を作成しました。 ブループライマリ (ロールバック) クラスターのセットアップ ブループライマリのクローンが完了したら、新しいブルークラスター (パブリッシャー) からブループライマリクラスター (サブスクライバー) へのセルフマネージドな論理レプリケーションを設定します。データ同期の問題を防ぐため、書き込みアクティビティやスキーマ変更が行われないようにしてください。 新しいブルークラスター (パブリッシャー) で、クラスターエンドポイントを使用してデータベースに接続し、新しいパブリケーションを作成します: CREATE PUBLICATION publication_name FOR ALL TABLES ; 重要 : 各テーブルにレプリケーションアイデンティティ (プライマリキーやユニークキーなど) があることを確認してください。同じクラスターに複数のデータベースがある場合は、新しく昇格した本番クラスター (新しいブルークラスター) の各データベースに対して以下の手順を繰り返してください。 新しいブルークラスター (パブリッシャー) で、クラスターエンドポイントに接続し、以下のコマンドを使用して ‘pgoutput’ プラグインを使用したレプリケーションスロットを作成します: SELECT pg_create_logical_replication_slot(' replication_slot_name ', 'pgoutput'); ブループライマリクラスター (サブスクライバー) で、以下のコマンドを使用して、データのコピーや新しいスロットの作成を行わずに新しいサブスクリプションを作成します: CREATE SUBSCRIPTION subscription_name CONNECTION 'postgres:// admin_user_name : admin_user_password @ source_instance_URL / database ' PUBLICATION publication_name WITH (copy_data = false, create_slot = false, enabled = false, connect = true, slot_name = ' replication_slot_name '); このコードには以下のパラメータが必要です: subscription_name – サブスクリプションの名前 admin_user_name – rds_superuser 権限を持つ管理ユーザーの名前 admin_user_password – 管理ユーザーに関連付けられたパスワード source_instance_URL – パブリケーションサーバーインスタンスの URL database – サブスクリプションサーバーが接続するデータベース publication_name – パブリケーションサーバーの名前 replication_slot_name – ステップ 2 で作成したレプリケーションスロットの名前 重要 : ブループライマリクラスター上のすべてのパブリケーション (ステップ 1) に対して、この作業を繰り返す必要があります。 ブループライマリクラスターで、以下のコマンドを使用してサブスクリプションを有効にします: ALTER SUBSCRIPTION subscription_name ENABLE ; 重要 : ブループライマリクラスター上のすべてのサブスクリプションに対して、この作業を繰り返す必要があります。 論理レプリケーションのセットアップが完了し、新しいブルークラスターからブループライマリクラスターへのデータフローを確認した後、既存のクラスターエンドポイントを使用して新しいブルークラスターへのトラフィックを再開できます。Amazon RDS ブルー/グリーンデプロイが DNS の変更を自動的に処理するため、アプリケーションは同じエンドポイントを引き続き使用できます。 ブループライマリクラスターへのロールバック ブループライマリクラスター (元のバージョン) にロールバックする必要がある場合は、以下の手順に従ってください。 移行中のデータ整合性を維持するためにアプリケーショントラフィックを停止します (Amazon Aurora VPC セキュリティグループを使用して受信トラフィックをブロックできます) アプリケーションまたは DNS レコードを更新して、ブループライマリクラスターのエンドポイントを指すようにします ブループライマリクラスターのサブスクリプションを削除します 該当する場合はシーケンス値を手動で更新します この切り替えは自動ではありません。ブループライマリクラスターはマネージドサービスの管理下にないためです。実行時のエラーを最小限に抑えるために、ロールバック手順のランブックまたは自動化スクリプトを作成することをお勧めします。 この戦略はロールバックオプションを提供しますが、ブループライマリクラスターのセットアップ時に追加のダウンタイムが発生します。このアプローチを実装する際に考慮すべきトレードオフであり、本番環境に移行する前にステージング環境で十分にテストすることを推奨します。 クリーンアップ 本番環境では、すべてのアプリケーションが正常に移行されたことを検証する間、新しいブループライマリクラスターを維持する必要があります。両方の環境を同時に稼働させておくことで、新しいインフラストラクチャで何か不整合や予期しない動作が発生した場合にロールバックできることが保証されます。コンプライアンス目的で旧ブルークラスターをバックアップした後、コスト削減のためにクラスターを削除できます。すべてのクラスターは削除されるまで課金されます。 テスト目的でこれらのリソースを作成した場合は、追加料金が発生しないように、すべてのクラスター (ブルー、グリーン、ブループライマリ) を削除する必要があります。データベースクラスターをクリーンアップするには、以下の手順を実行してください。 リードレプリカインスタンスがあれば、 それぞれを削除します。 プライマリインスタンスを削除します。 データベースクラスターを削除します。 まとめ この記事では、Amazon RDS ブルー/グリーンデプロイを使用してデータベースバージョンのアップグレードを行う際のロールバック戦略の作成方法を紹介しました。安全性を高めるために、ロールバック戦略として論理レプリケーションを設定しました。ブルー/グリーンデプロイは、ミラーリングされた同期済みのデータベースステージングバージョンの作成、ガードレールチェックの実行、スイッチオーバーの実施、DNS 変更の自動化など、多くの複雑なタスクを自動的に処理します。しかし、本番データベースの変更には、アプリケーションの非互換性などのリスクが伴う可能性があります。ロールバッククラスターを設定しておくことで、アップグレード後に問題が発生した場合に迅速にフォールバックできる追加の安全策が得られます。問題が解決されるまで、以前の本番バージョンに戻すことができます。 本番ワークロードを切り替える前に、本番レベルの負荷をかけた状態で新しいデータベースバージョンに対してアプリケーションを十分にテストしてください。アプリケーションが完全に互換性があり、パフォーマンスが安定していることを確認してください。これにより、ブルー/グリーンデプロイの切り替え後にアプリケーションの問題やパフォーマンス低下が発生する可能性を大幅に減らすことができます。このロールバック戦略を実装する前に、 RDS ブルー/グリーンデプロイ の仕組みと機能について確認することから始めることをお勧めします。 Chirag Dave Chirag は マネージドな PostgreSQL を専門とする Amazon Web Services のプリンシパルソリューションアーキテクトです。セキュリティ、コスト、パフォーマンス、信頼性、効率的なオペレーション、アーキテクチャについてのベストプラクティスを通じてお客様と技術的な関係を構築しています。 Kovan Chandra Kovan は PostgreSQL データベースを専門とする Amazon Web Services (AWS) のテクニカルアカウントマネージャーです。エンタープライズサポートのお客様と協業し、クラウドにおけるカスタマージャーニー、セキュリティ、レジリエンシー、コスト削減、およびオペレーショナルエクセレンスの改善に取り組んでいます。 Daxeshkumar Patel Daxeshkumar は Amazon Web Services (AWS) のソリューションアーキテクトであり、主要なクラウド案件においてお客様やパートナーと密接に連携しています。概念実証（PoC）プロジェクトの設計・提供、実装支援、および AWS サービスを活用したアプリケーションの構築・移行を支援しています。データ処理、分散コンピューティングソリューション、そしてお客様が AWS クラウドを効果的に活用できるようにすることに注力しています。 Kamal Singh Kamal は Amazon Web Services (AWS) のシニアデリバリーコンサルタントです。データベースの移行およびモダナイゼーションプログラムに重点を置き、お客様やパートナーの AWS クラウドへの移行を支援しています。 Jinesh Shah Jinesh は Amazon Web Services (AWS) のデリバリーコンサルタントです。レガシーデータベースおよびアプリケーションのモダンな AWS プラットフォームへの移行を支援しています。データ処理、分散コンピューティングソリューション、そしてお客様が AWS クラウドを効果的に活用できるようにすることに注力しています。

本記事は 2026 年 5 月 19 日 に公開された「 Automated JDBC query caching with the AWS Advanced JDBC Wrapper 」を翻訳したものです。 データベース負荷の大半を読み取りクエリが占めている場合、元データがほとんど変化しない場合でもレスポンスタイムが悪化し、コストが増加します。従来の対策はカスタムキャッシュレイヤーの構築ですが、クエリごとに外部キャッシュロジックを実装し、シリアライゼーションを処理し、データベースとの整合性を維持する必要があります。ビジネス機能の開発に割くべきリソースを大きく消費します。 本日、AWS Advanced JDBC Wrapper 向けの Remote Query Cache Plugin を発表します。クエリキャッシュを自動的に処理し、JDBC クエリをインターセプトして結果を Amazon ElastiCache for Valkey にキャッシュし、以降の同一クエリをキャッシュから提供します。アプリケーション側の変更はクエリに SQL ヒントを付加するだけです。 本記事では、Amazon CloudWatch Database Insights を使用してキャッシュ対象のクエリを特定する方法、Java アプリケーションで Remote Query Cache Plugin を設定する方法、Amazon CloudWatch でキャッシュの効果をモニタリングする方法を説明します。 外部キャッシュ実装の課題 データベースアプリケーションにキャッシュを追加する場合、通常 3 つの大きな障壁があります。 アプリケーションの複雑な改修: 既存アプリケーションにキャッシュを追加しようとする場合、サービスコードメソッドへのアノテーション、キャッシュパラメータの設定、別設定ファイルでの TTL 管理など、アプリケーション層での変更が必要です。変更はコードベース全体に広がり、特定のフレームワークに依存する場合があります。 新しい API とパターンの習得: キャッシュの統合には、新しいクライアントライブラリの習得、シリアライゼーションフレームワークの理解、キャッシュ障害時のエラーハンドリングの実装が必要です。既存のデータベースコードを維持しながら、これらの技術に習熟する必要があります。 キャッシュ管理の複雑さ: キャッシュの無効化、キャッシュサーバーの適切なサイジング、一貫したキャッシュキーの生成、キャッシュヒット率のモニタリング、キャッシュサーバーがダウンした時の安全な障害処理を手動で管理する必要があります。 結果として、キャッシュロジック構築に多大なリソースを投じるか、データベースコストの増大とパフォーマンス低下を許容するかの選択を迫られます。 AWS Advanced JDBC Wrapper Remote Query Cache Plugin による課題の解決 Remote Query Cache Plugin を使用すると、既存の PostgreSQL、MySQL、MariaDB アプリケーションにクエリ結果キャッシュを統合できます。プラグインはアプリケーションに対して透過的に動作し、自身でキャッシュレイヤーを構築するオーバーヘッドがありません。 キャッシュ対象のクエリに SQL ヒントを追加するだけで済みます。プラグインは Amazon ElastiCache for Valkey の確認、ミス処理、結果のシリアライゼーション、キャッシュへの自動格納を透過的に行います。 プラグインは既存の JDBC インターフェース経由で動作します。Spring Data JPA、Hibernate、Spring JDBC Template、ネイティブ JDBC など、使い慣れたパターンをそのまま使い続けられます。Valkey クライアント、シリアライゼーション、エラーハンドリングはプラグインがバックグラウンドで管理します。 プラグインはキャッシュキーを自動生成し、設定可能な TTL (time-to-live) 値で有効期限を管理し、キャッシュが利用不可の場合はデータベースクエリにフォールバックします。独自の計測コードを追加せずに Amazon CloudWatch へメトリクスを送信してモニタリングできます。 アーキテクチャ概要 Remote Query Cache Plugin のリードスルーキャッシュの動作を次の図に示します。 図 1: Java アプリケーション、Amazon ElastiCache for Valkey、Amazon Aurora または Amazon RDS 間の Remote Query Cache Plugin リードスルーキャッシュフロー 動作の仕組み: アプリケーションがキャッシュヒント ( /* CACHE_PARAM(ttl=<duration>) */ ) 付きのクエリを実行します。 プラグインがクエリに一致するキャッシュ結果を ElastiCache で確認します。 キャッシュヒット (3a): 結果がマイクロ秒単位でプラグインに返され、ステップ 4 と 5 はスキップします。 キャッシュミス (3b): プラグインがクエリを Aurora/RDS データベースに転送します。 データベースがクエリを実行し、最新の結果をプラグインに返します。 プラグインが結果を非同期で ElastiCache に格納し、以降のリクエストに備えます。 プラグインが結果をアプリケーションに返します。 プラグインは初回アクセス時にキャッシュを格納するため、アプリケーションロジックの変更は最小限で、SQL ヒントの設定のみで済みます。 キャッシュ対象クエリの特定方法 すべてのクエリがキャッシュの恩恵を受けるわけではありませんが、まず着目すべきは頻繁に実行されデータベース負荷に大きく影響を与える SELECT 文です。通常、大規模なデータセットを集計または結合して小さく安定した結果セットを返すクエリが該当します。 Amazon Relational Database Service (Amazon RDS) と Amazon Aurora で稼働するデータベースの場合、 CloudWatch Database Insights を使用してこれらのクエリを特定できます。 describe-dimension-keys CLI コマンドは、 db.load.avg 順にランク付けされた上位 SQL 文を返します。このメトリクスは平均アクティブセッション数を測定し、各クエリがどの程度データベースキャパシティを消費しているかを示します。 データベース負荷による上位 SELECT 文の特定 INSTANCE_ID="<your-db-instance-identifier>" REGION="<your-aws-region>" aws pi describe-dimension-keys \ --service-type RDS \ --identifier $(aws rds describe-db-instances \ --db-instance-identifier "${INSTANCE_ID}" \ --query "DBInstances[0].DbiResourceId" \ --output text \ --region "${REGION}") \ --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \ --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \ --metric db.load.avg \ --group-by '{"Group":"db.sql_tokenized","Dimensions":["db.sql_tokenized.statement"],"Limit":20}' \ --region "${REGION}" \ --query 'sort_by(Keys[?starts_with(Dimensions."db.sql_tokenized.statement",`SELECT`) || starts_with(Dimensions."db.sql_tokenized.statement",`select`)], &Total) | reverse(@) | [*].{Load:Total, SQL:Dimensions."db.sql_tokenized.statement"}' \ --output table このコマンドは結果を SELECT 文のみにフィルタリングし、 db.load.avg の降順でソートします。 db.load.avg の値は、対象時間ウィンドウにおけるそのクエリの平均アクティブセッション数です。値が 0.42 の場合、そのクエリが平均して 1 つのアクティブデータベースセッションの 42% を占めていたことを意味します。リストの上位にあるクエリほどデータベースキャパシティを多く消費しており、キャッシュの有力な候補です。 出力例 通常のトラフィック下で稼働する EC サイトアプリケーションを考えてみましょう。コマンドは次のような出力を返す可能性があります。 ----------------------------------------------------------- | DescribeDimensionKeys | +--------+------------------------------------------------+ | Load | SQL | +--------+------------------------------------------------+ | 0.42 | SELECT p.id, p.name, p.price, c.name AS category, ... | | 0.18 | SELECT u.id, u.name, u.email, u.preferences FROM ... | | 0.09 | SELECT r.region_code, r.tax_rate, r.currency FROM ... | | 0.02 | SELECT COUNT(*) FROM orders WHERE status = ? | +--------+------------------------------------------------+ 最初の 3 つのクエリはキャッシュの有力候補です。商品カタログの結合 ( db.load.avg 0.42)、ユーザープロファイルの参照 (0.18)、地域別税率の取得 (0.09) です。これらはデータベース負荷が高く、SELECT のみであり、変更頻度の低いデータに基づいています。4 番目のクエリ (リアルタイム注文件数、0.02) は、注文のたびに結果が変わるためキャッシュすべきではありません。 良い候補の判断基準 シグナル 確認すべきポイント 高い db.load.avg クエリがデータベース負荷に大きく影響を与えている。 SELECT 文 読み取りクエリのみキャッシュに適している。 安定した結果セット 選択した TTL に対してデータの変更頻度が低い。 繰り返し実行 1分間に何度も呼び出される。頻度が高いほど効果が大きい。 候補を特定したら、 /* CACHE_PARAM(ttl=<duration>) */ の形式でヒントを追加します。残りは Remote Query Cache Plugin が処理します。 前提条件 開始前に以下を確認してください。 Amazon ElastiCache for Valkey サーバーレスキャッシュ (推奨)、セルフマネージド ElastiCache Valkey クラスター、またはセルフマネージド Valkey キャッシュ。 AWS Advanced JDBC Wrapper 4.0.1 以降。 PostgreSQL、MySQL、または MariaDB を JDBC で使用するアプリケーション。 Amazon ElastiCache Serverless はインフラ管理不要で自動スケーリングと高可用性が組み込まれているため推奨です。 Remote Query Cache Plugin によるキャッシュの設定 Remote Query Cache Plugin の有効化には、ドライバー依存関係の追加、接続の設定、キャッシュ対象クエリへの SQL クエリヒントの追加の 3 ステップが必要です。 ステップ 1: AWS Advanced JDBC Wrapper 依存関係の追加 まず、Maven 設定にラッパー依存関係を追加します (Gradle もサポートされています)。 Maven: <dependency> <groupId>software.amazon.jdbc</groupId> <artifactId>aws-advanced-jdbc-wrapper</artifactId> <version>4.0.1</version> </dependency> Gradle: implementation 'software.amazon.jdbc:aws-advanced-jdbc-wrapper:4.0.1' ステップ 2: キャッシュ接続の設定 データベース接続設定を更新して Remote Query Cache Plugin を有効にします。フレームワークによって設定が若干異なります。 Spring Boot の例 (application.yml): spring: datasource: url: jdbc:aws-wrapper:postgresql://<DATABASE_CONNECTION_STRING> wrapperPlugins: remoteQueryCache cacheEndpointAddrRw: <VALKEY_ENDPOINT> cacheUseSSL: true username: <DB_USER> password: <DB_PASS> jpa: properties: hibernate: use_sql_comments: true # Required to enable SQL hints データベース認証: この例ではプレースホルダーとしてユーザー名とパスワードを使用しています。AWS Advanced JDBC Wrapper は IAM データベース認証や AWS Secrets Manager など複数の認証方法をサポートしています。詳細は Secrets Manager Plugin を参照してください。 主な設定プロパティ: wrapperPlugins=remoteQueryCache : Remote Query Cache Plugin を有効にします。 cacheEndpointAddrRw : 読み書き操作用の Amazon ElastiCache エンドポイント。 cacheName : Amazon ElastiCache クラスター名 (IAM 認証用)。 cacheUsername : キャッシュのユーザー名 (Amazon ElastiCache Serverless の場合は default を使用)。 cacheIamRegion : IAM 認証用の AWS リージョン。 cacheUseSSL=true : アプリケーションと ElastiCache 間の転送中データに TLS 暗号化を有効にします。すべてのデプロイで true に設定してください。 ステップ 3: 対象クエリへの SQL ヒントの追加 キャッシュ対象のクエリに TTL (time-to-live) 付きの SQL ヒントを追加してマークします。構文は SELECT 文の先頭に /* CACHE_PARAM(ttl=<duration>) */ を付けます。 Spring Data: @Repository public interface ProductRepository extends JpaRepository<Product, Long> { @Query(value = "SELECT * FROM products WHERE category_id = :categoryId AND active = true", nativeQuery = true) @QueryHints({ @QueryHint(name = org.hibernate.jpa.QueryHints.HINT_COMMENT, value = "CACHE_PARAM(ttl=300s)") }) List<Product> findActiveProductsByCategory(@Param("categoryId") Long categoryId); } Remote Query Cache Plugin のドキュメント に、Hibernate と Spring Data の追加例が掲載されています。 OpenTelemetry によるパフォーマンスモニタリング Remote Query Cache Plugin は AWS Distro for OpenTelemetry (ADOT) Collector を通じてキャッシュメトリクスを送信するよう設定できます。ヒット数とミス数、バイパスイベント、ヘルスチェックステータスを取得でき、キャッシュの効果をリアルタイムに把握できます。分散トレーシングを有効にして、クエリがキャッシュとデータベースのどちらにアクセスしたかも確認できます。プラグインは Remote Query Cache Plugin テレメトリドキュメント と テレメトリ設定ガイド に記載の方法で AWS X-Ray にトレースを転送します。 図 2: OpenTelemetry 経由で収集されたキャッシュヒット/ミスメトリクス、ヘルスチェック、クエリパフォーマンスを表示する Amazon CloudWatch ダッシュボード セキュリティの考慮事項 本ソリューションは AWS 責任共有モデル に従います。AWS が ElastiCache と RDS/Aurora の基盤インフラストラクチャを保護します。アクセス制御の設定、暗号化の有効化、認証情報の管理はお客様の責任です。 転送中の暗号化 : 接続 URL で cacheUseSSL=true を設定し、アプリケーションと ElastiCache 間の全トラフィックを暗号化します。 保管時の暗号化 : Amazon ElastiCache Serverless はデフォルトで保管時の暗号化が有効です。ノードベースのクラスターでは、作成時に AtRestEncryptionEnabled=true を設定します。 ElastiCache の IAM 認証 : 静的パスワードの代わりに IAM 認証を使用するには、接続 URL で cacheIamRegion と cacheName を設定します。アプリケーションの IAM ロールに以下のポリシーをアタッチします。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "elasticache:Connect", "Resource": "arn:aws:elasticache:REGION:ACCOUNT_ID:serverlesscache:CACHE_NAME" } ] } Performance Insights CLI 用の IAM 権限: aws pi describe-dimension-keys と aws rds describe-db-instances コマンドには以下の最小権限が必要です。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "pi:DescribeDimensionKeys", "rds:DescribeDBInstances" ], "Resource": [ "arn:aws:rds:REGION:ACCOUNT_ID:db:INSTANCE_ID", "arn:aws:pi:REGION:ACCOUNT_ID:metrics/rds/RESOURCE_ID" ] } ] } クリーンアップ テスト用に Amazon ElastiCache for Valkey クラスターを作成した場合、継続的な課金を避けるため ElastiCache コンソール または AWS CLI で削除してください。キャッシュを削除すると、キャッシュされた全データが完全に削除されます。新しいキャッシュをプロビジョニングするまで、アプリケーションはデータベースへの直接クエリにフォールバックします。 コード変更を元に戻すには: 接続 URL から wrapperPlugins=remoteQueryCache とキャッシュパラメータを削除します。 クエリから /* CACHE_PARAM(ttl=...) */ ヒントを削除します。 他の Wrapper プラグインを使用していない場合、ビルド設定から Wrapper 依存関係を削除します。 まとめ 本記事では、最小限のアーキテクチャ変更でデータベース負荷を削減しアプリケーションパフォーマンスを向上させる自動クエリキャッシュの方法を紹介しました。 AWS Advanced JDBC Wrapper Remote Query Cache Plugin を設定して Amazon ElastiCache for Valkey と通信し、SQL ヒントを使用してキャッシュ対象クエリをマークします。キャッシュの検索、シリアライゼーション、コネクションプーリング、認証、障害時の安全なフォールバックはすべて自動的に管理されます。繰り返しの読み取りクエリを Amazon ElastiCache にオフロードすることで、書き込みが多い処理やレイテンシーが重要なオペレーション用にデータベースキャパシティを確保できます。 まず、Aurora または RDS インスタンスで Amazon CloudWatch Database Insights を使用し、データベース負荷による上位 SELECT クエリを特定してください。本記事の aws pi describe-dimension-keys コマンドを実行して候補を洗い出します。次に、最も負荷の高い候補に /* CACHE_PARAM(ttl=<duration>) */ ヒントを追加し、ラッパーを設定してアプリケーションをデプロイします。PostgreSQL 直接接続、AWS JDBC Wrapper、Remote Query Cache Plugin のクエリレイテンシーを並べて比較するには、GitHub の jdbc-caching-demo サンプル をお試しください。 著者について Qu Chen Qu は、AWS クラウドテクノロジーとインメモリデータベースサービスの技術エキスパートであるシニアソフトウェア開発エンジニアで、Amazon ElastiCache for Valkey/Memcached と Amazon MemoryDB の構築・保守を担当しています。Valkey オープンソースコミュニティのアクティブなコントリビューターとして、キャッシュを活用した低レイテンシーアプリケーションの構築に関する講演やブログ記事の執筆を行っています。 Puneet Rawal Puneet は、シカゴを拠点とする AWS のプリンシパルデータベーススペシャリストソリューションアーキテクトで、エンタープライズのお客様による AWS でのデータベースワークロードの設計、移行、最適化を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenta Nagasue がレビューしました。

本記事は 2026 年 5 月 11 日 に公開された「 Amazon Aurora DSQL connections: Drivers, strings, and best practices 」を翻訳したものです。 Amazon Aurora DSQL への初めての接続を設定しようとしていますか? PostgreSQL を使ったことがあれば流れは似ていますが、いくつか重要な違いがあります。長期間有効なパスワードの代わりに、 短命の IAM 認証トークン を使用します。静的なエンドポイントの代わりに、複数のアベイラビリティゾーンにまたがる分散クラスターエンドポイントを使用します。接続タイムアウトのトラブルシューティング、トークンの有効期限管理、ドライバーの初回設定など、接続パターンを理解しておくと一般的な問題を回避できます。 本記事では、接続文字列の設定方法、Python・Java・Node.js でのドライバー設定、認証・接続プーリング・ライフサイクル管理のベストプラクティスについて説明します。 接続アーキテクチャ Amazon Aurora DSQL は、従来の PostgreSQL デプロイとは根本的に異なる分散接続アーキテクチャを採用しています。アプリケーションは単一のデータベースインスタンスに接続するのではなく、複数のアベイラビリティゾーンにトラフィックを分散するルーティングレイヤーを介して接続します。ドライバーや接続文字列を設定する前に、エンドポイントの構造とワイヤプロトコルの動作を理解しておく必要があります。以下のセクションでは、接続前に知っておくべきエンドポイント形式とワイヤプロトコルの互換性について説明します。 エンドポイント形式 Amazon Aurora DSQL クラスターのエンドポイントは次のパターンに従います。 <cluster-id>.dsql.<region>.on.aws 例: weaxxxxxxxxxxxxxxxxqdqqm.dsql.us-east-1.on.aws デュアルスタック形式で、IPv4 と IPv6 の両方をサポートしています。エンドポイントは Aurora DSQL の分散ルーティングレイヤーに接続し、複数のアベイラビリティゾーンへの接続分散を自動的に処理します。 主要な接続パラメータ: Host: クラスターエンドポイント (上記の形式)。 Port: 5432 (PostgreSQL 標準ポート)。 Database: postgres (デフォルトのデータベース名)。 SSL Mode: すべての接続で必須。 ワイヤプロトコルの互換性 Amazon Aurora DSQL は標準の PostgreSQL v3 ワイヤプロトコルを使用しており、psql、pgjdbc、psycopg、psycopg2 などの一般的な PostgreSQL ドライバーとの互換性があります。既存のツールやライブラリは、最小限の設定変更で利用できます。 認証とセキュリティ Aurora DSQL では、従来の PostgreSQL データベースとは異なる認証方式とネットワークセキュリティを採用しています。以下のセクションでは、IAM ベースのトークン生成、ネットワーク接続オプション、認証情報管理のベストプラクティスについて説明します。 IAM ベースの認証 Amazon Aurora DSQL は短命の IAM 認証トークンのみを使用します。IAM 認証には以下のセキュリティ上の利点があります。 セキュリティの強化: パスワードの保存やローテーションに伴うリスクを軽減します。 アクセス制御の一元化: AWS Identity and Access Management (AWS IAM) による統一的な権限管理が可能です。 監査証跡: 接続試行が AWS CloudTrail に記録されます。 自動期限切れ: トークンはデフォルトで 15 分後に期限切れになります (最大 1 週間まで設定可能)。デフォルトを超える有効期間の延長は推奨しません。漏洩した長命トークンは重大なセキュリティリスクです。延長が必要な場合は、トークンのスコープを最小限の権限に絞り、CloudTrail で長命トークンを監視してください。 アクセス制御パターンとセキュリティのベストプラクティスの詳細については、 Amazon Aurora DSQL のセキュリティ対策：アクセス制御のベストプラクティス を参照してください。 AWS Command Line Interface (AWS CLI) でのトークン生成: 以下のコマンドで、AWS CLI を使用して Aurora DSQL クラスターの認証トークンを生成します。 aws dsql generate-db-connect-admin-auth-token \ --region us-east-1 \ --hostname <your-cluster-id>.dsql.us-east-1.on.aws 必要な IAM 権限: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dsql:DbConnect", "dsql:DbConnectAdmin" ], "Resource": "arn:aws:dsql:region:account-id:cluster/cluster-id", "Condition": { "IpAddress": { "aws:SourceIp": ["10.0.0.0/8"] } } } ] } dsql:DbConnect: 通常のデータベースユーザーとしての接続権限を付与します。 dsql:DbConnectAdmin: 管理者権限を付与します。 最小権限の原則 ユースケースごとに必要最小限の権限のみを付与します。 標準のアプリケーションアクセスには dsql:DbConnect を使用します。 dsql:DbConnectAdmin は管理タスク専用に限定します。 既知のネットワーク範囲のみにアクセスを制限するため、IP ベースの 条件 を追加します。 ネットワークセキュリティ Amazon Aurora DSQL はパブリックアクセスとプライベートアクセスの両方をサポートしています。 パブリックエンドポイントアクセス は以下によりセキュリティを確保します。 IAM ベースの認証 – パスワードベースの脆弱性を軽減します。 IP ベースのアクセス制御 – IAM ポリシー条件により接続を制限します。 SSL/TLS 暗号化の必須化 – 暗号化されたトランスポートが必須です。 プライベートエンドポイントアクセス (AWS PrivateLink) はトラフィックを AWS 内に保持します。 VPC インターフェイスエンドポイント – インターネットに公開されないプライベート接続。 VPC エンドポイントポリシー – ネットワークレベルの追加のアクセス制御。 セキュリティグループ – 特定のサブネットとポートへのトラフィックを制限。 VPC エンドポイントポリシーをアタッチして、エンドポイント経由で接続できるプリンシパルを制限します。設定しない場合、VPC 内のすべてのプリンシパルがエンドポイントを使用してクラスターに接続できます。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::account-id:role/your-app-role" }, "Action": [ "dsql:DbConnect" ], "Resource": "arn:aws:dsql:region:account-id:cluster/cluster-id" } ] } ネットワークエグレス制御 インバウンドアクセスの制御だけでは不十分です。エグレス制限がなければ、侵害されたアプリケーションが外部にデータを送出する可能性があります。アプリケーションホストからのアウトバウンドトラフィックを制限してください。 セキュリティグループのアウトバウンドルール – 必要な宛先 (Aurora DSQL のポート 5432、AWS サービスエンドポイントなど) へのトラフィックのみを許可します。 VPC Network ACLs – セカンダリレイヤーとしてサブネットレベルのエグレス制限を追加します。 VPC Flow Logs – 予期しないアウトバウンドトラフィックパターンを監視します。 AWS Network Firewall – セキュリティグループを超えた、きめ細かいエグレスフィルタリングに使用します。 認証情報の管理 Aurora DSQL に接続する際の認証情報管理のベストプラクティスを以下に示します。 認証情報をハードコードしない – アプリケーションコードに埋め込まないでください。 環境変数を使用する – ホスト名やリージョンなどの設定値には環境変数を使用します。 トークンを動的に生成する – 接続時に AWS SDK 呼び出しでトークンを生成します。 AWS Secrets Manager を使用する – 接続設定の保存に利用します。 IAM 認証情報を定期的にローテーションする – AWS のセキュリティベストプラクティス に従います。 認証試行を監視する – CloudTrail による異常検知 を活用します。 認証トークンをログに記録・永続化しない – トークンはデータベースパスワードとして渡されるため、接続文字列ログ、アプリケーションログ、エラーメッセージに漏洩する可能性があります。ロギングフレームワークでパスワードフィールドを確実にマスクし、URL や診断出力にトークンを含めないでください。 接続の監視 CloudTrail はすべての Aurora DSQL 認証イベントを記録します。異常な接続アクティビティを検知するアラートを設定してください。 認証失敗 – DbConnect または DbConnectAdmin の繰り返し失敗に対して Amazon CloudWatch アラームを作成し、認証情報の悪用や設定ミスを検知します。 予期しない送信元 IP やリージョン – CloudTrail イベントを sourceIPAddress と awsRegion でフィルタリングし、想定外のネットワーク範囲からの接続をフラグ付けします。 異常な接続パターン – CloudWatch 異常検知を使用して、接続量の急増や通常の運用時間外の接続を監視します。 長命トークンの使用 – 要求された有効期間がデフォルトの 15 分を超える GenerateDbConnectAdminAuthToken 呼び出しを追跡します。 自動対応として、CloudTrail イベントの Amazon EventBridge ルールを使用して、 Amazon Simple Notification Service (Amazon SNS) 通知や AWS Lambda による修復ワークフローをトリガーできます。 SSL/TLS の設定 Amazon Aurora DSQL は接続に暗号化トランスポートを必須としています。 sslmode=require – 暗号化の最小要件。 sslmode=verify-full – 完全な証明書検証とホスト名検証によるセキュリティ強化。 本番環境の推奨事項: verify-full モードを使用してください。証明書チェーンとホスト名の両方を検証し、中間者攻撃への対策となります。 Amazon Aurora DSQL コネクター AWS は Amazon Aurora DSQL コネクターを提供しています。コネクターは透過的な認証レイヤーとして機能し、IAM トークンの生成とリフレッシュを自動的に処理します。認証コードではなく、接続コードだけを記述すれば済みます。 利用可能なコネクター JDBC Connector – 標準の Java データベース接続レイヤーに IAM 認証を統合し、既存の Java データアクセスフレームワークとシームレスに連携します。 Python Connector – psycopg、psycopg2、asyncpg (非同期ワークロード) をサポートします。認証プラグインとして動作し、既存の接続ワークフローを変更せずにトークン生成を処理します。 Node.js Connectors – node-postgres (pg) と Postgres.js の両方に対応しています。 Go Connector – pgx をラップし、IAM 認証の自動処理、SSL 設定、接続管理を行います。 Ruby Connector – Ruby アプリケーション向けの IAM ベース認証を提供します。 .NET Connector – Npgsql をラップし、IAM 認証の自動処理、SSL 設定、接続管理を行います。 Rust Connector – SQLx をラップし、IAM 認証の自動処理、SSL 設定、接続管理を行います。 実装の詳細については、 Amazon Aurora DSQL Connectors GitHub を参照してください。 コネクター使用の利点 トークン管理の自動化 – クラスターホスト名からのリージョン自動検出を含む、IAM トークン生成とリフレッシュのライフサイクル全体を管理します。 シームレスな統合 – 接続プーリングライブラリ (HikariCP、psycopg ConnectionPool、psycopg2 ThreadedConnectionPool、asyncpg ネイティブプール) と透過的に連携します。 フレームワークサポート – Spring Boot、Django など、標準的なデータベースドライバーインターフェイスに依存するフレームワークと互換性があります。 ボイラープレートの削減 – 手動のトークン生成コードの記述やメンテナンスが不要です。 クイックスタート例 (JDBC コネクター) 以下の例は、Java で JDBC コネクターを使用して Aurora DSQL クラスターに接続する方法を示しています。コードを実行する前に、プロジェクトの依存関係に Aurora DSQL JDBC ドライバーを追加し、IAM 認証情報を設定済みであることを確認してください (環境変数、インスタンスプロファイル、または AWS 認証情報ファイルのいずれか)。JDBC URL に jdbc:aws-dsql:// プレフィックスを設定し、 DriverManager.getConnection を呼び出します。コネクターが IAM トークン生成を自動的に処理するため、手動のトークンコードは不要です。コネクターは、トークンを長期間キャッシュするのではなく、新しい接続または接続プールの初期化ごとに新しいトークンを生成します。 // Change the JDBC URL prefix to jdbc:aws-dsql:// String url = "jdbc:aws-dsql://" + clusterEndpoint + ":5432/postgres"; Connection conn = DriverManager.getConnection(url, "admin", ""); // No password needed — the connector handles token generation automatically 手動接続パターン コネクターを使用しない場合 (学習目的、デバッグ、カスタム認証フローなど) は、AWS SDK で IAM トークンを手動で生成し、データベースパスワードとして渡せます。 接続には最低限 sslmode=require が必要です。トークンは、呼び出し元の IAM アイデンティティから派生し、特定のクラスターホスト名にスコープされた、有効期限付きの認証情報です。 SDK トークン生成メソッド Python (boto3) generate_db_connect_admin_auth_token Java DsqlClient.generateDbConnectAdminAuthToken Node.js GenerateDbConnectAdminAuthTokenCommand Go dsql.GenerateDbConnectAdminAuthToken Ruby Aws::DSQL::Client#generate_db_connect_admin_auth_token .NET AmazonDSQLClient.GenerateDBConnectAdminAuthToken Rust dsql::Client::generate_db_connect_admin_auth_token 生成したトークンを、接続確立時にデータベースパスワードとして渡します。 完全なコード例については、 Amazon Aurora DSQL ユーザーガイド と Amazon Aurora DSQL Code Samples を参照してください。 接続プーリング 適切に設定された接続プーリングは、レイテンシーを低減し、Aurora DSQL の接続レート制限への到達を回避します。本セクションでは、プールの設定、サイジング、考慮すべき主要な制約について説明します。 クライアント側プーリングが必須 Aurora DSQL にはサービスレイヤーでの組み込み接続プーリングがありますが、新しい接続ごとに TLS ハンドシェイクとサービスによる認証が必要です。接続をプールすれば、そのコストをリクエストごとではなく一度だけ支払えばよくなります。 PgBouncer や pgpool-II などのサーバー側コネクションプーラーは使用しないでください。 これらのツールは従来の PostgreSQL アーキテクチャ向けに設計されており、Amazon Aurora DSQL の分散接続処理で可用性の問題を引き起こす可能性があります。 プール設定 最も重要なパラメータは 最大接続寿命 です。Amazon Aurora DSQL は接続期間に 60 分のハードリミットを適用します。プールの最大ライフタイムを 45〜55 分に設定し、Aurora DSQL が接続を切断する前にプロアクティブにリサイクルしてください。 Java で HikariCP を使用する場合は、 maximumPoolSize 、 maxLifetime (60 分未満) を設定し、手動のトークン管理を避けるために JDBC Connector を使用します。HikariCP の完全な設定については、公式ガイド「 Using Amazon Aurora DSQL with JDBC, Hibernate, and HikariCP 」を参照してください。 Python の場合は、手動で生成した IAM トークンを使用して psycopg2 で接続するか ( Amazon Aurora DSQL ユーザーガイド – Psycopg2 の使用 を参照)、 Amazon Aurora DSQL Python Connector (GitHub) を使用してトークンのボイラープレートを完全に排除できます。 接続制限とクォータ 接続プールのサイジングを決定する前に、Amazon Aurora DSQL の接続制限を理解しておく必要があります。Amazon Aurora DSQL は接続作成レートの制御に トークンバケットアルゴリズム を使用しています。新しい接続ごとにトークンを 1 つ消費し、バケットは一定レートで補充されます。バケット容量を上限としてバーストも可能です。 クラスターあたりのデフォルト制限は以下のとおりです。 クォータ デフォルト値 備考 最大確立接続数 10,000 クラスターごとの制限。Service Quotas で調整可能 新規接続レート (定常状態) 100 接続/秒 トークンバケットの補充レート バースト容量 1,000 接続 補充前の t=0 時点で利用可能なトークン数 最大接続期間 60 分 ハードリミット。1 時間後に接続切断 最大トランザクション期間 5 分 トランザクションごと (BEGIN から COMMIT まで) トークンバケットの実際の動作: アプリケーション起動時に 1,000 接続を開いた場合、すべて成功します (バーストトークン 1,000 個)。ただし、バケットは空になります。1,001 番目の接続は、バケットが 100 トークン/秒で補充されるのを待つ必要があります。クライアント側プーリングが重要な理由はここにあります。接続を再利用すれば、作成バジェットの消費を避けられます。 接続ライフサイクル Aurora DSQL の接続には最大ライフタイムが固定されており、有効期限付きトークンを使用するため、アプリケーションは接続のリサイクルとトークンリフレッシュを適切に処理する必要があります。 1 時間の接続制限 Amazon Aurora DSQL のすべての接続の最大ライフタイムは 60 分です。1 時間後、接続がアイドル状態でもアクティブ状態でも、サービスが接続を切断します。これは設計上の仕様です。Aurora DSQL の分散アーキテクチャでは内部コンポーネントがバックグラウンドで障害復旧や交換されるため、1 時間の制限によりアプリケーションが定期的に新しい接続を確立し、正常なインフラに自然に接続されるようになっています。Aurora DSQL は切断にジッターを適用するため、接続が同時に切断されることはなく、トランザクション中の接続は切断されません。 トークンの有効期限管理 トークンはデフォルトで 15 分後に期限切れになります (最大 1 週間まで設定可能)。重要なポイント: 有効なトークンで接続が確立された後は、トークンが期限切れになっても接続は有効なままです。新しいトークンが必要なのは新しい接続を確立するときだけであり、60 分の接続制限がバインディング制約となります。トークンの有効期限は制約になりません。 トークンはリージョンスコープでもあります。 region=us-east-1 で生成されたトークンは us-east-1 エンドポイントへの接続にのみ有効で、同じマルチリージョンクラスターの us-east-2 エンドポイントには使用できません。マルチリージョンデプロイでは、アプリケーションが接続する各リージョンエンドポイントに対して個別のトークンを生成してください。 推奨アプローチ: Amazon Aurora DSQL コネクター を使用してください。新しい接続ごとに自動的にトークンを生成するため、トークン管理コードが不要です。 接続リトライロジック 分散システムでは一時的な接続障害は例外ではなく通常の動作です。内部コンポーネントに障害が発生した場合、Aurora DSQL が自動的に処理しますが、アプリケーション側ではその接続に対するエラーが発生します。 SerializationFailure (OCC コンフリクト) と OperationalError (一時的な障害) の両方に対して、エクスポネンシャルバックオフとジッターを伴うリトライロジックを実装してください。推奨パターンについては、Amazon Aurora DSQL の同時実行制御ドキュメントと AWS Builders’ Library – タイムアウト、リトライ、ジッター付きバックオフ を参照してください。 マルチリージョン接続パターン 地理的リージョンをまたいだ高可用性が必要なアプリケーション向けに、Amazon Aurora DSQL マルチリージョンクラスターはリージョンエンドポイントで読み書き両方をサポートするアクティブ-アクティブアーキテクチャを提供します。 アクティブ-アクティブ マルチリージョンアーキテクチャ Amazon Aurora DSQL マルチリージョンクラスターは、アクティブ-アクティブアクセスのためのリージョンエンドポイントを提供します。アプリケーションはどちらのエンドポイントにも接続して読み書きが可能で、地理的な分散とリージョンフェイルオーバーを実現します。 エンドポイント選択戦略 レイテンシーのために最寄りのリージョンエンドポイントに接続し、プライマリリージョンに問題がある場合はセカンダリエンドポイントへのヘルスベースのフェイルオーバーを実装します。 フェイルオーバーロジックは事前にテストしておいてください。 一般的な接続問題のトラブルシューティング 本セクションでは、Aurora DSQL に接続する際に発生しやすいエラーや接続障害と、その原因および推奨される対処方法について説明します。認証失敗、タイムアウトエラー、ドライバーの互換性の問題のいずれの場合も、以下のガイダンスで問題を迅速に診断・解決できます。 問題 1: “Connection Attempt Failed” 症状: Amazon Aurora DSQL エンドポイントへの接続を確立できない 一般的な原因: IAM 権限の不備、認証トークンの期限切れ、ネットワーク接続の問題、エンドポイント形式の誤り 解決方法: 接続失敗を解決するには、以下の手順を順に実行してください。まず、IAM ユーザーまたはロールのポリシーに適切な dsql:DbConnect または dsql:DbConnectAdmin 権限がアタッチされていることを確認します。次に、認証トークンが期限切れでないことを確認します。トークンは短命であり、新しい接続試行のたびに再生成が必要です。クラスターエンドポイントの形式が正しいこと、ポート 5432 へのアウトバウンドトラフィックをブロックするネットワークレベルの制限 (セキュリティグループ、VPC ルーティングルール、ファイアウォールポリシーなど) がないことを確認してください。以下の例は、新しいトークンを生成して明示的なエラーハンドリングで接続を試みることで、根本原因を特定しやすくする方法を示しています。 # Verify IAM permissions aws iam get-user # Test token generation aws dsql generate-db-connect-admin-auth-token \ --region us-east-1 \ --hostname <cluster-id>.dsql.us-east-1.on.aws # Test network connectivity nc -zv <cluster-id>.dsql.us-east-1.on.aws 5432 問題 2: “Access Denied” エラー 症状: 接続は確立されるが認証に失敗する 解決方法: IAM ポリシーに dsql:DbConnect または dsql:DbConnectAdmin が含まれていることを確認します。 IAM ポリシーのアクセス制限条件 (aws:SourceIp、aws:RequestedRegion、aws:PrincipalTag など) を確認します。基本権限が付与されていても、条件によって接続がサイレントに拒否される場合があります。 トークンが正しいリージョンで生成されていることを確認します。 AWS 認証情報が期限切れでないことを確認します。 問題 3: PrivateLink 接続の問題 VPC の外部から PrivateLink 経由で接続する場合、クライアントはクラスターエンドポイントを VPC エンドポイント IP に解決する必要があります。2 つのアプローチがあります。 オプション 1: PGHOSTADDR で IP アドレスをオーバーライド export PGHOSTADDR=<vpce-ip-address> export HOSTNAME=<cluster-id>.dsql.<region>.on.aws psql -h $HOSTNAME -U admin -d postgres SNI に正しいホスト名を使用しながら VPC エンドポイント IP に接続します。 オプション 2: amzn-cluster-id 接続オプションを使用 (DNS 不要) export CLUSTERID=<cluster-id> export PGOPTIONS="-c amzn-cluster-id=$CLUSTERID" psql -h <vpce-endpoint> -U admin -d postgres クラスター識別子を接続オプションとして直接渡し、DNS 解決を不要にします。VPC エンドポイントのプライベート DNS が設定されていない場合に便利です。 詳細については、 PrivateLink 接続エンドポイントを使用した Amazon Aurora DSQL への接続 を参照してください。 問題 4: 接続プールのヘルスチェックストーム 症状: 負荷スパイク時の大量の接続切断と再確立、カスケード的なヘルスチェック失敗、接続レート制限エラー 原因: 短いヘルスチェック間隔 (HikariCP のデフォルト 5 秒タイムアウトなど) により、数千のプール接続に対して同時にヘルスチェックがトリガーされる場合があります。多数のチェックが同時に失敗すると、プールがすべての接続の再確立を試み、100 接続/秒のレート制限を使い果たして障害がカスケードします。 解決方法: すべての接続に固定間隔を使用するのではなく、接続間でヘルスチェック間隔をずらします。 不要な接続リサイクルを避けるため、アイドルタイムアウトを増やします。 HikariCP の場合、 connectionTimeout と validationTimeout をデフォルトより長く設定します。 maxLifetime に十分なジッターを設定します (HikariCP は自動的に ±2.5% を適用)。同期した接続期限切れを回避できます。 まとめ 本記事では、JDBC や PostgreSQL 互換クライアント、AWS CLI など、さまざまなドライバーやツールを使用して Amazon Aurora DSQL に接続する方法を紹介しました。接続アーキテクチャ、IAM ベースの認証トークンの生成と使用方法、認証情報管理と接続プーリングのベストプラクティスについて解説しました。クイックスタート例と、一般的な接続問題の診断・解決に役立つトラブルシューティングガイドも提供しました。 実際に試してみたいですか? プレイグラウンド でセットアップなしに Aurora DSQL を体験できます 。接続の操作、クエリの実行、本記事で紹介した機能の確認を実際に行えます。 著者について Alex Pawvathil Alex は、AWS のシニアテクニカルアカウントマネージャーで、データベースアーキテクチャとエンタープライズ規模の実装を専門としています。クラウドアーキテクチャ、データベース戦略、エンタープライズアドバイザリーで 14 年以上の実務経験があり、Amazon RDS for SQL Server の実装とエンタープライズ規模のデプロイメントの専門家です。 Sandhya Khanderia Sandhya は、AWS のシニアテクニカルアカウントマネージャー兼データアナリティクススペシャリストです。AWS のお客様と密接に連携し、継続的なサポートと技術ガイダンスを提供しています。ベストプラクティスを活用したソリューションの計画・構築を支援しながら、AWS 環境の運用状態をプロアクティブに健全に保つことに取り組んでいます。 Rob Petersen Rob は、AWS のシニアテクニカルアカウントマネージャーで、IT 業界での 20 年の経験を活かし、お客様のクラウド導入ジャーニーを支援しています。大規模なクラウドマイグレーションのリードとハイブリッドインフラストラクチャの運用管理の両方の経験があり、クラウド導入時に組織が直面する課題と機会について独自の視点を持っています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Arisa Izuno がレビューしました。