Amazon RDS Proxy

Amazon RDS Proxy は、アプリケーションと RDS / Aurora の間に配置されるフルマネージドなデータベースプロキシです。確立済みのデータベース接続をプールして複数のアプリケーション接続で共有することで、接続数の急増に伴うリソース枯渇を抑え、アプリケーションのスケーラビリティと可用性を高めます。インフラの管理は AWS が担い、利用者はプロキシエンドポイントへ接続先を向けるだけで利用できます。

解決する課題

アプリケーションが多数の短命なデータベース接続を頻繁に開閉すると、接続の確立そのものがオーバーヘッドになり、データベース側の接続数上限やメモリを圧迫します。とくに Lambda のように水平方向へ大量にスケールする実行環境では、同時実行数の増加に比例して接続が膨れ上がり、データベースが接続を受けきれなくなる事態が起こりやすくなります。

RDS Proxy は確立済みの接続をプールして使い回すことで、こうした接続の急増をデータベース側に波及させずに吸収します。さらに、データベースのフェイルオーバー時にはプロキシが切り替えを引き受け、アプリケーション側で接続を張り直す手間と停止時間を減らします。認証情報の管理や IAM 認証の統合も担うため、接続管理とセキュリティの両面で運用負荷を軽減できます。

主要概念と用語

• プロキシ: アプリケーションとデータベースの間に立つ仲介層。接続のプールと多重化を担い、アプリケーションはプロキシのエンドポイントへ接続する。
• 接続プール: 確立済みのデータベース接続をまとめて保持し、複数のクライアント接続で使い回す仕組み。接続確立のコストを削減する。
• ピン留め（ピンニング）: セッション固有の状態が検出された場合に、クライアント接続を特定のデータベース接続へ専有的に結び付ける挙動。多重化が効かなくなり効率が下がる。
• ターゲットグループ: プロキシが接続を振り向ける対象のデータベース（RDS インスタンスや Aurora クラスター）の集合。
• プロキシエンドポイント: アプリケーションが接続する接続先。読み書き用のほか、Aurora では読み取り専用エンドポイントも作成できる。
• IAM 認証: データベースのパスワードの代わりに IAM の認証トークンで接続する方式。プロキシ経由で利用すると鍵管理が簡素化する。
• Secrets Manager 連携: データベースの認証情報を Secrets Manager に保管し、プロキシがそこから取得して接続する仕組み。
• アイドルクライアントタイムアウト: クライアント接続が無操作のまま放置された場合に切断するまでの時間。

仕様・制限・クォータ

RDS Proxy は、RDS の MySQL / PostgreSQL / MariaDB と、Aurora の MySQL 互換 / PostgreSQL 互換エンジンに対応します。プロキシは VPC 内に配置され、アプリケーションとは同一 VPC からプライベートに接続する構成が基本です。データベースの認証情報は Secrets Manager に保管し、プロキシがその取得権限を持つ IAM ロールを介してアクセスします。

プロキシ数やターゲット数、同時接続数などにはサービス側の上限が設定されています。具体的な上限値や対応エンジンバージョンはリージョンや時期によって変わるため、最新の値は公式ドキュメントとサービスクォータで確認してください。接続プールの最大利用率や接続借用のタイムアウトといった挙動はプロキシの設定で調整できます。なお、セッションレベルの状態（一時テーブルや一部のセッション変数、保持中のトランザクションなど）が使われると接続がピン留めされ、多重化の効果が薄れる点は設計上の重要な制約です。

内部の仕組み

プロキシは複数のクライアント接続を受け付け、それらを少数の確立済みデータベース接続へ多重化します。あるクライアントがトランザクションを実行していない空き時間には、その背後のデータベース接続を別のクライアントへ貸し出すことで、限られた接続数を効率良く共有します。これにより、アプリ側の接続数がデータベースの物理的な接続数を上回っても、データベースの接続上限を圧迫しにくくなります。

接続の多重化が安全に行えるのは、セッション間で状態を引きずらない場合に限られます。セッション固有の状態が検出されるとプロキシはその接続をピン留めし、当該クライアントが切断するまで専有させます。ピン留めが頻発すると接続共有の利点が損なわれるため、何がピン留めを引き起こすかを把握することが重要です。

フェイルオーバー時には、プロキシがデータベースの状態変化を検知し、新しいプライマリへ接続を張り直します。アプリケーションはプロキシのエンドポイントに接続したままで済むため、フェイルオーバー中の接続エラーや待ち時間を抑えられます。プロキシ自体も冗長な構成で稼働し、可用性に配慮された設計になっています。

設計パターン / ベストプラクティス

最も効果が大きいのは、Lambda などサーバーレス実行環境からリレーショナルデータベースへ接続するパターンです。実行環境が大量にスケールしても、プロキシが接続を集約するためデータベース側の接続枯渇を防げます。バースト的なトラフィックや、多数のマイクロサービスが同一データベースを共有するケースでも同様の効果が得られます。

認証情報はアプリケーションに直書きせず、Secrets Manager に集約してプロキシ経由で利用します。データベースへの接続は IAM 認証と組み合わせると、長期的な静的パスワードへの依存を減らせます。可用性が要件であれば、フェイルオーバー時間の短縮効果を踏まえてプロキシを前段に置く構成を検討します。

運用・監視

監視は CloudWatch のメトリクスを中心に行います。クライアント接続数とデータベース接続数、接続プールの利用状況、ピン留めの発生状況、接続の借用に関する指標などを観察し、接続が効率良く共有されているかを確認します。ピン留めが多い場合は、原因となるセッション状態の利用箇所を見直します。

アプリケーションからの接続先はプロキシのエンドポイントに向け、接続不可時はセキュリティグループ、サブネット、Secrets Manager の権限、IAM ロールの設定を順に確認します。プロキシはマネージドで稼働するためパッチや冗長化の管理は不要ですが、対象データベースのメンテナンスやフェイルオーバーに合わせた挙動の確認は運用上の重要な観点です。アイドルタイムアウトや接続借用のタイムアウトなどのパラメータは、ワークロードの特性に合わせて調整します。

コスト

課金は主に、プロキシが対象とするデータベースインスタンスの容量に応じた時間単価に基づきます。利用するプロキシとデータベースの規模に比例してコストが増えるため、プロキシを導入することで得られる接続の安定性やフェイルオーバー短縮の価値と、追加コストを天秤にかけて判断します。

接続が枯渇して障害につながる事態を避けられる点や、運用負荷の軽減を考慮すると、サーバーレスや高並列のワークロードでは費用対効果が高くなりやすいです。一方で、接続数が常に少なく安定しているワークロードでは効果が限定的なこともあります。具体的な料金は時期・リージョン・データベースの規模によって変動するため、見積もりは最新の料金ページで確認してください。

セキュリティ

データベースの認証情報は Secrets Manager に保管し、プロキシがその取得を許可された IAM ロールを介してアクセスします。これによりアプリケーションが直接パスワードを保持する必要がなくなり、認証情報のローテーションも扱いやすくなります。クライアントからプロキシへの接続には IAM 認証を利用でき、データベース固有のパスワード配布を避けられます。

ネットワーク面では、プロキシを VPC 内に配置し、セキュリティグループで接続元を限定します。クライアントからプロキシ、プロキシからデータベースの双方で転送時の暗号化（TLS）を有効にし、通信を保護します。エンドポイントを不必要に公開せず、最小権限の IAM ロールとセキュリティグループ設計を徹底することが基本方針です。

Well-Architected の観点

信頼性の柱では、接続のプールによってデータベースの接続枯渇を防ぎ、フェイルオーバー時の切り替えをプロキシが引き受けることで、障害時の停止時間と接続エラーを減らせます。アプリケーション側はプロキシのエンドポイントへ接続したまま運用できるため、復旧の挙動が安定します。

パフォーマンス効率の柱では、接続確立のオーバーヘッドを抑え、限られたデータベース接続を多重化して有効活用することで、高並列のワークロードを支えられます。セキュリティの柱では、Secrets Manager と IAM 認証の統合によって認証情報の取り扱いを簡素化し、静的パスワードへの依存を減らせます。これらの効果を最大化するには、ピン留めを抑える実装と最小権限の設計が前提になります。

試験で問われるポイント

関連サービス・比較

読み取り負荷のスケールを担うリードレプリカと混同されがちですが、目的は異なります。リードレプリカは読み取りクエリを別ノードへ分散して処理能力を増やす仕組みであり、RDS Proxy は接続そのものを集約して管理する仕組みです。両者は競合せず、組み合わせて使うこともできます。

ハンズオン / CLI例

以下は、Secrets Manager に保管した認証情報と IAM ロールを使って RDS Proxy を作成し、対象データベースを登録する例です。サブネット ID やセキュリティグループ ID、シークレットの ARN、ロールの ARN、対象データベースの識別子は環境に合わせて置き換えてください。

# RDS Proxy を作成（認証情報は Secrets Manager から取得、TLS 必須）
aws rds create-db-proxy \
  --db-proxy-name app-db-proxy \
  --engine-family POSTGRESQL \
  --auth Description="app secret",AuthScheme=SECRETS,SecretArn=arn:aws:secretsmanager:ap-northeast-1:111122223333:secret:app-db-secret \
  --role-arn arn:aws:iam::111122223333:role/rds-proxy-role \
  --vpc-subnet-ids subnet-0123456789abcdef0 subnet-0123456789abcdef1 \
  --vpc-security-group-ids sg-0123456789abcdef0 \
  --require-tls

# 対象のデータベース（DBインスタンス）をプロキシに登録
aws rds register-db-proxy-targets \
  --db-proxy-name app-db-proxy \
  --db-instance-identifiers app-db

# 作成したプロキシのエンドポイントと状態を確認
aws rds describe-db-proxies \
  --db-proxy-name app-db-proxy