ホスティングサービスの向かう道を思うがままに書いてみました。まずは話半分で読む事をおすすめします。
ホスティングサービスの売りは運用？
AmazonEC2やクラウドサービスの普及に伴って、簡単に仮想サーバ（VPS）を借りられたり、簡単にWebやMailサービスを使う事が可能になってきています。そういう状況でホスティングサービスがどこで差別化をしていくかと考えた時、よく言われるのが「サーバの運用を代行する」という事です。
これは確かに重要で、これまでホスティングサービスとして培ってきた運用のノウハウを全面に出すことで、セキュリティを担保したり、面倒なバージョン管理やHWの保守、高負荷対応等を売りにするというのは大事な事だと思います。
しかし、本記事では、その売りである「運用代行」の本質を考察し、単純に運用代行を全面に出すのではなく、そこからホスティングサービスが「サービスの提供の仕方」としてどういう方向性に進めばいいのか、運用のノウハウをどのようにサービスに融合させるのか、を考えてみました。
IaasやPaaSを提供する？
IaaSやPaaSなど、様々なクラウドサービスが世の中にあり、ホスティングサービスで提供しているほとんどのサービスがそれらで安くまかなえてしまいます。リソースを自由にスケールできたり従量課金だったり素晴らしいですね。
このような状況で、ホスティング会社としてIaaSやPaasを提供するべくいくら頑張ったとしても、もはや限られたコストやリソースをつぎ込んだ所で代表的なプロダクトの二番煎じになることは否めないでしょう。
その場合、ホスティングサービスはどういうサービス提供の仕方が良いのでしょうか。単純に運用を売りにするだけでやっていけるのでしょうか。
そこで、以下のようなホスティングサービス形態はどうだろう、と考えてみました。
ビュッフェ形式のつまみ食いホスティングサービス
あえてキャッチーなネーミングにしています。
これはどういうことかというと、大きな物理インフラ上に仮想マシンやコンテナを領域として顧客に割り当てます。そして、その上には汎用ミドルウェア基盤というものを用意しておきます。それをビュッフェでいう皿として、その皿に好きなものを数あるサービス品目の中から選んで乗せていく、というイメージです。お皿のサイズも数種類から選べます。
図にするとこのようになります。
サービスを自由に選択して組み合わせる
このように、汎用ミドルウェア基盤の上に、自分の欲しい物、例えば、100GのストレージにRDBMSを用意して、アプリケーションサーバ上にリバースプロキシをのせてCMSアプリケーションをGitHubからデプロイして動作させる、となると上のような機能のつまみ食いになります。
品目はこのように沢山あるので、数ある中から皿である仮想マシンやコンテナに好きなようにサービスを組み合わせる事ができます。また、CPUやメモリ、ストレージもサービス品目として同様に載せることができます。場合によっては、各サービス品目間に依存関係はあっても良いと思いますが、できるだけ疎結合にするべきだと思います。
こうすることで、クラウドサービスではミドルウェアの設定等を顧客が適切な値にチューニングする必要がありましたが、ホスティングサービスで培ってきたノウハウで、お皿のサイズを考慮した適切なチューニング値（料理しておくイメージ）で各種ミドルウェアを使用する事ができます。
お皿である仮想マシンを借りる事に対価を払いサービスは取り放題
お皿である仮想マシンやコンテナを借りるためにお金を払いますが、基本的にそこに載せるサービスは選び放題です。ただし、お皿に載せられる商品数は限られていたりします。例えば、お皿に10載せられるとして、App Serverを載せると3使用、CPU2コアを乗せると2使用、メモリ6Gを乗せると5使用などです。このあたりの設計は色々やり方があるでしょう。
これによって、複数のお皿である仮想マシンを借りて、その上に好きなサービスを乗せて、仮想マシン間で連携をしたり、GitHubやAWSからのデプロイや連携もできるようにします。また、そのお皿のサイズを大きいものから小さいものまで用意しておくと良いでしょう。
自動でスケールしたりはしませんが、それぞれの品目がお皿の大きさに適したクオリティに保たれていておいしく食べられるのが、クラウドサービスとの違いだと言えます。
ホスティングサービス会社は環境を分離し制限する運用が得意
結局、なぜこういう方向性のサービスが良いのではないかと考えたのかというと、現状、クラウドサービスではオートスケールやリソースを自動で拡張するようなサービスが望まれています。しかし、ホスティングサービス会社はあえてそれと逆行して、「制限をするアプローチ」をとってみても良いじゃないかと考えました。
制限をするアプローチ
なぜかといと、ホスティングサービス会社というのは、一つのサービスを巨大にする事はあまり得意ではないですが、サーバが落ちないように考慮した上で、複数のサービスが共存する環境を運用構築したり、その環境を多数のユーザに提供し自由に使ってもらうようなサービスを提供するのが得意な会社だからです。
もう少し言い変えると、大きなDBを持っていたり大量のトラフィックをさばくような巨大なWebサービスを構築運用する事は得意でないですが、WebやMaiｌ等の複数のサービスが混在した環境を上手にリソースや権限の分離をしておいて、大多数の複数顧客に自由に使ってもらい、そのそれぞれの顧客環境を最適な状態に維持・制限する運用は非常に得意だと思います。
つまり、ホスティングサービス会社は各サービスを仮想マシンやコンテナであるお皿の範囲内で高品質なサービスを提供し制限する運用が得意なのです。
だとすると、一つのサービスを高負荷に耐えうるように拡張していくアプローチではなく、上記のような、とにかく沢山あるサービスをうまくお皿の範囲内に制限して、できるだけ快適に、リソースが足りなくなったら皿の上のサービスを制限の範囲内で別のものに変えて対応するか、皿を追加で増やすかといったやり方になるのだと思います。
サービスの選択肢や組み合わせを増やすアプローチ
あくまで、サービスの選択肢や組み合わせを増やす（スケール）ことを売りにし、リソースのスケールをそこまで売りにしない方が良いのではないかと思うのです。
制限をする運用が得意なホスティングサービス会社が、例えばGoogle App Engineのように自動でスケールするようなPaaSを提供したところで、きっとうまくいかないだろうし、ユーザが満足するほどそんな潤沢にHW資源も用意できないだろうと思います。
であれば、やはり「領域を制限する」方向でサービスを展開していった方が、ホスティングサービス会社の得意な分野でより質の良いサービスを提供できるのではないかと思います。
さいごに
このように、ホスティングサービスの向かう道はどうあるべきかを想像してみました。
どう考えても、大規模Webサービスを提供している会社がやっているような基盤技術を提供したり、リソースを拡張して大規模に耐えうるようなサービスの提供の仕方は、ホスティング会社には難しいんじゃないかと感じています。
そのため、「リソースをスケールするのではなく、サービスの種類や品質をスケールする」というアプローチで、過負荷時にはサーバが落ちないように運用するやり方を考えると、上記のようなサービス体系を思いつきました。
しかし、ホスティングサービス会社でも様々なアプローチがあり得ると思っているので、上記のようなサービスはその中のほんの一例だと思ってもらうぐらいが良いでしょう。
結局、ホスティングサービスが培ってきた技術の本質とは、「可変な領域を制限して、本来落としてはならない領域を守る事」だと思うのです。