私の雇用主は現在、複数の Postgres インスタンス (顧客ごとに 1 つ、固有のサイト コードを持つ) を所有しており、これらは顧客の敷地内で物理的に分離されています。各顧客はインスタンス内で 1 ～ 4 個のデータベースを実行しており、各データベースには 20 を超えるスキーマが含まれています。
アクセス/制御を簡素化するために、オンプレミスまたはクラウド プロバイダー (RDS など) を使用して、これらのデータベースを単一の Postgres インスタンスにまとめようとしています。お客様は引き続きデータベースにアクセスできますが、共有 RESTful サービス レイヤーを導入し、各 API の URL パスの一部として追加されたサイト コードを使用して特定のデータベースをターゲットにします。パフォーマンスに関する SLA (1 秒未満で 90%) を満たし、リソース使用量を抑えるために、サービス レイヤーで接続プールを使用する予定です。
私たちが直面している主な問題は、Postgres が接続中にデータベースを必要とすることです。つまり、顧客ごとに接続プールが必要になり、多くのリソースを非効率的に使用します。リソースを効率的に使用していないため、サービス レイヤーのインスタンスをさらに用意する必要があり、アーキテクチャのコストと複雑さが増します。サービス レイヤーの複数のインスタンスに顧客を効果的に「分割」することは可能ですが、接続の非効率的な使用という実際の問題は解決されません。
私が考慮していない別の解決策はありますか? リクエストが特定のデータベースに転送される単一の接続プールを用意する方法でしょうか? または、負荷に基づいて動的にサイズを変更できる動的接続プールでしょうか?
ありがとう
答え1
AWS RDS プロキシ接続要件を削減する実用的な方法かもしれません。