コンテンツにスキップ
Authrim

リフレッシュトークン負荷テスト

テスト概要

項目詳細
テスト日2025年12月
対象エンドポイントPOST /token (grant_type=refresh_token)
目的盗難検知付きリフレッシュトークンローテーションのパフォーマンスを測定

テスト環境

インフラ構成

コンポーネントテクノロジー説明
WorkerCloudflare WorkersOAuth2/OIDCエンドポイント処理
Durable ObjectsCloudflare DORefreshTokenRotator（トークンローテーション管理）
DatabaseCloudflare D1ユーザー情報、セッション、監査ログ
CacheCloudflare KVJWKキャッシュ、RBACクレームキャッシュ、ユーザーキャッシュ

アーキテクチャ

flowchart TB
    subgraph Local["テスト環境"]
        k6["k6 OSS / K6 Cloud"]
    end

    subgraph CF["Cloudflare"]
        Edge["Cloudflare Edge"]

        subgraph Worker["op-token Worker"]
            W["トークン処理 + JWT署名"]
        end

        subgraph Cache["キャッシュ層"]
            KV["KV: JWK / RBAC / ユーザーキャッシュ"]
        end

        subgraph DO["Durable Objects"]
            RTR["RefreshTokenRotator"]
        end

        subgraph DB["Database"]
            D1["D1: sessions / audit_logs"]
        end
    end

    k6 -->|HTTPS| Edge
    Edge --> W
    W --> KV
    W --> RTR
    W --> D1
    RTR --> D1

テスト設定

設定項目値本番推奨
REFRESH_TOKEN_ROTATION_ENABLEDtruetrue
REFRESH_TOKEN_EXPIRY30日30日
ACCESS_TOKEN_EXPIRY1時間1時間
RBAC_CACHE_TTL5分5分
USER_CACHE_TTL1時間1時間

テスト方法論

シナリオ: Refresh Token Storm

本番環境でのリフレッシュトークンローテーション動作をシミュレート：

項目設定
トークンローテーション有効（毎回新しいリフレッシュトークンを発行）
VU設計VUごとに独立したトークンファミリー
テストパターン正常ローテーションパスのみ（エラーケースなし）
Think Time0ms（連続リクエスト）

TokenFamilyV2設計

バージョンベースの盗難検知：

{
  "sub": "user_id",
  "client_id": "client_id",
  "rtv": 5,              // Refresh Token Version
  "jti": "unique_id",
  "exp": 1735689600
}
  • rtv (Refresh Token Version): トークンファミリー内のバージョン番号
  • 古いバージョンのトークン使用 → 盗難として全トークン無効化
  • 状態管理はDurable Objects、監査永続化はD1

プリセット構成

プリセット目標RPS時間最大VUユースケース
rps100100 RPS2分120本番ベースライン
rps200200 RPS2分240高トラフィックシナリオ
rps300300 RPS2分360ピーク負荷検証

結果 - 200 RPSテスト

実行日時: 2025年12月3日 09:33 JST

K6メトリクス

メトリクス値
総リクエスト数29,186
成功率100%
トークンローテーション成功率100%
エラー0

Cloudflare Analytics

メトリクス値備考
Worker Duration P509.35 msMedian
Worker Duration P99816.24 msTail latency
CPU Time P504.80 ms
CPU Time P9914.40 ms
DO Wall Time P509.16 msDurable Objects処理時間
DO Wall Time P9918.43 ms
D1 Reads10,5100.36/リクエスト
D1 Writes23,5180.81/リクエスト

DOとD1効率

メトリクス計算値説明
DOリクエスト/Workerリクエスト3.09サブリクエスト効率
D1 Reads/リクエスト0.36RBACキャッシュヒット率 > 95%
D1 Writes/リクエスト0.81監査ログとセッション更新

結果 - 3,000 RPSテスト（シャーディング）

シャーディングの影響

シャード数DO P99DOエラーHTTP失敗
32781ms11,972多数
4843ms00

劇的な改善:

  • DO P99: 781ms → 43ms（95%削減）
  • DOエラー: 11,972 → 0（100%解消）

Before vs After（3,000 RPS）

メトリクス32シャード48シャード改善
Worker P5012ms12ms同等
Worker P95100ms39ms-61%
Worker P99781ms43ms-94%
DOエラー11,9720-100%
成功率~96%100%✅

最適化履歴

D1読み取りクエリ削減

最適化段階D1 Reads/リクエスト改善
V1（キャッシュなし）~14.6ベースライン
V2（RBACキャッシュ前）9.7-34%
V2（RBACキャッシュ後）0.36-96%

適用した最適化

日付最適化効果
2025-12-01TokenFamilyV2（バージョンベース盗難検知）DOストレージI/O削減
2025-12-01UserCache（KV Read-Through）D1ユーザークエリ削減
2025-12-03非同期監査ログ（Fire-and-Forget）レスポンスレイテンシ削減
2025-12-03RBACクレームキャッシュ（5分TTL）D1 RBACクエリ96%削減

キャッシュ戦略

キャッシュTTL目的
USER_CACHE1時間ユーザー情報（Read-Through）
REBAC_CACHE5分RBACクレーム（ロール、権限、グループ）
CLIENTS_CACHE1時間クライアント情報
KeyManager5分JWK署名鍵（Workerメモリ）

キャパシティ推奨

用途推奨RPS根拠
通常運用≤200P99 < 500ms維持
ピーク対応≤2,50048シャード使用
絶対上限≤3,00048シャードでゼロエラー

MAU換算

RPSトークン発行/時間トークン発行/日推定MAU
100360,0008.6M200K-400K
200720,00017.3M500K-1M
3001,080,00025.9M1M-2M

換算式:

RPS = (MAU × DAU率 × リクエスト/DAU) / (稼働時間 × 3600) × ピーク係数
    ≈ MAU / 5,000

主要な発見

1. シャーディングが不可欠

48シャードで3,000 RPSのエラーを完全解消（32シャードでは11,972件のDOエラー）。

2. RBACキャッシュでD1負荷96%削減

D1 readsが14.6/リクエスト→0.36/リクエストに減少。

3. トークンローテーションは信頼性高

200 RPSでローテーション有効で100%成功率。

4. Workerは効率的

CPU時間は負荷下でも4-15msを維持。

パフォーマンス目標

メトリクス目標結果状態
成功率> 99.9%100%✅
トークンローテーション> 99%100%✅
Worker Duration P99< 1000ms816ms / 43ms✅
DO Wall Time P99< 100ms18.43ms / 43ms✅
D1 Reads/リクエスト< 50.36✅

結論

Authrimのリフレッシュトークンエンドポイント（ローテーション有効）は：

  • 200 RPSで100%成功率
  • 100%トークンローテーション成功
  • 0.36 D1 reads/リクエスト（キャッシュで96%削減）
  • 3,000 RPSでゼロエラー（48シャード使用）

重要なポイント: 適切なシャーディング（48シャード）により、システムは不安定（11,972エラー）から完全に信頼性の高い状態（0エラー）に変わります。

TokenFamilyV2設計はセキュリティ（盗難検知）とパフォーマンス（バージョンベース状態管理）の両方を提供します。