プロキシエンドポイントの概要プロキシエンドポイントの制限 Aurora クラスターでのリーダーエンドポイントの使用 VPC 間の Aurora データベースへのアクセス

Amazon RDS Proxy エンドポイントの操作

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

プロキシで複数のエンドポイントを使用して、異なるアプリケーションからの接続を個別にモニタリングおよびトラブルシューティングできます。
Aurora DB クラスターでリーダーエンドポイントを使用して、クエリを多用するアプリケーションの読み取りスケーラビリティと可用性を向上させることができます。
クロス VPC エンドポイントを使用して、ある VPC のデータベースに別の VPC の Amazon EC2 インスタンスなどのリソースからアクセスできるようにすることができます。

トピック

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

RDS Proxy エンドポイントを使用する際は、Aurora DB クラスターとリーダーエンドポイントと同じ種類の手順に従います。Aurora エンドポイントに詳しくない場合は、Amazon Aurora エンドポイント接続で詳細を確認してください。

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

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

ヒント

AWS Management Console を使用して Aurora クラスターのプロキシを作成する場合、RDS Proxy にリーダーエンドポイントを自動で作成できます。リーダーエンドポイントの利点については、「Aurora クラスターでのリーダーエンドポイントの使用」を参照してください。

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

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

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

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

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

プロキシエンドポイントが Aurora グローバルデータベースの DB クラスターでどのように機能するかについては、「RDS Proxy エンドポイントとグローバルデータベースの連携について」を参照してください。

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

RDS Proxy エンドポイントには以下の制限があります。

各プロキシには、変更できるが作成または削除できないデフォルトのエンドポイントがあります。
プロキシのユーザー定義エンドポイントの最大数は 20 です。したがって、プロキシには最大 21 個のエンドポイント (デフォルトのエンドポイントとユーザーが作成する 20) を持つことができます。
追加のエンドポイントをプロキシに関連付けると、RDS Proxy は、クラスター内のどの DB インスタンスをエンドポイントごとに使用するかを自動的に決定します。Aurora カスタムエンドポイントの場合とは異なり、特定のインスタンスを選択することはできません。

Aurora クラスターでのリーダーエンドポイントの使用

RDS Proxy を Aurora クラスターで使用する場合は、リーダーエンドポイントと呼ばれる読み取り専用エンドポイントを作成して接続できます。このリーダーエンドポイントは、クエリを多用するアプリケーションの読み取りスケーラビリティを向上させるのに役立ちます。また、リーダーエンドポイントは、クラスター内のリーダー DB インスタンスが使用できなくなった場合に接続の可用性を向上させるのに役立ちます。

注記

新しいエンドポイントが読み取り専用であることを指定する場合、RDS Proxy は Aurora クラスターに 1 つ以上のリーダー DB インスタンスがあることを必要とします。場合によっては、プロキシのターゲットを、シングルライターのみを含む Aurora クラスターに変更することがあります。この場合、リーダーエンドポイントへのリクエストはすべてエラーになり、失敗します。プロキシのターゲットが Aurora クラスターではなく RDS インスタンスである場合も、リクエストは失敗します。

Aurora クラスターにリーダーインスタンスがあるが、それらのインスタンスが利用できない場合、RDS Proxy はすぐにエラーを返すのではなく、リクエストの送信を待ちます。接続借用タイムアウト期間内にリーダーインスタンスが使用可能にならなかった場合、リクエストはエラーで失敗します。

リーダーエンドポイントがアプリケーションの可用性をどのように支援するか

場合によっては、クラスター内の 1 つ以上のリーダーインスタンスが使用できなくなることがあります。その場合、DB プロキシのリーダーエンドポイントを使用する接続は、Aurora リーダーエンドポイントを使用する接続よりも迅速に回復できます。RDS Proxy は、クラスター内の利用可能なリーダーインスタンスのみに接続をルーティングします。インスタンスが使用できなくなると、DNS キャッシュによる遅延はありません。

接続が多重化されている場合、RDS Proxy はアプリケーションを中断せずに、後続のクエリを別のリーダー DB インスタンスに転送します。新しいリーダーインスタンスへの自動切り替え中に、RDS Proxy は古いリーダーインスタンスと新しいリーダーインスタンスのレプリケーションラグをチェックします。RDS Proxy は、以前のリーダーインスタンスと同じ変更を加えて、新しいリーダーインスタンスが最新の状態になるようにします。そうすれば、RDS Proxy があるリーダー DB インスタンスから別のリーダー DB インスタンスに切り替えたときに、アプリケーションで古いデータが表示されることはありません。

接続が固定されている場合、接続の次のクエリはエラーを返します。ただし、アプリケーションはすぐに同じエンドポイントに再接続できます。RDS Proxy は、available 状態の別のリーダー DB インスタンスに接続をルーティングします。手動で再接続する場合、RDS Proxy は古いリーダーインスタンスと新しいリーダーインスタンス間のレプリケーションラグをチェックしません。

Aurora クラスターに使用可能なリーダーインスタンスがない場合は、RDS Proxy はこの状態が一時的であるか永続的であるかを確認します。それぞれの場合の動作は次のとおりです。

クラスターに 1 つ以上のリーダー DB インスタンスがありますが、いずれも Available 状態になっていないとします。例えば、すべてのリーダーインスタンスが再起動しているか、問題が発生している可能性があります。この場合、リーダーエンドポイントへの接続を試行し、リーダーインスタンスが利用可能になるまで待ちます。接続借用タイムアウト期間内にリーダーインスタンスが使用可能いならなかった場合、接続試行は失敗します。リーダーインスタンスが利用可能になると、接続試行は成功します。
クラスターにリーダー DB インスタンスがないとします。その場合は、リーダーエンドポイントに接続しようとすると、RDS Proxy はすぐにエラーを返します。この問題を解決するには、リーダーエンドポイントに接続する前に、クラスターに 1 つ以上のリーダーインスタンスを追加します。

リーダーエンドポイントがクエリスケーラビリティにどのように役立つか

プロキシのリーダーエンドポイントは、次の方法で Aurora クエリのスケーラビリティを支援します。

リーダーインスタンスを Aurora クラスターに追加すると、RDS Proxy は任意のリーダーエンドポイントへの新しい接続を別のリーダーインスタンスにルーティングできます。この方法では、1 つのリーダーエンドポイント接続を使用して実行されたクエリは、別のリーダーエンドポイント接続を使用して実行されるクエリの速度を低下させません。クエリは個別の DB インスタンスで実行されます。各 DB インスタンスには、独自のコンピューティングリソースやバッファキャッシュなどがあります。
実用的な場合は、RDS Proxy は特定のリーダーエンドポイント接続を使用するすべてのクエリの問題に同じリーダー DB インスタンスを使用します。これにより、同じテーブルに対する一連の関連クエリが、特定の DB インスタンスでキャッシング、プランの最適化などを活用できます。
リーダー DB インスタンスが使用できなくなった場合、アプリケーションへの影響は、セッションが多重化されているか固定されているかによって異なります。セッションが多重化されている場合、RDS Proxy は、後続のクエリを、ユーザー側でアクションを実行せずに別のリーダー DB インスタンスにルーティングします。セッションが固定されている場合、アプリケーションはエラーを受け取り、再接続する必要があります。リーダーエンドポイントにすぐに再接続でき、RDS Proxy は、接続を利用可能なリーダー DB インスタンスにルーティングします。プロキシセッションの多重化および固定の詳細については、「RDS Proxy の概念」を参照してください。
クラスター内のリーダー DB インスタンスの数が多いほど、リーダーエンドポイントを使用して作成できる同時接続が増えます。例えば、クラスターに 4 つのリーダー DB インスタンスがあり、それぞれが 200 の同時接続をサポートするように設定されているとします。また、プロキシが最大接続の 50% を使用するように設定されているとします。ここでは、プロキシのリーダーエンドポイントを介して確立できる接続の最大数は、リーダー 1 に対して 100 (200 の 50%) です。それはまた、リーダー 2 に対して 100 などと続き、合計で 400 になります。クラスターリーダー DB インスタンスの数を 2 倍の 8 とした場合、リーダーエンドポイントを経由する最大接続数は 2 倍の 800 になります。

リーダーエンドポイントの使用例

次の Linux の例は、リーダーエンドポイントを介して Aurora MySQL クラスターに接続していることを確認する方法を示しています。innodb_read_only 構成設定が有効になっています。CREATE DATABASE ステートメントなどの書き込み操作を実行しようとすると、エラーが発生して失敗します。また、aurora_server_id 可変を使用して DB インスタンス名を確認することで、リーダー DB インスタンスに接続していることを確認できます。

ヒント

接続が読み取り/書き込み可能か読み取り専用かを判断するために、DB インスタンス名の確認だけに頼らないでください。フェイルオーバーが発生すると、Aurora クラスター内の DB インスタンスがライターとリーダーの間でロールを変更する可能性があることに注意してください。


$ mysql -h endpoint-demo-reader.endpoint.proxy-demo.us-east-1.rds.amazonaws.com -u admin -p
...
mysql> select @@innodb_read_only;
+--------------------+
| @@innodb_read_only |
+--------------------+
|                  1 |
+--------------------+
mysql> create database shouldnt_work;
ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement

mysql> select @@aurora_server_id;
+---------------------------------------+
| @@aurora_server_id                    |
+---------------------------------------+
| proxy-reader-endpoint-demo-instance-3 |
+---------------------------------------+

次の例は、リーダー DB インスタンスが削除された場合でも、プロキシリーダーエンドポイントへの接続がどのように機能するかを示しています。この例では、Aurora クラスターには、instance-5507 と instance-7448 の 2 つのリーダーインスタンスがあります。リーダーエンドポイントへの接続は、リーダーインスタンスの 1 つを使用してスタートします。この例の中で、delete-db-instance コマンドによってこのリーダーインスタンスは削除されます。RDS Proxy は、後続のクエリでは、別のリーダーインスタンスに切り替えます。


$ mysql -h reader-demo.endpoint.proxy-demo.us-east-1.rds.amazonaws.com
  -u my_user -p
...
mysql> select @@aurora_server_id;
+--------------------+
| @@aurora_server_id |
+--------------------+
| instance-5507      |
+--------------------+

mysql> select @@innodb_read_only;
+--------------------+
| @@innodb_read_only |
+--------------------+
|                  1 |
+--------------------+

mysql> select count(*) from information_schema.tables;
+----------+
| count(*) |
+----------+
|      328 |
+----------+

mysql セッションの実行中、次のコマンドは、リーダーエンドポイントが接続されているリーダーインスタンスを削除します。


aws rds delete-db-instance --db-instance-identifier instance-5507 --skip-final-snapshot

mysql セッションでは、再接続しなくてもクエリが続きます。RDS Proxy は、自動的に別のリーダー DB インスタンスに切り替わります。


mysql> select @@aurora_server_id;
+--------------------+
| @@aurora_server_id |
+--------------------+
| instance-7448      |
+--------------------+

mysql> select count(*) from information_schema.TABLES;
+----------+
| count(*) |
+----------+
|      328 |
+----------+

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

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

RDS Proxy により、EC2 インスタンスなど、別の VPC のリソースから 1 つの VPC の Aurora DB クラスターへのアクセスを設定できます。例えば、組織に、同じデータベースリソースにアクセスする複数のアプリケーションがあるとします。各アプリケーションは独自の VPC 内にある場合があります。

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

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

2 つの VPC を作成するか、Aurora の作業に既に使用している 2 つの VPC を選択します。各 VPC には、インターネットゲートウェイ、ルートテーブル、サブネット、セキュリティグループなど、独自のネットワークリソースが関連付けられている必要があります。VPC が 1 つしかない場合は、別の VPC をセットアップして正常に Aurora を使用できるようにするステップについて Amazon Aurora の開始方法と相談できます。Amazon EC2 コンソールで既存の VPC を調べて、相互に接続するリソースの種類を確認することもできます。
接続する Aurora DB クラスターに関連付けられた DB プロキシを作成します。「RDS Proxy の作成」の手順に従います。
RDS コンソールのプロキシの [詳細] ページの [プロキシエンドポイント] セクションで、[エンドポイントの作成] を選択します。「プロキシエンドポイントの作成」の手順に従います。
クロス VPC エンドポイントを読み取り/書き込み可能にするか、読み取り専用にするかを選択します。
Aurora DB クラスターと同じ VPC のデフォルトを受け入れる代わりに、別の VPC を選択します。この VPC は、プロキシが存在する VPC と同じ AWS リージョンに存在する必要があります。
これで、 Aurora DB クラスターと同じ VPC からサブネットとセキュリティグループのデフォルトを受け入れるのではなく、新しい選択を行います。選択した VPC のサブネットとセキュリティグループに基づいて、これらを作成します。
Secrets Manager シークレットの設定を変更する必要はありません。各エンドポイントがどの VPC にあるかに関係なく、プロキシのすべてのエンドポイントで同じ認証情報が機能します。
新しいエンドポイントが Available (利用可能) 状態に達するのを待ちます。
完全なエンドポイント名を書き留めます。これは、データベースアプリケーションの接続文字列の一部として指定する、Region_name.rds.amazonaws.com で終わる値です。
エンドポイントと同じ VPC 内のリソースから新しいエンドポイントにアクセスします。このプロセスをテストする簡単な方法は、この VPC 内に新しい EC2 インスタンスを作成することです。次に、EC2 インスタンスにログインし、mysql または psql コマンドを実行して、接続文字列のエンドポイント値を使用して接続します。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

RDS Proxy の削除

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