Amazon Aurora DSQL は、フルマネージドかつサーバーレスの分散SQLデータベースとして、スケーラビリティと可用性を両立できる選択肢です。一方で、その性能と安定性を実際に引き出せるかどうかは、データベース本体の設定よりもむしろアプリケーション側の接続管理設計に大きく左右されます。従来のリレーショナルデータベースと同じ感覚で接続を扱うと、接続レート制限や接続寿命といったAurora DSQL固有の制約に足をすくわれかねません。本記事では、AWSが公開している接続プーリング戦略の考え方を整理し、開発リーダーやバックエンドエンジニアが実務で押さえるべき設計指針を、Ragateの導入支援の視点も交えて解説します。

Aurora DSQL が接続管理に課す固有の制約

Aurora DSQL の接続プーリングを設計するうえで、まず理解しておきたいのが接続に関する明確な制約です。Aurora DSQL は新規接続の確立に対してレート制限を設けており、通常時は1秒あたり100接続、瞬間的なバースト時でも1秒あたり1,000接続が上限となります。アプリケーションの起動時やスケールアウト時に大量の接続を一斉に張ろうとすると、この上限に達して接続エラーが発生する可能性があります。

さらに重要なのが接続寿命の上限です。Aurora DSQL では、1つの接続が確立してから1時間が経過すると、その接続がアイドル状態であってもトランザクションの実行中であっても、サービス側が強制的に切断します。つまり、一度張った接続を無期限に使い回すという前提は成り立ちません。加えて、クラスターあたりの同時接続数は10,000というクォータが設定されており、この枠の中で全アプリケーションの接続をやりくりする必要があります。

これらの制約は、Aurora DSQL がトランザクション単位で接続を扱うアーキテクチャを採用していることに由来します。制約を弱点ととらえるのではなく、接続を有限で寿命のあるリソースとして扱う前提で設計することが、安定運用への第一歩になります。

公式コネクタが担うIAMトークンのライフサイクル自動管理

Aurora DSQL への認証は、パスワードではなくIAMベースの認証トークンを用います。このトークンには有効期限があり、期限が切れる前に新しいトークンを取得し直す必要があります。ここを自前で実装しようとすると、トークンの生成タイミングやキャッシュ、失効時のリトライといった煩雑なロジックを抱え込むことになります。

そこで有効なのが、AWSが提供する公式コネクタやドライバの活用です。公式コネクタは、認証トークンのライフサイクルを自動で管理します。具体的には、トークンの生成、有効期間の80%に達した時点でのキャッシュ更新、そして透過的な差し替えを、アプリケーションが意識しないところで実行します。トークンはローカルでの署名処理によって生成されるため、リモート呼び出しを伴わず、オーバーヘッドはごくわずかです。

なお、発行されるトークンの有効期限は、基となるIAMクレデンシャルのセッション有効期限を超えることはありません。たとえば1時間で切れるロールを使っている場合、トークンの寿命もその範囲に収まります。公式コネクタを使うことで、認証周りの実装を自社で保守する負担が減り、トークン更新漏れによる接続断のリスクも下げられます。これは、限られた工数で堅牢なアプリケーションを構築したいチームにとって現実的なメリットです。

ジッターで再接続集中（thundering herd）を分散する

接続寿命が1時間という制約は、単純に対処すると新たな問題を生みます。プール内の接続がアプリ起動時にまとめて張られた場合、それらはほぼ同時刻に生成されるため、寿命もほぼ同時に尽きます。結果として、多数の接続が一斉に失効し、それらを一斉に張り直そうとする再接続の集中が発生します。これが、いわゆる thundering herd（サンダリングハード）と呼ばれる再接続集中の問題です。前述の接続レート制限と重なると、再接続の波そのものがエラーの原因になりかねません。

この問題を避けるための実践的な手法がジッター（jitter）の導入です。各接続の最大寿命にランダムな揺らぎを加えることで、失効のタイミングを時間軸上に散らします。AWSが示す推奨設定では、最大接続寿命（MaxConnLifetime）を55分に設定し、そこに5分のジッター（MaxConnLifetimeJitter）を加えます。こうすると、各接続はおおよそ55分から60分の間でばらついた寿命を持つようになり、失効が特定の瞬間に集中しなくなります。

寿命の上限を1時間ちょうどではなく55分側に寄せているのは、サービス側の強制切断を待つのではなく、アプリケーション側が余裕を持って計画的に接続を作り替えるためです。ジッターは数行の設定で導入できる一方、大規模なワークロードほど効果が大きく、費用対効果の高い対策といえます。

プールサイジングと横スケールの設計指針

接続プールのサイズ設定にも目安があります。AWSが示す出発点は、アプリケーションインスタンスあたりで最小2〜5接続、最大10〜20接続という控えめな値です。あわせて、プールが空いた接続を待つ際の接続タイムアウトは30秒程度を確保し、バースト時のキューを消化できるようにします。アイドルタイムアウトについては無効化する方針が推奨されます。Aurora DSQL ではアイドル接続そのものにコストがかからず、接続を維持しておくほうが、再接続時のTLSハンドシェイクや認証のオーバーヘッドを避けられるためです。

スケール戦略の考え方も従来型と異なります。負荷が増えたときに1インスタンスあたりの接続数を増やすのではなく、小さめのプールを持つアプリケーションインスタンスを増やして水平方向にスケールアウトする方針が推奨されます。クラスターあたり10,000という同時接続クォータは、この横スケールを支える枠として活用します。次の表は、標準的なアプリケーションインスタンスでの設定目安をまとめたものです。

これらの値はあくまで出発点であり、実際のトラフィック特性に応じて調整することが前提です。ただし、いきなり大きなプールを構えるのではなく、小さく始めて水平に広げるという原則を守ることが、レート制限やクォータとの衝突を避ける近道になります。

Lambda とマルチリージョン構成での設定勘所

サーバーレス実行環境である AWS Lambda では、接続プールの扱いに特有の注意点があります。最も重要なルールは、プールをハンドラ関数の外側、つまりモジュールスコープでインスタンス化することです。こうすることで、ウォーム状態の実行環境が再利用される際にプールも引き継がれ、リクエストのたびに接続を張り直す無駄を避けられます。ハンドラ内でプールを生成してしまうと、呼び出しごとに新規接続が発生し、レート制限に抵触しやすくなります。

プールサイズについては、Lambda では1〜3接続程度に抑えるのが妥当です。1つの実行環境は基本的に同時に1リクエストしか処理しないため、大きなプールは無駄になります。アイドルタイムアウトは設定せず、実行環境が生存している間は接続を維持します。最大寿命は他の環境と同様に55分にジッターを加え、1時間の強制切断を回避します。

マルチリージョンでactive-active構成を組む場合は、リージョンごとに独立した接続プールを用意し、それぞれがローカルのAurora DSQLエンドポイントを指すように設計します。読み取りはローカルリージョンの速度で完結し、リージョン間のラウンドトリップが発生するのはコミット時のみです。したがって、レイテンシに敏感なワークロードほど、接続性の良いリージョンの組み合わせを選ぶことがコミットレイテンシの低減につながります。単一の巨大なプールで複数リージョンをまたごうとせず、リージョン単位で完結したプールを持つことが設計の基本になります。

Ragate視点での評価と導入判断のポイント

ここまでの内容を踏まえると、Aurora DSQL を評価するうえで見落としてはならない論点が浮かび上がります。それは、PgBouncer や pgpool-II といったデータベース側のプロキシを導入すべきではないという点です。Aurora DSQL は、トランザクション単位での接続多重化をデフォルトで内蔵しており、トランザクションを実行している間だけQuery Processorに接続を割り当てる仕組みを持ちます。つまり、外部プロキシが担ってきた多重化の役割をサービス自身が引き受けているため、DB側プロキシを重ねても機能が重複し、かえって構成を複雑にして逆効果になり得ます。プーリングはアプリケーション側で完結させるのが正しい設計です。

Ragateでは、顧客のサーバーレス化や分散データベース導入を支援する際、こうした接続管理の設計をアプリケーション層の標準として早い段階で組み込むことを重視しています。Aurora DSQL のようなマネージドサービスは、インフラ運用の負担を大きく減らす一方で、性能を引き出す責任がアプリケーション設計側に移る側面があります。レート制限や接続寿命、ジッター、横スケールといった観点をPoCの段階から検証項目に含めておくことで、本番移行後に再接続集中やレート制限違反といった問題に直面するリスクを抑えられます。

導入判断にあたっては、既存アプリケーションが接続をどのように保持しているか、ライブラリが寿命やジッターの設定に対応しているか、Lambdaなどサーバーレス実行環境との組み合わせで無駄な再接続が起きていないか、といった点を棚卸しすることをおすすめします。Aurora DSQL の制約は、正しく設計すればむしろスケーラビリティを担保する土台になります。技術選定の初期から接続戦略を織り込むことが、分散SQLの利点を安全に享受するための鍵だと考えます。