ASP型のサービスのスケーラビリティについて

直接会って名刺渡したりしてご存知の方は知ってるかもしれないですけど、あえてdiscloseすると、自分はsalesforce.comというところで現在働いております。関係者になってしまってからは、このブログでそのことについて書くのは当初のスタンスからあまりよくないと思ってたので書きませんでしたが、最近ちょっとやっぱり書きたくなったので書きます。

以下これはASPのアーキテクチャの話です。アーキテクチャに関する限り、SaaSとかASPとか、どうでもいい。

多分だいたいのCGM系サイトが、たくさんユーザを集めたときにスケーラビリティを出すのに苦心されていると思います。そういう場合、あるレベルに達すると必ずデータベース側のアーキテクチャを考えることになり、おそらくアプリケーション・パーティショニング的なことをしていると思うのですが、アプリケーション・パーティショニングができるのって、アプリケーションががっちり固定の場合なのだと思います。つまり、そういうパーティショニング戦略を取った時点で、サービサーは常にサービサーであって、ユーザによる拡張というのはあまり考慮に入れていない。アクセスパターンもあらかじめきっちり固定し、それに最適化するようなことを行います。

最適化としては他にもユーザごとに処理を割り振るユーザ・パーティショニング的な方法もあると思うのですが、CGM自体が不特定多数とのコラボレーションを前提としているので、限界があります。コミュニティやフレンドリストに応じてすべてのパターンで割り振ることって、考えるだに難しそう。

しかしCGM系ではなくエンタープライズ系のASPサービスの場合、ユーザ・パーティショニングを行うことができます。つまり、企業という単位でユーザの母集団がクラスタになっていることが前提になるので、その中で最適にリソースを割り振ることができるようになります。もちろん、企業間のコラボレーションというのもあるでしょうが、全体のトラフィックとしては少数だと割り切ります。

さらに、ユーザ・パーティショニングが効いているので、あえてアプリケーション・パーティショニングについては積極的には採用せず、むしろユーザにスキーマの再構成を許すような設計にして、カスタマイズ性を重視させることもできます。少なくとも、上記のSalesforceはそういうアプローチを取ってます。ただしスキーマを弄らせるといっても、直接ではなく一段階くらい抽象化された上で行っているので、物理スキーマは常に一定になります。これは事業者が運用管理を効率化する上でとても重要です。

ちなみに上記は別に中の人だからわかることではなく、ホスティングアーキテクチャを考えて行くとたどり着く、ある意味普遍的な結論だと考えています。もっと進んだアーキテクチャももしかしたら存在可能かもしれませんが、とりあえず、絵だけではなく実際のサービスとして実現されているところに意味があります。

まあ、僕がここに入ったのは、結局そういう（？）経緯で、純粋にそんなアーキテクチャが実現されているのがちょっと面白いなと思っただけです。その判断自体は後悔してません。あ、あと、JSの人にもそれなりに重宝される環境です。っていうか、仕事の半分以上はJavaScript書いてます。あとはFirebugです。エンタープライズ系で、Product Development でもない人間がこれだけJavaScriptを使う（しかも一般的なサーバサイド言語は全く無し）というのは、きっと稀です。善し悪しはさておき。

以上、しばらく更新していなかったので、エントリに困っての雑記でした。