プロダクトノート
静かに増えるデータベース
ユーザーが増えてきた。うれしい反面、認証データをいつまで今のデータベースに置けるのかが気になり始める。移行先を選び、データを分け、切り替えの手順を組む。その仕事を、サービスが忙しくなってから抱えたくはありません。Authrimは、新しいアカウントを受け入れるデータベースを、必要になる前に用意します。
移し替える前に、置き場所を増やす
Authrimが使うCloudflare D1には、データベース1つあたりの容量に上限があります。無料プランでは500MB、有料プランでは10GBです。ユーザーや保存する情報が増えれば、いずれ別の保存先が必要になります。
そのたびに全員分のデータを移すのは大変です。Authrimは最初から、アカウントを複数のデータベースに振り分けられる構成にしています。分けた保存先の一つひとつを、ここでは「シャード」と呼びます。
登録済みのアカウントは動かさず、新しく登録されるアカウントの保存先を増やす。アカウント用データベースは、この考え方で拡張します。
何を保存するかで、増え方も違う
OAuthクライアントやポリシーなどのテナント設定。ユーザーのアカウントと個人情報。メールアドレスなどから保存先を探すための索引。Authrimでは、用途の違うこれらのデータを分けて保存しています。
ユーザーが増えても、すべてのデータベースを一緒に増やす必要はありません。アカウント用と検索用では、件数も増える速さも違います。それぞれの状況を見ながら容量を追加します。
残りの登録枠を見て、次を用意する
新しいアカウントの保存先は、そのテナントが使えるシャードから選びます。正常に動いていて、目標件数に対する割当件数の割合が低いものを優先します。
ここで見るのはディスクの使用率ではありません。設定した目標アカウント数に対して、あと何件受け入れられるかです。たとえば目標が10万件なら、残り2万件という余裕を次の保存先を用意する目安にします。
使えるシャードの余裕が減ると、用意してある予備を割り当てます。複数のテナントで一つのシャードを使う共有型でも、一つのテナントだけが使う専有型でも、考え方は同じです。
共有テナントのみ
専有テナントのみ
共有・専有が混在
普段の運用で、しなくてよくなること
自動プロビジョニングを設定しておけば、登録数が増えるたびに担当者がデータベースを作る必要はありません。テーブルを用意し、新しい登録先につなぐ作業も繰り返さずに済みます。容量を増やすたびに、既存アカウントの引っ越しを計画する必要もありません。
担当者は、増設の進み具合や失敗の有無、利用量と費用が想定内かを見ます。権限不足やサービス側の上限で止まったときは、人が対応します。それ以外の保存先の準備は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の公式仕様。