BaaSの夢再び〜機能刷新でParseに近づいたFirebaseについての個人的な考察
今年は野外会場で行われたGoogle I/Oのキーノート。Googleが買収したFirebaseにも大きなアナウンスがありました。
ログ解析ツールやPush Notificationサービスの無料化が話題になっているようですが、それ以外にも多くの機能が追加され、今年のはじめに突然終了が告知されたFacebookの「Parse」に近いラインナップになった点に注目しました。
こちらのThe Vergeの記事では、これまではシンプルなデータ・ベース・サービスで「Parseキラーには程遠い」存在だったFirebaseが、ストレージ、アナリティクス、ホスティング、認証、メッセージングなどなどの機能を追加したと書いています。
筆者は、こうしたBaaSをプロダクション・レベルで利用した経験はないのですが、プロダクトの立ち上げを行うときには、人件費の観点から一度は採用の検討をしており、どこかのタイミングで使うかもしれないということで常に目を光らせています。
そんな訳で、Firebaseの新機能について、Twitterで思うところなどを書いていたものをまとめて、関連情報を加えて記事にしました。
Firebaseに追加された機能
Firebaseのブログに、新規追加された機能が紹介されています。
Analyticsのイベント解析を使って、アプリケーションのヘルプ機能を呼び出した人を抽出、Push Notificationサービスと連携してメッセージを送信するといった連携ができるようです。
その他にも、アプリの設定情報をリモート管理するRemote ConfigでA/Bテストを実施できたり、ディープ・リンクを簡単に実装したりと、いわゆるアプリを「カイゼン」するための機能を多く提供しています。
Firebaseのホーム・ページの機能一覧では「Develop」「Grow」「Earn」の３つのカテゴリが提示されていますが、この「Grow」の部分がそれにあたります。Googleらしさを感じる切り口ですよね。
費用
Firebaseの利用プランは、こちらでチェックできます。ここで提供されている機能を、サーバのセット・アップを含めて実装することと比較して、相当低価格であるという印象です。
ゲーム・アプリをやっているため、アセット配信のためのホスティング費用が気になるのですが、$0.15/1GBとなっていました。AmazonのCloudFrontなどと横並びという感じでしょうか。CloudFrontはボリューム・ディスカウントが効くのと、ほかにもっと低価格なCDNサービスがあったりするので、激安という感じではないです。
APIサーバとしてのFirebase
FireBaseは、ウェブ・アプリのバックエンドとしての機能も持っています。Facebook/Twitter/Google/Github認証つきで、エンドポイントに対して認証とアクセス・コントロールが可能なJSON APIサーバのホスティングをしてくれます。
モバイル・アプリ、あるいはウェブ・アプリでも、APIサーバを実装するケースが多いと思いますが、バックエンドのデータベースも含めて自動でスケールしてくれるAPIサーバ・ホスティングというのは、開発コストを抑える面で非常に良さそうな印象があります。
バリデーション、アクセス・コントロールの設定には、JavaScriptのサブセットを使用します。
自前でNode.jsなどを使ってサーバを運用し、Firebaseのデータ・ベースの更新時のメッセージに合わせて独自のコードを実行することも可能です。
(追記アリ)ただし、APIサーバそのものの挙動を変更できる訳ではないので、エンドポイントへのPOSTリクエストに対して、クエリ・パラメータから別の値を生成してDBに保存するというようなことはできないようです。
上記のような処理は、APIへのPOSTアクセス時にキューにジョブを追加して、外部サーバであとから非同期的に更新をかけるようなシステムにする必要があるかと思います。
2017.7.26追記:
この記事がまだ読まれているようなので追記します。その後「Cloud Functions for Firebase」が追加されて、ある程度のコードをFirebase内で実行出来るようになりました。詳しくは下記のブログ記事を参照してください。
Firebaseクライアント・ライブラリ
iOS/Android/C++のネイティブなSDKと、Angular/React/Ember/BackboneからFirebaseを使うためのラッパーが用意されていました。もともとシンプルなREST APIなので、JSON APIを扱うこうしたライブラリとは相性がいいと思います。
同時コネクション数の上限について
さて、BaaSで気になるのは、サービスのパフォーマンスです。自動でのサービス・スケーリングなどを謳っているものも多いですが、やはり具体的な数値が気になります。以前、同様のBaaSである「Parse」について書いた時にも、Parseの同時接続数のリミットが低く、プロダクション環境での利用に不安があることについて指摘をしました。
Firebaseの「Simultaneous Connections」のリミットはフリープランで100、有料だと10,000に制限されます。有料プランならサポートに連絡して上限をアップすることもできるとのこと。
同時接続数10,000というと十分にも思えるのですが、Firebaseは「リアルタイム・データベース」を標榜していて、アプリで使用しているデータにサーバ側で変更があると自動でsyncをしてくれるのが売りになっています(らしい)。とすると、なんらかのnotificationチャンネルに繋ぎっぱなしであることが想像され、この数字の意味は図りかねるところがあります。
Parseの持っていた「秒間600リクエストまで」という制約に比べると、10,000という数字は大きいように見えますが、いわゆる「コネクション張りっぱなし」状態なら、数分あるいは数十分の延べでアクセス数を計算する必要があり、10,000という数字も十分ではありません。
実際にプロジェクトを作成して試してみないとなんとも言えないのですが、チェックポイントとして覚えておきたいところです。
まとめ
冒頭にも書いたように、アプリ開発における「カイゼン」のための機能が便利そうで、試してみたいと思わせる魅力があると思いました。
- APIサーバの開発、運用コストを下げたい
- データなどのホスティングを低コストで実現したい
- A/Bテストなどのプロダクト改善サイクルを回すためのツールが欲しい
などなど、開発者再度からみて心に刺さる機能が多く提供されているので、ひとまずどれか一つでも試しに導入してみようかと思っています。
「バックエンドをBaaSにまかせて、低コストでスケールするサービス開発」というテーマは、Parseが提示した”夢”でしたが、そのParseがサービスを閉じたことによって”呪い”になりました。BaaS系は提供する機能もさることながら、継続性を見極めなければ、採用することによって大やけどをする危険性をはらんでいるのです。
AdMobをより多くのプロダクトに組み込み、そしてマネタイズを拡大したいGoogleには、プロダクトにとっても良質なモチベーションがあり、その点に期待をかけてみたいところですが、同時にいつでも他の環境に移行できるバックアップ・プランも意識しておきたいところです。
