今回は、データベース／バックエンドとして何故Firebaseを選択したかについてお話したいと思います。
過去には JBoss+Oracle（かなり古いです） や Tomcat + PostgreSQLといった構成でのシステム開発の経験があります。今回はクラウドネイティブな選択として Firebase を採用しました。なぜその道を選んだのか、そしてその際に重視した「運用コスト」「ユーザー管理」「セキュリティ等」の側面から、具体的に説明します。
運用コスト
クラウド上でサーバーを “自前構築” する場合、仮想マシン・OS／ミドルウェア管理・データベース構成・スケーリング・バックアップ・監視・ログ保管など、細かい積み上げがあります。
一方、Firebase では多くの機能が “サーバーレス” またはマネージド形式で提供されており、初期構築やサーバー運用の手間を大幅に軽減できます。
結果として「インフラを動かすための手間・継続的メンテナンス」が抑えられ、初期～中期フェーズのコスト構造として有利と判断しました。
ユーザー管理
ユーザー認証・アカウント管理・ログイン／ログアウト・アクセス権限・データ所有者管理などがキーになるため、自前構築するには “仕組み作り” がかなり膨大になります。
Firebase では、Authentication や Firestore／Realtime Database、Storage 等と連携しやすく、ユーザー管理を含めた “開発者が作るべき機能” に集中できる土台が整っています。
これにより、「認証・ユーザーデータ／セッション管理・UIとの連携」の部分を構築済みのサービスに任せることで、機能開発のスピードアップ＆保守簡素化が期待できます。
セキュリティ・スケーラビリティ
クラウドネイティブな環境では、サービス提供者側でインフラのセキュリティやスケーラビリティを担保してくれていることが大きな強みです。
Firebase は Google のサービスであり、アクセス制御ルール（Firestore セキュリティルール）、ユーザー認証連携、ログ／監視／エラーレポート等が整備されており、自前で “ゼロから” これらを整備するよりリスクが低く、将来的なメンテナンスも容易と判断しました。
また、予期せぬアクセス増・ピーク処理・グローバル配信なども、マネージド基盤ゆえに柔軟に対応可能であり、将来の機能拡張を視野に入れておいて “選びやすい土台” という点でもメリットがありました。
自前サーバー＋RDBMS 時代との違い
もちろん、Firebase に切り替えることで「自前で自由にチューニングできる RDBMS とアプリサーバー構成」とは異なるトレードオフがあります。
自前で用意する場合、すべて自分の流儀で設計出来ます。しかし、Firebaseを利用するとなるとすべてFirebaseの流儀に従わなければなりません。つまり、Firebaseに合わせた設計をする必要があります。初めておげんこキャットを開発した際、Firebaseに慣れるのが一番大変でした。
今回は以上です。思いっきり専門用語ばかりで申し訳ありません。ぶっちゃけ、サーバーへのアクセス数が少ない間はFirebaseに支払う金額がゼロに抑えられるのが一番の理由です。でも、「アクセス数が少ない＝ユーザー数が少ない＝広告収入が少ない」と言う事なので、それはそれで大問題なのです。
システムねこ 