ありがとう、さようなら Parse.com。ノハナがParse.comと共に過ごした4年間の話。

ノハナで主にサーバーサイドを担当しているエンジニアの武市 (@tacke_jp) です。

Parse.comが1年後にサービスを終了することをアナウンスしたのが2016年の1月28日 。それから約1年が経った本日未明にParse.comは完全にサービスを終了しました。これまでノハナを支えてくれたParse.comに感謝を述べつつ、ノハナがParse.comと共に過ごした4年間を振り返りたいと思います (※1)。

Parse.comとノハナ

ノハナがサービスインしたのは2013年の2月13日でした。サービスの立ち上げ時からParse.comをフル活用していたため、そこから考えると約4年間Parse.comを使っていたことになります(※2)。 利用していた機能は多岐にわたり、データベースはもちろんのことユーザー認証やプッシュ通知、さらにはファイルストレージもParse.comのものを使用していました。サービス開始から4年が経ち、レコード数は4億ほどになりファイルストレージに保存している写真は約1.5億枚になりました。しっかりと調査したわけではありませんが、恐らく日本中を探してもノハナ以上にParse.comを使い倒していた企業はなかったのではないかと思います。

Parse.comとの出会い

ノハナが開発初期にParse.comを全面的に採用して開発することになったのは、タイトなスケジュールと限られた開発リソースという制約からでした。ノハナは株式会社ミクシィの社内公募制度から生まれた企業内スタートアップ(後に子会社化)で、当時の公募制度の事業化の条件が「開発開始から3ヶ月でのサービスイン」でした。このタイトなスケジュールの中でiOSアプリの開発、クレカ決済機能、フォトブック印刷用画像の合成機能など様々な機能を開発しなければなりませんでした。また、サービスの立ち上げ時は(どんなサービスでも最初はそうだと思いますが)開発リソースが限られており、エンジニアは2人しかいませんでした。このような状況の中では開発がとても間に合わないということで、Webサーバーの開発にかかる時間を極力短縮することを目的としてParse.comが導入されました。

Parse.comの提供するSDKを組み込めば、コードを2,3行書くだけでデータベースへのクエリやデータを保存する機能が作れました。コンソールからボタン1つでプッシュ通知を送信することが出来ました。開発者はアプリのUXに時間を掛けることができ、ノハナのフォトブックサービス特有に必要な機能の開発に専念することができました。こうして開発は無事期限内に完了しノハナは無事リリースされました。

ノハナとParse.com、それぞれの成長の痛み

リリースから半年後、全国放送のテレビに取り上げられた際に事件が起こりました。テレビに取り上げられた際の膨大なトラフィックに耐えきれずParse.comがポータルごと全て落ちてしまったのです。復帰したもののデータには大量の不整合が残り、やむなく注文を1ヶ月ほど停止させて頂きデータの復旧作業と注文頂いたユーザーの方々への対応を行いました。またその後も2,3ヶ月ほど新規登録が不安定となる期間が続き、その間一日に新規登録を受け付ける時間を制限させて頂くなど、苦渋の対応を行っていました。

また、ノハナは「フォトブック毎月1冊無料」(※3)というビジネスモデルのため、1冊無料の権利がなくなる月末にトラフィックが集中します。特に末日のピークタイム(23時頃)には通常の5倍~10倍のトラフィックがあり、Parse.comから大量のエラーが返ってくることがしばしばありました。月末に注文が集中するため我々にとって月末にサービスが安定しているかしていないかは死活問題であり、月末になると毎月のようにチームはざわつきました。毎月月末はエンジニアが張り付いて監視し、パフォーマンス障害が発生した際にすぐに対応できるようにしていました。

このようなことが続いたため、実は社内でParse.comから別インフラへの移行を検討してはいましたが、Parse.com終了のアナウンスまでに実際に移行に踏み切ることはありませんでした。理由には、どうロックインから逃れるかという大きな技術的困難があったためです。ストアに配信されているアプリに組み込まれているSDKは固定されたParse.comのエンドポイント(api.parse.com)に対してリクエストを送るようになっていました。そのエンドポイントのURLを書き換えて独自のものにすれば新たに配信されたアプリについては移行できますが、以前のデータも参照できるようにしなければならないためデータの同期が必要になります。しかし、api.parse.comに書き込まれたデータを整合性を保ったまま独自のDBに同期させる方法は当時は提供されていませんでした。そのため移行するためには、(1)一旦api.parse.comをプロキシするエンドポイントを別に用意する。(2)そのプロキシサーバーに向き先を切り替えたアプリをストアにリリースして十分ユーザーに浸透するまで待つ。(3)api.parse.comと互換のAPIサーバーを開発する。(4)一旦リクエストを全てストップし、Parse.comからデータを全てダンプし新DBに入れ直した後エンドポイントの向き先を変える。という手順を踏まなければなりませんでした。そのための開発に膨大な開発リソースが必要なのは想像に難くないかと思います。ノハナにとって、既存のサービス開発を止めずにこの移行を行うのは事実上不可能でした。

そのため、無駄なクエリをなくすなどノハナ側でできる範囲で対応を行っていました。またParse.comのAPIサーバーがRuby on RailsからGolangにリライトされたあたりからだいぶ安定したように思います。おかげでサービス開始から2年が経ったぐらいから月末になっても落ちることもなくだいぶサービスが安定してきました。そんな矢先の昨年1月28日、Parse.com終了の衝撃の一報でした。(※4)

Parse.com終了という衝撃の一報

出社すると社内はざわついていました。Parse.comへの依存度が高いことは社内のエンジニア全員が把握していたため事の重大さとこの先の困難についてはすぐに認識することが出来ました。すぐにParse.comからの移行のためにエンジニア3人からなる特別チームが結成され、移行の具体的な方法についての検討が始まりました。

Parse.comから提示された移行のシナリオはこうでした。まず、データの移行先として新たにMongoDB用意します。そのIPアドレスと認証情報をParse.comのコンソールに入力するとParse.comからMongoDBへデータのスナップショットが大量にinsertされて来ます。スナップショット書き込み中のデータの更新は別途キューに入れられスナップショットのコピーが完了したタイミングでそれらが流し込まれてきます。両者にラグがなくなりほぼデータを同期し終えたタイミングで「finalize」ボタンを押すとDBのread/writeクエリの向き先が切り替わるという仕組みです。その後自分たちでオープンソースのParseAPI互換サーバーであるParse Serverを立て新しいDBを向くようにします。そのAPIサーバーに対してクライアントの向き先を切り替えれば移行は完了、という流れです。

当時は「Parse.comがオープンソース化された」と報道されましたが、実際に公開されたParse-ServerはParse.comの中で動いているものとは別のただの互換APIで、クオリティが高いとは言えませんでした。(その後コミュニティの努力によってこの1年でだいぶ改善されています。)(※4)また、データベースの切替は後戻りの効かない一発作業だったため、恐怖がありました。また、ノハナ社のシステムでapi.parse.comに依存していないものはありませんでした。つまり、iOS / Androidのネイティブの他に注文WebView画面でのJSが依存していたり注文APIのWebサーバーも依存していました。また、画像合成サーバーや写真の代理アップロードサーバーなどバックグラインドジョブを行うサーバー類の依存も解消しなければなりませんでした。

一年がかりの移行作業

この4年間インフラはParse.comに任せきりだったため、社内は大規模なAppServerとDBの構築経験がありませんでした。ですが、自分たちでコントロールしたいという理由から、サードパーティの互換サービスを使わず、独自にGCP上にインフラを構築することになりました。

各種IaaS検討のため検証作業などのしていたのが春先ぐらいまで、そこから夏頃までMongoDBの環境構築と運用のための知識の獲得とデータ移行の実施、そこからparse-serverやCloudCodeのバグ修正、秋から冬にかけてiOSとAndroidのエンドポイント切替、年末から年明け早々までは細々としたParse.com依存の解消をやっていました。

Parse.comからの移行の詳細に関しては、GCP NEXTでの登壇資料GCPUGでの発表資料をご覧ください。

MBaaS採用の是非

ノハナがParse.comを採用したのは正解だったのでしょうか?それを考える上でのひとつのポイントは、「MBaaSを採用することはそれと運命を共にする」ということです。MBaaSとはモバイルアプリを開発する際に必要な全ての機能が1つにパッケージ化され、簡単にスピーディーにアプリを開発しリリースするためのものです。それを使うということはエンドポイントや認証系にロックインされることや保存しているデータにロックインされることと同義です。しかし、ロックインされないようにMBaaSを使おうとすることは矛盾しています。なぜなら、それはMBaaSの一部の機能を限定的に利用しようとすることであり、MBaaSを使う意義から外れているためです。個別の機能を提供してくれるSaaSはいくらでもあるので、初めからロックインを嫌って多少の追加の工数をかけて各種SaaSを組み合わせるというのも十分理にかなった戦略です。ノハナの場合、結果的にParse.comがクローズとなり後に大きなコストを払うことになってしまいましたが、限られたスケジュールと開発リソースという制約下ではParse.comなしではサービスは誕生しませんでした。そういう意味で、十分Parse.comを利用した意義があったのではないかと思います。

これからの話

本日をもってParse.comはMBaaSとしての役割を終えましたが、Parse.comはParse Serverというオープンソースソフトウエアとしてこれからもコミュニティの中で生き続けます。ノハナはParse.comがオープン化された利点を活かし、また自社インフラでサービスをホスティングするようになった利点を活かし、ユーザーの皆様により快適にサービスをご利用頂けるようにこれからも改善を続けていきます。

最後に改めてParse.comに感謝の意を伝えたいと思います。ありがとう、さようならParse.com。


(※1) 自分が入社したのは2014年の5月なのでそれ以前の話は伝え聞いたものです。

(※2) parse.com自体がサービスを開始したのは2011年の6月ごろなので、parse.comのかなり初期からのユーザーでした。

(※3) 送料は別途掛かります

(※4) 中の人も終了を当日まで知らなかったようです。