MBaaS を含めてクラウドサービスをレイヤー整理する


今まで日本で知り合いに話してきた感じだと、MBaaS(Mobile Backend as a Service) を知ってる人は3割くらいだった。スマホアプリを作っている人でも存在自体を知らないで、サーバ環境で悩んでいる状況が続いているようなので、そもそもどういうものか知ってもらう必要性を感じた。

ということで、クラウドサービスは歴史とともに多用化してきているが、MBaaS も含めて一度整理してみる。

やはりわかりやすいのは階層的に理解することだと思って、各ジャンルごとにどこまでのレイヤーを提供しているか図にまとめてみた。

130328WhatsMBaaS

この図はユーザがサービス提供者として一般的なWebアプリケーションを提供するシステムを想定していて、四角がクラウドサービスが提供しているレイヤーの範囲で、四角の上辺がユーザとの責任分界点となってそれより上の範囲をユーザは自分で補う必要がある。

比較しやすいためにクラウド以外の旧来のハウジングも加えている。SaaS はユーザがサービス提供者となるケースは生じないので載せていない。

最もレイヤが低いものはハウジングで、単なる電源、空調、物理スペースのみ提供しているので、ユーザはそれより上位のネットワーク、サーバ、アプリケーションを用意する必要がある。

その右部分がクラウドコンピューティングで提供されるサービスカテゴリーで、最もレイヤーが低いのが IaaS(Infrastructure as a Service)。
代表例は AWS で日本で言えばハウジング会社たちである IDCフロンティア、Niftyクラウド、GMOクラウド、さくらのクラウドなどが該当する。基本的には仮想サーバOSまでの提供で、ユーザはサーバプロセスのインストール・セットアップ、サーバ上で動くアプリケーションの開発・デプロイ、サーバ自体のスケールを管理運用する必要がある。
IaaS はクラウドサービスの1つではあるが提供範囲が低レイヤーなので、仮想とはいえユーザ自身がサーバスペックを選択してスケーリングを考慮しなくてはいけない。そういう意味では、本来のクラウドコンピューティングの理念からは矛盾していてるが、利用ケースは非常に多いという面白い状況になっている。単純にサーバやネットワーク機器を「買う(資産になってしまう)」から「借りる(必要な分だけ必要な時に)」に移行するための手段になっている気がする。

次は PaaS(Platform as a Service)。代表例は、Heroku、Google App Engine。基本的には Web + DB の構成で、Webサーバ上で動作する言語もしくはフレームワークをサポートしている。ユーザはプログラミングしたソースコードをデプロイすれば動作してくれる。サーバが正しく動作するかどうかはユーザが書いたコードに依存する。
PaaS の提供レイヤーより、本来ユーザはサーバスペックは意識しなくても良い環境にあるので、スケールについてはサービス側が担保すべきことになるが、実際はストレージ容量や帯域などの上限があり、ユーザはプランを選択している。これは PaaS のサービス範囲からくるものではなく、サービス提供者側の収益担保のための手段としてで、利用したリソースに対しての料金徴収をわかりやすくプランを設けることでで区切っている。なので、IaaS と同じように使った分だけ料金徴収という料金プランも作れるはず。

そして MBaaS は最も高いレイヤーまでがサービス提供範囲になる。PaaS の場合 Web API をユーザがコーディングして「作る」が、MBaaS はサービス側がすでに用意したものをユーザが「使う」ことになる。
他のクラウドサービスと異なる最も大きな点は、ユーザはサーバプロセスの開発に関わる必要が全くないこと。あらかじめ用意されている Web API を使うだけの立場になる。
使う方法は iOS/AndroidアプリからSDK、Javascript SDK、REST API があって、コードに SDK を使うための記述をする。
主にデータストレージ系の用途が多いだろうが、モバイルに特化した機能も用意されているので BaaS ではなく MBaaS と言われているのがポイント。Push をサーバを立てることなく簡単に送る、ユーザアクティビティの分析機能なども用意されている。
アメリカでは2012年後半頃からホットになっていて認知度の高い Parse が頭ひとつ出ている。日本での提供者は数が少なく、日米リージョンを持ってワールドワイドに展開できているのは Kii Cloud くらいだと認識している。今後日本でもプレイヤーが増えるかもしれない。また、日本でもユーザの多い Titanium が Cocoafish を買収して提供している ACS も MBaaS と言え、これもかなりの規模になってくると思っている。

MBaaS の提供レイヤー範囲が広いから優れているということではなくて、ユーザはサーバことを意識しなくて良い代わりに、提供されている機能しか使うことしかできないので、使いたくても提供されていなければどうしようもない、ということになる。
だからユーザはサーバは MBaaS の提供機能からどれを使えば良いかを選び、やりたいことが実現できるか(実現できるように)設計する必要がある。

ただ、一度使ってみるとわかるが、サーバから開放された環境は非常に楽で、小さなチームでアプリをヒットさせたいと企む人たちにとっては非常に魅力的だと思う。アプリ開発にたずさわる方々にとって試してみる価値はあると思う。

MBaaS の歴史はまだ浅いので、モバイルに特化したとはいえ機能的に十分ではない状況が各社ある。今後もいろいろな機能がたされていくだろう。ユーザが使いたい機能をいち早く提供し合うような開発規模やスピード勝負になってくるんではと思っている。

Related Posts

長沼公園 - お気に入りの場所

Flutter in_app_purchase で定期購入を実現する方法 2023年版

ペップのビルドアップ UEFA Champions League Final

テクニカルアドバイザー仕事が終わったのでまとめ

Amazon で Kindle とペーパーバックを作るやり方

[思考]老いへの許容

「ひとりスタートアップ」が本の形になりました

2022年を振り返る

ハードウエアのWeb化

本を書きました「ひとりスタートアップ」