データベースプロキシ - RDS Proxy vs Azure SQL Database serverless

データベースプロキシの必要性と RDS Proxy の設計思想

モダンなアプリケーション、特にサーバーレスアーキテクチャでは、Lambda 関数の同時実行数が急増した際にデータベースへのコネクション数が爆発的に増加する問題が発生します。RDS のデフォルトの最大接続数は、db.t3.micro で約 66、db.r6g.large で約 1,000 ですが、Lambda の同時実行数が数百〜数千に達すると、各実行環境がそれぞれコネクションを確立するため、データベースの接続上限を容易に超過します。AWS RDS Proxy は、アプリケーションとデータベースの間に位置するフルマネージドのデータベースプロキシで、コネクションプーリングにより数千のアプリケーション接続を少数のデータベース接続に多重化します。RDS Proxy は Amazon RDS (MySQL、PostgreSQL、MariaDB、SQL Server) と Amazon Aurora (MySQL、PostgreSQL) をサポートし、既存のデータベースエンドポイントを RDS Proxy のエンドポイントに置き換えるだけで導入できます。Azure SQL Database にはサーバーレスコンピューティング層がありますが、これはデータベース自体の自動スケーリングであり、RDS Proxy のようなコネクション管理の課題を解決するプロキシサービスではありません。Azure で同等の機能を実現するには、アプリケーション側でコネクションプーリングライブラリを実装する必要があります。

この分野について体系的に学びたい方は、関連書籍 (Amazon) も参考になります。

コネクションプーリングとマルチプレキシング

RDS Proxy のコネクションプーリングは、アプリケーションからの接続リクエストを受け付け、事前に確立されたデータベース接続のプールから利用可能な接続を割り当てます。トランザクションが完了すると、接続はプールに返却され、次のリクエストに再利用されます。この仕組みにより、Lambda 関数が 1,000 同時実行されても、データベースへの実際の接続数を 100 程度に抑えることが可能です。RDS Proxy はコネクションの借用 (borrow) と返却 (return) を透過的に管理するため、アプリケーションコードの変更は不要です。接続の多重化 (multiplexing) では、同一のデータベース接続を複数のクライアントセッション間で共有し、セッション状態 (トランザクション分離レベル、文字セットなど) を自動的に切り替えます。RDS Proxy はピン留め (pinning) の概念を持ち、セッション固有の状態 (一時テーブル、ユーザー変数、プリペアドステートメントなど) が使用されている場合は、そのセッションを特定のデータベース接続に固定します。ピン留めが発生するとマルチプレキシングの効率が低下するため、RDS Proxy は CloudWatch メトリクス (DatabaseConnectionsCurrentlySessionPinned) でピン留めの発生状況を監視できます。Azure にはこのようなフルマネージドのデータベースプロキシサービスが存在しないため、PgBouncer や ProxySQL などのオープンソースプロキシを自前で運用する必要があります。

フェイルオーバーの高速化と可用性

RDS Proxy は、データベースのフェイルオーバー時間を大幅に短縮します。通常の RDS Multi-AZ フェイルオーバーでは、DNS の伝播に 30〜60 秒かかり、アプリケーションが新しいプライマリインスタンスに接続するまでにダウンタイムが発生します。RDS Proxy を使用すると、プロキシがフェイルオーバーを検知して新しいプライマリインスタンスへの接続を自動的に切り替えるため、アプリケーションから見たフェイルオーバー時間を最大 66% 短縮できます (AWS 公式ドキュメントの記載)。Aurora の場合、RDS Proxy と組み合わせることで、フェイルオーバー時間をさらに短縮し、数秒以内での切り替えが可能です。RDS Proxy はリーダーエンドポイントもサポートしており、読み取りワークロードを Aurora レプリカに自動的に分散します。Azure SQL Database のフェイルオーバーグループも自動フェイルオーバーを提供しますが、DNS ベースのフェイルオーバーであるため、TTL の伝播時間 (通常 30 秒) が必要です。RDS Proxy のプロキシベースのフェイルオーバーは、DNS に依存しないため、より高速で予測可能な切り替えを実現します。RDS Proxy は VPC 内に配置され、プライベートサブネットからのみアクセス可能なため、データベースへの直接アクセスを防止するセキュリティ境界としても機能します。

Lambda との統合と IAM 認証

RDS Proxy は Lambda 関数との統合に特化した設計がなされています。Lambda 関数が RDS Proxy に接続する際、IAM データベース認証を使用することで、データベースのユーザー名とパスワードをコードに埋め込む必要がなくなります。IAM 認証では、Lambda 関数の実行ロールに RDS Proxy への接続権限を付与するだけで、Secrets Manager に保存されたデータベース認証情報を RDS Proxy が自動的に取得・管理します。この仕組みにより、認証情報のローテーションも Secrets Manager の自動ローテーション機能で透過的に行われ、アプリケーションの再デプロイは不要です。Azure SQL Database も Azure Active Directory 認証をサポートしますが、Lambda + RDS Proxy + IAM 認証 + Secrets Manager の統合的なセキュリティチェーンは AWS 固有の優位性です。RDS Proxy の料金は、プロキシインスタンスの vCPU あたり 0.015 USD/時で、db.r6g.large (2 vCPU) のデータベースに対するプロキシコストは月額約 21.6 USD (0.015 × 2 × 24 × 30) です。データベースの接続上限超過によるエラーやフェイルオーバー時のダウンタイムを考慮すると、この追加コストは十分に正当化されます。SAM テンプレートでは、AWS::RDS::DBProxy リソースを定義するだけで RDS Proxy をデプロイでき、Lambda 関数の環境変数にプロキシエンドポイントを設定するだけで統合が完了します。

パフォーマンスモニタリングと運用

RDS Proxy は CloudWatch メトリクスを通じて、プロキシの動作状況を詳細に監視できます。主要なメトリクスとして、ClientConnections (クライアント接続数)、DatabaseConnections (データベース接続数)、QueryRequests (クエリリクエスト数)、AvailabilityPercentage (可用性)、DatabaseConnectionsCurrentlySessionPinned (ピン留めされた接続数) などが提供されます。ClientConnections と DatabaseConnections の比率を監視することで、コネクションプーリングの効率を定量的に評価できます。たとえば、ClientConnections が 500 で DatabaseConnections が 50 であれば、10:1 の多重化率が達成されていることがわかります。RDS Proxy のログは CloudWatch Logs に出力でき、接続エラー、認証失敗、フェイルオーバーイベントなどの詳細を確認できます。Azure SQL Database にも DMV (Dynamic Management Views) によるコネクション監視はありますが、RDS Proxy のようにプロキシ層での統合的なメトリクスとログは提供されません。RDS Proxy は Enhanced Monitoring と Performance Insights とも連携し、データベースのパフォーマンスボトルネックをプロキシ層からデータベース層まで一貫して分析できます。

さらに詳しく知りたい方は、関連書籍 (Amazon) で理解を深められます。

まとめ

AWS RDS Proxy は、サーバーレスアーキテクチャにおけるデータベース接続管理の課題を根本的に解決するフルマネージドプロキシサービスです。コネクションプーリングによる接続数の多重化 (数千のアプリケーション接続を数十のデータベース接続に集約)、フェイルオーバー時間の最大 66% 短縮、IAM 認証と Secrets Manager の統合によるセキュアな認証情報管理、CloudWatch メトリクスによる詳細な運用監視など、Azure には同等のフルマネージドプロキシサービスが存在しない領域で AWS が明確な優位性を持っています。vCPU あたり 0.015 USD/時という低コストで、Lambda との統合を含むサーバーレスデータベースアクセスの信頼性とセキュリティを大幅に向上させます。