Ubie、Firebase Authから内製認証基盤へ無停止移行し年間1000万円以上を削減

Ubieは症状検索エンジン「ユビー」を提供しており、様々な角度の情報を蓄積し、時系列を加味してパーソナライズした情報提供をする必要があるため、プロダクト全体を通したID管理は極めて重要な位置づけにある。認証基盤には当初Firebase Auth（GCP Identity Platform）を採用していたが、700万MAUを超えるまでにグロースした現在では、無視できないコストになっていた。特にUbieでは新規ユーザーに自動的に匿名アカウントを発行し、ユーザーがアカウント登録しているかどうかに関わらず同じID体系で透過的に履歴情報等を扱うという設計を採っていたため、その利便性と引き替えに匿名アカウント分もMAUに計上され費用が増大していた。さらに、Capacitorでモバイルアプリを作っているなど特殊な要件が多く無理なハックが必要になっていたこと、より厳密なリスクベース認証やSMS以外での二要素認証といった今後の要件に応えられないことも、内製化を決断する理由となった。

移行はユーザーに強制ログアウトを強いることなく、無停止で進めるために細かいステップに分割された。ユーザーレコードはFirebase側のFbAccountIDと、内製基盤側のUbieAccountID（当初は空）の両方を保持する形にした。

• バックエンドのトークン検証を二重化し、まずUbieアカウントのトークンを検証してUbieAccountIDでユーザーレコードを探し、失敗したらFirebaseアカウントのトークンにフォールバックする
• ユーザーの来訪時に新規発行した匿名UbieアカウントのUbieAccountIDを紐づけ、移行前の情報を引き継ぐ。既存ユーザーはFbAccountIDから既存レコードを取得し、新規ユーザーはUbieAccountID用にレコードを作成する
• 登録・ログイン時には、Firebase Authが発行したトークンではなく認証基盤で発行したトークンを握るようにすることで、シームレスにセッションを移行する
• Firebase Authから全アカウントをエクスポートしてバッチ移行する。公式CLIには課題があったため、数百万レコードに耐える独自のエクスポートツール（fbdump）を自作した
• 認証基盤はOIDCに準拠しているため、登録・ログインのフローはFirebase Authの頃とほぼ変わらず向き先が変わっただけで完全移行できた
• 既にログイン済みのユーザーには、アクセスしたタイミングでUbieアカウントのセッションを発行する

引き継ぎ処理はリテンションを参考に数ヶ月単位の移行期間を設定し、期間が終わったら匿名アカウント・登録アカウントともに削除した。

丁寧にステップを踏むことにより、ビジネス影響ほぼなしで認証基盤に移行することができた。700万MAU・累計1億を超えるレコードを抱えた状態での移行にもかかわらず、ダウンタイムも、ユーザーへの強制ログアウトも発生していない。コスト面では内製基盤の運用費はFirebase Auth利用時の1/3以下になり、年間1000万円以上の削減となった。あわせて、Capacitor製モバイルアプリのために必要だった無理なハックの解消や、リスクベース認証・二要素認証といった要件に自分たちで対応できる素地も得られた。