システムのスモールスタート - ビープラウド社長のブログ

ウェブサービスなどのシステムのスタートアップ時には「小さく始めて、大きく育てる」のがリスクも少なく妥当な方法です。いわゆるスモールスタートという考え方です。

私はシステムのスタートアップに関して、さらに２つに分けて考えるようにしています。

「物理的にはスモールスタート、論理的にはスケーラブルスタート」

ここで「物理的」というのは、主にハードウェアに関わる部分をあらわし、「論理的」とはアプリケーションの設計・プログラムに関わる部分をあらわします。

つまり「ハードウェアは小さな投資でスタート、アプリケーションはスケーラブルな設計でスタート」ということです。

この「論理的にスケーラブルスタート」の具体的な例が、DB Magazineの2007年1月号に掲載されています。

DeNAの「モバオク」に学ぶWeb-DBシステム開発／運用術

具体的には、以下の図のように、ユーザ系テーブル(マスタ系テーブル)と、出品系テーブル(トランザクション系テーブル)を最初からスキーマを分けて設計しています。この設計によりシステム増強が必要になった際に、それぞののスキーマを別々のサーバーに配置することによって、アプリケーションの変更なしにサーバー増設を可能としています。

記事によると、モバオクでは、初期構築時から、スケーラビリティを考慮していたおかげで、当初の設計のまま大きな変更を行わずに72万会員、1日7000万PV（記事執筆時：2006年9月時点)のシステム規模に対応できているそうです。

スケーラビリティを考慮した設計としては、このスキーマを分けるという方法以外にも、画像専用サーバーを最初から想定する(用意するわけではない)、キャッシュ機能を使用するなどが考えられるでしょう。これらのパターンを集めてみても面白いと思います。

全てのシステムでこのようなスケーラブルスタートが適しているとは限らないと思います。少ないユーザで、データの更新も少ないようなシステムではやりすぎとも言えるでしょう。

しかし、ビジネスを前提としたシステムでは、多くの顧客獲得を想定し、将来のシステムの大きな伸びを見越した、スケーラブルなアーキテクチャ設計をしておく必要があります。容易に拡張できないシステムは、ビジネスの足枷となるからです。これらを見越した設計能力も、ソフトウェアエンジニアの重要なスキルの１つではないでしょうか。

(※)　YAGNI<ヤグニと読む>(You Aren't Going to Need It.「今必要のあることだけをやれ」)というXPの原則がありますが、これはプログラミングにおけるものと解釈しています。つまり、必要の無い機能はつくるな、活用されるか分からない過度の汎用化はするなということです。

今年の目標：１００エントリーまであと６２．残り２８５日、４０週と５日。