Amazon RDS Proxy による接続の管理 - Amazon Relational Database Service
RDS Proxy の概念と用語RDS Proxy の計画と設定RDS Proxy を介した接続RDS Proxy の管理RDS Proxy のモニタリングRDS Proxy エンドポイントRDS Proxy の例RDS Proxy のトラブルシューティングAWS CloudFormation での RDS Proxy の使用

Amazon RDS Proxy による接続の管理

Amazon RDS Proxy を使用すると、データベース接続のプーリングと共有をアプリケーションに許可してスケーラビリティを向上させることができます。RDS Proxy は、アプリケーション接続を維持しながら、スタンバイ DB インスタンスに自動的に接続することで、データベース障害に対するアプリケーションの耐障害性を高めます。RDS Proxy を使用すると、データベースに AWS Identity and Access Management (IAM) 認証を適用し、AWS Secrets Manager に認証情報を安全に保存することもできます。

注記

RDS Proxy には、MySQL および PostgreSQL との完全な互換性があります。ほとんどのアプリケーションでは、コードを変更せずに RDS Proxy を有効にすることができます。

RDS Proxy を使用すると、データベーストラフィックの予測不可能なサージを処理できます。このようなサージは、接続のオーバーサブスクリプションや新しい接続の矢継ぎ早の作成に伴って発生し、問題の原因となることがあります。RDS Proxy はデータベース接続プールを確立し、このプール内の接続を再利用するため、毎回新しいデータベース接続を開くためのメモリや CPU オーバーヘッドはありません。オーバーサブスクリプションからデータベースを保護するために、データベース接続の作成数を制御できます。

RDS Proxy は、接続プールからアプリケーション接続をすぐに提供できない場合に、これらの接続の処理順番を決めたり、スロットリングを行ったりします。レイテンシーは増加する場合がありますが、データベースの障害や過負荷が突然発生することはなく、アプリケーションは継続してスケーリングされます。接続リクエスト数が指定した制限を超えると、RDS Proxy はアプリケーション接続を拒否 (負荷を削除) します。同時に、使用可能な容量で対応できる負荷に対して、予測可能なパフォーマンスを維持します。

認証情報を処理するオーバーヘッドを減らし、新しい接続ごとに安全な接続を確立できます。RDS Proxy は、この作業の一部をデータベースに代わって処理できます。

RDS Proxy の概念と用語

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

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

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

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

RDS Proxy の概念

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

各プロキシは、単一の RDS DB インスタンスや Aurora DB クラスターへの接続を処理します。プロキシは、RDS のマルチ AZ DB インスタンスや Aurora のプロビジョンドクラスターで、現在のライターインスタンスを自動的に判別します。Aurora マルチマスタークラスターの場合、プロキシはライターインスタンスの 1 つに接続し、他のライターインスタンスをホットスタンバイターゲットとして使用します。

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

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

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

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

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

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

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

接続プーリング

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

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

RDS Proxy のセキュリティ

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

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

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

RDS Proxy での TLS/SSL の使用

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

注記

RDS Proxy は AWS Certificate Manager (ACM) の証明書を使用します。RDS Proxy を使用している場合は、SSL/TLS 証明書を更新するときに、RDS Proxy 接続を使用するアプリケーションを更新する必要はありません。

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

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

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

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

RDS Proxy は、TLS プロトコルバージョン 1.0、1.1、および 1.2 をサポートしています。プロキシに接続するには、基になるデータベースで使用しているものよりも高いバージョンの 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 モード VERIFY_IDENTITY を使用できます。作成したプロキシエンドポイントに接続するときに、その SSL モードを使用することはできません。

--ssl-mode、VERIFY_CA、または VERIFY_IDENTITY でクライアントを使用する場合は、CA を指す --ssl-ca を .pem 形式で指定します。使用できる .pem ファイルとしては、Amazon Trust Services から「Amazon root CA 1 trust store」をダウンロードします。

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

フェイルオーバー

フェイルオーバーは、元のデータベースインスタンスが使用できなくなったときに、別のインスタンスに置き換える高可用性機能です。フェイルオーバーは、データベースインスタンスの問題が原因で発生することがあります。また、通常のメンテナンス手順の一環として、データベースのアップグレード時などに発生することもあります。フェイルオーバーは、マルチ AZ 設定の RDS DB インスタンスに適用されます。また、ライターインスタンスに加えて 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 つのトランザクション内のすべてのステートメントは、常に同じ基となるデータベース接続を使用します。このトランザクションが終了すると、この接続は別のセッションで使用可能になります。トランザクションを粒度の単位として使用すると、次のような結果になります。

  • RDS for MySQL または Aurora MySQL autocommit 設定が有効である場合は、各ステートメントが終わるたびに接続の再利用が起こることがあります。

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

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

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

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

RDS Proxy の計画と設定

以下のセクションでは、RDS Proxy の設定方法について説明します。また、各プロキシにアクセスできるユーザーと、各プロキシから DB インスタンスに接続する方法を制御する関連セキュリティオプションの設定方法についても説明します。

RDS Proxy の制限

RDS Proxy には以下の制限が適用されます。

  • RDS Proxy は特定の AWS リージョンでのみ利用可能です。詳細については、Amazon RDS プロキシを参照してください。

    AWS アカウント ID ごとに設定できるプロキシは最大 20 個です。アプリケーションでさらなるプロキシが必要な場合は、AWS サポート組織でチケットを開いて、追加のプロキシをリクエストできます。

  • 各プロキシには、最大 200 個の Secrets Manager シークレットを関連付けることができます。したがって、各プロキシは、任意の時点で最大 200 の異なるユーザーアカウントに接続できます。

  • プロキシごとに最大 20 のエンドポイントを作成、表示、変更、および削除できます。これらのエンドポイントは、プロキシごとに自動的に作成されるデフォルトのエンドポイントに追加されます。

  • Aurora クラスターでは、デフォルトのプロキシエンドポイントを使用するすべての接続が Aurora ライターインスタンスによって処理されます。読み込み負荷の高いワークロードの負荷分散を実行するには、プロキシの読み取り専用エンドポイントを作成できます。そのエンドポイントは、クラスターのリーダーエンドポイントに接続を渡します。そうすれば、プロキシ接続で Aurora 読み取りのスケーラビリティを利用できます。詳細については、「プロキシエンドポイントの概要」を参照してください。

    レプリケーション設定の RDS DB インスタンスの場合、リードレプリカではなく、ライター DB インスタンスにのみプロキシを関連付けることができます。

  • Aurora サーバーレスクラスターでは RDS Proxy を使用できません。

  • Aurora グローバルデータベースの一部である Aurora クラスターで RDS Proxy を使用することはできません。

  • RDS Proxy は、データベースと同じ VPC 内に存在する必要があります。プロキシにはパブリックにアクセスできませんが、データベースにはパブリックにアクセスできます。

    注記

    Aurora DB クラスターの場合、プロキシ用に追加のエンドポイントを作成し、そのエンドポイントで別の VPC、サブネット、およびセキュリティグループを指定することで、クロス VPC アクセスを有効にできます。詳細については、「Aurora へのアクセスと VPC 間の RDS データベース」を参照してください。

  • 専有テナントを含む VPC で RDS Proxy を使用することはできません。

  • IAM 認証が有効になっている RDS DB インスタンスまたは Aurora DB クラスターで RDS Proxy を使用する場合、プロキシ経由で接続するすべてのユーザーがユーザー名とパスワードで認証されていることを確認してください。RDS Proxy の IAM サポートの詳細については、「AWS Identity and Access Management (IAM) ポリシーの設定」を参照してください 。

  • カスタム DNS で RDS Proxy を使用することはできません。

  • RDS Proxy は MySQL エンジンファミリーおよび PostgreSQL エンジンファミリーで使用できます。

  • 各プロキシは、1 つのターゲット DB インスタンスまたはクラスターに関連付けることができます。ただし、同じ DB インスタンスまたはクラスターに複数のプロキシを関連付けることができます。

MySQL には、次の RDS Proxy の前提条件と制限が適用されます。

  • RDS for MySQL の場合、RDS Proxy は MySQL 5.6 および 5.7 をサポートします。Aurora MySQL の場合、RDS Proxy はバージョン 1 (MySQL 5.6 と互換) およびバージョン 2 (MySQL 5.7 と互換) をサポートします。

  • 現在、すべてのプロキシはポート 3306 で MySQL をリッスンします。プロキシは引き続き、データベース設定で指定したポートを使用してデータベースに接続します。

  • RDS for MySQL 8.0 では RDS Proxy を使用できません。

  • RDS Proxy は、EC2 インスタンスのセルフマネージド MySQL データベースでは使用できません。

  • プロキシは MySQL の圧縮モードをサポートしていません。たとえば、mysql コマンドの --compress オプションや -C オプションで使用される圧縮はサポートされていません。

  • 一部の SQL ステートメントと関数は、ピン留めを発生させずに接続状態を変更できます。ピン留めの最新の動作については、「ピン留めを回避する」を参照してください。

PostgreSQL には、次の RDS Proxy の前提条件と制限が適用されます。

  • RDS PostgreSQL の場合、RDS Proxy はバージョン 10.10 以降のマイナーバージョンと、バージョン 11.5 以降のマイナーバージョンをサポートします。Aurora PostgreSQL の場合、RDS Proxy はバージョン 10.11 以降のマイナーバージョンと、バージョン 11.6 以降のマイナーバージョンをサポートします。

  • 現在、すべてのプロキシはポート 5432 で PostgreSQL をリッスンします。

  • クエリのキャンセルは PostgreSQL ではサポートされていません。

  • PostgreSQL 関数 lastval の結果は必ずしも正確ではありません。回避策としては、INSERT ステートメントを RETURNING 句と共に使用します。

RDS Proxy 用の DB インスタンス、クラスター、アプリケーションの識別

RDS Proxy を使用することで最大の利点を得られる DB インスタンス、クラスター、およびアプリケーションを判別できます。そのためには、以下の要因を考慮します。

  • RDS Proxy プロキシは可用性が高く、複数のアベイラビリティーゾーン (AZ) にデプロイできます。データベースの全体的な高可用性を確保するには、Amazon RDS DB インスタンスまたは Aurora クラスターをマルチ AZ 設定でデプロイします。

  • 「接続が多すぎます」エラーが頻繁に発生する DB インスタンスやクラスターは、プロキシと関連付けることをお勧めします。プロキシを使用すると、アプリケーションは多数のクライアント接続を開くことができます。一方、プロキシは DB インスタンスやクラスターへの長続きする接続の数をより少なく管理します。

  • より小さい AWS インスタンスクラス (T2 や T3 など) を使用する DB インスタンスやクラスターの場合、プロキシを使用すると、メモリ不足状態を回避できます。また、接続を確立するための CPU オーバーヘッドを削減することもできます。メモリ不足状態は、多数の接続を処理するときに発生する場合があります。

  • Amazon CloudWatch の特定のメトリクスをモニタリングして、DB インスタンスまたはクラスターが特定のタイプの制限に近づいているかどうかを判断できます。これらの制限は、接続数や接続管理関連のメモリに適用されます。また、特定の CloudWatch メトリクスをモニタリングすることで、DB インスタンスやクラスターが、多数の存続期間の短い接続を処理しているかどうかも判断できます。このような接続を開いたり閉じたりすると、データベースにパフォーマンスのオーバーヘッドが生じる可能性があります。モニタリングするメトリクスの詳細については、「Amazon CloudWatch を使用した RDS Proxy のモニタリング」を参照してください。

  • AWS Lambda 関数も、プロキシの使用に適しています。これらの関数で頻繁に行う短いデータベース接続は、RDS Proxy の接続プールを使用することで利点を得られます。Lambda アプリケーションコードでデータベース認証情報を管理する代わりに、Lambda 機能に設定済みの IAM 認証を利用できます。

  • PHP や Ruby on Rails などの言語やフレームワークを使用するアプリケーションは、通常、プロキシの使用に適しています。このようなアプリケーションは、通常、多数のデータベース接続を開いたり閉じたりします。また、接続プーリング機構が組み込まれていません。

  • 長期にわたって多数の接続を開いたままにするアプリケーションは、通常、プロキシの使用に適しています。SaaS (サービスとしてのソフトウェア) や e コマースなどの業界のアプリケーションは、接続を開いたままにしておくことで、データベースリクエストのレイテンシーを最小化できる場合があります。RDS Proxy を使用すると、アプリケーションは、DB インスタンスまたはクラスターに直接接続する場合よりも多くの接続を開いたままにできます。

  • IAM 認証や Secrets Manager は設定が複雑であるという理由で、すべての DB インスタンスやクラスターには導入されていない場合があります。その場合は、既存の認証方法をそのままにして、認証をプロキシに委任できます。プロキシは、特定のアプリケーションのクライアント接続に対して認証ポリシーを適用できます。Lambda アプリケーションコードでデータベース認証情報を管理する代わりに、Lambda 機能に設定済みの IAM 認証を利用できます。

ネットワーク前提条件の設定

RDS Proxy を使用するには、一連のネットワークリソースが必要です。これには、Virtual Private Cloud (VPC)、複数のサブネット、同じ VPC 内の Amazon EC2 インスタンス、およびインターネットゲートウェイが含まれます。RDS DB インスタンスや Aurora DB クラスターに正常に接続できた場合は、必要なネットワークリソースがすでに存在します。

次の Linux の例は、AWS アカウントが所有する VPC とサブネットを調べるAWS CLIコマンドを示しています。特に、CLI を使用してプロキシを作成するときは、サブネット ID をパラメーターとして渡します。 

aws ec2 describe-vpcs
aws ec2 describe-internet-gateways
aws ec2 describe-subnets --query '*[].[VpcId,SubnetId]' --output text | sort

次の Linux の例は、特定の Aurora DB クラスターまたは RDS DB インスタンスに対応するサブネット ID を決定するAWS CLIコマンドを示しています。Auroraクラスターの場合は、まず、関連付けられた DB インスタンスの 1 つの ID を見つけます。DB インスタンスの describe 出力で、DBSubnetGroupと Subnets 属性内のネストされたフィールドを調べることで、その DB インスタンスで使用されるサブネット ID を抽出できます。データベースサーバーのプロキシを設定するときに、それらのサブネット ID の一部またはすべてを指定します。 

$ # Optional first step, only needed if you're starting from an Aurora cluster. Find the ID of any DB instance in the cluster.
$  aws rds describe-db-clusters --db-cluster-id my_cluster_id --query '*[].[DBClusterMembers]|[0]|[0][*].DBInstanceIdentifier' --output text
my_instance_id
instance_id_2
instance_id_3
...

$ # From the DB instance, trace through the DBSubnetGroup and Subnets to find the subnet IDs.
$ aws rds describe-db-instances --db-instance-id my_instance_id --query '*[].[DBSubnetGroup]|[0]|[0]|[Subnets]|[0]|[*].SubnetIdentifier' --output text
subnet_id_1
subnet_id_2
subnet_id_3
...

代わりに、最初に DB インスタンスの VPC ID を見つけることができます。次に、VPC を調べて、そのサブネットを見つけることができます。次の Linux の例はその方法を示しています。 


$ # From the DB instance, find the VPC.
$ aws rds describe-db-instances --db-instance-id my_instance_id --query '*[].[VpcId]' --output text
my_vpc_id

$ aws ec2 describe-subnets --filters Name=vpc-id,Values=my_vpc_id --query '*[].[SubnetId]' --output text
subnet_id_1
subnet_id_2
subnet_id_3
subnet_id_4
subnet_id_5
subnet_id_6

AWS Secrets Manager でのデータベース認証情報の設定

作成するプロキシごとに、まず Secrets Manager サービスを使用してユーザー名およびパスワード認証情報のセットを保存します。RDS DB インスタンスや Aurora DB クラスターで、プロキシの接続先のデータベースユーザーアカウントごとに異なる Secrets Manager シークレットを作成します。

Secrets Manager では、username および password フィールドの値を使用してこれらのシークレットを作成します。これにより、プロキシに関連付けた RDS DB インスタンスや Aurora DB クラスターの対応するデータベースユーザーにプロキシから接続できます。これを行うには、[他のデータベース認証情報]、[RDS データベース認証情報]、[他の種類のシークレット] のいずれかの設定を使用します。[ユーザー名] フィールドと [パスワード] フィールドに適切な値を入力し、その他の必須フィールドにはプレースホルダ値を入力します。プロキシは、ホスト や ポート などの他のフィールド (シークレット内に存在する場合) を無視します。これらの詳細は、プロキシによって自動的に提供されます。

[その他のタイプのシークレット] を選択することもできます。この場合、username と password という名前のキーを使用してシークレットを作成します。

プロキシが使用するシークレットは特定のデータベースサーバーに関連付けられないため、複数のデータベースサーバーで同じ認証情報を使用する場合は、複数のプロキシ間でシークレットを再利用できます。たとえば、開発サーバーとテストサーバーのグループ全体で同じ認証情報を使用できます。

特定のユーザーとしてプロキシを介して接続するには、シークレットに関連付けられているパスワードが、そのユーザーのデータベースパスワードと一致していることを確認してください。不一致がある場合は、Secrets Manager で該当するシークレットを更新できます。この場合でも、シークレットの認証情報とデータベースパスワードが一致する他のアカウントには接続できます。

AWS CLI または RDS API を通じてプロキシを作成する場合、プロキシからアクセスできるすべての DB ユーザーアカウントで対応するシークレットの Amazon リソースネーム (ARN) を指定します。AWS マネジメントコンソール では、シークレットをそのわかりやすい名前を使用して選択します。

Secrets Manager でシークレットを作成する手順については、Secrets Manager ドキュメントの「シークレットの作成」ページを参照してください。次のいずれかの方法を使用します。

  • コンソールで Secrets Manager を使用します。

  • CLI を使用して RDS Proxy 用の Secrets Manager シークレットを作成するには、次のようなコマンドを使用します。 

    aws secretsmanager create-secret
  --name "secret_name"
  --description "secret_description"
  --region region_name
  --secret-string '{"username":"db_user","password":"db_user_password"}'

たとえば、以下のコマンドは、2 つのデータベースユーザーの Secrets Manager シークレットを作成します。1 つは admin という名前で、もう 1 つはapp-user という名前です。 

aws secretsmanager create-secret \
  --name admin_secret_name --description "db admin user" \
  --secret-string '{"username":"admin","password":"choose_your_own_password"}'

aws secretsmanager create-secret \
  --name proxy_secret_name --description "application user" \
  --secret-string '{"username":"app-user","password":"choose_your_own_password"}'

AWS アカウントが所有する秘密を確認するには、次のようなコマンドを使用します。 

aws secretsmanager list-secrets

CLI を使用してプロキシを作成する場合、1 つ以上のシークレットの Amazon リソースネーム (ARN) を --auth パラメータに渡します。次の Linux の例は、AWS アカウントが所有する各シークレットの名前と ARN のみを含むレポートを準備する方法を示しています。この例では、AWS CLI バージョン 2 で使用可能な --output table パラメーターを使用します。AWS CLI バージョン 1 を使用している場合は、代わりに --output text を使用します。 

aws secretsmanager list-secrets --query '*[].[Name,ARN]' --output table

シークレットに正しい資格情報を正しい形式で格納したことを確認するには、次のようなコマンドを使用します。your_secret_nameは、ショートネームまたはシークレットの ARN に置き換えます。 

aws secretsmanager get-secret-value --secret-id your_secret_name

出力には、次のような JSON でエンコードした値を表示する行を含める必要があります。 

"SecretString": "{\"username\":\"your_username\",\"password\":\"your_password\"}",

AWS Identity and Access Management (IAM) ポリシーの設定

Secrets Manager でシークレットを作成したら、これらのシークレットにアクセスできる IAM ポリシーを作成します。RDS および Aurora での IAM の使用に関する一般的な情報については、「Amazon RDS での Identity and Access Management」を参照してください。

ヒント

以下の手順は、IAM コンソールを使用する場合に適用されます。RDS に AWS マネジメントコンソール を使用する場合は、RDS によって自動的に IAM ポリシーが作成されます。その場合は、以下の手順を省略できます。

プロキシで使用する Secrets Manager シークレットにアクセスするための IAM ポリシーを作成するには

  1. IAM コンソールにサインインします。「IAM ロールの作成」で説明されている「ロールの作成」プロセスに従います。ロールをデータベースに追加するステップを含めます。

  2. 新しいロールの場合は、インラインポリシーを追加するステップを実行します。「IAM ポリシーの編集」と同じ一般的な手順を使用します。以下の JSON を [JSON] テキストボックスに貼り付けます。自分のアカウント ID に置き換えます。AWS リージョンを us-east-2 に置き換えてください。作成したシークレットを Amazon リソースネーム (ARN) に置き換えます。kms:Decrypt アクションでは、Secrets Manager シークレットの暗号化に使用したキーに応じて、デフォルトの AWS KMS カスタマーマスターキー (CMK) または独自の AWS KMS CMK の ARN を置き換えます。 

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "secretsmanager:GetSecretValue",
            "Resource": [
                "arn:aws:secretsmanager:us-east-2:account_id:secret:secret_name_1",
                "arn:aws:secretsmanager:us-east-2:account_id:secret:secret_name_2"
            ]
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "kms:Decrypt",
            "Resource": "arn:aws:kms:us-east-2:account_id:key/key_id",
            "Condition": {
                "StringEquals": {
                    "kms:ViaService": "secretsmanager.us-east-2.amazonaws.com"
                }
            }
        }
    ]
}

  3. この IAM ロールの信頼ポリシーを編集します。以下の JSON を [JSON] テキストボックスに貼り付けます。 

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "rds.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

次のコマンドは、AWS CLI で同じ操作を実行します。 

PREFIX=choose_an_identifier

aws iam create-role --role-name choose_role_name \
  --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":["rds.amazonaws.com"]},"Action":"sts:AssumeRole"}]}'

aws iam put-role-policy --role-name same_role_name_as_previous \
  --policy-name $PREFIX-secret-reader-policy --policy-document """
same_json_as_in_previous_example
"""

aws kms create-key --description "$PREFIX-test-key" --policy """
{
  "Id":"$PREFIX-kms-policy",
  "Version":"2012-10-17",
  "Statement":
    [
      {
        "Sid":"Enable IAM User Permissions",
        "Effect":"Allow",
        "Principal":{"AWS":"arn:aws:iam::account_id:root"},
        "Action":"kms:*","Resource":"*"
      },
      {
        "Sid":"Allow access for Key Administrators",
        "Effect":"Allow",
        "Principal":
          {
            "AWS":
              ["$USER_ARN","arn:aws:iam::account_id:role/Admin"]
          },
        "Action":
          [
            "kms:Create*",
            "kms:Describe*",
            "kms:Enable*",
            "kms:List*",
            "kms:Put*",
            "kms:Update*",
            "kms:Revoke*",
            "kms:Disable*",
            "kms:Get*",
            "kms:Delete*",
            "kms:TagResource",
            "kms:UntagResource",
            "kms:ScheduleKeyDeletion",
            "kms:CancelKeyDeletion"
          ],
        "Resource":"*"
      },
      {
        "Sid":"Allow use of the key",
        "Effect":"Allow",
        "Principal":{"AWS":"$ROLE_ARN"},
        "Action":["kms:Decrypt","kms:DescribeKey"],
        "Resource":"*"
      }
    ]
}
"""

RDS Proxy の作成

指定した DB インスタンスのセットに対する接続を管理するには、プロキシを作成します。プロキシは、RDS for MySQL DB インスタンス、PostgreSQL DB インスタンス、または Aurora DB クラスターに関連付けることができます。

プロキシを作成するには

  1. AWS マネジメントコンソールにサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[プロキシ] を選択します。

  3. [Create proxy (プロキシの作成)] を選択します。

  4. プロキシのすべての設定を選択します。

    [プロキシの設定] で、以下の情報を提供します。

    • プロキシ識別子。AWS アカウント ID と現在の AWS リージョン内で一意の名前を選択して入力します。

    • エンジンの互換性。MySQL または POSTGRESQL を選択します。

    • Transport Layer Security が必要。プロキシですべてのクライアント接続に対して TLS/SSL を適用する場合は、この設定を選択します。プロキシへの暗号化された接続または暗号化されていない接続を使用すると、プロキシは基となるデータベースへの接続時に同じ暗号化設定を使用します。

    • アイドル状態のクライアント接続のタイムアウト。プロキシがクライアント接続を閉じるまでに接続がアイドル状態を継続できる時間を選択します。デフォルトは 1,800 秒 (30 分) です。クライアント接続がアイドル状態と見なされるのは、前のリクエストの完了後、新しいリクエストが指定時間内にアプリケーションから送信されない場合です。基となるデータベース接続は開いたままで、接続プールに返されるため、新しいクライアント接続で再利用できます。

      プロキシで古い接続を事前に削除する場合は、アイドル状態のクライアント接続のタイムアウトを短くすることを検討してください。ワークロードがスパイクしている場合は、接続を確立するコストを節約するために、アイドル状態のクライアント接続のタイムアウトを長くすることを検討してください。

    [ターゲットグループの設定] で、以下の情報を提供します。

    • データベース。このプロキシを介してアクセスする RDS DB インスタンスまたは Aurora DB クラスターを 1 つ選択します。このリストには、互換性のあるデータベースエンジン、エンジンバージョン、および他の設定を持つ DB インスタンスとクラスターのみが含まれます。リストが空の場合は、RDS Proxy と互換性のある新しい DB インスタンスまたはクラスターを作成します。これを行うには、「Amazon RDS DB インスタンスの作成」の手順に従います。次に、プロキシの作成をもう一度試します。

    • 接続プールの最大接続数。1 ～ 100 の値を指定します。この設定は、RDS Proxy が接続に使用できる max_connections 値の割合 (%) を表します。この DB インスタンスまたはクラスターで 1 つのプロキシのみを使用する場合は、この値を 100 に設定できます。この設定を RDS Proxy で使用する方法の詳細については、「接続の制限とタイムアウトの制御」を参照してください。

    • セッションのピン留めフィルタ。(オプション) これは、特定のアプリケーションのパフォーマンス問題についてトラブルシューティングを行うための高度な設定です。現在、唯一の選択肢は EXCLUDE_VARIABLE_SETS です。フィルタを選択するのは、次の両方に当てはまる場合です。アプリケーションで接続が再利用されていない原因が特定の種類の SQL ステートメントにある。これらの SQL ステートメントを使用して接続を再利用してもアプリケーションの正確性に影響がない。詳細については、「ピン留めを回避する」を参照してください。

    • 接続の借用タイムアウト。場合によっては、利用可能なすべてのデータベース接続をプロキシが使い切ることがあります。このような場合、プロキシがタイムアウトエラーを返す前に、データベース接続が使用可能になるまで待つ時間を指定できます。最大 5 分の期間を指定できます。この設定は、プロキシで最大数の接続が開いていて、すべての接続がすでに使用されている場合にのみ適用されます。

    [接続性] で、以下の情報を提供します。

    • Secrets Manager の ARN。このプロキシでアクセスする RDS DB インスタンスまたは Aurora DB クラスターの DB ユーザー認証情報を含む Secrets Manager シークレットを少なくとも 1 つ選択します。

    • IAM ロール。前に選択した Secrets Manager シークレットに対するアクセス許可のある IAM ロールを選択します。また、AWS マネジメントコンソール で新しい IAM ロールを作成して使用することを選択することもできます。

    • IAM 認証。プロキシへの接続に IAM 認証を要求するか拒否するかを選択します。IAM 認証またはネイティブデータベース認証の選択は、このプロキシにアクセスするすべての DB ユーザーに適用されます。

    • サブネット。このフィールドには、VPC に関連付けられたすべてのサブネットがあらかじめ入力されています。このプロキシに不要なサブネットは削除できます。少なくとも 2 つのサブネットを残す必要があります。

    追加の接続設定を定義します。

    • VPC セキュリティグループ。既存の VPC セキュリティグループを選択します。また、AWS マネジメントコンソール で新しいセキュリティグループを作成して使用することを選択することもできます。

      注記

      このセキュリティグループは、プロキシの接続先のデータベースへのアクセスを許可する必要があります。同じセキュリティグループが、アプリケーションからプロキシへのイングレスと、プロキシからデータベースへのエグレスに使用されます。たとえば、データベースとプロキシに同じセキュリティグループを使用するとします。この場合は必ず、そのセキュリティグループ内のリソースが同じセキュリティグループ内の他のリソースと通信できるように指定してください。

    (オプション) 詳細設定を定義します。

    • 拡張ログ記録の有効化。この設定を有効にして、プロキシの互換性やパフォーマンスの問題のトラブルシューティングを行うことができます。

      この設定を有効にすると、RDS Proxy は SQL ステートメントに関する詳細情報をログに含めます。この情報に基づいて、SQL の動作やプロキシ接続のパフォーマンスとスケーラビリティに関する問題をデバッグできます。デバッグ情報には、プロキシ経由で送信する SQL ステートメントのテキストが含まれます。したがって、この設定を有効にするのは、デバッグに必要な場合と、ログ内の機密情報を保護するセキュリティ対策がある場合に限ります。

      プロキシに関連するオーバーヘッドを最小限に抑えるために、この設定は有効にしてから 24 時間後に RDS Proxy によって自動的にオフにされます。特定の問題のトラブルシューティングを行うには、その設定を一時的に有効にします。

  5. [Create proxy (プロキシの作成)] を選択します。

プロキシを作成するには、AWS CLI コマンド create-db-proxy を使用します。--engine-family 値は大文字と小文字が区別されます。

例

Linux、macOS、Unix の場合:

aws rds create-db-proxy \
    --db-proxy-name proxy_name \
    --engine-family { MYSQL | POSTGRESQL } \
    --auth ProxyAuthenticationConfig_JSON_string \
    --role-arn iam_role \
    --vpc-subnet-ids space_separated_list \
    [--vpc-security-group-ids space_separated_list] \
    [--require-tls | --no-require-tls] \
    [--idle-client-timeout value] \
    [--debug-logging | --no-debug-logging] \
    [--tags comma_separated_list]

Windows の場合:

aws rds create-db-proxy ^
    --db-proxy-name proxy_name ^
    --engine-family { MYSQL | POSTGRESQL } ^
    --auth ProxyAuthenticationConfig_JSON_string ^
    --role-arn iam_role ^
    --vpc-subnet-ids space_separated_list ^
    [--vpc-security-group-ids space_separated_list] ^
    [--require-tls | --no-require-tls] ^
    [--idle-client-timeout value] ^
    [--debug-logging | --no-debug-logging] ^
    [--tags comma_separated_list]
ヒント

--vpc-subnet-ids パラメータに使用するサブネット ID がまだわからない場合は、「ネットワーク前提条件の設定」を使用して、使用できるサブネット ID を検索する方法の例をご参照ください。

プロキシに必要な情報と関連付けを作成するには、register-db-proxy-targets コマンドも使用します。ターゲットグループ名 default を指定します。各プロキシを作成するときに、RDS Proxy によってこの名前のターゲットグループが自動的に作成されます。 

aws rds register-db-proxy-targets
    --db-proxy-name value
    [--target-group-name target_group_name]
    [--db-instance-identifiers space_separated_list]  # rds db instances, or
    [--db-cluster-identifiers cluster_id]        # rds db cluster (all instances), or
    [--db-cluster-endpoint endpoint_name]          # rds db cluster endpoint (all instances)

RDS プロキシを作成するには、Amazon RDS API オペレーション CreateDBProxy を呼び出します。AuthConfig データ構造でパラメータを渡します。

RDS Proxyは、各プロキシを作成するときに、default という名前のターゲットグループが自動的に作成します。RegisterDBProxyTargets 関数を呼び出して、このターゲットグループに RDS DB インスタンスまたは Aurora DB クラスターを関連付けます。

RDS Proxy の表示

1 つ以上の RDS プロキシを作成すると、すべてのプロキシを表示して設定の詳細を確認し、変更や削除などを行うプロキシを選択できます。

プロキシを使用するデータベースアプリケーションでは、接続文字列でプロキシエンドポイントを使用する必要があります。

プロキシを表示するには

  1. AWS マネジメントコンソールにサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. AWS マネジメントコンソール の右上で、RDS Proxy を作成した AWS リージョンを選択します。

  3. ナビゲーションペインで、[プロキシ] を選択します。

  4. 詳細を表示する RDS プロキシの名前を選択します。

  5. 詳細ページの [ターゲットグループ] セクションに、プロキシと特定の RDS DB インスタンスや Aurora DB クラスターとの関連付けが表示されます。[デフォルト] ターゲットグループページへのリンクに従って、プロキシとデータベースの関連付けの詳細を表示できます。このページには、最大接続数の割合 (%)、接続の借用タイムアウト、エンジンの互換性、セッションのピン留めフィルターなど、プロキシの作成時に指定した設定が表示されます。

CLI を使用してプロキシを表示するには、describe-db-proxies コマンドを使用します。デフォルトでは、AWS アカウントが所有するすべてのプロキシが表示されます。単一のプロキシの詳細を表示するには、 --db-proxy-name パラメータで名前を指定します。 

aws rds describe-db-proxies [--db-proxy-name proxy_name]

プロキシに関連付けられた他の情報を表示するには、以下のコマンドを使用します。 

aws rds describe-db-proxy-target-groups  --db-proxy-name proxy_name

aws rds describe-db-proxy-targets --db-proxy-name proxy_name

プロキシに関連付けられている情報の詳細を表示するには、次のコマンドのシーケンスを使用します。

  1. プロキシのリストを取得するには、describe-db-proxies を実行します。

  2. プロキシが使用できる接続の最大割合などの接続パラメータを表示するには、describe-db-proxy-target-groups --db-proxy-name を実行し、パラメータ値としてプロキシの名前を使用します。

  3. 返されたターゲットグループに関連付けられている RDS DB インスタンスや Aurora DB クラスターの詳細を表示するには、describe-db-proxy-targets を実行します。

RDS API を使用してプロキシを表示するには、DescribeDBProxies オペレーションを使用します。DBProxy データ型の値が返されます。

プロキシの接続設定の詳細を表示するには、この戻り値のプロキシ識別子を DescribeDBProxyTargetGroups オペレーションで使用します。DBProxyTargetGroup データ型の値が返されます。

プロキシに関連付けられている RDS インスタンスや Aurora DB クラスターを表示するには、DescribeDBProxyTargets オペレーションを使用します。DBProxyTarget データ型の値が返されます。

RDS Proxy を介したデータベースへの接続

プロキシを介して RDS DB インスタンスや Aurora DB クラスターに接続する方法は、データベースに直接接続する方法とほぼ同じです。主な違いは、インスタンスやクラスターのエンドポイントの代わりに、プロキシのエンドポイントを指定することです。Aurora DB クラスターの場合、すべてのプロキシ接続にはデフォルトで読み取り/書き込み機能があり、ライターインスタンスを使用します。通常、読み取り専用の接続にリーダーエンドポイントを使用する場合は、プロキシ用の追加の読み取り専用エンドポイントを作成し、そのエンドポイントを同じ方法で使用できます。詳細については、「プロキシエンドポイントの概要」を参照してください。

ネイティブ認証を使用したプロキシへの接続

以下の基本的な手順でネイティブ認証を使用してプロキシに接続します。

  1. プロキシエンドポイントを見つけます。AWS マネジメントコンソール では、プロキシの詳細ページで対応するエンドポイントを見つけることができます。AWS CLI では、describe-db-proxies コマンドを使用できます。以下の例のように指定します。 

    # Add --output text to get output as a simple tab-separated list.
$ aws rds describe-db-proxies --query '*[*].{DBProxyName:DBProxyName,Endpoint:Endpoint}'
[
    [
        {
            "Endpoint": "the-proxy.proxy-demo.us-east-1.rds.amazonaws.com",
            "DBProxyName": "the-proxy"
        },
        {
            "Endpoint": "the-proxy-other-secret.proxy-demo.us-east-1.rds.amazonaws.com",
            "DBProxyName": "the-proxy-other-secret"
        },
        {
            "Endpoint": "the-proxy-rds-secret.proxy-demo.us-east-1.rds.amazonaws.com",
            "DBProxyName": "the-proxy-rds-secret"
        },
        {
            "Endpoint": "the-proxy-t3.proxy-demo.us-east-1.rds.amazonaws.com",
            "DBProxyName": "the-proxy-t3"
        }
    ]
]

  2. クライアントアプリケーションの接続文字列で、そのエンドポイントをホストパラメータとして指定します。たとえば、mysql -h オプションまたは psql -h オプションの値としてプロキシエンドポイントを指定します。

  3. 通常と同じようにデータベースのユーザー名とパスワードを指定します。

IAM 認証を使用したプロキシへの接続

RDS Proxy で IAM 認証を使用する場合は、通常のユーザー名とパスワードで認証するようにデータベースユーザーを設定します。IAM 認証は、Secrets Manager からユーザー名とパスワードの認証情報 RDS Proxy を取得する場合に適用されます。RDS Proxy から基礎となるデータベースへの接続は IAM を経由しません。

IAM 認証を使用して RDS Proxy に接続するには、IAM 認証を使用して RDS DB インスタンスまたは Aurora クラスターに接続する場合と同じ一般的な手順に従います。RDS および Aurora での IAM の使用に関する一般的な情報については、「Amazon RDS でのセキュリティ」を参照してください。

RDS Proxy での IAM の使用方法の主な違いは以下のとおりです。

  • 認可プラグインで個々のデータベースユーザーを設定することはありません。データベースユーザーが通常使用するユーザー名とパスワードはデータベース内に保管されています。これらのユーザー名とパスワードを含む Secrets Manager シークレットを設定し、RDS Proxy に Secrets Manager からの認証情報の取得を認可します。

    重要

    IAM 認証がクライアントプログラムとプロキシ間の接続に適用されます。その後、プロキシは、Secrets Manager から取得したユーザー名とパスワードの認証情報を使用して、データベースに対して認証します。プロキシへの接続に IAM を使用する場合は、基になる RDS DB インスタンスまたは Aurora DB クラスターで IAM が有効になっていないことを確認します。

  • インスタンス、クラスター、またはリーダーの各エンドポイントの代わりに、プロキシエンドポイントを指定します。プロキシエンドポイントの詳細については、「IAM 認証を使用した DB インスタンスへの接続」を参照してください。

  • 直接 DB IAM 認証の場合は、データベースユーザーを選択し、特別な認証プラグインで識別されるように設定します。その後、IAM 認証を使用してそれらのユーザーに接続できます。

    プロキシのユースケースでは、ユーザーのユーザー名とパスワード (ネイティブ認証) を含むシークレットをプロキシに提供する必要があります。次に、IAM 認証 (データベースエンドポイントではなくプロキシエンドポイントで認証トークンを生成することによる)、および先ほど提供したシークレットのユーザー名のいずれかと一致するユーザー名を使用して、プロキシに接続します。

  • IAM 認証を使用してプロキシに接続する場合は、Transport Layer Security (TLS) / Secure Sockets Layer (SSL) を使用する必要があります。

IAM ポリシーを変更することで、特定のユーザーにプロキシへのアクセスを許可できます。以下に例を示します。 

"Resource": "arn:aws:rds-db:us-east-2:1234567890:dbuser:prx-ABCDEFGHIJKL01234/db_user"

PostgreSQL でプロキシに接続する際の考慮事項

PostgreSQL では、クライアントは PostgreSQL データベースへの接続を開始するとき、パラメータ名と値の文字列のペアを含む起動メッセージを送信します。詳細については、PostgreSQL ドキュメントの「PostgreSQL Message Formats」で StartupMessage を参照してください。

RDS プロキシを介して接続する場合、起動メッセージには、現在認識されている以下のパラメータを含めることができます。

  • user

  • database

  • replication

起動メッセージには、以下の追加のランタイムパラメータを含めることもできます。

PostgreSQL メッセージの詳細については、PostgreSQL ドキュメントの「Frontend/Backend Protocol」を参照してください。

PostgreSQL では、JDBC を使用する場合、ピン留めを回避するために以下の操作をお勧めします。

  • ピン留めを回避するために、JDBC 接続パラメータ assumeMinServerVersion を 9.0 以上に設定します。これを行うと、JDBC ドライバーが SET extra_float_digits = 3 を実行するとき、接続の開始中に余分なラウンドトリップを実行しなくなります。

  • ピン留めを回避するために、JDBC 接続パラメータ ApplicationName を any/your-application-name に設定します。これを行うと、JDBC ドライバーが SET application_name = "PostgreSQL JDBC Driver" を実行するときの接続の開始中に余分なラウンドトリップを実行しなくなります。JDBC パラメータは ApplicationName ですが、PostgreSQL StartupMessage パラメータは application_name です。

  • ピン留めを回避するために、JDBC 接続パラメータ preferQueryMode を extendedForPrepared に設定します。extendedForPrepared により、拡張モードがプリペアドステートメントにのみ使用されことになります。

    preferQueryMode パラメータのデフォルトは extended であり、拡張モードがすべてのクエリに使用されます。拡張モードでは、一連の Prepare、Bind、Execute、および Sync リクエストと対応するレスポンスを使用します。このタイプの一連のリクエストとレスポンスにより、RDS プロキシで接続がピン留めされます。

詳細については、「ピン留めを回避する」を参照してください。JDBC を使用した接続の詳細については、PostgreSQL ドキュメントの「Connecting to the Database」を参照してください。

RDS Proxy の管理

次に、RDS プロキシのオペレーションと設定を管理する方法について説明します。以下の手順は、アプリケーションがデータベース接続を最も効率的に使用し、接続を最大限に再利用するのに役立ちます。接続の再利用率を高めるほど、CPU とメモリのオーバーヘッドを減らすことができます。これにより、アプリケーションのレイテンシーを減らし、データベースのより多くのリソースをアプリケーションからのリクエストの処理に集中させることができます。

RDS Proxy の変更

プロキシの作成後に、プロキシに関連付けられた特定の設定を変更できます。これを行うには、プロキシ自体、プロキシに関連付けられているターゲットグループ、またはその両方を変更します。各プロキシには、ターゲットグループが関連付けられています。

プロキシの設定を変更するには

  1. AWS マネジメントコンソールにサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[プロキシ] を選択します。

  3. プロキシのリストで、設定を変更するプロキシを選択するか、その詳細ページに移動します。

  4. [アクション]、[変更] の順に選択します。

  5. 変更するプロパティを入力または選択します。以下の操作を行うことができます。

    • プロキシの名前を変更するには、新しい識別子を入力します。

    • Transport Layer Security (TLS) の要件をオンまたはオフにします。

    • アイドル接続のタイムアウトの時間を入力します。

    • Secrets Manager シークレットを追加または削除します。これらのシークレットは、データベースのユーザー名とパスワードに対応します。

    • Secrets Manager からシークレットを取得するために使用する IAM ロールを変更します。

    • プロキシへの接続に IAM 認証をすることを要求または禁止します。

    • プロキシで使用する VPC サブネットを追加または削除します。

    • プロキシで使用する VPC セキュリティグループを追加または削除します。

    • 拡張ログ記録を有効または無効にします。

  6. [Modify] を選択します。

変更する設定がリストにない場合は、以下の手順を使用して、プロキシのターゲットグループを更新します。プロキシに関連付けられているターゲットグループは、物理データベース接続に関連する設定を制御します。プロキシごとに default という名前の 1 つのターゲットグループが関連付けられています。このターゲットグループはプロキシと共に自動的に作成されます。

ターゲットグループは、プロキシの詳細ページからのみ変更できます。[プロキシ] ページのリストから変更することはできません。

プロキシのターゲットグループの設定を変更するには

  1. [プロキシ] ページから、プロキシの詳細ページに移動します。

  2. [ターゲットグループ] で、default リンクを選択します。現在、すべてのプロキシには default という名前のターゲットグループが 1 つ あります。

  3. [デフォルト] ターゲットグループの詳細ページで、[変更] を選択します。

  4. 変更できるプロパティに対して新しい設定を選択します。

    • 別の RDS DB インスタンスまたは Aurora クラスターを選択します。

    • プロキシに使用できる最大接続数の割合 (%) を調整できます。

    • セッションのピン留めフィルタを選択します。これにより、トランザクションレベルでの不十分な接続の再利用に起因するパフォーマンス問題を軽減できます。この設定を使用するには、RDS Proxy でセッションをデータベース接続にピン留めする場合のアプリケーションの動作と状況を理解する必要があります。

    • 接続の借用タイムアウト間隔を調整します。この設定は、プロキシで最大数の接続がすでに使用されている場合に適用されます。この設定により、プロキシがタイムアウトエラーを返す前に、接続が使用可能になるまで待つ時間が決まります。

    ターゲットグループ識別子やデータベースエンジンなどの特定のプロパティは変更できません。

  5. [Modify target group (ターゲットグループの変更)] を選択します。

AWS CLI を使用してプロキシを変更するには、modify-db-proxy、modify-db-proxy-target-group、deregister-db-proxy-targets、register-db-proxy-targets の各コマンドを使用します。

modify-db-proxy コマンドを使用すると、次のようなプロパティを変更できます。

  • プロキシで使用する一連の Secrets Manager シークレット。

  • TLS が必要かどうか。

  • アイドルクライアントのタイムアウト。

  • デバッグ用に SQL ステートメントからの追加情報をログに記録するかどうか。

  • Secrets Manager シークレットの取得に使用する IAM ロール。

  • プロキシで使用するセキュリティグループ。

次の例は、既存のプロキシの名前を変更する方法を示しています。 

aws rds modify-db-proxy --db-proxy-name the-proxy --new-db-proxy-name the_new_name

接続関連の設定を変更したり、ターゲットグループの名前を変更したりするには、modify-db-proxy-target-group コマンドを使用します。現在、すべてのプロキシには default という名前のターゲットグループが 1 つ あります。このターゲットグループを使用する場合、プロキシの名前とターゲットグループ名 (default) を指定します。

次の例は、最初にプロキシの MaxIdleConnectionsPercent 設定をチェックし、次にターゲットグループを使用して設定を変更する方法を示しています。 

aws rds describe-db-proxy-target-groups --db-proxy-name the-proxy

{
    "TargetGroups": [
        {
            "Status": "available",
            "UpdatedDate": "2019-11-30T16:49:30.342Z",
            "ConnectionPoolConfig": {
                "MaxIdleConnectionsPercent": 50,
                "ConnectionBorrowTimeout": 120,
                "MaxConnectionsPercent": 100,
                "SessionPinningFilters": []
            },
            "TargetGroupName": "default",
            "CreatedDate": "2019-11-30T16:49:27.940Z",
            "DBProxyName": "the-proxy",
            "IsDefault": true
        }
    ]
}

aws rds modify-db-proxy-target-group --db-proxy-name the-proxy --target-group-name default --connection-pool-config '
{ "MaxIdleConnectionsPercent": 75 }'

{
    "DBProxyTargetGroup": {
        "Status": "available",
        "UpdatedDate": "2019-12-02T04:09:50.420Z",
        "ConnectionPoolConfig": {
            "MaxIdleConnectionsPercent": 75,
            "ConnectionBorrowTimeout": 120,
            "MaxConnectionsPercent": 100,
            "SessionPinningFilters": []
        },
        "TargetGroupName": "default",
        "CreatedDate": "2019-11-30T16:49:27.940Z",
        "DBProxyName": "the-proxy",
        "IsDefault": true
    }
}

register-db-proxy-targets コマンドと deregister-db-proxy-targets コマンドでは、ターゲットグループを通じてプロキシが関連付けられている RDS DB インスタンスまたは Aurora DB クラスターを変更します。現在、各プロキシが接続できる RDS DB インスタンスまたは Aurora DB クラスターは 1 つです。ターゲットグループは、マルチ AZ 設定のすべての RDS DB インスタンス、または Aurora クラスター内のすべての DB インスタンスの接続の詳細を追跡します。

次の例では、cluster-56-2020-02-25-1399 という名前の Aurora MySQL クラスターに関連付けられているプロキシを最初に使用します。次に、このプロキシを変更して provisioned-cluster という名前の別のクラスターに接続できるようにします。

RDS DB インスタンスを使用する場合は、--db-instance-identifier オプションを指定します。Aurora DB クラスターを使用する場合は、代わりに --db-cluster-identifier オプションを指定します。

次の例では、Aurora MySQL プロキシを変更します。Aurora PostgreSQL プロキシにはポート 5432 があります。 

aws rds describe-db-proxy-targets --db-proxy-name the-proxy

{
    "Targets": [
        {
            "Endpoint": "instance-9814.demo.us-east-1.rds.amazonaws.com",
            "Type": "RDS_INSTANCE",
            "Port": 3306,
            "RdsResourceId": "instance-9814"
        },
        {
            "Endpoint": "instance-8898.demo.us-east-1.rds.amazonaws.com",
            "Type": "RDS_INSTANCE",
            "Port": 3306,
            "RdsResourceId": "instance-8898"
        },
        {
            "Endpoint": "instance-1018.demo.us-east-1.rds.amazonaws.com",
            "Type": "RDS_INSTANCE",
            "Port": 3306,
            "RdsResourceId": "instance-1018"
        },
        {
            "Type": "TRACKED_CLUSTER",
            "Port": 0,
            "RdsResourceId": "cluster-56-2020-02-25-1399"
        },
        {
            "Endpoint": "instance-4330.demo.us-east-1.rds.amazonaws.com",
            "Type": "RDS_INSTANCE",
            "Port": 3306,
            "RdsResourceId": "instance-4330"
        }
    ]
}

aws rds deregister-db-proxy-targets --db-proxy-name the-proxy --db-cluster-identifier cluster-56-2020-02-25-1399

aws rds describe-db-proxy-targets --db-proxy-name the-proxy

{
    "Targets": []
}

aws rds register-db-proxy-targets --db-proxy-name the-proxy --db-cluster-identifier provisioned-cluster

{
    "DBProxyTargets": [
        {
            "Type": "TRACKED_CLUSTER",
            "Port": 0,
            "RdsResourceId": "provisioned-cluster"
        },
        {
            "Endpoint": "gkldje.demo.us-east-1.rds.amazonaws.com",
            "Type": "RDS_INSTANCE",
            "Port": 3306,
            "RdsResourceId": "gkldje"
        },
        {
            "Endpoint": "provisioned-1.demo.us-east-1.rds.amazonaws.com",
            "Type": "RDS_INSTANCE",
            "Port": 3306,
            "RdsResourceId": "provisioned-1"
        }
    ]
}

RDS API を使用してプロキシを変更するには、ModifyDBProxy、ModifyDBProxyTargetGroup、DeregisterDBProxyTargets、RegisterDBProxyTargets の各オペレーションを使用します。

ModifyDBProxy では、次のようなプロパティを変更できます。

  • プロキシで使用する一連の Secrets Manager シークレット。

  • TLS が必要かどうか。

  • アイドルクライアントのタイムアウト。

  • デバッグ用に SQL ステートメントからの追加情報をログに記録するかどうか。

  • Secrets Manager シークレットの取得に使用する IAM ロール。

  • プロキシで使用するセキュリティグループ。

ModifyDBProxyTargetGroup では、接続関連の設定や、ターゲットグループの名前を変更できます。現在、すべてのプロキシには default という名前のターゲットグループが 1 つ あります。このターゲットグループを使用する場合、プロキシの名前とターゲットグループ名 (default) を指定します。

DeregisterDBProxyTargets コマンドと RegisterDBProxyTargets コマンドでは、ターゲットグループを通じてプロキシが関連付けられている RDS DB インスタンスまたは Aurora DB クラスターを変更します。現在、各プロキシが接続できる RDS DB インスタンスまたは Aurora DB クラスターは 1 つです。ターゲットグループは、マルチ AZ 設定のすべての RDS DB インスタンス、または Aurora クラスター内のすべての DB インスタンスの接続の詳細を追跡します。

新しいデータベースユーザーの追加

状況に応じて、プロキシに関連付けられている RDS DB インスタンスや Aurora クラスターに新しいデータベースユーザーを追加できます。その場合は、Secrets Manager シークレットを追加または転用して、そのユーザーの認証情報を保存します。これを行うには、次のいずれかのオプションを選択します。

  • 「AWS Secrets Manager でのデータベース認証情報の設定」で説明している手順を使用して、新しい Secrets Manager シークレットを作成します。

  • IAM ロールを更新して、RDS Proxy に新しい Secrets Manager シークレットへのアクセスを許可します。そのためには、IAM ロールポリシーのリソースセクションを更新します。

  • 既存のユーザーを新しいユーザーに置き換える場合は、プロキシで既存のユーザーの Secrets Manager シークレットに保存されている認証情報を更新します。

データベースユーザーのパスワードの変更

状況に応じて、プロキシに関連付けられている RDS DB インスタンスや Aurora クラスターのデータベースユーザーのパスワードを変更できます。その場合は、対応する Secrets Manager シークレットを新しいパスワードで更新します。

接続の制限とタイムアウトの制御

RDS Proxy は、RDS DB インスタンスまたは Aurora DB クラスターの max_connections 設定を使用します。この設定は、プロキシが一度に開くことができる接続全体の上限を示します。Aurora クラスターや RDS マルチ AZ 設定で、プロキシが使用する max_connections 値は、Aurora プライマリインスタンスや RDS ライターインスタンスの値です。

RDS DB インスタンスまたは Aurora DB クラスターにこの値を設定するには、「DB パラメータグループを使用する」の手順に従います。以下の手順では、パラメータグループをデータベースに関連付け、パラメータグループの max_connections 値を編集する方法を示しています。

プロキシ設定の最大接続数は、プロキシに関連付けられているデータベースの max_connections 値の割合を表します。複数のアプリケーションのすべてで同じデータベースを使用している場合、アプリケーションごとに max_connections の特定の割合でプロキシを使用することで、接続クォータを効率的に分割できます。その場合は、同じデータベースに関連付けられているすべてのプロキシの割合の合計が 100% 以下であることを確認してください。

RDS Proxy はアイドル状態の接続を定期的に切断し、接続プールに戻します。このタイムアウト間隔を調整できます。これにより、アプリケーションは古いリソースを処理できます。特に、重要なデータベースリソースが保留されているときに誤って接続を開いたままにしている場合に対応できます。

接続プールの管理とモニタリング

「接続プーリング」で説明しているように、接続プーリングは RDS Proxy の重要な機能です。次に、接続プーリングとトランザクションレベルの接続の再利用 (多重化) を最も効率的に使用する方法について説明します。

接続プールは RDS Proxy によって管理されるため、アプリケーションコードを変更することなく、接続プールをモニタリングして接続の制限とタイムアウト間隔を調整できます。

プロキシごとに、接続プールで使用される接続数の上限を指定できます。上限は割合 (%) で指定します。この割合は、データベースで設定されている最大接続数に適用されます。正確な数は、DB インスタンスのサイズと設定によって異なります。

たとえば、データベースの最大接続数の 75% を使用するように RDS Proxy を設定したとします。MySQL の場合、最大値は max_connections 設定パラメータによって定義されます。この場合、最大接続数の残りの 25% は、他のプロキシや、プロキシを経由しない接続に割り当てることができます。場合によっては、プロキシで特定の時間に開いている接続の数が最大接続数の 75 パーセントに満たないことがあります。たとえば、データベースに多数の同時接続がない場合や、一部の接続が長時間アイドル状態になっている場合があります。

接続プールで使用できる接続の総数は、RDS DB インスタンスや Aurora クラスターに適用される max_connections 設定を更新すると、変わります。

プロキシは、これらの接続のすべてを事前に予約するわけではありません。したがって、比較的大きな割合を指定できます。これらの接続は、プロキシがビジーとなって接続を必要とする状態になったときにのみ開かれます。

アプリケーションで接続を使用できるようになるまでの待機時間を選択できます。この時間は、プロキシの作成時に [Connection borrow timeout (接続の借用タイムアウト)] オプションで設定します。この設定では、タイムアウトエラーを返すまでに接続プールで接続が利用可能になるのを待機する時間を指定します。これは、接続数が最大値に達し、接続プールで利用可能な接続がなくなった場合に適用されます。また、フェイルオーバーオペレーションが進行中であるためにライターインスタンスが使用できない場合にも適用されます。この設定を使用すると、アプリケーションコードでクエリタイムアウトを変更しなくても、アプリケーションに最適な待機期間を設定できます。

ピン留めを回避する

データベースリクエストが以前のリクエストの状態情報に依存しない場合、多重化の効率が高まります。その場合、RDS Proxy は、各トランザクションの終了時に接続を再利用できます。このような状態情報の例には、SET ステートメントや SELECT ステートメントで変更できるほとんどの変数や設定パラメータが含まれます。クライアント接続の SQL トランザクションでは、デフォルトで、基となるデータベース接続を多重化できます。

プロキシへの接続は、ピン留めと呼ばれる状態に入る場合があります。接続がピン留めされると、以降の各トランザクションは、セッションが終了するまで、同じ基になるデータベース接続を使用します。また、他のクライアント接続は、セッションが終了するまでそのデータベース接続を再利用できません。クライアント接続がドロップされると、セッションは終了します。

RDS Proxy は、他のセッションに不適切なセッション状態の変化を検出すると、クライアント接続を特定の DB 接続に自動的にピン留めします。ピン留めにより、接続の再利用の有効性が低下します。すべての接続やほぼすべての接続でピン留めが発生する場合は、ピン留めが発生する状態を減らすようにアプリケーションコードやワークロードを変更します。

たとえば、アプリケーションによってセッションの変数や設定パラメータが変更された場合、後続のステートメントでは変更後の変数やパラメータが有効であることに依存します。したがって、RDS Proxy はセッションの変数や構成設定の変更リクエストを処理する場合、そのセッションを DB 接続にピン留めします。これにより、セッション状態は、同じセッション内の後続のすべてのトランザクションで有効になります。

このルールは、設定可能なすべてのパラメータに適用されるわけではありません。RDS Proxy は、文字セット、照合順序、タイムゾーン、自動コミット、現在のデータベース、SQL モード、および session_track_schema の各設定への変更を追跡します。したがって、これらの変更時に RDS Proxy はセッションをピン留めしません。この場合、RDS Proxy は、これらの設定の値が同じである他のセッションでのみ、接続を再利用します。

RDS Proxy のパフォーマンスチューニングでは、ピン留めを最小化してトランザクションレベルの接続の再利用 (多重化) を最大化します。そのためには、以下の操作を行います。

  • ピン留めの原因となる可能性のある不要なデータベースリクエストを避けます。

  • すべての接続間で変数と構成設定を一貫して設定します。これにより、これらの特定の設定を持つ接続が後続のセッションで再利用される可能性が高くなります。

    ただし、PostgreSQL では、変数の設定によりセッションのピン留めが発生します。

  • セッションのピン留めフィルターをプロキシに適用します。特定の種類のオペレーションがアプリケーションの正常な動作に影響しないことがわかっている場合、これらのオペレーションを除外してセッションのピン留めを起こさないように指定できます。

  • CloudWatch メトリクス DatabaseConnectionsCurrentlySessionPinned をモニタリングして、ピン留めが発生する頻度を確認します。このメトリクスおよび他の CloudWatch メトリクスの詳細については、「Amazon CloudWatch を使用した RDS Proxy のモニタリング」を参照してください。

  • SET ステートメントを使用して各クライアント接続を同等に初期化する場合、トランザクションレベルの多重化を維持したまま、この初期化を実行できます。この場合、初期セッション状態を設定するステートメントを、プロキシが使用する初期化クエリに移動します。このプロパティは、セミコロンで区切られた 1 つ以上の SQL ステートメントを含む文字列です。

    たとえば、特定の設定パラメータを設定する初期化クエリをプロキシに定義できます。これにより、RDS Proxy でプロキシの新しい接続を設定するたびに、これらの設定が適用されます。トランザクションレベルの多重化を妨げないように、アプリケーションコードから対応する SET ステートメントを削除できます。

    重要

    MySQL データベースに関連付けられているプロキシの場合、初期化クエリで設定パラメータ sql_auto_is_null を true または 0 以外の値に設定しないでください。その場合、アプリケーションの動作が正常でなくなる場合があります。

以下の場合は、多重化が予期しない動作をもたらす可能性があるため、プロキシはセッションを現在の接続にピン留めします。

  • ステートメントのテキストサイズが 16 KB を超える場合、プロキシはセッションをピン留めします。

  • プリペアドステートメントの場合、プロキシはセッションをピン留めします。このルールは、プリペアドステートメントで SQL テキストを使用するか、バイナリプロトコルを使用するかに関係なく、適用されます。

  • 明示的な MySQL ステートメントである LOCK TABLE、LOCK TABLES、または FLUSH TABLES WITH READ LOCK が原因でプロキシによるセッションのピン留めが発生します。

  • ユーザー変数またはシステム変数 (例外あり) を設定した場合、プロキシはセッションをピン留めします。この状況によって接続の再利用が制限されすぎる場合は、SET オペレーションでピン留めを発生させないように選択できます。SessionPinningFilters プロパティを設定する方法については、「RDS Proxy の作成」を参照してください。

  • 一時テーブルを作成した場合、プロキシはセッションをピン留めします。これにより、トランザクションの境界に関係なく、一時テーブルの内容がセッション全体で保持されます。

  • MySQL 関数 ROW_COUNT、FOUND_ROWS、および LAST_INSERT_ID を呼び出すと、ピン留めが発生する場合があります。

    これらの関数によりピン留めが発生する正確な状況は、MySQL 5.6 および MySQL 5.7 と互換性のある Aurora MySQL バージョン間で異なる場合があります。

MySQL ストアドプロシージャやストアド関数を呼び出しても、ピン留めは発生しません。RDS Proxy は、この種の呼び出しに伴うセッション状態の変更を検出しません。したがって、アプリケーションによってストアドルーチン内でセッション状態が変更されないことを確認し、そのセッション状態がトランザクション間で維持されるようにします。たとえば、ストアドプロシージャがトランザクション間で維持されることを意図した一時テーブルを作成する場合、このアプリケーションは現在 RDS Proxy と互換性がありません。

PostgreSQL の場合、次の操作に伴ってピン留めが発生します。

  • SET コマンドの使用

  • JDBC のデフォルト設定を使用するなど、拡張クエリプロトコルの使用

  • 一時シーケンス、テーブル、またはビューの作成

  • カーソルの宣言

  • セッション状態の破棄

  • 通知チャネルでのリッスン

  • auto_explain などのライブラリモジュールのロード

  • nextval や setval などの関数を使用したシーケンスの操作

  • pg_advisory_lock や pg_try_advisory_lock などの機能を使用したロックの操作

  • 準備されたステートメントの使用、パラメータの設定、またはパラメータのデフォルトへのリセット

アプリケーションの動作に関する専門知識がある場合は、特定のアプリケーションステートメントについてピン留め動作をスキップできます。これを行うには、プロキシの作成時に [セッションのピン留めフィルタ] オプションを選択します。現在、セッションの変数や構成設定の定義により発生するセッションのピン留めを回避できます。

プロキシでのピン留めの発生回数のメトリクスについては、「Amazon CloudWatch を使用した RDS Proxy のモニタリング」を参照してください。

RDS Proxy の削除

不要になったプロキシは削除できます。プロキシを使用していたアプリケーションが無効になった場合は、プロキシを削除できます。または、プロキシに関連付けられている DB インスタンスやクラスターがサービスから外された場合に、プロキシを削除できます。

プロキシを削除するには

  1. AWS マネジメントコンソールにサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[プロキシ] を選択します。

  3. リストから削除するプロキシを選択します。

  4. [Delete Proxy (プロキシの削除)] を選択します。

DB プロキシを削除するには、AWS CLI コマンド delete-db-proxy を使用します。該当する関連付けを削除するには、deregister-db-proxy-targets コマンドも使用します。 

aws rds delete-db-proxy --name proxy_name
aws rds deregister-db-proxy-targets
    --db-proxy-name proxy_name
    [--target-group-name target_group_name]
    [--target-ids comma_separated_list]       # or
    [--db-instance-identifiers instance_id]       # or
    [--db-cluster-identifiers cluster_id]

DB プロキシを削除するには、Amazon RDS API 関数 DeleteDBProxy を呼び出します。関連する項目と関連付けを削除するには、関数 DeleteDBProxyTargetGroup と DeregisterDBProxyTargets も呼び出します。

Amazon CloudWatch を使用した RDS Proxy のモニタリング

RDS Proxy は Amazon CloudWatch を使用してモニタリングできます。CloudWatch はプロキシの RAW データを収集し、ほぼリアルタイムの読み取り可能なメトリクスに加工します。これらのメトリクスを CloudWatch コンソールで確認するには、[Metrics (メトリクス)]、[RDS]、[Per-Proxy Metrics (プロキシごとのメトリクス)] の順に選択します。詳細については、Amazon CloudWatch ユーザーガイド の「Amazon CloudWatch メトリクスの使用」を参照してください。

注記

RDS は、これらのメトリクスを、プロキシに関連付けられている基になる Amazon EC2 インスタンスごとに発行します。1 つのプロキシは、複数の EC2 インスタンスによって処理される場合があります。CloudWatch の統計情報を使用して、すべての関連付けられたインスタンスにわたってプロキシの値を集計します。

これらのメトリクスの一部は、プロキシによる最初の接続が成功するまで表示されないことがあります。

RDS Proxy ログでは、各エントリの前に、関連付けられたプロキシエンドポイントの名前が付けられます。この名前は、ユーザー定義のエンドポイントに指定した名前、またはプロキシのデフォルトのエンドポイントを使用した読み取り/書き込みリクエストの特別な名前 default にすることができます。

すべての RDS Proxy メトリクスはグループ proxy にあります。

各プロキシエンドポイントには独自の CloudWatch メトリクスがあります。各プロキシエンドポイントの使用状況を個別にモニタリングできます。プロキシエンドポイントの詳細については、「Amazon RDS Proxy のエンドポイント」を参照してください。

次のいずれかのディメンションセットを使用して、各メトリクスの値を集計できます。例えば、ProxyName ディメンションセットを使用すると、特定のプロキシのすべてのトラフィックを分析できます。他のディメンションセットを使用すると、さまざまな方法でメトリクスを分割できます。メトリクスは、各プロキシの異なるエンドポイントまたはターゲットデータベース、または各データベースへの読み取り/書き込みおよび読み取り専用のトラフィックに基づいて分割できます。

  • ディメンションセット 1:ProxyName

  • ディメンションセット 2:ProxyName,EndpointName

  • ディメンションセット 3:ProxyName,TargetGroup,Target

  • ディメンションセット 4:ProxyName,TargetGroup,TargetRole

メトリクス 説明 有効期間 CloudWatch ディメンションセット

AvailabilityPercentage

ディメンションで示されたロールでターゲットグループが利用できた時間の割合。このメトリクスは 1 分ごとにレポートされます。このメトリクスの最も有用な統計は Average です。

1 分 ディメンションセット 4
ClientConnections

現在のクライアント接続の数。このメトリクスは 1 分ごとにレポートされます。このメトリクスの最も有用な統計は Sum です。

1 分

ディメンションセット 1、ディメンションセット 2
ClientConnectionsClosed

閉じられたクライアント接続の数。このメトリクスの最も有用な統計は Sum です。

1 分以上

ディメンションセット 1、ディメンションセット 2

ClientConnectionsNoTLS

Transport Layer Security (TLS) を使用しない現在のクライアント接続の数。このメトリクスは 1 分ごとにレポートされます。このメトリクスの最も有用な統計は Sum です。 1 分以上 ディメンションセット 1、ディメンションセット 2

ClientConnectionsReceived

受信したクライアント接続リクエストの数。このメトリクスの最も有用な統計は Sum です。

1 分以上

ディメンションセット 1、ディメンションセット 2
ClientConnectionsSetupFailedAuth

認証または TLS の設定ミスのために失敗したクライアント接続の試行回数。このメトリクスの最も有用な統計は Sum です。

1 分以上

ディメンションセット 1、ディメンションセット 2
ClientConnectionsSetupSucceeded

TLS の有無にかかわらず、認証機構を使用して正常に確立されたクライアント接続の数。このメトリクスの最も有用な統計は Sum です。

1 分以上

ディメンションセット 1、ディメンションセット 2
ClientConnectionsTLS TLS を使用する現在のクライアント接続の数。このメトリクスは 1 分ごとにレポートされます。このメトリクスの最も有用な統計は Sum です。 1 分以上 ディメンションセット 1、ディメンションセット 2
DatabaseConnectionRequests

データベース接続の作成リクエストの数。このメトリクスの最も有用な統計は Sum です。

1 分以上

ディメンションセット 1、ディメンションセット 3、ディメンションセット 4

DatabaseConnectionRequestsWithTLS

TLS を使用してデータベース接続を作成するリクエストの数。このメトリクスの最も有用な統計は Sum です。 1 分以上 ディメンションセット 1、ディメンションセット 3、ディメンションセット 4
DatabaseConnections

現在のデータベース接続の数。このメトリクスは 1 分ごとにレポートされます。このメトリクスの最も有用な統計は Sum です。

1 分

ディメンションセット 1、ディメンションセット 3、ディメンションセット 4

DatabaseConnectionsBorrowLatency

モニタリングされているプロキシがデータベース接続を取得するのにかかる時間 (マイクロ秒)。このメトリクスの最も有用な統計は Average です。 1 分以上 ディメンションセット 1、ディメンションセット 2
DatabaseConnectionsCurrentlyBorrowed

借用状態のデータベース接続の現在の数。このメトリクスは 1 分ごとにレポートされます。このメトリクスの最も有用な統計は Sum です。

1 分

ディメンションセット 1、ディメンションセット 3、ディメンションセット 4
DatabaseConnectionsCurrentlyInTransaction

トランザクションでの現在のデータベース接続の数。このメトリクスは 1 分ごとにレポートされます。このメトリクスの最も有用な統計は Sum です。

1 分

ディメンションセット 1、ディメンションセット 3、ディメンションセット 4
DatabaseConnectionsCurrentlySessionPinned

セッション状態を変更するクライアントリクエストのオペレーションのために現在ピン留めされているデータベース接続の数。このメトリクスは 1 分ごとにレポートされます。このメトリクスの最も有用な統計は Sum です。

1 分

ディメンションセット 1、ディメンションセット 3、ディメンションセット 4
DatabaseConnectionsSetupFailed

失敗したデータベース接続リクエストの数。このメトリクスの最も有用な統計は Sum です。

1 分以上

ディメンションセット 1、ディメンションセット 3、ディメンションセット 4
DatabaseConnectionsSetupSucceeded

TLS の有無にかかわらず、正常に確立されたデータベース接続の数。このメトリクスの最も有用な統計は Sum です。

1 分以上

ディメンションセット 1、ディメンションセット 3、ディメンションセット 4

DatabaseConnectionsWithTLS

TLS を使用する現在のデータベース接続の数。このメトリクスは 1 分ごとにレポートされます。このメトリクスの最も有用な統計は Sum です。 1 分 ディメンションセット 1、ディメンションセット 3、ディメンションセット 4
MaxDatabaseConnectionsAllowed

許可されるデータベース接続の最大数。このメトリクスは 1 分ごとにレポートされます。このメトリクスの最も有用な統計は Sum です。

1 分

ディメンションセット 1、ディメンションセット 3、ディメンションセット 4

QueryDatabaseResponseLatency

データベースがクエリに応答するのにかかった時間 (マイクロ秒)。このメトリクスの最も有用な統計は Average です。 1 分以上 ディメンションセット 1、ディメンションセット 2、ディメンションセット 3、ディメンションセット 4
QueryRequests

受信したクエリの数。複数のステートメントを含むクエリは、1 つのクエリとしてカウントされます。このメトリクスの最も有用な統計は Sum です。

1 分以上

ディメンションセット 1、ディメンションセット 2
QueryRequestsNoTLS 非 TLS 接続から受信したクエリの数。複数のステートメントを含むクエリは、1 つのクエリとしてカウントされます。このメトリクスの最も有用な統計は Sum です。 1 分以上 ディメンションセット 1、ディメンションセット 2

QueryRequestsTLS

TLS 接続から受信したクエリの数。複数のステートメントを含むクエリは、1 つのクエリとしてカウントされます。このメトリクスの最も有用な統計は Sum です。 1 分以上 ディメンションセット 1、ディメンションセット 2
QueryResponseLatency クエリリクエストを取得してから、プロキシが応答するまでの時間 (マイクロ秒)。このメトリクスの最も有用な統計は Average です。 1 分以上 ディメンションセット 1、ディメンションセット 2

Amazon RDS Proxy のエンドポイント

次に、RDS Proxy のエンドポイントとその使用方法について説明します。エンドポイントを使用すると、次の機能を活用できます。

  • プロキシで複数のエンドポイントを使用して、異なるアプリケーションからの接続を個別にモニタリングおよびトラブルシューティングできます。

  • Aurora DB クラスターでリーダーエンドポイントを使用して、クエリを多用するアプリケーションの読み取りスケーラビリティと可用性を向上させることができます。

  • クロス VPC エンドポイントを使用して、ある VPC のデータベースに別の VPC の Amazon EC2 インスタンスなどのリソースからアクセスできるようにすることができます。

プロキシエンドポイントの概要

RDS Proxy エンドポイントを使用する際は、Aurora DB クラスターとリーダーエンドポイントおよび RDS インスタンスのエンドポイントと同じ種類の手順に従います。 RDS エンドポイントに詳しくない場合は、「MySQL データベースエンジンを実行している DB インスタンスへの接続」および「PostgreSQL データベースエンジンを実行している DB インスタンスへの接続」で詳細を確認してください。

デフォルトでは、RDS Proxy を Aurora クラスターで使用するときに接続するエンドポイントには読み取り/書き込み機能があります。結果として、このエンドポイントはすべてのリクエストをクラスターのライターインスタンスに送信し、それらの接続はすべてライターインスタンスの max_connections 値にカウントされます。プロキシが Aurora DB クラスターに関連付けられている場合は、そのプロキシ用に追加の読み取り/書き込みエンドポイントまたは読み取り専用エンドポイントを作成できます。

Aurora プロビジョンドクラスターにリーダーエンドポイントを使用するのと同じ方法で、読み取り専用クエリに対して、プロキシで読み取り専用エンドポイントを使用できます。そうすることで、1 つ以上のリーダー DB インスタンスを持つ Aurora クラスターの読み取りスケーラビリティを活用するのに役立ちます。読み取り専用エンドポイントを使用し、必要に応じて Aurora クラスターにリーダー DB インスタンスを追加することで、より多くの同時クエリを実行し、より多くの同時接続を確立できます。

作成したプロキシエンドポイントについては、プロキシ自体が使用するものとは異なる Virtual Private Cloud (VPC) にエンドポイントを関連付けることもできます。これにより、組織内の別のアプリケーションで使用される VPC など、別の VPC からプロキシに接続できます。両方の VPC は同じ AWS アカウントが所有している必要があります。

プロキシエンドポイントに関連付けられた制限の詳細については、「プロキシエンドポイントの制限」を参照してください。

RDS Proxy ログでは、各エントリの前に、関連付けられたプロキシエンドポイントの名前が付けられます。この名前は、ユーザー定義のエンドポイントに指定した名前、またはプロキシのデフォルトのエンドポイントを使用した読み取り/書き込みリクエストの特別な名前 default にすることができます。

各プロキシのエンドポイントには、独自の CloudWatch メトリクスのセットがあります。プロキシのすべてのエンドポイントのメトリクスをモニタリングできます。また、プロキシの特定のエンドポイント、またはそのすべての読み取り/書き込みまたは読み取り専用エンドポイントのメトリクスをモニタリングすることもできます。詳細については、「Amazon CloudWatch を使用した RDS Proxy のモニタリング」を参照してください。

プロキシエンドポイントは、関連付けられたプロキシと同じ認証メカニズムを使用します。RDS Proxy は関連するプロキシのプロパティと一致するように、ユーザー定義のエンドポイントのアクセス許可と承認を自動的に設定します。

リーダーエンドポイント

RDS Proxy では、リーダーエンドポイントを作成して使用できます。ただし、これらのエンドポイントは、Aurora DBクラスターに関連付けられたプロキシに対してのみ機能します。AWS マネジメントコンソール にリーダーエンドポイントへの参照が表示される場合があります。RDS CLI または API を使用する場合、値が READ_ONLY で、TargetRole の属性が表示される場合があります。プロキシのターゲットを RDS DB インスタンスから Aurora DB クラスターに変更することで、これらの機能を利用できます。リーダーエンドポイントについては、Aurora ユーザーガイドの「Amazon RDS Proxy の接続の管理」を参照してください。

Aurora へのアクセスと VPC 間の RDS データベース

デフォルトでは、RDS と Aurora テクノロジースタックのコンポーネントはすべて同じ Amazon VPC にあります。例えば、Amazon EC2 インスタンスで実行されているアプリケーションが Amazon RDS DB インスタンスまたは DB Aurora クラスターに接続するとします。この場合、アプリケーションサーバーとデータベースは両方とも同じ VPC 内に存在する必要があります。

RDS Proxy により、別の VPC の EC2 インスタンスなどのリソースから、ある VPC の Aurora クラスターまたは RDS インスタンスへのアクセスを設定できます。例えば、組織に、同じデータベースリソースにアクセスする複数のアプリケーションがあるとします。各アプリケーションは独自の VPC 内にある場合があります。RDS Proxy でクロス VPC 機能を使用するには、すべての VPC が同じ AWS アカウントによって所有されている必要があります。

クロス VPC アクセスを有効にするには、プロキシの新しいエンドポイントを作成します。プロキシエンドポイントの作成に詳しくない場合は、「Amazon RDS Proxy のエンドポイント」を参照してください。プロキシ自体は、Aurora DB クラスターまたは RDS インスタンスと同じ VPC に存在します。ただし、クロス VPC エンドポイントは、EC2 インスタンスなどの他のリソースとともに、他の VPC に存在します。クロス VPC エンドポイントは、EC2 および他のリソースと同じ VPC のサブネットおよびセキュリティグループに関連付けられます。このような関連付けにより、VPC の制限によりデータベースにアクセスできないアプリケーションからエンドポイントに接続できます。

次の手順では、RDS Proxy を使用して VPC 間エンドポイントを作成してアクセスする方法について説明します。

  1. 2 つの VPC を作成するか、Aurora と RDS が機能するように既に使用している 2 つの VPC を選択します。各 VPC には、インターネットゲートウェイ、ルートテーブル、サブネット、セキュリティグループなど、独自のネットワークリソースが関連付けられている必要があります。 VPC が 1 つしかない場合は、別の VPC をセットアップして正常に RDS を使用できるようにする手順について Amazon RDS の開始方法 と相談できます。 Amazon EC2 コンソールで既存の VPC を調べて、相互に接続するリソースの種類を確認することもできます。

  2. 接続する Aurora DB クラスターまたは RDS インスタンスに関連付けられた DB プロキシを作成します。「RDS Proxy の作成」の手順に従います。

  3. RDS コンソールのプロキシの [詳細] ページの [プロキシエンドポイント] セクションで、[エンドポイントの作成] を選択します。「プロキシエンドポイントの作成」の手順に従います。

  4. クロス VPC エンドポイントを読み取り/書き込み可能にするか、読み取り専用にするかを選択します。

  5. Aurora DB クラスターまたは RDS インスタンスと同じ VPC のデフォルトを受け入れる代わりに、別の VPC を選択します。この VPC は、プロキシが存在する VPC と同じ AWS リージョンに存在する必要があります。

  6. これで、Aurora DB クラスターまたは RDS インスタンスと同じ VPC からサブネットとセキュリティグループのデフォルトを受け入れるのではなく、新しい選択を行います。選択した VPC のサブネットとセキュリティグループに基づいて、これらを作成します。

  7. Secrets Manager シークレットの設定を変更する必要はありません。各エンドポイントがどの VPC にあるかに関係なく、プロキシのすべてのエンドポイントで同じ認証情報が機能します。

  8. 新しいエンドポイントが Available (利用可能) 状態に達するのを待ちます。

  9. 完全なエンドポイント名を書き留めます。これは、データベースアプリケーションの接続文字列の一部として指定する、Region_name.rds.amazonaws.com で終わる値です。

  10. エンドポイントと同じ VPC 内のリソースから新しいエンドポイントにアクセスします。このプロセスをテストする簡単な方法は、この VPC 内に新しい EC2 インスタンスを作成することです。次に、EC2 インスタンスにログインし、mysql または psql コマンドを実行して、接続文字列のエンドポイント値を使用して接続できます。

プロキシエンドポイントの作成

プロキシエンドポイントを作成するには

  1. AWS マネジメントコンソールにサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[プロキシ] を選択します。

  3. 新しいエンドポイントを作成するプロキシの名前をクリックします。

    そのプロキシの詳細ページが表示されます。

  4. [プロキシエンドポイント] セクションで、[プロキシエンドポイントの作成] を選択します。

    [プロキシエンドポイントの作成] ウィンドウが表示されます。

  5. [プロキシエンドポイント名] に、選択したわかりやすい名前を入力します。

  6. [ターゲットロール] で、エンドポイントを読み取り/書き込みにするか、読み取り専用にするかを選択します。

    読み取り/書き込みエンドポイントを使用する接続では、データ定義言語 (DDL) ステートメント、データ操作言語 (DML) ステートメント、クエリなど、あらゆる種類の操作を実行できます。これらのエンドポイントは、常に Aurora クラスターのプライマリインスタンスに接続します。アプリケーションでエンドポイントを 1 つだけ使用する場合は、読み取り/書き込みエンドポイントを一般的なデータベース操作に使用できます。読み取り/書き込みエンドポイントは、管理操作、オンライントランザクション処理 (OLTP) アプリケーション、および抽出変換ロード (ETL) ジョブにも使用できます。

    読み取り専用エンドポイントを使用する接続では、クエリのみを実行できます。Aurora クラスターに複数のリーダーインスタンスがある場合、RDS Proxy はエンドポイントへの接続ごとに異なるリーダーインスタンスを使用できます。そうすれば、クエリを多用するアプリケーションは、Aurora のクラスタリング機能を利用できます。リーダー DB インスタンスを追加することで、クラスターにクエリキャパシティーを追加できます。読み取り専用接続では、クラスターのプライマリインスタンスでオーバーヘッドが発生することはありません。このようにすると、レポートおよび分析クエリによって、OLTP アプリケーションの書き込み操作の速度が低下することはありません。

  7. Virtual Private Cloud (VPC) では、プロキシまたはそれに関連付けられたデータベースに通常アクセスするのと同じ EC2 インスタンスまたは他のリソースからエンドポイントにアクセスする場合は、デフォルトを選択します。このプロキシに対してクロス VPC アクセスを設定する場合は、デフォルト以外の VPC を選択します。クロス VPC アクセスの詳細については、「Aurora へのアクセスと VPC 間の RDS データベース」を参照してください。

  8. Subnets では、RDS Proxy がデフォルトで関連するプロキシと同じサブネットを入力します。VPC のアドレス範囲の一部のみがエンドポイントに接続できるように、エンドポイントへのアクセスを制限する場合は、選択肢から 1 つ以上のサブネットを削除します。

  9. VPC セキュリティグループの場合、既存のセキュリティグループを選択するか、新しいセキュリティグループを作成できます。RDS Proxy はデフォルトでは、関連付けられたプロキシと同じセキュリティグループを入力します。プロキシのインバウンドルールとアウトバウンドルールがこのエンドポイントに適切な場合は、デフォルトの選択肢のままにしておくことができます。

    新しいセキュリティグループを作成することにした場合は、このページでセキュリティグループの名前を指定します。その後、EC2 コンソールからセキュリティグループ設定を編集します。

  10. [プロキシエンドポイントの作成] を選択します。

プロキシエンドポイントを作成するには、AWS CLI create-db-proxy-endpoint コマンドを使用します。

以下の必須パラメータを含めます。

  • --db-proxy-name value

  • --db-proxy-endpoint-name value

  • --vpc-subnet-ids list_of_ids。サブネット ID はスペースで区切ります。VPC 自体の ID は指定しません。

また、次のオプションパラメータを含めることができます。

  • --target-role { READ_WRITE | READ_ONLY }。このパラメータのデフォルトは READ_WRITE です。READ_ONLY 値は、1 つ以上のリーダー DB インスタンスを含む Aurora プロビジョンドクラスターにのみ影響します。プロキシが RDS インスタンス、またはライター DB インスタンスのみを含む Aurora クラスターに関連付けられている場合、READ_ONLY を指定することはできません。

  • --vpc-security-group-ids value。セキュリティグループ ID はスペースで区切ります。このパラメータを省略すると、RDS Proxy は VPC のデフォルトのセキュリティグループを使用します。RDS Proxy は、--vpc-subnet-ids パラメータに指定したサブネット ID に基づいて VPC を決定します。

例

次の例では、my-endpoint という名前のプロキシエンドポイントを作成します。

Linux、macOS、Unix の場合:

aws rds create-db-proxy-endpoint \
  --db-proxy-name my-proxy \
  --db-proxy-endpoint-name my-endpoint \
  --vpc-subnet-ids subnet_id subnet_id subnet_id ... \
  --target-role READ_ONLY \
  --vpc-security-group-ids security_group_id ]

Windows の場合:

aws rds create-db-proxy-endpoint ^
  --db-proxy-name my-proxy ^
  --db-proxy-endpoint-name my-endpoint ^
  --vpc-subnet-ids subnet_id_1 subnet_id_2 subnet_id_3 ... ^
  --target-role READ_ONLY ^
  --vpc-security-group-ids security_group_id

プロキシエンドポイントを作成するには、RDS API CreateProxyEndpoint アクションを使用します。

プロキシエンドポイントの表示

プロキシエンドポイントの詳細を表示するには

  1. AWS マネジメントコンソールにサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[プロキシ] を選択します。

  3. リストから、エンドポイントを表示するプロキシを選択します。プロキシ名をクリックして、詳細ページを表示します。

  4. で、プロキシエンドポイントセクションで、表示するエンドポイントを選択します。名前をクリックすると、詳細ページが表示されます。

  5. 関心のある値を持つパラメータを調べます。次のようなプロパティを確認できます。

    • エンドポイントが読み取り/書き込み可能か読み取り専用か。

    • データベース接続文字列で使用するエンドポイントアドレス。

    • エンドポイントに関連付けられた VPC、サブネットおよびセキュリティグループ。

1 つ以上の DB プロキシエンドポイントを表示するには、AWS CLI describe-db-proxy-endpoints コマンドを使用します。

以下のオプションのパラメータを含めることができます。

  • --db-proxy-endpoint-name

  • --db-proxy-name

次の例では、my-endpoint プロキシエンドポイントについて説明します。

例

Linux、macOS、Unix の場合:

aws rds describe-db-proxy-endpoints \
  --db-proxy-endpoint-name my-endpoint

Windows の場合:

aws rds describe-db-proxy-endpoints ^
  --db-proxy-endpoint-name my-endpoint

1 つ以上のプロキシエンドポイントを記述するには、RDS API DescribeDBProxyEndpoints オペレーションを使用します。

プロキシエンドポイントの変更

1 つまたは複数のプロキシエンドポイントを変更するには

  1. AWS マネジメントコンソールにサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[プロキシ] を選択します。

  3. リストから、エンドポイントを変更するプロキシを選択します。プロキシ名をクリックして、詳細ページを表示します。

  4. [プロキシエンドポイント] セクションで、変更するエンドポイントを選択します。リストから選択するか、名前をクリックして詳細ページを表示できます。

  5. プロキシの詳細ページの [プロキシエンドポイント] セクションで、[編集] を選択します。または、プロキシエンドポイントの詳細ページの [アクション] で、[編集] を選択します。

  6. 変更するパラメータの値を変更します。

  7. [Save changes] を選択します。

DB プロキシエンドポイントを変更するには、次の必須パラメータを指定して AWS CLI modify-db-proxy-endpoint コマンドを使用します。

  • --db-proxy-endpoint-name

次のパラメータの 1 つまたは複数を使用して、エンドポイントプロパティの変更を指定します。

  • --new-db-proxy-endpoint-name

  • --vpc-security-group-ids。セキュリティグループ ID はスペースで区切ります。

次の例では、my-endpoint プロキシエンドポイントの名前を new-endpoint-name に変更します。

例

Linux、macOS、Unix の場合:

aws rds modify-db-proxy-endpoint \
  --db-proxy-endpoint-name my-endpoint \
  --new-db-proxy-endpoint-name new-endpoint-name

Windows の場合:

aws rds modify-db-proxy-endpoint ^
  --db-proxy-endpoint-name my-endpoint ^
  --new-db-proxy-endpoint-name new-endpoint-name

プロキシエンドポイントを変更するには、RDS API の ModifyDBProxyEndpoint 操作を使用します。

プロキシエンドポイントの削除

次の手順に従って、コンソールを使用してプロキシのエンドポイントを削除できます。

注記

RDS Proxy がプロキシごとに自動的に作成されるデフォルトのエンドポイントを削除することはできません。

プロキシを削除すると、RDS Proxy は、関連するすべてのエンドポイントを自動的に削除します。

プロキシエンドポイントを削除するにはAWS マネジメントコンソール

  1. ナビゲーションペインで、[プロキシ] を選択します。

  2. リストから、エンドポイントを設定するプロキシを選択します。プロキシ名をクリックして、詳細ページを表示します。

  3. [プロキシエンドポイント] セクションで、削除するエンドポイントを選択します。リストから 1 つ以上のエンドポイントを選択するか、1 つのエンドポイントの名前をクリックして詳細ページを表示できます。

  4. プロキシの詳細ページの [プロキシエンドポイント] セクションで、[削除] を選択します。または、プロキシエンドポイントの詳細ページの [アクション] で、[削除] を選択します。

プロキシエンドポイントを削除するには、次の必須パラメータを指定して delete-db-proxy-endpoint コマンドを実行します。

  • --db-proxy-endpoint-name

次のコマンドは、my-endpoint という名前のプロキシエンドポイントを削除します。

Linux、macOS、Unix の場合:

aws rds delete-db-proxy-endpoint \
  --db-proxy-endpoint-name my-endpoint

Windows の場合:

aws rds delete-db-proxy-endpoint ^
  --db-proxy-endpoint-name my-endpoint

RDS API でプロキシエンドポイントを削除するには、DeleteDBProxyEndpoint オペレーションを実行します。DBProxyEndpointName パラメータのプロキシエンドポイントの名前を指定します。

プロキシエンドポイントの制限

各プロキシには、変更できるが作成または削除できないデフォルトのエンドポイントがあります。

プロキシのユーザー定義エンドポイントの最大数は 20 です。したがって、プロキシには最大 21 個のエンドポイント (デフォルトのエンドポイントとユーザーが作成する 20) を持つことができます。

追加のエンドポイントをプロキシに関連付けると、RDS Proxy は、クラスター内のどの DB インスタンスをエンドポイントごとに使用するかを自動的に決定します。Aurora カスタムエンドポイントの場合とは異なり、特定のインスタンスを選択することはできません。

RDS Proxy でクロス VPC 機能を使用するには、すべての VPC が同じ AWS アカウントによって所有されている必要があります。

リーダーエンドポイントは、Aurora マルチライタークラスターでは使用できません。

SSL モード REQUIRED および VERIFY_CA を使用して、作成したプロキシエンドポイントに接続できます。SSL モード VERIFY_IDENTITY を使用して作成したエンドポイントに接続することはできません。

RDS Proxy のコマンドラインの例

接続コマンドと SQL ステートメントの組み合わせが RDS Proxy とやり取りする方法については、以下の例を参照してください。

例

例 フェイルオーバー全体で MySQL データベースへの接続を保持する

この MySQL の例では、データベースを再起動したり、問題が生じてデータベースが使用不能になったりしてフェイルオーバーする場合に、開いている接続を引き続き動作させる方法を示します。この例では、the-proxy という名前のプロキシと、DB インスタンスとして instance-8898 と instance-9814 が含まれている Aurora DB クラスターを使用します。Linux コマンドラインから failover-db-cluster コマンドを実行すると、プロキシの接続先のライターインスタンスが別の DB インスタンスに変更されます。接続が開いたままで、プロキシに関連付けられている DB インスタンスが変更されることがわかります。 

$ mysql -h the-proxy.proxy-demo.us-east-1.rds.amazonaws.com -u admin_user -p
Enter password:
...

mysql> select @@aurora_server_id;
+--------------------+
| @@aurora_server_id |
+--------------------+
| instance-9814      |
+--------------------+
1 row in set (0.01 sec)

mysql>
[1]+  Stopped                 mysql -h the-proxy.proxy-demo.us-east-1.rds.amazonaws.com -u admin_user -p
$ # Initially, instance-9814 is the writer.
$ aws rds failover-db-cluster --db-cluster-id cluster-56-2019-11-14-1399
JSON output
$ # After a short time, the console shows that the failover operation is complete.
$ # Now instance-8898 is the writer.
$ fg
mysql -h the-proxy.proxy-demo.us.us-east-1.rds.amazonaws.com -u admin_user -p

mysql> select @@aurora_server_id;
+--------------------+
| @@aurora_server_id |
+--------------------+
| instance-8898      |
+--------------------+
1 row in set (0.01 sec)

mysql>
[1]+  Stopped                 mysql -h the-proxy.proxy-demo.us-east-1.rds.amazonaws.com -u admin_user -p
$ aws rds failover-db-cluster --db-cluster-id cluster-56-2019-11-14-1399
JSON output
$ # After a short time, the console shows that the failover operation is complete.
$ # Now instance-9814 is the writer again.
$ fg
mysql -h the-proxy.proxy-demo.us-east-1.rds.amazonaws.com -u admin_user -p

mysql> select @@aurora_server_id;
+--------------------+
| @@aurora_server_id |
+--------------------+
| instance-9814      |
+--------------------+
1 row in set (0.01 sec)
+---------------+---------------+
| Variable_name | Value         |
+---------------+---------------+
| hostname      | ip-10-1-3-178 |
+---------------+---------------+
1 row in set (0.02 sec)

例 Aurora DB クラスターの max_connections 設定を調整する

この例では、Aurora MySQL DB クラスターの max_connections 設定を調整する方法を示します。そのためには、MySQL 5.6 または 5.7 と互換性のあるクラスターのデフォルトのパラメータ設定に基づいて、独自の DB クラスターパラメータグループを作成します。max_connections 設定の値を指定し、デフォルト値を設定する式を上書きします。DB クラスターパラメータグループを DB クラスターに関連付けます。 

export REGION=us-east-1
export CLUSTER_PARAM_GROUP=rds-proxy-mysql-56-max-connections-demo
export CLUSTER_NAME=rds-proxy-mysql-56

aws rds create-db-parameter-group --region $REGION \
  --db-parameter-group-family aurora5.6 \
  --db-parameter-group-name $CLUSTER_PARAM_GROUP \
  --description "Aurora MySQL 5.6 cluster parameter group for RDS Proxy demo."

aws rds modify-db-cluster --region $REGION \
  --db-cluster-identifier $CLUSTER_NAME \
  --db-cluster-parameter-group-name $CLUSTER_PARAM_GROUP

echo "New cluster param group is assigned to cluster:"
aws rds describe-db-clusters --region $REGION \
  --db-cluster-identifier $CLUSTER_NAME \
  --query '*[*].{DBClusterParameterGroup:DBClusterParameterGroup}'

echo "Current value for max_connections:"
aws rds describe-db-cluster-parameters --region $REGION \
  --db-cluster-parameter-group-name $CLUSTER_PARAM_GROUP \
  --query '*[*].{ParameterName:ParameterName,ParameterValue:ParameterValue}' \
  --output text | grep "^max_connections"

echo -n "Enter number for max_connections setting: "
read answer

aws rds modify-db-cluster-parameter-group --region $REGION --db-cluster-parameter-group-name $CLUSTER_PARAM_GROUP \
  --parameters "ParameterName=max_connections,ParameterValue=$$answer,ApplyMethod=immediate"

echo "Updated value for max_connections:"
aws rds describe-db-cluster-parameters --region $REGION \
  --db-cluster-parameter-group-name $CLUSTER_PARAM_GROUP \
  --query '*[*].{ParameterName:ParameterName,ParameterValue:ParameterValue}' \
  --output text | grep "^max_connections"

RDS Proxy のトラブルシューティング

以下に、いくつかの一般的な RDS Proxy 問題のトラブルシューティングのヒントと、RDS Proxy の CloudWatch ログに関する情報を示します。

RDS Proxy ログでは、各エントリの前に、関連付けられたプロキシエンドポイントの名前が付けられます。この名前は、ユーザー定義のエンドポイントに指定した名前、またはプロキシのデフォルトのエンドポイントを使用した読み取り/書き込みリクエストの特別な名前 default にすることができます。プロキシエンドポイントの詳細については、「Amazon RDS Proxy のエンドポイント」を参照してください。

一般的な問題と解決策

RDS Proxy の使用時に発生する可能性があるいくつかの一般的な問題の考えられる原因と解決策については、以下を参照してください。

新しいプロキシの作成時やプロキシへの接続時に、次の問題が発生することがあります。

エラー 原因または回避策

403: The security token included in the request is invalid

新しい IAM ロールを作成せずに、既存の IAM ロールを選択します。

MySQL プロキシへの接続時に次の問題が発生することがあります。

エラー 原因または回避策
ERROR 1040 (HY000): Connections rate limit exceeded (limit_value) クライアントからプロキシへの接続リクエストのレートが制限を超えました。
ERROR 1040 (HY000): IAM authentication rate limit exceeded クライアントからプロキシへの IAM 認証による同時リクエストの数が制限を超えました。
ERROR 1040 (HY000): Number simultaneous connections exceeded (limit_value) クライアントからプロキシへの同時接続リクエストの数が制限を超えました。

ERROR 1045 (28000): Access denied for user 'DB_USER'@'%' (using password: YES)

次のような原因が考えられます。

  • プロキシで使用される Secrets Manager シークレットが既存のデータベースユーザーのユーザー名およびパスワードと一致しません。Secrets Manager シークレットの認証情報を更新します。または、データベースユーザーが存在し、そのパスワードがシークレットのものと同じであることを確認します。

ERROR 1105 (HY000): Unknown error 不明なエラーが発生しました。
ERROR 1231 (42000): Variable ''character_set_client'' can't be set to the value of value

character_set_client パラメータに設定した値が無効です。たとえば、値 ucs2 は、MySQL サーバーをクラッシュさせる可能性があるため、有効ではありません。

ERROR 3159 (HY000): This RDS Proxy requires TLS connections.

プロキシで [Transport Layer Security が必要] 設定を有効にしましたが、MySQL クライアントで接続にパラメータ ssl-mode=DISABLED が含まれていました。次のいずれかを行います。

  • プロキシの [Transport Layer Security が必要] 設定を無効にします。

  • MySQL クライアントで ssl-mode=REQUIRED の最小設定を使用してデータベースに接続します。

ERROR 2026 (HY000): SSL connection error: Internal Server Error

プロキシへの TLS ハンドシェイクが失敗しました。次のような原因が考えられます。

  • SSL は必須ですが、サーバーではサポートされていません。

  • 内部サーバーエラーが発生しました。

  • 不正なハンドシェイクが発生しました。

ERROR 9501 (HY000): Timed-out waiting to acquire database connection

プロキシは、データベース接続の取得を待機中にタイムアウトしました。次のような原因が考えられます。

  • 最大接続数に達したため、プロキシはデータベース接続を確立できません

  • データベースが使用不能であるため、プロキシはデータベース接続を確立できません。

PostgreSQL プロキシへの接続中に次の問題が発生することがあります。

エラー 原因 ソリューション

IAM authentication is allowed only with SSL connections.

ユーザーが、PostgreSQL クライアントで sslmode=disable を設定して IAM 認証を使用してデータベースに接続しようとしました。

ユーザーは、PostgreSQL クライアントで sslmode=require の最小設定を使用して、データベースに接続する必要があります。詳細については、PostgreSQL の SSL サポートに関するドキュメントを参照してください。

This RDS Proxy requires TLS connections.

ユーザーは [Transport Layer Security が必要] オプションを有効にしましたが、PostgreSQL クライアントで sslmode=disable を使用して接続しようとしました。

このエラーを修正するには、以下のいずれかを行います。

  • プロキシの [Transport Layer Security が必要] オプションを無効にします。

  • PostgreSQL クライアントで sslmode=allow の最小設定を使用してデータベースに接続します。

IAM authentication failed for user user_name. Check the IAM token for this user and try again.

このエラーの原因としては、以下が考えられます。

  • クライアントが不正な IAM ユーザー名を指定した。

  • クライアントがユーザーの不正な IAM 認証トークンを指定した。

  • クライアントが使用している IAM ポリシーに必要なアクセス許可がない。

  • クライアントがユーザーの期限切れの IAM 認証トークンを指定した。

このエラーを修正する方法は次のとおりです。

  1. 指定した IAM ユーザーが存在することを確認します。

  2. IAM 認証トークンが指定した IAM ユーザーに属することを確認します。

  3. IAM ポリシーに RDS への適切なアクセス許可があることを確認します。

  4. 使用した IAM 認証トークンが有効であることを確認します。

This RDS proxy has no credentials for the role role_name. Check the credentials for this role and try again.

このロールには Secrets Manager シークレットはありません。

このロールの Secrets Manager シークレットを追加します。

RDS supports only IAM or MD5 authentication.

プロキシへの接続に使用されているデータベースクライアントが、SCRAM-SHA-256 など、プロキシで現在サポートされていない認証メカニズムを使用しています。

IAM 認証を使用していない場合は、MD5 パスワード認証のみを使用してください。

A user name is missing from the connection startup packet. Provide a user name for this connection.

プロキシへの接続に使用されているデータベースクライアントが、接続の確立を試みるときにユーザー名を送信していません。

選択した PostgreSQL クライアントを使用してプロキシへの接続を設定するときは、必ずユーザー名を定義してください。

Feature not supported: RDS Proxy supports only version 3.0 of the PostgreSQL messaging protocol.

プロキシへの接続に使用される PostgreSQL クライアントは、3.0 より古いプロトコルを使用します。

3.0 メッセージングプロトコルをサポートする、より新しい PostgreSQL クライアントを使用します。PostgreSQL psql CLI を使用している場合は、バージョン 7.4 以降を使用します。

Feature not supported: RDS Proxy currently doesn't support streaming replication mode.

プロキシへの接続に使用されている PostgreSQL クライアントが、ストリーミングレプリケーションモードを使用しようとしています。このモードは、現在 RDS プロキシでサポートされていません。

接続に使用されている PostgreSQL クライアントでストリーミングレプリケーションモードをオフにします。

Feature not supported: RDS Proxy currently doesn't support the option option_name.

プロキシへの接続に使用されている PostgreSQL クライアントが、起動メッセージを通じて、RDS プロキシで現在サポートされていないオプションをリクエストしています。

接続に使用されている PostgreSQL クライアントで、上記のメッセージから、サポートされていないと表示されているオプションをオフにします。

The IAM authentication failed because of too many competing requests.

クライアントからプロキシへの IAM 認証による同時リクエストの数が制限を超えました。

PostgreSQL クライアントからの IAM 認証を使用した接続の確立速度を下げます。

The maximum number of client connections to the proxy exceeded number_value.

クライアントからプロキシへの同時接続リクエストの数が制限を超えました。

PostgreSQL クライアントからこの RDS プロキシへのアクティブな接続の数を減らします。

Rate of connection to proxy exceeded number_value.

クライアントからプロキシへの接続リクエストのレートが制限を超えました。

PostgreSQL クライアントからの接続の確立速度を下げます。

The password that was provided for the role role_name is wrong.

このロールのパスワードが Secrets Manager シークレットと一致しません。

Secrets Manager でこのロールのシークレットをチェックして、パスワードが PostgreSQL クライアントで使用されているものと同じかどうかを確認します。

The IAM authentication failed for the role role_name. Check the IAM token for this role and try again.

IAM 認証に使用される IAM トークンに問題があります。

新しい認証トークンを生成し、新しい接続で使用します。

IAM is allowed only with SSL connections.

クライアントが IAM 認証を使用して接続しようとしましたが、SSL が有効になっていませんでした。

PostgreSQL クライアントで SSL を有効にします。

Unknown error.

不明なエラーが発生しました。

AWS サポートに連絡して、問題の調査を依頼してください。

Timed-out waiting to acquire database connection.

プロキシは、データベース接続の取得を待機中にタイムアウトしました。次のような原因が考えられます。

  • 最大接続数に達したため、プロキシはデータベース接続を確立できません。

  • データベースが使用不能であるため、プロキシはデータベース接続を確立できません。

考えられる解決策:

  • RDS DB インスタンスのターゲットまたは Aurora DB クラスターステータスをチェックして、利用できないかどうかを確認します。

  • 実行時間の長いトランザクションやクエリが実行されているかどうかを確認します。接続プールからのデータベース接続を長時間使用できます。

Request returned an error: database_error.

プロキシから確立されたデータベース接続がエラーを返しました。

解決策は、具体的なデータベースエラーによって異なります。1 つの例は、Request returned an error: database "your-database-name" does not exist です。これは、指定されたデータベース名、またはデータベース名として使用されているユーザー名 (データベース名が指定されていない場合) がデータベースサーバーに存在しないことを意味します。

RDS Proxy での CloudWatch ログの使用

RDS Proxy アクティビティのログは、AWS マネジメントコンソール の CloudWatch にあります。各プロキシには、[ロググループ] ページにエントリがあります。

重要

これらのログは、トラブルシューティングを目的としたもので、プログラムによるアクセス用ではありません。ログの形式と内容は変更される可能性があります。

特に、古いログには、各リクエストのエンドポイントを示すプレフィックスは含まれていません。新しいログでは、各エントリの先頭に、関連付けられたプロキシエンドポイントの名前が付けられます。この名前は、ユーザー定義のエンドポイントに指定した名前、またはプロキシのデフォルトのエンドポイントを使用するリクエストの特別な名前 default にすることができます。

プロキシでの接続の検証

次のコマンドを使用して、接続機構のすべてのコンポーネントが他のコンポーネントと通信できることを検証できます。

describe-db-proxies コマンドを使用して、プロキシ自体を調べます。また、describe-db-proxy-target-groups を使用して、関連するターゲットグループを調べます。ターゲットの詳細が、プロキシに関連付ける RDS DB インスタンスまたは Aurora DB クラスターと一致することを確認します。以下のようなコマンドを使用します。 

aws rds describe-db-proxies --db-proxy-name $DB_PROXY_NAME
aws rds describe-db-proxy-target-groups --db-proxy-name $DB_PROXY_NAME

プロキシが基になるデータベースに接続できることを確認するには、describe-db-proxy-targets コマンドを使用して、ターゲットグループで指定されたターゲットを調べます。以下のようなコマンドを使用します。 

aws rds describe-db-proxy-targets --db-proxy-name $DB_PROXY_NAME

describe-db-proxy-targets コマンドの出力には、TargetHealth フィールドが含まれます。TargetHealth 内のフィールド State、Reason、および Description を調べて、プロキシが基になる DB インスタンスと通信できるかどうかを確認できます。

  • State の値 AVAILABLE は、プロキシが DB インスタンスに接続できることを示します。

  • State の値 UNAVAILABLE は、一時的または永続的な接続の問題を示します。この場合は、Reason および Description フィールドを調べます。たとえば、Reason の値が PENDING_PROXY_CAPACITY の場合は、プロキシがスケーリングオペレーションを完了した後で、接続を再試行します。Reason の値が UNREACHABLE、CONNECTION_FAILED、または AUTH_FAILURE の場合は、Description フィールドの説明が問題の診断に役立ちます。

  • State フィールドでは、AVAILABLE または UNAVAILABLE に変わるまでの短い間、値が REGISTERING になる場合があります。

次の Netcat コマンド (nc) が成功した場合は、ログインしている EC2 インスタンスや他のシステムからプロキシエンドポイントにアクセスできます。このコマンドは、プロキシおよび関連付けられたデータベースと同じ VPC 内に存在していない場合、失敗を報告します。同じ VPC に存在していなくても、データベースに直接ログインできる場合があります。ただし、同じ VPC 内に存在していない限り、プロキシにはログインできません。 

nc -zx MySQL_proxy_endpoint 3306

nc -zx PostgreSQL_proxy_endpoint 5432

次のコマンドを使用して、EC2 インスタンスに必要なプロパティがあることを確認できます。特に、EC2 インスタンスの VPC は、プロキシが接続する先の RDS DB インスタンスまたは Aurora DB クラスターの VPC と同じである必要があります。 

aws ec2 describe-instances --instance-ids your_ec2_instance_id

プロキシで使用されている Secrets Manager シークレットを確認します。 

aws secretsmanager list-secrets
aws secretsmanager get-secret-value --secret-id your_secret_id

get-secret-value によって表示される SecretString フィールドが JSON 文字列としてエンコードされ、この文字列に username フィールドと password フィールドが含まれていることを確認します。次の例は、SecretString フィールドの形式を示しています。 

{
  "ARN": "some_arn",
  "Name": "some_name",
  "VersionId": "some_version_id",
  "SecretString": '{"username":"some_username","password":"some_password"}',
  "VersionStages": [ "some_stage" ],
  "CreatedDate": some_timestamp
}

AWS CloudFormation での RDS Proxy の使用

AWS CloudFormation では RDS Proxy を使用できます。これにより、新しく作成された Amazon RDS DB インスタンスまたは Aurora DB クラスターに接続できるプロキシを含め、関連リソースのグループを作成できます。AWS CloudFormation での RDS Proxy は、2 つの新しいレジストリタイプ DBProxy と DBProxyTargetGroup をサポートしています。

以下のリストは、RDS Proxy のサンプル AWS CloudFormation テンプレートを示しています。 

Resources:
 DBProxy:
   Type: AWS::RDS::DBProxy
   Properties:
     DBProxyName: CanaryProxy
     EngineFamily: MYSQL
     RoleArn:
      Fn::ImportValue: SecretReaderRoleArn
     Auth:
       - {AuthScheme: SECRETS, SecretArn: !ImportValue ProxySecret, IAMAuth: DISABLED}
     VpcSubnetIds:
       Fn::Split: [",", "Fn::ImportValue": SubnetIds]

 ProxyTargetGroup: 
   Type: AWS::RDS::DBProxyTargetGroup
   Properties:
     DBProxyName: CanaryProxy
     TargetGroupName: default
     DBInstanceIdentifiers: 
       - Fn::ImportValue: DBInstanceName
   DependsOn: DBProxy

AWS CloudFormation を使用して作成できる Amazon RDS リソースと Aurora リソースの詳細については、「RDS リソースタイプリファレンス」を参照してください。