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

Authrim は Workers でリクエストを処理し、Cloudflare の状態を持つサービスに ID 情報やプロトコル状態を保存します。ユーザーに近い場所で Worker を動かすことで通信経路の一部を短くできますが、すべての DB やセッションがその場所へ移るわけではありません。

処理とデータの場所は別

構成要素	確認すること
Workers	公開リクエストの振り分け、プロトコル処理、ストレージを呼ぶサービスの配置
Service Bindings	各 Worker を公開 HTTP サービスにせず、Worker 間を呼び出す経路
Durable Objects	特定のオブジェクトの状態を強い整合性で管理。配置はリクエストの入口とは別
D1	明示的な経路と配置を持つ Core・PII・Lookup・管理／制御用の保存先
KV	設定、キャッシュ、署名付きレジストリ。反映遅延やキャッシュの挙動も考慮
R2・Queues	有効な機能で使うオブジェクト保存と非同期処理

Service Bindings は Worker 間の呼び出しを提供します。ストレージ待ちがなくなる、複数サービスを使う処理全体が即座に終わる、という意味ではありません。

Authrim のスケーリング

Workers はリクエスト処理を担います。状態を持つ部分の容量は別に管理し、プロトコル用サービスには Durable Object のシャード設定があり、D1 の容量と配置は Control が管理します。容量を追加しても、すべての既存アカウントが自動移動したり、混雑した DB が必ず速くなったりするわけではありません。

登録数、検索パターン、シャード別の負荷、再試行、メールや外部 IdP の応答を監視します。世界中からアクセスできる入口があっても、サービスの上限や容量計画は必要です。

データの所在地

Control Plane の経路は、データの役割と所在地の区分を識別します。residency プロファイルによるポリシー、Worker の配置、Durable Object の location hint は別の仕組みです。Cloudflare も location hint と jurisdiction の制約を分けて説明しています。hint を、データの境界が保証される根拠にはしないでください。

性能を測る

ログイン、コード交換、トークン更新、UserInfo、管理操作では、必要な通信とストレージ処理が異なります。それぞれの処理全体を測り、レイテンシーの分布、エラー率、同時実行数、データ量、使用したリリースと設定を記録します。Worker の CPU 時間と、利用者が待つ応答時間は別です。

公開済みの負荷試験値は、その実行条件での結果です。新しいバージョン、プラグイン、地域、保存構成で同じ容量が出る保証ではありません。負荷試験レポートも参照してください。

費用

Authrim にユーザー単位のライセンス料金はありません。一方、Worker のリクエストと CPU、D1 の読み書き・保存量、Durable Objects、KV、R2、Queues、外部プロバイダーには利用に応じた費用があります。監視、バックアップ、保守、障害対応も別途必要です。

トップページの計算機は、記載した前提に基づく概算です。導入計画には実際の負荷測定と最新の Cloudflare 料金を使ってください。

経路と状態の管理はアーキテクチャで説明しています。