テスト概要
| 項目 | 詳細 |
|---|
| テスト日 | 2025年12月11日 |
| 対象エンドポイント | GET /authorize?prompt=none |
| 目的 | サイレント認証の最大スループットとパフォーマンス限界を測定 |
テスト環境
K6 Cloud構成
インフラ
| コンポーネント | テクノロジー |
|---|
| コンピュート | Cloudflare Workers |
| 状態管理 | Durable Objects (シャード化) |
| データベース | Cloudflare D1 |
| キャッシュ | Cloudflare KV |
シャード構成
| Durable Object | 標準 | 拡張 |
|---|
| AuthorizationCodeStore | 64 | 128 |
| SessionStore | 64 | 128 |
| TokenStore | 48 | 64 |
テスト方法論
シナリオ
- Admin APIで500ユーザーセッションを事前作成
- 各VUがランダムなセッションを選択してサイレント認証を実行
- 成功判定: HTTP 302リダイレクト +
codeパラメータ
負荷パターン
executor: 'ramping-arrival-rate',
{ target: 1000, duration: '15s' }, // ramp-up
{ target: 2000, duration: '180s' }, // 維持
{ target: 0, duration: '15s' }, // ramp-down
結果 - パフォーマンスメトリクス
サマリー(64シャード)
| RPS | 総リクエスト数 | HTTP失敗 | CF DOエラー | 状態 |
|---|
| 500 | 73,124 | 0 | 13 | ✅ |
| 1,000 | 146,249 | 0 | 0 | ✅ |
| 1,500 | 219,374 | 0 | 0 | ✅ |
| 2,000 | 292,499 | 0 | 0 | ✅ |
| 2,500 | 365,624 | 0 | 0 | ✅ |
| 3,000 | 445,378 | 0 | 0 | ✅ |
| 3,500 | 521,646 | 0 | 0 | ✅ |
| 4,000 | 599,440 | 160 | 1,223 | ⚠️ |
128シャードテスト
| RPS | HTTP失敗 | CF DOエラー | 状態 |
|---|
| 4,000 | 0 | 2,112 | ✅ |
| 4,500 | 287 | 1,376 | ⚠️ |
効果: 128シャードで4,000 RPSのHTTP失敗がゼロに(64シャードでは160件)
K6クライアントレイテンシ(ms)
| RPS | P50 | P95 | P99 | Max |
|---|
| 500 | 406.62 | 453.68 | 535.93 | 1,802 |
| 1,000 | 403.44 | 453.39 | 528.18 | 2,978 |
| 2,000 | 404.65 | 451.84 | 528.25 | 3,014 |
| 2,500 | 652.44 | 793.59 | 837.71 | 5,181 |
| 3,000 | 1,243.49 | 1,582.82 | 1,641.73 | 5,482 |
| 3,500 | 614.85 | 1,631.44 | 1,727.45 | 8,077 |
| 4,000 | 458.43 | 668.64 | 5,621.68 | 58,618 |
結果 - インフラメトリクス
Worker Duration (ms)
| RPS | P50 | P75 | P90 | P99 | P999 |
|---|
| 500 | 48.14 | 49.96 | 51.27 | 68.10 | 141.93 |
| 1,000 | 49.44 | 50.45 | 51.79 | 70.15 | 155.28 |
| 2,000 | 49.74 | 50.86 | 52.15 | 68.27 | 157.83 |
| 2,500 | 82.86 | 101.78 | 116.63 | 134.59 | 157.84 |
| 3,000 | 157.24 | 180.27 | 194.63 | 222.03 | 254.70 |
| 3,500 | 76.16 | 148.35 | 193.47 | 231.27 | 257.43 |
| 4,000 | 50.23 | 56.26 | 74.84 | 175.81 | 3,750.00 |
Worker CPU Time (ms)
| RPS | P50 | P75 | P90 | P99 | P999 |
|---|
| 500 | 2.24 | 2.78 | 3.23 | 8.01 | 21.93 |
| 1,000 | 2.35 | 2.78 | 3.17 | 10.47 | 23.27 |
| 2,000 | 2.34 | 2.83 | 3.45 | 6.40 | 20.30 |
| 3,000 | 2.25 | 2.85 | 3.55 | 5.80 | 17.38 |
| 4,000 | 2.27 | 2.83 | 3.53 | 13.68 | 15.55 |
重要な発見: CPU時間はRPSに関係なく安定(P50で2-3ms)
Durable Objects Wall Time (ms)
| RPS | 総DOリクエスト | DOエラー | P50 | P75 | P90 | P99 |
|---|
| 500 | 186,520 | 13 | 122.04 | 180.60 | 320.99 | 1,779 |
| 1,000 | 399,282 | 0 | 170.87 | 179.58 | 189.45 | 556 |
| 2,000 | 747,073 | 0 | 169.92 | 177.78 | 183.42 | 321 |
| 2,500 | 1,097,668 | 0 | 180.54 | 193.23 | 408.75 | 645 |
| 3,000 | 1,336,694 | 0 | 183.39 | 731.48 | 1,040.33 | 1,312 |
| 3,500 | 1,565,263 | 0 | 178.94 | 190.19 | 690.62 | 1,381 |
| 4,000 | 1,796,556 | 1,223 | 172.92 | 182.15 | 190.99 | 442 |
シャーディング分析
4,000 RPSでの64 vs 128シャード
| メトリクス | 64シャード | 128シャード | 改善 |
|---|
| HTTP失敗 | 160 | 0 | ✅ 解消 |
| clientDisconnected | 160 | 0 | ✅ 解消 |
| DOエラー | 1,223 | 2,112 | ⚠️ 増加 |
| 最大エラーなしRPS | 3,500 | 4,000 | +500 RPS |
注意: DOエラーの増加は新シャードのコールドスタートコストによるもの。ウォームアップ後は安定します。
キャパシティ推奨
| 用途 | 推奨RPS | 根拠 |
|---|
| 通常運用 | ≤2,000 | P99 < 600ms、エラー0% |
| ピーク対応 | ≤3,000 | P99 < 1,700ms、エラー0% |
| 絶対上限 | ≤3,500 | P99 < 1,800ms、DOエラー0% |
| ハードリミット(128シャード) | ~4,000 | HTTP失敗開始 |
主要な発見
1. Workerは軽量
CPU時間は全RPS帯でP50が2-3ms - Worker自体はボトルネックではありません。
2. DOキューイングがボトルネック
高RPS時、DO wall timeはリクエストキューイングにより急増します(処理時間ではなく)。
3. 3,500 RPSでゼロエラー達成
64シャードで、システムは3,500 RPSをHTTP失敗なし、DOエラーなしで処理します。
4. シャーディングでキャパシティ拡張
64→128シャードへの増加でエラーなし限界が3,500→4,000 RPSに(+14%)。
5. 4,500 RPSがハードシーリング
128シャードでも4,500 RPSでタイムアウト発生(Worker Durationが3.75秒の上限に到達)。
結論
Authrimのサイレント認証エンドポイントは:
- 64シャード: 3,500 RPSでゼロエラー
- 128シャード: 4,000 RPSでゼロエラー(+14%向上)
推奨設定:
- 通常運用: 64シャード(〜3,000 RPS)
- 高負荷: 128シャード(〜4,000 RPS)
Cloudflare Workers + Durable ObjectsアーキテクチャはDOシャーディングによる効果的な水平スケーリングを実証しています。ただし、コールドスタートオーバーヘッドにより128シャードが実用的な上限と考えられます。