D1の自動スケールアウト

Authrimは、アカウント数と保存先を検索する情報の増加を予測し、必要なD1データベースを追加します。追加時にはスキーマを作成し、WorkerからD1を使うための接続設定を検証します。準備が完了したデータベースを新しいアカウントの保存先として登録します。

容量は複数のデータベースに分けて確保します。１つのD1のサイズ上限は変わりません。追加後も既存アカウントは元の保存先を使います。アプリケーションはAuthrimのID管理APIを使い続け、データベースの追加と保存先の管理はAuthrimが行います。

保存するデータと保存先の検索

Authrimは、アカウントの状態、個人情報などの機微な値、保存先を検索する情報を分けて保存します。実装上の名称は、それぞれCore、PII、Lookupです。それぞれに複数のD1を使えます。管理画面やデータベース管理のための情報は別に保存し、アカウント数の予測による追加の対象には含めません。

新しいアカウントには、テナントの配置方針とデータの保存地域に合う保存先を割り当てます。読み書きするときは、登録済みの保存先情報を使います。すべてのD1を検索したり、データベース名だけで保存先を決めたりすることはありません。

Lookupの役割

Lookupは、ユーザーを探すときに使う索引です。メールアドレス、外部IdPのユーザー識別子、アカウントIDなどから、対象アカウントと、そのアカウント用・個人情報用のD1を特定します。個人情報の値を保存する本体のデータベースとは別に持ちます。

例えばメールアドレスでユーザーを検索する処理では、Authrimがメールアドレスから検索用の値を生成し、Lookupを検索します。検索結果を対象テナントで絞り、１つのアカウントに特定できた場合に、その保存先を検証して読み書きします。検索結果がない場合や複数ある場合はエラーになり、別のD1を順番に探すことはありません。

検索用の値には、秘密鍵を使って元の識別子から生成した索引値を使います。メールアドレスをそのまま索引キーにする方式ではありません。Lookupの容量不足はユーザーや保存先の検索にも影響するため、アカウントの保存容量とは別に予測します。

flowchart TB
    Start(["定期処理／新しいアカウントの割り当て"]) --> Count["割り当て件数と検索情報の増加を計測"]
    Count --> Predict["登録率をならし、予測期間内の必要容量を計算"]
    Predict --> Enough{"作成中の分を含めて容量が足りる？"}
    Enough -->|はい| Keep(["追加せず、既存の保存先を利用"])
    Enough -->|いいえ| Authority{"自動作成の準備が完了している？"}
    Authority -->|いいえ| Operator["設定を確認／保留中の操作をセットアップツールで実行"]
    Authority -->|はい| Request["追加要求を記録／作成数の上限と予算を確認"]
    Request --> Create["D1作成・スキーマ適用・Workerの接続設定更新"]
    Create --> Check{"接続設定と利用準備の検証に成功？"}
    Check -->|いいえ| Retry["未稼働のまま記録／再試行または運用者が対応"]
    Check -->|はい| Publish["保存先情報を配布し、割り当て可能にする"]
    Publish --> New(["新しいアカウントを追加したD1にも割り当てる"])

この図はアカウント用容量の追加判断を示しています。検索用容量も同じように不足を予測しますが、検索情報の登録・公開をもとに計測します。作成予算を使い切った場合は、追加処理の進行を待つ必要があります。

IDデータの構造と保存先の検証は、個人情報の分離で説明しています。

新しいアカウントの割り当て

保存先には、割り当て情報が有効で、稼働中かつ正常なD1を選びます。新規割り当てが許可され、目標アカウント数に達していないことも条件です。内部の状態ではactive・healthy・eligibleに対応します。複数テナントで共有するshared_poolか、テナント専用のtenant_exclusiveかという設定と、保存地域を確認します。

候補の中では、目標件数に対する割り当て済み件数の比率が低いD1を優先します。計算に使う値はallocated_account_count / target_account_countです。同率なら件数、分割先のIDの順で選びます。アカウント用と個人情報用の保存先はまとめて予約し、片方だけの割り当ては受け付けません。追加したD1も、割り当てと保存先情報の準備が整ってから使います。

追加したD1の空き容量は、新しいアカウントの保存に使います。既存アカウントの保存先を変える場合は、別に移行操作を行います。

アカウント容量の予測

成功したアカウント割り当ての累積件数から、登録の増加率を求めます。最新の計測値を指数加重移動平均（EWMA）に取り込み、変動をならしてから次の計算を行います。

予測される新規件数 = 切り上げ（EWMAによる登録率 × 予測期間）

予測アカウント数 = 割り当て済み件数 + 予測される新規件数

利用可能容量 = 切り捨て（目標容量の合計 ×（1 − 余裕率））

追加単位数 = 切り上げ（最大（0, 予測アカウント数 − 利用可能容量）÷ １単位あたりの利用可能な目標容量）

予測は、データの種類、共有・専用の区分、専用の場合の所有テナント、保存地域ごとに行います。追加を要求したもの、作成中のもの、準備済みのもの、稼働中のものは、確保予定の容量に含めます。内部の状態はrequested・provisioning・ready・activeです。この容量を計算に含めることで、同じ不足分を繰り返し要求しないようにします。ただし、準備が終わるまでは保存先に使えません。

計算前に、計測時刻、累積件数の増減、整数の範囲、設定値を検証します。率と割合には固定小数点の整数演算を使います。古い計測値や不正なカウンタから容量追加を決めることはありません。

計算例

１単位の目標が10万アカウント、余裕率が20%なら、予測に使う容量は８万です。割り当て済みが７万5,000件、ならした登録率が毎秒10件、予測期間が900秒なら、予測は８万4,000件になります。4,000件分が不足するため、対象のデータの種類・配置区分で１単位の追加を要求します。

これは計算方法を示す例です。実測した処理性能や保存できる容量の保証ではありません。実際の要求には、作成中のデータベースと作成数の予算も反映します。

保存先の検索に使う容量は別に予測する

保存先を探すための検索情報は、有効な保存先情報の件数と登録成功の件数から増加を測ります。こちらもEWMA、予測期間、余裕率を使い、検索用データベースごとの容量の重みを計算に含めます。アカウント用や個人情報用のD1を増やしただけでは、検索用の容量が足りるとは判断しません。

検索用の容量を増やす際は、検索情報の分割単位であるバケットの割り当てと、保存先情報の配布も調整します。検索情報の再配置と、アカウントデータの移行は別の操作です。検索情報を別のD1に移しても、アカウントや個人情報の保存先は変わりません。

容量計算と作成数の設定

以下は、Authrimのデータベース管理用設定のスキーマ既定値です。容量の計画に使う値で、Cloudflareの上限ではありません。すべての環境に同じ値を推奨するものでもなく、導入済み環境では設定が異なる場合があります。

この表は容量計算が参照する管理値です。同名のWorker環境変数を追加しても、これらの値は変更されません。

フィールド	既定値	用途
`target_account_count`	100,000	アカウント用の容量１単位の目標件数。
`account_forecast_horizon_seconds`	900	15分先までのアカウント予測。
`account_scale_out_headroom_bps`	2,000	目標容量の20%を余裕として残します。
`account_registration_ewma_alpha_bps`	5,000	最新の登録率の重みを50%にします。
`lookup_target_active_route_count`	100,000	容量の重みを適用する前の、検索用容量１単位の保存先情報の目標件数。
`lookup_forecast_horizon_seconds`	86,400	24時間先までの検索情報の予測。
`lookup_scale_out_headroom_bps`	2,000	検索用容量の余裕率20%。
`lookup_registration_ewma_alpha_bps`	2,500	最新の検索情報の増加率の重み25%。
`max_concurrent_provisioning`	2	同時に進める作成操作の上限。
`max_d1_resources`	1,000	Authrim側で設定する環境のD1作成数上限。
`daily_d1_create_budget`	20	１日のデータベース作成予算。

予測期間はアカウントが60〜2,592,000秒、検索情報が300〜2,592,000秒です。余裕率とEWMAの重みは、1%を100とする整数で指定します。余裕率は0〜9,000、EWMAの重みは1〜10,000を受け付けます。アカウント数の目標は、プロフィールのサイズ、インデックス、実際の保存量の増え方、処理負荷に合わせて調整してください。件数だけでは、大きなレコードが多いデータベースのバイト上限到達を防げません。

自動作成を有効にする条件

自動実行には、AUTHRIM_AUTOMATIC_PROVISIONING=trueを指定します。さらに、空でない別々のCLOUDFLARE_D1_API_TOKENとCLOUDFLARE_WORKERS_API_TOKENを用意し、Authrim側の自動作成の登録を準備済みにする必要があります。トークンには、対象データベースの作成とWorkerの更新に必要な権限を与えます。フラグだけでは自動実行は始まりません。

セットアップツールの自動作成フローで、登録と権限を準備・確認します。認証情報はWorkerのsecretとして保存してください。データベース管理用Workerの定期処理は毎分実行する設定です。アカウントの割り当て時にも容量を再確認します。定期処理での自動予測・作成は、自動作成の準備が整っている場合に実行します。

既存環境で有効にする手順

セットアップ画面の開き方はセットアップウィザードを参照してください。

セットアップツールの環境詳細を開き、Automatic provisioningの項目を使います。対象環境とCloudflareアカウントが一致していることを確認してから進めてください。

「Create one-time Cloudflare token」から一時トークンを作成し、入力欄へ貼り付けます。
「Enable」を押します。ツールは自動作成の登録を準備し、データベース管理用Workerを更新します。
ツールが用途別の認証情報を登録し、利用権限を確認します。初期設定用トークンの失効処理まで完了させます。
画面で準備済みの状態を確認します。処理が中断した場合は、表示された再開手順に従い、既存の操作を引き継ぎます。

運用開始前に、配置を共有・専用のどちらにするか、保存地域、１日の作成予算、環境全体の作成数上限を確認してください。登録増加に対して作成が間に合うよう、予測期間と余裕率も容量計画に含めます。作成数とデータベースの実サイズは別々に監視します。

運用開始後の確認

新規アカウントを登録したら、割り当て済み件数と予測が更新されることを確認します。追加要求が発生した場合は、その操作IDを追い、D1の作成、スキーマ適用、Workerの接続設定の検証、保存先情報の配布が完了したことを確認してください。その後、新しいアカウントの保存先として利用されることを確認します。

追加が進まないときは、操作の最終エラー、作成予算、APIトークンの権限、Workerの接続設定の順に確認します。D1が作成済みでも利用準備が完了していなければ、アカウントの保存先には使いません。

自動実行できない場合は、記録済みの保留中の操作をセットアップツールへ引き継げます。Authrimのリポジトリから、対象の操作を確認して実行します。

pnpm run setup control-provision --env prod --operation-id <operation-id> --dry-run
pnpm run setup control-provision --env prod --operation-id <operation-id>

環境名と操作IDは実際の値を使ってください。セットアップツールには環境の状態、鍵、Cloudflareへの権限が必要です。手作業で無関係なデータベースを作っても、Authrimの保存先として自動登録されるわけではありません。

作成処理と失敗時の扱い

Authrimは、容量の追加要求と操作IDを保存します。続いてD1の作成、スキーマ初期化、WorkerからD1への接続設定の更新・検証、保存先情報の配布、利用準備の確認を行います。これらの処理が完了してから、新しい保存先を使います。

作成数の上限、１日の作成予算、権限不足、登録済み構成と実際の構成の不一致、Cloudflare側のエラーで処理が止まる場合があります。再試行できる操作は状態を残して再確認します。再試行できないエラーでは運用者の対応を待ちます。新しく要求し直す前に、操作の最終エラーと、予測に記録された操作IDを確認してください。別の要求を繰り返すと、元の失敗を追いにくくなります。

容量の予測と実際の利用状態は分けて確認します。作成中のD1は確保予定の容量に含めますが、保存先に使うには稼働中・正常・割り当て可能であることが必要です。使える保存先がなければ容量不足のエラーを返し、任意のD1へ書き込むことはありません。

データの移行・削除とD1の上限

共有するD1からテナント専用のD1への変更には、別の移行フローがあります。容量予測だけでこの移行を承認したり、自動で共有へ戻したり、古いデータベースを削除したりしません。削除には独自の承認と安全確認があります。リリースに伴うスキーマ移行も、現在のスキーマで容量を増やす操作とは別です。

D1の実際のサイズ、クエリ時間、読み書きした行数、割り当て率、予測した増加、保留中の操作、WorkerからD1への接続設定を監視します。スケールアウトしても、Cloudflareのアカウント上限、データベースごとの上限、料金はなくなりません。Cloudflareが現在示す１データベースの最大サイズはWorkers Paidが10 GB、Freeが500 MBです。導入時には最新のD1の制限と料金を確認してください。

この予測の入力は、アカウントと保存先の検索情報の増加です。ディスク使用率や毎秒リクエスト数による自動拡張ではありません。特定の料金やユーザー数を保証するには、利用環境に合わせた容量設計と検証が必要です。