プロダクトノート
静かに増えるデータベース
ユーザーが増えてきた。うれしい反面、認証データをいつまで今のデータベースに置けるのかが気になり始める。移行先を選び、データを分け、切り替えの手順を組む。その仕事を、サービスが忙しくなってから抱えたくはありません。Authrimは、新しいアカウントを受け入れるデータベースを、必要になる前に用意します。
移し替える前に、置き場所を増やす
Authrimが使うCloudflare D1には、データベース1つあたりの容量に上限があります。無料プランでは500MB、有料プランでは10GB。ユーザーや保存する情報が増えれば、どこかで次の置き場所が必要になります。
そのときに全員分のデータを移し替えずに済むよう、Authrimは最初から、アカウントを複数のデータベースへ振り分けられる構成にしています。分割した保存先の単位を、ここでは「シャード」と呼びます。
すでに登録されているアカウントは元の場所に置いたまま、新しく登録されるアカウントの保存先を増やす。これが、アカウント用データベースを拡張するときの基本です。
何を保存するかで、増え方も違う
OAuthクライアントやポリシーなどのテナント設定、ユーザーのアカウントと個人情報、メールアドレスなどから保存先を探すための索引。Authrimでは、これらを別々に保存しています。
ユーザーが増えたからといって、すべてのデータベースを一緒に増やす必要はありません。アカウント用と検索用では、必要な件数も増加のペースも違います。それぞれの状況を見て、容量を追加します。
残りの登録枠を見て、次を用意する
新しいアカウントの保存先は、そのテナントが使えるシャードの中から選びます。健康に動作していて、目標件数に対する割当件数の割合が低いものを優先します。
判断の基準になるのは、ディスクの使用率ではなく、設定した目標アカウント数に対して、あと何件を受け入れられるかです。たとえば目標を10万件とした場合、残り2万件という余裕を、次の保存先を準備する目安にします。
利用できるシャードの余裕が少なくなると、用意してある予備を割り当てます。複数のテナントが同じシャードを使う共有型でも、1つのテナントだけが使う専有型でも、この考え方は変わりません。
共有テナントのみ
専有テナントのみ
共有・専有が混在
普段の運用で、しなくてよくなること
自動プロビジョニングの設定を済ませれば、登録数が増えるたびに担当者がデータベースを作り、テーブルを用意し、新しい登録先へつなぐ作業を繰り返す必要はありません。既存アカウントの引っ越し計画も、容量を追加するたびには要りません。
担当者が見るのは、増設が進んでいるか、失敗していないか、利用量と費用が想定の範囲かです。権限不足やサービス側の上限で止まれば対応する。この役割分担を前提に、Authrimが次の保存先を用意します。
今日の空きだけでは足りない
残り2万件あっても、1日に100件増えるサービスと、1時間に1万件増えるサービスでは、用意を急ぐ度合いが違います。
そこでAuthrimは、現在の割当件数に加えて、直近の登録ペースから今後必要になる容量を見積もります。アカウント用も検索用も予測の対象です。定期処理は1分おきに動き、アカウントの割当後にも予測を更新します。
必要な量を計算するときは、すでに作成中のシャードも数に入れます。複数の処理が同じ容量不足に気づいても、そのたびに余分なデータベースを作らないためです。
作成から利用開始までをつなぐ
予備だけでは足りないときは、Cloudflareの管理APIを使ってD1を作成します。テーブルを用意し、Workerから参照できるよう設定し、新しい保存先の情報を配布する。読み書きを確認できたものから、割当先として使い始めます。
自動で進めるには、自動プロビジョニングを有効にし、D1用とWorkers用のAPIトークンをそれぞれ設定する必要があります。自動実行できない場合は、運用者がセットアップツールで処理を進める形になります。
作成の途中経過は保存されます。一時的な通信障害なら、その状態をもとに再試行できます。権限不足やリソース上限など、人の対応が必要な理由で止まった場合は、原因を解消してから再開します。
準備が追いつかず登録枠がなくなった場合には、新規登録の再試行が必要になることもあります。先回りして用意するのは、そうした待ち時間をできるだけ減らすためです。
データを動かす判断は、運用者に残す
容量の追加と、既存データの移動は別の操作です。たとえば、共有シャードで始めたテナントを専有シャードに移す場合。新しい登録先を増やすだけでは済まず、すでにあるデータも移す必要があります。
この移行を始めるかどうかは、運用者が判断します。承認を受けた後の同期、検証、切り替えは、Authrimが進めます。
現在、対応している配置変更は共有から専有への移行です。専有から共有へ戻す移行や、既存アカウントを自動で均等に配置し直す機能はありません。
使い終えたシャードの削除にも、人の承認が必要です。使う容量が増えたからといって、既存データの移動や削除まで自動で始まることはありません。
どこまで確かめているか
2026年7月のテストデータによる計測では、20万アカウントを保存した時点で、Coreが約208MB、PIIが約238MB、Lookupが約426MBでした。それぞれ、有料プランの1データベースあたり10GBという上限に対して5%未満です。保存する属性や索引によって、実際の使用量は変わります。
目標アカウント数の初期値は、1シャードあたり10万件です。物理的に入るだけ詰め込むのではなく、次を用意する余裕を残しています。
Authrimはpre-1.0で、この仕組みの長期間・大規模な本番運用での実績は、これから積み上げていく段階です。20万件の保存容量を測った結果と、数百万人が日々使う環境での運用実績は、分けて見ています。
成長のたびに、移行計画を立てずに済むように
小さなサービスのうちから、大規模な構成を用意しておく必要はありません。少ないシャードで始めて、登録の増え方に合わせて保存先を足していく。そのための準備と手順を、Authrimの中に組み込んでいます。
ユーザーが増えてきたときに、まずデータベースの引っ越しを考える。その仕事を減らして、サービスを育てるほうに時間を使えるようにしたいと考えています。
容量の計測：2026年7月30日、テスト環境の20万アカウント。MBは10進表記。D1の容量上限はCloudflareの公式仕様。