エッジコンピューティング

AuthrimはCloudflare Workers向けのエッジネイティブなアイデンティティ＆アクセスプラットフォームです。ログイン、トークン交換、セッション検証、フェデレーション、管理サーフェスを複数Workerに分割し、Service Bindingsで接続します。このページでは、なぜアイデンティティにエッジネイティブなデプロイが重要なのか、AuthrimがWorkersネイティブなprimitiveをどう使うか、運用者が評価すべきパフォーマンスとコスト特性を説明します。

なぜアイデンティティにエッジか？

従来のアイデンティティプラットフォームは、1つまたは少数のリージョンにある中央集権的なサーバーで動作します。これには本質的な限界があります。

課題	中央集権型アプローチ	エッジアプローチ
レイテンシ	固定リージョンへの余分な往復が発生	ワークロードに応じてユーザーまたはストレージに近い場所で実行可能
コールドスタート	コンテナ/VM起動で遅延が増える場合がある	V8 isolateは軽量に起動
スケーリング	垂直スケーリングまたは複雑なオートスケーリング	リクエスト単位の自動水平スケーリング
単一障害点	リージョン障害がサービス全体に影響しやすい	Cloudflareのグローバルネットワーク上でルーティング可能
グローバルユーザー	中央リージョンへの距離に依存	Global Workersと明示的なstorage/residency profileを組み合わせられる

認証はすべてのユーザーインタラクションのクリティカルパス上にあります。遅いログインフローやトークン検証は、ユーザー体験とアプリケーションパフォーマンスに直接影響します。エッジネイティブなデプロイは不要なルーティングを減らしますが、実際のレイテンシーはワークロード、ストレージプロファイル、Cloudflareプラン制限、ネットワーク経路に依存します。

Cloudflare Workersプラットフォーム

AuthrimはCloudflare Workers上で動作します。これは独自の特性を持つサーバーレスプラットフォームです。

V8 Isolate（コンテナではない）

WorkersはV8 isolate — Chromeと同じJavaScriptエンジン — で実行されます。コンテナやVMとは異なり:

軽量な起動 — isolate起動は一般にコンテナ起動より軽量
小さなランタイムフットプリント — コンテナイメージやVM fleetの管理を避けられる
セキュア — テナント間のハードウェアレベル分離

グローバル分散

WorkersはCloudflareのグローバルネットワーク上で動作します。Authrimは公開プロトコルエンドポイントにこれを使いつつ、D1 binding、runtime storage profile、tenant-D1 routing、外部DB adapter、必要に応じたDurable Object location hintでストレージ配置を明示します。

プラットフォームプリミティブ

AuthrimはWorkersエコシステムをフル活用しています。

プリミティブ	Authrimでの用途
Workers	ステートレスなリクエスト処理（認証フロー、トークン検証）
Durable Objects	hotで強整合な状態（sessions、auth codes、challenges、PAR、DPoP、device/CIBA、SAML、flow state）
D1	デプロイ/テナントDB（`DB`、`DB_PII`、`DB_ADMIN`、生成済みtenant-D1 slots）
KV	生成設定、cache、consent cache、tenant runtime registry snapshots
Service Bindings	Worker間通信（ネットワークコストゼロのRPC）
Queues	非同期処理（Webhook、SCIM sync、監査ログエクスポート）

ステートレスWorkers ＋ステートフルDurable Objects

Authrimのアーキテクチャは関心事を明確に分離します。

flowchart TB
    subgraph Stateless["ステートレス層 — Workers"]
        w1["リクエストルーティング"]
        w2["トークン署名"]
        w3["OIDC検証"]
        w4["ポリシー評価"]
        w5["クレームマッピング"]
    end
    subgraph Stateful["ステートフル層 — Durable Objects"]
        do1["セッション保存"]
        do2["認可コードライフサイクル"]
        do3["チャレンジ状態"]
        do4["リフレッシュトークン"]
        do5["レート制限カウンター"]
    end
    Stateless -- RPC --> Stateful
    Stateless --> D1["D1 (SQL)"]
    Stateful --> DOS["DOストレージ（シャード単位）"]

Workersはステートレスな計算を処理します — リクエストの解析、トークンの検証、ポリシーの評価、レスポンスの構築。設定なしで水平スケーリングします。

Durable Objectsはステートフルな操作を処理します — セッションの保存、認可コードのライフサイクル管理、レート制限、プロトコル状態の維持。各DOインスタンスはシングルスレッドのアクターであり、強い一貫性を持つストレージを備え、対応済みの箇所では明示的なシャード設定によりスケールします。詳細はアーキテクチャ — Durable Objectの状態管理とシャーディングを参照してください。

この分離により、ステートレス層はWorkersに合わせてスケールし、ステートフル層はDurable Objectの明示的なシャーディングとストレージプロファイル選択によりスケールします。

パフォーマンス特性

K6 Cloudで代表的なAuthrimワークロードに対して測定:

メトリック	値	備考
トークン系エンドポイント	2,500〜3,500 RPS	token/introspection系の検証ワークロード
完全OAuthログインフロー	約150 logins/sec	代表的なログインワークロード
Worker CPU時間	典型1〜4ms	検証ランでの観測値
エラー率	検証ランで0%	測定したシナリオ内

なぜレイテンシーが重要か

Identity操作はログイン、トークン更新、API認可、フェデレーションの経路にあります。Authrimの構成は、protocol workerをリクエスト経路に近づけ、worker間通信にService Bindingsを使うことで不要なネットワークhopを減らします。一方で、ストレージが重い経路ではD1、Durable Objects、tenant-D1、外部DB、audit sinkを含めたキャパシティ設計が必要です。

スケーリング

水平スケーリング

Workersは自動的にスケールします — Cloudflareが受信リクエストを処理するために必要な数のisolateをインスタンス化します。プロビジョニングもキャパシティプランニングも不要です。

Durable Objectsについては、セッション、認可コード、リフレッシュトークンローテーション、チャレンジなど高トラフィックなauth stateに明示的なシャード数を使います。詳細はアーキテクチャ — Durable Objectの状態管理とシャーディングを参照してください。

結果:

flowchart TB
    req["受信リクエスト"]
    req --> W1["Worker 1"] & W2["Worker 2"] & WN["Worker N"]
    W1 & W2 & WN --> DO0["Session shard 0"] & DO1["Session shard 1"] & DO2["Auth code shard 0"] & DO3["Refresh shard 0"]

配置とストレージ局所性

Authrimはcompute placementとstorage selectionを分離します。

Worker routingは ar-router とService Bindingsで処理されます。
Storage localityはruntime storage profile（shared-d1、tenant-d1、外部DBプロファイル）で選択します。
Durable Objectの locationHint は初期配置をガイドできますが、レイテンシー保証ではありません。
tenant-D1デプロイでは、生成済みtenant DB slot、migration、registry snapshotを計画する必要があります。

コスト効率

Authrim自体にユーザー単位のベンダー課金はありませんが、運用コストがゼロになるわけではありません。Cloudflare利用量と運用要件がコストを左右します。

コスト要因	影響するもの
Workers	リクエスト量、CPU時間、worker数、deployment profile
D1 / tenant-D1	read/write量、DB数、tenant slot数、storage size
KV	cache read/write、生成設定、tenant runtime registry snapshots
Durable Objects	hot state requests、storage、shard counts
R2 / logging sinks	audit retention、archive policy、export volume
Operations	monitoring、security review、compliance、support、backup、incident response

エッジ vs. 従来型 — まとめ

側面	従来型（中央集権）	Authrim（エッジ）
レイテンシ	選択リージョンと距離に依存	worker routing、storage profile、network pathに依存
コールドスタート	コンテナ/VM起動で遅延が増える場合がある	Workers isolateは軽量に起動
スケーリング	手動/オートスケール（分単位）	自動（ミリ秒単位）
リージョン	明示的にプロビジョンしたリージョン	Cloudflare global networkと明示的なstorage/residency選択
コスト	ベンダー/インフラモデルに依存	Cloudflare利用量 + Authrim運用コスト
運用負荷	サーバー、スケーリング、パッチ、証明書	Cloudflare-managed primitivesを利用。ただしAuthrimのデプロイ/コンプライアンス運用は必要
データ局所性	リージョン選択に制限	Runtime storage profiles、tenant-D1、外部DBプロファイル、location hints
可用性	リージョンバウンドアーキテクチャ	Cloudflare services、deployment design、storage profileに依存

次のステップ

アーキテクチャ — システム設計、データベース抽象化、DOシャーディングの詳細
アイデンティティハブ — 統合アイデンティティ連携のコンセプト