レート制限のための同時接続数計画
APIレート制限に対する最適な同時接続数を計算します。Littleの法則と制限を超えずにスループットを最大化する方法を学びます。
Best Practices
詳細な説明
同時接続数の計画
同時接続数はレート制限を効率的に利用する能力に直接影響します。接続が少なすぎるとキャパシティを無駄にし、多すぎるとレート制限エラーが発生します。
Littleの法則
同時実行数、スループット、レイテンシの基本的な関係はLittleの法則で記述されます：
L = lambda x W
ここで：
L = 平均同時リクエスト数（同時実行数）
lambda = 平均到着レート（スループット、リクエスト/秒）
W = システム内の平均時間（レイテンシ、秒）
実践的な例
| シナリオ | レート制限 | 平均レイテンシ | 必要な同時実行数 |
|---|---|---|---|
| GitHub API | 1.39/秒 | 200ms | ceil(1.39 x 0.2) = 1 |
| Stripe読み取り | 100/秒 | 150ms | ceil(100 x 0.15) = 15 |
| OpenAI GPT-4 | 8.33/秒 (500 RPM) | 2000ms | ceil(8.33 x 2.0) = 17 |
| Google Maps | 50/秒 | 100ms | ceil(50 x 0.1) = 5 |
| 内部API | 1000/秒 | 50ms | ceil(1000 x 0.05) = 50 |
コネクションプールのサイジング
コネクションプールは、レイテンシのバラつきを処理するために計算された同時実行数の1.5倍から2倍にサイジングすべきです：
プールサイズ = ceil(レート制限 x 平均レイテンシ x 1.5)
適応型同時実行
本番システムでは、適応型同時実行を実装します：
- 計算された同時実行数から開始
- 実際のレイテンシ（p50、p99）を監視
- p99が増加した場合、同時実行数を10%削減
- p99が安定しており利用率が80%未満の場合、10%増加
- 計算値の2倍を超えないこと
ユースケース
レート制限が50リクエスト/秒で平均レスポンスタイムが300msのサードパーティAPIからデータを取り込むETLパイプラインを構築しています。レート制限を尊重しながらスループットを最大化するための最適なワーカースレッド数とコネクションプールサイズを決定する必要があります。