YourSQL VS Oracle VS GFS
梅田さんから「シリコンバレー精神」の献本をいただきました(ありがとうございます)。
それで、このエントリは書評ではなくて、ここからインスパイアーされた話。
結論から先に言えば、「EXITの前後でストレージ・エンジンに関わる技術に注目すると、その会社の実態に迫りやすい」という仮説。
EXITとは、ものすごくおおざっぱに言えば、会社を上場すること。
つまり、創業者の私物であったベンチャー企業が社会の公器になること。社会がその会社と契約を交わすこと。「これこれのことを責任持ってやってくれるなら、それなりの金を渡すよ」
その契約の代理人となるのが、日本では株式市場しかない。それに対しシリコンバレーでは、もちろん市場も機動的だけどそれ以外にも、大企業による買収とか、すでに公開している企業との合併とかいろいろな代理人がいる。
多くの場合創業者は会社に残るのだろうが、その役割の中に完全に変化する部分がある。つまり、公器になる為に、一定のルールに縛られて、情報公開の義務を負うわけだ。それによって一定の社会的責任を担う代わりに、飛躍的に潤沢な資金が与えられる。
他の国と比較して、早めにこのEXITというフェーズを行なうような仕組みが用意されているのが、シリコンバレーの社会的システムとしてのイノベーションである。これまでの常識では、その会社の事業の価値が広く社会全体に認められてからじっくり審査してEXITさせるところを、シリコンバレーでは、まだ売上が安定しない仮想的な価値の段階でEXITさせる選択肢を用意した。それが多産多死=イノベーションを活気づけることで、Web2.0を産業として成立させている。その負の面も含めた梅田さんによるこれについての分析が、「シコンバレー精神」の「文庫のための長いあとがき」に繰り広げられているので、詳しくはそちらを参照していただきたい。
それで私の仮説は、まず、EXITまでの段階ではデータベースとしてはMySQLをそれなりに使いこなせばなんとかなる。EXITの前後で、かなり根本的な見直しが必要になる、というもの。その選択肢は、以下の通り。
MySQLの限界が、会社の規模的にEXITに相当するというのは、ひとつには漠然とした印象論というか経験則なんだけど、オープンソースにおいてはコミュニティが活発であることが必要であり、その為にはユーザ層のボリュームが必要だ。EXITの前には、たくさんのプロジェクトがひしめいているので、コミュニティのプロセスが機能するだけのユーザ数が自然と確保される。
だから、試験的なプロトタイプを作る時に、「はじめてのMySQL」みたいな本を読んで、意味もわからず真似をして、そこからサイトの成長に合わせて、泥縄式にネット上のノウハウをかき集めていても、だいたいは何とか運用できる。ボリュームゾーンにいる限りは、必要な機能は実装されているし、テクニカルな情報もたくさんある。
これから、ハードの性能向上に対応して、MySQLの機能もどんどん向上していくだろうが、その改良は主としてEXITのこちら側で行なわれる。だから、具体的なアクセス数とかレスポンスとか容量とかデータベースサーバの台数とか、そういう数字で見た「MySQLの限界」は動くだろうが、「EXITがMySQLの限界である」という経験則は案外長持ちするのではないだろうか。
そして、この限界を超える時にどうするか。ひとつの選択肢は、独自ノウハウによってMySQLを徹底的に使いこなすことである。
ここにあるように、その場合のポイントは「アプリケーションの特性を生かした最適化」だと思う。
これをやりはじめると、技術的に見たそのシステムの独自性は急速に高くなる。おそらく、MySQLのエキスパートが、mixi(や同じパターンのLivedoor)のソースを見ても、得意のデータベース回りでしていることがなかなか理解できないのではないか。それを極端に言えば「これはもうMySQLではない。少なくとも俺の知ってるMySQLじゃない。これはあんたのMySQLだ」ということで、「あんたのMySQL」→ YourSQLである。
つまり、YourSQLとは「MySQLに代表されるオープンソースのソフトウエアを、特定のアプリケーションに対して徹底的に最適化、カスタマイズすることで、想定されている限界を超えて使い続けること」である。
問題は、「アプリケーションの特性を生かしてカスタマイズする」ということは、「論理設計と物理設計を一人の人間がやる」ということにつながることだ。
Oracleのような商用データベースがオープンソース系のそれと違うのは、論理設計と物理設計を別々に無関係にできることではないかと思う。もちろん、現実の運用上で全く無関係ということはないだろうが、アーキテクチャー上は、論理と物理でそれぞれのツールというかコマンドがあって、独立してできるようになっている。物理設計の変更が論理設計やアプリケーションに影響しないように注意深く設計されている。
私は、これは別々の人間がやるのが理想だと考えている。
論理設計とは、乱暴に言えばテーブルの定義で、テーブルの定義とは、ビジネスプロセスの中の不変点である。だから、組織や金の流れを見る目が必要だ。もちろん、高度な抽象化能力が必要でたくさんのメソッドを覚える必要はあるが、一番のキモはビジネスを見る目だ。だから、ここは娑婆っけの強い人がやった方がいい。
物理設計は、完全にコンピュータ側、システム側の話である。具体的なハードウェア構成を意識した、繊細で集中的な仕事が必要だ。だから、やっぱり浮世離れしたナードっぽい人に向いているような気がする。
両者が喧嘩して口もきかない状態でうまくいくとは思えないが、二人が仲良く相談しながらやるのが理想だとしても、資質として正反対なものが要求されているから、二人いた方がいい。
ソフトウエアアーキテクチャとはつきつめれば組織構造だと思うけど、Oracleは、そういう正反対の二人がうまくそれぞれの領分について合意できるような、論理屋物理屋共存の為のアーキテクチャになっている。
"YourSQL"で論理物理を分担することも可能だが、おそらく、論理屋と物理屋がついつい相手の領分に手を出して、気まずい思いをすることが多いのではないか。
Web系では完全に出遅れているOracleだが、EXIT後の"YourSQL"ユーザのリプレースには大きなビジネスチャンスがあると私は思う。価格体系等を見直せば、これからでも充分勝負になるだろう。
また、「公器としての社会的責任」という観点から、EXITの後は、システム面では信頼性とスケーラビリティにおいて要求されるレベルが格段に高くなる。ストレージエンジン以外は、どんどんマシンを増やしていけばよいのだが(そう言いきれちゃうのは外野の気楽さだとしても)、ストレージだけは難しい。その点でも、すでにノウハウと経験を持っているOracleは魅力的だと思う。
Web独特の特性もたくさんあるが、やっぱり金がからんできたらOracle。
しかし、「EXITしたらOracle」というのは、旧世代の見方かもしれない。(念の為にことわっておくと、私はDB回りでたいした実務的なノウハウは持ってないのだけど、それでも頭の固さだけはそれなりのもので、それだけで旧世代の代表ズラをしている)
いずれにせよ、EXITした後のストレージエンジンを見ていれば、組織構造の変遷(の有無)が自然に浮かびあがってきて、その会社の行く末もかなり明確に見えてくるのではないか。
そして、この分析からもGoogleの独自性が見えて来る。GoogleはGFSという独自のストレージエンジンで、EXITの前後をアーキテクチャ面での変革無しにシームレスに通過した。
Googleは、ガバナンス面でも独自路線でシームレスにEXITを通過した。今もGoogleは完全な公器ではなくて、半分創業者二人の私物であり続けている。その資金調達から見た独自性と技術から見た独自性は深い所で通底しているような気がする。
