Parseサービス終了についての雑感

BaaS(Backend as a Service)のParseが、来年一月でサービスを終了することをブログでアナウンスしました。昨年末にウェブ・ダッシュボードをReactベースで刷新するなど、活発に開発がされている印象があったので、とても驚きました。Twitterのタイムラインでは、デベロッパーさんのこんなつぶやきも。

筆者自身も現在開発中のゲーム・アプリでParseの一部機能を利用しており、以前にも自分の関わるウェブ・サイトでParseの利用を検討していたことがあったので、Twitterにいくつか感想を書きました。せっかくなのでここに記事としてまとめておきます。

Parseの移行に関する情報

先に書いておくと、既存の顧客にはデータをMongoDB形式でエクスポートするツールと、Parse互換のAPIサーバがオープンソースで提供されます。ただし、現状ではAPIサーバはウェブ・ダッシュボードやPushの機能を含んでいません。つまりデータを編集するための管理画面を自分で作る必要があり、Pushについては他のサービスに移行する必要があります。

同様のクラウド・サービスを提供する会社が受け入れサポートをする動きも出てきています。NIFTY CloudがParseからの乗り換えを検討している顧客に対して問い合わせフォームを開いたり、Push Notificationサービスを提供するOneSignalもParseの設定を引き継ぐためのツールを提供しています。

Parseはなぜ受け入れられなかったのか？

と、大げさなタイトルを見出しをつけましたが、単なる個人の感想です。ウェブ・サービスのバックエンドとして、それからゲーム・アプリのバックエンドとして利用を検討した時の印象です。

価格が高い

Parseは「１秒間あたりのAPIリクエスト数の上限」で費用が決まる仕組みになっていました。最新の価格体系では、１秒間あたり30リクエストまでは無料、以降秒間10リクエストごとに$100ということになっていました。リクエスト数は１分ごとの計測になっていて、１分間のアクセス数を60で割ったものを１秒あたりのリクエスト数としてカウントします（FAQ参照）。

自分のサービスで秒間あたりのリクエスト数の上限をどのように設定するかは一概に言えないのですが、例えばCerevoさんが以前に公開していた「EC2とS3をうまく使い分けてワールドビジネスサテライト砲を確実に乗り切る方法」などでは、テレビ番組でサイトが紹介された際にピークで秒間1000リクエスト程度のアクセスがあったことが書かれています。個人的な運用経験でも、Yahoo!ニュースからリンクされた際のアクセスや、いわゆるコンテンツがバズった際のアクセスを参考に、秒間1000リクエスト程度をターゲットにしています（実際はもう少し余裕をもたせますし、他サービスとのコラボで秒間3000リクエストを要求されたこともありますが….）。

さて、そうしたパフォーマンス要求に対して、Parseの価格体系は明らかに高価です。上記の1000リクエストをカバーしてプランの設定をすると、1000 ÷ 10 × $100 = $10000 = 100万円以上の金額を請求されることになります。

一秒間あたりのアクセスリミットの上限がきつい

FAQによると、Parseがサポートするアクセス数の上限は秒間600までとなっています。つまり価格が高いだけでなく、そもそも秒間600リクエスト以上のサービスを運用することができません。

結論: 課金の体系が、バズ前提の運用にフィットしない

ParseのFAQには、秒間30リクエストという範囲でも１日当たりで25万のアクティブ・ユーザーを運用できると書いていますが、これはあくまでアクセスが均等に長時間にのぼって発生することを前提にしています。ウェブ・メディア、ゲーム・アプリでは朝とランチタイム、それから就寝前の特定の時間にアクセスが集中する運用が普通になっていて、通常の数十倍の「ピーク」を前提にシステムを設計する必要があります。つまり、価格面でも、あるいは上記のリミット的にも、Parseのプランは実際の運用にフィットしていないというのが筆者の評価でした（日本からだとAPIリクエストのレスポンスが結構遅いというのもありましたが）。

どういう場面でBaaSが使いたくなるのか？

先に書いたParseの価格面でのデメリットはしかし、あくまでもエンジニアが存在する組織での計算です。もしParseのようなBaaSを使わずに、その分を自社で開発するとなると多くの予算が必要になりますし、サーバのモニタリングなど運用のためのコストもかかります。

運用のためのエンジニアを配置せずにサービスを行うことを考えると、秒間600リクエストでサーバ込み月々60万円という設定は「高すぎる」ということはないのかもしれません。

問題は、そういう経営的な計算をできる人はすでにそれなりのエンジニアであり、そんな人材がすでにいる組織なら高価なサービス料を払ってBaaSを利用しなくても自社のエンジニアが問題を解決してしまうというミスマッチにあったのではないかと想像しています。

実際、筆者自身もゲームのプロジェクトでは運用にエンジニアのリソースをさかないように、Parseを使うことにしていましたが、エンジニアがいるチームでは導入に合理性をみつけることができませんでした。

少数のエンジニアを抱える組織が、それでも使いたくなるようなプラン設計(秒間3000リクエストまでOKで、定額で月額50万円、ネットワーク料金は従量制とか)だったら、もっと普通に利用を検討できたのになあというのが、個人的な感想です。

おしまい。

注釈

文中でリンクを貼った記事の一覧です。

Moving On
http://blog.parse.com/announcements/moving-on/

The New Parse Developer Experience
http://blog.parse.com/announcements/the-new-parse-developer-experience/

Parse Server Developers Guide | Parse
https://parse.com/docs/server/guide#migrating

Parse Pricing: Now Cheaper and Simpler! http://blog.parse.com/announcements/parse-pricing-now-cheaper-and-simpler/?mkt_tok=3RkMMJWWfF9wsRonuazAZKXonjHpfsX67O0qX6K%2BlMI%2F0ER3fOvrPUfGjI4ATsRkI%2BSLDwEYGJlv6SgFTbHGMblmy7gNUxU%3D

Parse Pricing: Now Cheaper and Simpler! http://blog.parse.com/announcements/parse-pricing-now-cheaper-and-simpler/?mkt_tok=3RkMMJWWfF9wsRonuazAZKXonjHpfsX67O0qX6K%2BlMI%2F0ER3fOvrPUfGjI4ATsRkI%2BSLDwEYGJlv6SgFTbHGMblmy7gNUxU%3D

OneSignal — Migrate to OneSignal with our Parse Importer https://onesignal.com/parse

EC2とS3をうまく使い分けてワールドビジネスサテライト砲を確実に乗り切る方法 | Cerevo TechBlog
https://tech-blog.cerevo.com/archives/283/

お乗換に関するお問い合わせフォーム https://inquiry.nifty.com/webeq/pub/mbaas/replace