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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

場合によっては、クラスター内の 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 はこの状態が一時的であるか永続的であるかを確認します。それぞれの場合の動作は次のとおりです。

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

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

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

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