RDS Proxy の概念と用語 - Amazon Aurora
RDS Proxy の概念接続プーリングセキュリティフェイルオーバートランザクション

RDS Proxy の概念と用語

RDS Proxy を使用すると、 Amazon Aurora DB クラスターの接続管理をシンプルにできます。

RDS Proxy は、クライアントアプリケーションとデータベースとの間のネットワークトラフィックを処理します。これを行うアクティブな方法として、まず、データベースプロトコルを確認します。次に、その動作をアプリケーションからの SQL オペレーションとデータベースからの結果セットに基づいて調整します。

RDS Proxy により、データベースの接続管理から発生するメモリと CPU のオーバーヘッドが減ります。アプリケーション接続を同時に開く数が多いほど、データベースに必要なメモリと CPU リソースが少なくなります。また、アプリケーションの接続を閉じてから長いアイドル状態の後でアプリケーションを再度開くためのロジックは不要です。同様に、データベース問題の発生時に接続を再確立するために必要なアプリケーションロジックも減ります。

RDS Proxy のインフラストラクチャは可用性が高く、複数のアベイラビリティーゾーン (AZ) にデプロイできます。RDS Proxy の計算、メモリ、およびストレージは、Aurora DB クラスターから独立しています。この分離によって、データベースサーバーのオーバーヘッドが減り、そのリソースをデータベースワークロードの処理に集中させることができます。RDS Proxy コンピューティングリソースはサーバーレスであり、データベースのワークロードに基づいて自動的にスケーリングされます。

RDS Proxy の概念

RDS Proxy は、接続プールや以降のセクションで説明するその他の機能を実行するインフラストラクチャを処理します。プロキシは、RDS コンソールの [プロキシ] ページに表示されます。

各プロキシは、単一の Aurora DB クラスターへの接続を処理します。プロキシは、 Aurora のプロビジョンドクラスターで、現在のライターインスタンスを自動的に判別します。

プロキシで開いたままにしてデータベースアプリケーションで使用できるようにした接続は、接続プールを形成します。

デフォルトでは、RDS Proxy はセッション内の各トランザクションの後で接続を再利用できます。このトランザクションレベルの再利用は、多重化と呼ばれます。RDS Proxy が接続を接続プールから一時的に削除して再利用する場合、そのオペレーションは、接続の借用と呼ばれます。この再利用が安全であれば、RDS Proxy はその接続を接続プールに返します。

場合によっては、RDS Proxy は、現在のセッションの外でデータベース接続を再利用しても安全であると判断できません。このような場合、セッションが終了するまで、セッションは同じ接続で維持されます。このフォールバック動作は、固定と呼ばれます。

プロキシにはデフォルトのエンドポイントがあります。Amazon Aurora DB クラスターを使用する場合は、このエンドポイントに接続します。 クラスターに直接接続する読み取り/書き込みエンドポイントに接続する代わりに、この操作を行います。特定用途のエンドポイントは、Aurora クラスターで引き続き使用可能です。Aurora DB クラスターの場合、追加の読み取り/書き込みエンドポイントと読み取り専用エンドポイントを作成することもできます。詳細については、「プロキシエンドポイントの概要」を参照してください。

例えば、接続プールを使用しなくても、読み取り/書き込み接続に、引き続きクラスターエンドポイントを使用できます。負荷分散された読み取り専用接続に、引き続きリーダーエンドポイントを使用できます。クラスター内の特定の DB インスタンスの診断やトラブルシューティングに、引き続きインスタンスエンドポイントを使用できます。他の AWS のサービス (AWS Lambda など) を使用して RDS データベースに接続している場合、プロキシエンドポイントを使用するには、接続設定を変更します。例えば、RDS Proxy 機能を利用してプロキシエンドポイントを通じてデータベースにアクセスすることを Lambda 関数に許可するように指定します。

プロキシごとにターゲットグループがあります。このターゲットグループは、プロキシが接続できる Aurora DB クラスターを指します。Aurora クラスターの場合、ターゲットグループはデフォルトでクラスター内のすべての DB インスタンスに関連付けられます。これにより、プロキシは、クラスター内のライターインスタンスとして昇格された Aurora DB インスタンスに接続できます。プロキシに関連付けられた Aurora DB クラスターは、そのプロキシのターゲットと呼ばれます。コンソールでプロキシを作成すると、RDS Proxy によって自動的に、対応するターゲットグループも作成され、関連するターゲットが登録されます。

エンジンファミリーは、同じ DB プロトコルを使用する関連データベースエンジンのセットです。作成するプロキシごとにエンジンファミリーを選択します。

接続プーリング

各プロキシは、関連付けられた Aurora DB のライターインスタンスに対して接続プーリングを実行します。接続プーリングは、接続の開閉や、多数の接続を同時に開いたままにすることに伴うオーバーヘッドを削減するための最適化方法です。このオーバーヘッドには、新しい各接続を処理するために必要なメモリも含まれます。また、各接続を閉じて新しい接続を開くため、CPU のオーバーヘッドを伴います。例えば、TLS/SSL (Transport Layer Security/Secure Sockets Layer) のハンドシェイク、認証、ネゴシエーション機能などがあります。接続プーリングは、アプリケーションロジックを簡素化します。同時に開いている接続の数を最小限に抑えるためのアプリケーションコードを記述する必要はありません。

各プロキシは、接続の多重化も実行します。これは接続の再利用とも呼ばれます。多重化により、RDS Proxy は 1 つの基となるデータベース接続を使用して 1 つのトランザクションのすべてのオペレーションを実行します。RDS は、次のトランザクションに別の接続を使用できます。プロキシへの接続は同時に多数を開くことができます。プロキシから DB インスタンスやクラスターへの接続の数はより少なく保持されます。これにより、データベースサーバーでの接続に伴うメモリオーバーヘッドがさらに最小化されます。「接続が多すぎます」エラーが発生する可能性も減ります。

RDS Proxy のセキュリティ

RDS Proxy は、TLS/SSL や AWS Identity and Access Management (IAM) などの既存の RDS セキュリティメカニズムを使用します。これらのセキュリティ機能の概要については、「Amazon Aurora でのセキュリティ」を参照してください。また、 Aurora で使用される認証、承認、その他のセキュリティ領域でどのように機能するかを理解する必要があります。

RDS Proxy は、クライアントアプリケーションおよび基となるデータベースの間に別のセキュリティ層を追加します。例えば、基になる DB インスタンスが古いバージョンの TLS をサポートしている場合でも、TLS 1.3 を使用してプロキシに接続できます。プロキシへの接続には IAM ロールを使用できます。これは、ネイティブユーザーとパスワードによる認証方法を使用してプロキシからデータベースへの接続する場合でも同じです。この方法により、DB インスタンス自体の高額な移行作業を必要とせずに、データベースアプリケーションに強力な認証要件を適用できます。

RDS Proxy で使用するデータベース認証情報は、AWS Secrets Manager に保存します。プロキシからアクセスされる Aurora DB クラスターの各データベースユーザーは、Secrets Manager に対応するシークレットを保持している必要があります。RDS Proxy のユーザーに対して IAM 認証を設定することもできます。これにより、データベースでパスワードによるネイティブ認証方法が使用されている場合でも、データベースへのアクセスに IAM 認証を適用できます。アプリケーションコードにデータベース認証情報を埋め込む代わりに、これらのセキュリティ機能を使用することをお勧めします。

RDS Proxy での TLS/SSL の使用

TLS/SSL プロトコルを使用して RDS Proxy に接続できます。

注記

RDS Proxy は AWS Certificate Manager (ACM) の証明書を使用します。RDS Proxy を使用している場合は、Amazon RDS 証明書をダウンロードしたり、RDS Proxy 接続を使用するアプリケーションを更新したりする必要はありません。

プロキシとデータベース間のすべての接続に TLS を適用するには、AWS Management Consoleでプロキシを作成または変更するときに [Transport Layer Security が必要] 設定を指定できます。

RDS Proxy により、セッションでクライアントと RDS Proxy エンドポイント間でも TLS/SSL が必ず使用されるようにもできます。そのためには RDS Proxy で、クライアント側の要件を指定します。SSL セッション可変は、RDS Proxy を使用したデータベースへの SSL 接続には設定されません。

  • Aurora MySQL の場合、mysql コマンドを実行するときに、--ssl-mode パラメータを使用してクライアント側の要件を指定します。

  • および Aurora PostgreSQL の場合、psql コマンドを実行するときに、conninfo 文字列の一部として sslmode=require を指定します。

RDS Proxy は、TLS プロトコルバージョン 1.0、1.1、1.2、および 1.3 をサポートしています。プロキシに接続するには、基になるデータベースで使用しているものよりも高いバージョンの TLS を使用します。

デフォルトでは、クライアントプログラムは RDS Proxy との暗号化された接続を確立します。さらに制御する場合は、--ssl-mode オプションを使用できます。RDS Proxy は、クライアント側のすべての SSL モードをサポートします。

クライアントの SSL モードは次のとおりです。

PREFERRED

SSL は初期の選択肢ですが、必須ではありません。

DISABLED

SSL は許可されていません。

REQUIRED

SSL を強制します。

VERIFY_CA

SSL を義務化し、認証機関 (CA) を検証します。

VERIFY_IDENTITY

SSL を義務化し、CA と CA ホスト名を検証します。

--ssl-mode、VERIFY_CA、または VERIFY_IDENTITY でクライアントを使用する場合は、CA を指す --ssl-ca を .pem 形式で指定します。.pem ファイルを使用するには、Amazon Trust Services からすべてのルート CA PEM をダウンロードし、1 つの .pem ファイルに配置します。

RDS Proxy は、ドメインとそのサブドメインの両方に適用されるワイルドカード証明書を使用します。mysql クライアントを使用して SSL モード VERIFY_IDENTITY で接続する場合、現時点では、MySQL 8.0 互換の mysql コマンドを使用する必要があります。

フェイルオーバー

フェイルオーバーは、元のデータベースインスタンスが使用できなくなったときに、別のインスタンスに置き換える高可用性機能です。フェイルオーバーは、データベースインスタンスの問題が原因で発生することがあります。また、通常のメンテナンス手順の一環として、データベースのアップグレード時などに発生することもあります。フェイルオーバーは、ライターインスタンスに加えて 1 つ以上のリーダーインスタンスが含まれている Aurora DB クラスターにも適用されます。

プロキシを介して接続すると、データベースのフェイルオーバーに対してアプリケーションの耐障害性が高くなります。元の DB インスタンスが使用できなくなると、RDS Proxy はアイドル状態のアプリケーション接続を切断せずにスタンバイデータベースに接続します。これにより、フェイルオーバープロセスが高速化および簡素化されます。これは、通常の再起動やデータベース問題に伴う停止よりも、アプリケーションの停止が短くなります。

RDS Proxy を使用していない場合は、フェイルオーバーによって短時間の停止が発生します。停止中は、フェイルオーバー中のデータベースに対して書き込み操作を実行できません。既存のデータベース接続はすべて中断されるため、アプリケーションで接続を再度開く必要があります。利用できなくなった DB インスタンスの代わりに読み取り専用 DB インスタンスが昇格すると、新しい接続および書き込みオペレーションでデータベースが使用可能になります。

DB フェイルオーバー中、RDS Proxy は引き続き同じ IP アドレスで接続を受け入れ、接続を自動的に新しいプライマリ DB インスタンスに転送します。RDS Proxy を介して接続しているクライアントは、以下の影響を受けません。

  • フェイルオーバー時のドメインネームシステム (DNS) 伝播の遅延。

  • ローカル DNS キャッシュ。

  • 接続タイムアウト。

  • どの DB インスタンスが現在のライターであるかの不確実性。

  • 接続を閉じずに使用不能になった以前のライターからのクエリ応答の待機。

アプリケーション独自の接続プールがある場合は、RDS Proxy を経由することで、ほとんどの接続がフェイルオーバーやその他の中断時にも存続します。トランザクションや SQL ステートメントの途中の接続のみがキャンセルされます。RDS Proxy は、すぐに新しい接続を受け入れます。データベースライターが使用できない場合、RDS Proxy は着信リクエストをキューに入れます。

アプリケーション独自の接続プールがない場合は、RDS Proxy を使用することで、接続速度が高速になり、開いたままの接続の数を増やすことができます。データベースからの頻繁な再接続に伴う高額なオーバーヘッドがオフロードされます。そのために、RDS Proxy 接続プールに保持されているデータベース接続を再利用します。このアプローチは、設定コストが大きい TLS 接続で特に重要です。

トランザクション

1 つのトランザクション内のすべてのステートメントは、常に同じ基となるデータベース接続を使用します。このトランザクションが終了すると、この接続は別のセッションで使用可能になります。トランザクションを粒度の単位として使用すると、次のような結果になります。

  • Aurora MySQL autocommit 設定がオンのときは、各ステートメントが終わるたびに接続の再利用が発生することがあります。

  • 逆に、autocommit 設定が無効になっていると、セッションで最初に発行したステートメントによって新しいトランザクションが開始されます。例えば、SELECT、INSERT、UPDATE などのデータ操作言語 (DML) ステートメントのシーケンスを入力したとします。この場合、COMMIT または ROLLBACK を発行するか、またはトランザクションが終了するまで、接続の再利用は起こりません。

  • データ定義言語 (DDL) ステートメントを入力すると、そのステートメントの完了後にトランザクションが終了します。

RDS Proxy は、データベースクライアントアプリケーションで使用されているネットワークプロトコルを介してトランザクションが終了したことを検出します。トランザクションの検出は、SQL ステートメントのテキスト内にある COMMIT や ROLLBACK などのキーワードに依存しません。

場合によっては、セッションを別の接続に移動することが実用的でないようなデータベースリクエストが RDS Proxy で検出されることがあります。このような場合、セッションの残りの部分では、その接続の多重化がオフになります。セッションに対して多重化が実用的であることを RDS Proxy で確信できない場合は、同じルールが適用されます。このオペレーションは固定と呼ばれます。固定を検出して最小化する方法については、「RDS Proxy の固定の回避」を参照してください。