接続数、接続の急増、プーリング

結果の要約

この実験では、アプリケーションがDSQLに接続する際にIAM認証と接続の確立がどの程度の負担になるか、また接続が一度に集中したときに拒否や遅延が起きるかを確認しました。最小範囲（MVP）として、E002規模のデータが入ったDSQLクラスター1つに対し、負荷発生器1台から、トークン署名、逐次接続、接続維持とリクエストごとの新規接続の比較、接続500個・1,000個の同時要求を測定しました。対照群は今回測定していません。

DSQLはパスワードの代わりにIAMで署名したトークンで認証します。トークンの署名はネットワーク呼び出しなしにランナー内で行われ、p50 0.2 msでした。最初の呼び出しだけはクライアントの初期化により131 msかかりました。新しい接続を張って最初の照会を終えるまでは、逐次実行100回でp50 15.5 ms、p95 109 ms、p99 120 msでした。

接続を維持した16個のワーカーは商品照会を毎秒8,370件（p50 1.9 ms）処理しましたが、リクエストごとに新しい接続を張ると毎秒121件（p50 131 ms）となり、約70分の1になりました。接続500個と1,000個を一度に要求したときは、すべて拒否なく成功しましたが、すべて確立されるまでにそれぞれ3.7秒と8.2秒かかりました。この速度（毎秒約120–135個）はリクエストごとに新規接続を張る場合のスループットと近く、DSQLの接続確立速度の制限なのか、ランナーの単一PythonプロセスがTLS接続を処理する限界なのかは、今回の測定では区別できませんでした。急増直後の新規接続はp50 16.2 msで、平常時と同じでした。

本番利用の観点

DSQLのIAMトークン認証自体の負担は小さいものでした。署名は0.2 msで、トークンを数分間再利用すれば接続ごとに署名する必要もありません。接続1,000個を一度に要求しても拒否されませんでした。しかし新規接続1回に15–120 msかかるため、リクエストごとに接続を新しく張る構造（例：接続プールなしで動作する短時間の関数）では、スループットが接続を維持した場合の約1/70に落ちました。接続プールを使い、DSQLは1時間を過ぎた接続を切断するため、プールが接続を定期的に入れ替えるように設定する必要があります。対照群とRDS Proxyとの比較は行っていません。

確認する問い

DSQLの認証・接続の更新・急増への対応にはどのような負担があるか？

実行条件

• リージョンと日時： ソウル（ap-northeast-2）、2026-09-29 10:25–10:27 UTC。
• 構成： D1 Aurora DSQLシングルリージョンクラスター（パブリックエンドポイント）、E002規模のデータ（注文1,100万行など約5 GiB）。E002の2回目の測定と同じクラスターです。
• クライアント： m7g.4xlarge Spotランナー1台、Python 3.11、psycopg 3、TLS sslmode=verify-full。トークンはgenerate_db_connect_admin_auth_tokenで署名しました。
• 測定項目：
  • トークン署名50回。
  • 逐次接続100回：新規接続 → SELECT 1 → クローズ。
  • 16個のワーカーが30秒間商品照会：接続維持 対 リクエストごとの新規接続。
  • 接続500個、1,000個の同時要求（非同期の単一プロセス）。
  • 急増直後の逐次接続20回。
• 計画から変わった点： アプリの同時実行数16/64/256/1,024とプールサイズ16/64/128の組み合わせ、60秒間の10倍の接続試行、RDS Proxy、対照群（R1・A1・A2）との比較、メモリ・拒否率の測定は実行していません。

性能結果

測定	結果
トークン署名	p50 0.2 ms、p95 0.3 ms、最大131.5 ms（最初の呼び出し）
逐次の新規接続 + 最初の照会	p50 15.5 ms、p95 109.0 ms、p99 119.7 ms、エラー0
照会、接続維持（16個）	8,370 TPS、p50 1.9 ms、p99 2.4 ms
照会、リクエストごとの新規接続（16個）	121 TPS、p50 130.9 ms、p99 247.1 ms
同時接続500個	500個成功、3.7秒、接続あたりp50 3.6秒
同時接続1,000個	1,000個成功、8.2秒、接続あたりp50 3.9秒、p99 8.2秒
急増直後の新規接続	p50 16.2 ms、p95 24.6 ms

開発・運用のしやすさ

• 認証： パスワードを保存せず、IAMロールの権限（dsql:DbConnectAdmin）で接続します。シークレットのローテーション作業はありませんが、接続を張るすべての箇所にトークン署名のコードが必要です。
• 同時署名の問題： E002では、256個の接続が同時に初回接続した際、すべてのスレッドがトークンに署名しようとインスタンスの認証情報を照会して失敗しました（NoCredentialsError）。プロセスごとに署名を1回だけ行うようロックをかけ、再試行を加えて解決しました。接続プールの初期化のように接続が集中するコードでは注意が必要です。
• 接続の寿命： DSQLは1時間を過ぎた接続を切断します。E002では50分ごとに接続を入れ替えました。
• 診断値の誤解： E004ではSHOW max_connectionsが20を返しましたが、公式のクォータはクラスターあたり接続1万個です。今回、1,000個の同時接続はすべて成功しました。

費用

同じクラスターを使ったE002の2回目の測定の一部として、この試験区間（10:26–10:28 UTC）のDSQL使用量は2,603 DPU（約$0.03）でした。クラスターとランナーの費用はE002レポートの費用の節に含めています。

結論と限界

• IAMトークン認証と接続の急増はDSQLにとって大きな負担ではなく、リクエストごとに新しい接続を張る構造が最大の性能リスクでした。
• 限界：1回の実行で、ランナー1台の単一プロセスによる測定です。急増時の接続速度がクライアントの限界なのかサービスの制限なのかは区別できませんでした。対照群とRDS Proxyとの比較がないため、「何倍」かは言えません。

後片付けの記録

• この試験はE002の2回目の測定実行（e002-20260929t081139z-4dce）のクラスターとランナーを使いました。リソースは11:08–11:10 UTCに削除し、e002.py verifyのremaining_count=0（11:10:30 UTC）と手動でのクロスチェック（DSQLクラスター・実験用VPC・実験用IAMロール・オープンなSpotリクエストが0個）を完了しました。