2005-01-16

近況

雨だ. 寒い. でかける気はおきない. 暖をとろう. そう思って日に三度も風呂に入り, ワインの紅茶割りを飲み, ガス暖房で尻を炙った. これが豚ならあとは切って皿に並べるだけだ. 豚でないのが幸いとばかりに積ん読をこなした. それにも飽きてきたのでよた話を書くことにする.

スケーラビリティ

スケーラビリティとは, Wikipedia によれば "資源(一般にはハードウェア)を追加することで高負荷下で性能アップできること" をいう. スケーラビリティを謳う世間のシステムはおおよそこの路線に従っている. ロードバランサー, レプリケーション, 分散オブジェクト, etc. スケーラビリティを気にするのは, 多くの場合サーバ・サイドのシステムだ. 増えつづける利用者という皮算用の下, システムはスケーラブルに設計される.

クライアント・サイドのプログラムは, あまりこのスケーラビリティを気にしない. なぜなら, 垂直方向のスケーラビリティは特に気にしなくても実現されるし, (大抵のソフトウェアは CPU が速くなれば高速に動く.) 水平方向にはそもそもスケールしない. (ソフトウェアを速く動かすために計算機を買い足すことはない.) かといって, クライアント・ソフトウェアをつくる時にスケーラビリティを気にしなくて良いということにはならない. 意識すべきスケールの向きが違うだけだ.

上で示したスケーラビリティは, 資源や負荷が大きい場合だけを気にしている. 実際には, 資源と負荷が小さい場合もある. 負荷が小さい分には構わないものの, 資源が少ないのは困る. しかしそういう事態はよくある.

逆方向のスケーラビリティ

そうした状況下でもクライアント・ソフトウェアにはうまく動いて欲しい. この "資源が少なくても低負荷なら動くこと", つまりしょぼい計算機でもそこそこ動くという "逆方向のスケーラビリティ" を, クライアント・サイドのソフトウェアを作る際には意識しておく必要がある. たとえば, RDB をバックエンドとした堅牢なコンテンツ管理システムと .NET Web Service による loosely coupled な分散協調型ペイントソフトなんてのが(仮に)あったとすると, これは上のスケーラビリティを満たさず, 貧弱な計算機を持つユーザに使われる機会を逃すだろう. (サーバ側でも同じことはおこりうるが, 計算資源が潤沢で問題にならないことが多い.)

また, クライアント・ソフトウェアの印象を決定づける "軽快感" はこの逆方向のスケーラビリティにかかっている. はじめて触ったときの印象は, 巨大なデータをそれなりに扱える事実より強い.

投機としての抽象化と高速化

完全に逆方向へスケーラブルなソフトウェアがもしあるなら, それはどんなに貧弱な計算機の上でも, 負荷(処理すべきデータ)がないならまったくストレスなしに動くだろう. もちろん, 実際のソフトウェアはそのようにできていない.

ソフトウェアの設計では, 多かれ少なかれ何らかの抽象化をする. 機能をモジュールに分割し, インターフェイスを決めて, という風に. こうした抽象化はある種の投機である. 何かの都合でインターフェイスの後側を変更したいかもしれない, 抽象化はこうした "かもしれない" に基いている. 抽象度があがるほど投機のコストは増す. 関数呼出しより仮想関数, 仮想関数より WSDL の方がコストが大きい. 抽象化のコストは逆方向のスケーラビリティを制限する. このコストは計算資源や負荷に関わらない定数だからだ. (なお, 抽象化の投機性については YAGNI に詳しい.)

ソフトウェアの高速化もその多くは投機だ. 高負荷時に備えてコストを払う. たとえばカスタム・メモリ・アロケータは余分な主記憶を必要とするし, 各種描画のカリング/クリッピング処理や探索の枝刈りは成功を期待して省略判定に資源を割く. 低負荷時にはこれら高速化のどれも余計な負担となる.

抽象化や高速化は手法によってコストや見返りが異る. その取捨選択がプログラマの仕事であり, 能力だと言える. 手法を多く知るほどそれを使う誘惑は強い. その言い訳としてスケーラビリティはよく引合いに出される. しかしトレードオフがあるこをと忘れてはならない. 凝った抽象化や高速化を踏み止まる材料として, 私はこの 逆方向のスケーラビリティ を思いだすようにしている.

サービスとスケーラビリティ

新しいサービスを考える際にもスケーラビリティを議論することができる. ビジネスで新しいサービスを作っている人は, たとえば会員が 1 万人を越えても破綻しないスケーラブルな仕組みを考えるだろう. しかしアマチュア(たとえば私)が草の根サービスを作ろうとしたら, そうしたスケーラビリティを考慮するのは皮算用が過ぎる. 私達アマチュアは, むしろサービスにおける 逆方向のスケーラビリティ を意識すべきだ. そのサービスは, 利用者が数人でも, あるいは自分だけでも有意義だろうか. そう問う必要がある. 利用者が少ないと使えないサービスが多くの利用者を得るのは難しい. たとえば SNS は利用者が少ないと意味のないサービスだ. 私が今日から full featured な SNS を運営しますと言ったところで, 利用者は誰もいないだろう. SNS の価値の多くは利用者自身が担っているからだ.

ビジネスとして運用されているサービスは, bootstrap に立ちはだかるこうした逆方向のスケーラビリティの壁を広告や既存の顧客といった資本を頼って乗り越えようとする. 草の根のサービスでもうまく流行に乗ってこの壁を越えることがある. (mixi などの SNS はその良い例.) しかし一般に草の根サービスやベンチャー企業は資本や運を頼れない. だから逆方向のスケーラビリティが必要になる. はてな を見るとわかりやすい. はてなはまず 人力検索 という逆方向にスケーラブル でない サービスを提供したが, さほど流行らなかった. その次に用意されたはてなアンテナやはてなダイアリは成功した; これらは逆方向にスケーラブルだった.

サービスがさほど斬新でなくても良いのは, 逆方向にスケーラブルなサービスが持つもう一つの利点である. たとえば他より優れた SNS をつくったとしても乗換えを期待するのは難しい. 優れたアンテナサービスを作れば, 他のアンテナサービスから利用者が移ってくるかもしれない.

新しさは投機性を持つ. それが新しくても有意義かどうかは試してみないとわからない. 有意義であっても理解されるとは限らない. こうした不確定要素が多い. 逆に有用性がわかっているアイデアを改善するのは投機性が低い. 逆方向のスケーラビリティを持つサービスなら, そうした改善を主体としながら使いものになるサービスを作ることができる. 都合のいい例をひくなら, キヌガサ は流行りそこねて i-know はそこそこ生き延びた. 改善は積み重ねればオリジナリティになる. 逆方向のスケーラビリティが制限されていると, そうしたアプローチを選べず, 投機性の高い目新しさに頼らざるをえなくなる.

逆方向のスケーラビリティは草の根サービスとってほとんど必須だと私は思う. 優れた発明家はそれを本能的に知っている. しかし順方向のスケーラビリティが持つ魅力に購うのは難しい. なぜなら 100 人の利用者がいたら実現できるであろう楽しいあれこれを想像するのは, 自分一人でも楽しめるアイデアを練るよりずっと簡単だからだ. 平凡な割に欲深い私は, こうした pitfall を割けるべく逆方向のスケーラビリティを意識したい.

スケーラビリティを捨てる

さて, 自分だけで使っても有意義なのが逆方向にスケーラブルなサービスだと上で述べた. より極端に, 自分(や特定の誰か)にとってのみ有意義なサービス/ソフトウェアを作ろうと Clay Shirky は主張する. Shirky はそれを "Situated Software" と呼ぶ. Situated Software はつくるためのコストが低いだけでなく, 特定の利用者やグループの特性や能力を最大限に引きだせるため非常に使いでのいいものになるという. "Software for Your Mom" という利用者個々人を尊重する姿勢は, サービス業としてのソフトウェアが目指すひとつのゴールになりうるかもしれない, そんなカタギな情報産業に憧れないこともない.