October 25, 2006

スケーラビリティと機能性は不可分。発行するSQL文が増える可能性がある以上、明らかにトレードオフの関係となる。
キレイ事や正論やあるべき論ではなく、実際、これでいいんじゃないかと思うんだがどうだろう、と言う質問。

■Webサービス開発：
キーワード：むしろ冗長でも良い、まずは最適化発想禁止、スケーラビリティは運用しながら調整（計算できないし、サービスの発展にあわせて作るかえるべき）

目的：極論だけど日単位で機能追加が可能であることを最重視

■エンタープライズなサービス開発：
キーワード：冗長は害悪、常に100%の最適化発想、スケーラビリティは社員の数と伸びで計算可能

目的：スケーラビリティは基本的に予測可能として考える。安定性と機能完成度重視なので、あらゆることを固める必要あり。アジャイル発想で、最近はそうでもないかもしれないけど、Webサービスほど発展が不明確ではないと思う。(M&Aして社員が2倍になったら機能統合、再編？）

これ、何が違ってくるかというと、仕様要求に対する柔軟性の違い。(って書いてますね）

サービスの仕様要求は、一日単位で変わることがあります。
毎日、ビジネスの状況が変わることがありうるからです。

ところが後者の発想で考えていると、機能追加、変更時の工数がすごく増えることがあります。

ようするに「こう最適化しちゃったから、できません」と。

そこでビジネスチャンスを逃すのが一番、怖い。

エンタープライズでの半年～1年単位などでの機能追加への柔軟性要求の対処と、Webサービスなどの1日単位での機能追加への柔軟性要求の対処は、結構、考え方が違うんじゃないか？、というのがポイント。

エンタープライズ的な観点で優秀なエンジニアが最初に最適化発想で作ってしまうと、サービスとしての拡張性が下がる可能性がある。

もちろんスケーラビリティなどは維持される方向なので、トレードオフの関係。

じゃぁ、mixiはどうなのよって話があるが、そもそも奇跡みたいな例なので、あそこに照準を合わせることがそもそもお門違いだと思うのと、そもそもそんなことを怖がって小さくまとまったサービスは伸びないと思うので、かるあるべし論って、サービスにとっては結構、怖い考え方だなぁと思ったりしています。

もちろんバランスですけどね。

でも、mixiみたいになったら泣きながら頑張れ・・・で良いと思うし、楽天はスケールに応じてシステム構成をかなり作り直しているという話なので、そこでエンジニアが頑張る余地があるハズですし、それを怖がってたらサービスでは生きていけないんでしょう。

例えば楽天だって、多分、今のシステムからしてみたら最初のシステムはめちゃくちゃだったハズです。みんなそこから泣きながら成長してきるのであって、今の楽天のかくあるべしのようなものを、成長途上のサービスに適用したら、完全にオーバースペックになってしまいます。

以前、はてなのnaoyaさんが、ハードを追加するだけでスケーラブルになるなら簡単で、実際はそんなことなく、拡張したいときに拡張できるように作っておくことが重要なんだと的な技術論がありましたが、そこのコンテキストにおいては、

「機能は日単位で柔軟に追加できる前提」

ってのが、暗黙のように存在しているハズです。そこが満たされていないサービスは、そもそも違うと思うところであります。

当たり前だと思う人には当たり前かもしれないけど、企業システムを前提とした最適化発想を是として教育されてきた人の中には、あまり意識されてないケースもあると思うのですが、どうなんでしょうか？

※1：かと言って、スケーラビリティが破綻するのは論外なので、それは一応。それはF-1レーサーがクラッシュするのと同じなので、悪しからず。
※2:そういう意味では、厳密な要求仕様とは、「日々のビジネス変化に対応する設計をすること」ということのような気がする。ここを仕様がいい加減だ！とビジネスにコミットできないエンジニアだと結構、サービスでは辛い思いをすると思う。
※3:まだ曖昧だけどゴールとしての上場モデルってのが頭にある。要はキャズムを超えるまでには、固めなきゃいけない場所ってのはかなり大きくなってると思うのは今のmixiを見てて思うこと。そこまでには不安要素は全部取り除いてスケールするようにしておくのがゴールではないかと。