Ringo's Weblog

2008年06月27日金曜日

google on ec2

先日、Amazon EC2のTechnology Evangelistの人に対して
Googleとどう競争するのか、と質問する機会があった。

彼の答えに新しい部分は無かったのだが、ひとつの発言が印象に残った：
「EC2の上にGoogleを載せることができる」という発言だ。
これは計算してみるしかない。

EC2の価格リストはここにある：

早速計算開始。当然だが、私はGoogleの当事者ではなく野次馬だ。
なので内容は当然正確ではない、あしからず。飲み屋のネタにしてください。

さて、adsenseなども入れるとGoogleは1000億クエリ/month (100G q/month)
をこなしている。

1クエリの処理に0.3sec, マージンを適当に入れて0.5secかかるとしよう。
またoutgoing trafficは、1queryで5KB送信するとしよう。
incoming trafficは無視できるので、outgoingは1queryあたりHTMLのサイズを
計測してみたが、5KBとして良いだろう。

1ヶ月は2.5M秒あるので、Googleは1秒あたり
100G/2.5M = 40K query/sec
処理してることになる。多いなあ。

合計では、出力に必要な帯域は、40K * 5KB = 200Mbytes/sec。
CPU時間は1秒あたり 20Ksec必要なので、1秒に2万秒必要。
utility rateを高くしたとしても、インスタンスが5~10万個必要。10万とする。
クローラ用に1000インスタンス、インデクサ用にさらに
1000インスタンスだがこれは誤差として無視する。

インスタンスコストは、instance/hour high-cpu medium $0.2　
なので1時間に2万ドル、１ヶ月に1500万ドル必要となる。

次は、サーバに入っていく帯域を見てみる。単価は：

$0.100 per GB - all data transfer in

クローラは帯域を消費する。100億ページを毎月10回づつ取るとすると、
1000億get, ほとんどheadリクエストだが大きいページもあるので15KBとすれば、
100G * 15KB = 1.5PBytes なので、1.5M * $0.1 = 0.15M$ 毎月15万ドル。
インスタンスにくらべて安い。

次はサーバから出て行く帯域。　単価は：

$0.170 per GB - first 10 TB / month data transfer out
$0.130 per GB - next 40 TB / month data transfer out
$0.110 per GB - next 100 TB / month data transfer out
$0.100 per GB - data transfer out / month over 150 TB

月間1000億クエリ * 5KBだ。
100G * 5K = 500TBなので、 $0.1 per GB が適用される。
500K * $0.1 = 50K 1ヶ月に5万ドル。安い。

ストレージも必要だ。

$0.15 per GB-Month of storage used

100億ページを10倍に圧縮して保存している。
平均して10バージョンづつ置いていれば、ページサイズを15KBとすれば
10G * 0.1 * 10 * 15KB = 150TB
150TBのログと格闘するには最低5倍の容量が必要なので、 1PB
とすれば、 1M * $0.15 = $150K 毎月15万ドル。
インスタンスに比べると誤差に近い。
一説によるとストレージに関してはGmailが飛び抜けて大きいという。
1億ユーザが平均して100MB保存しているとすれば(大きすぎだろうが)、
100M * 100M=10PB　となり、毎月150万ドル追加。165万ドル。

次はストレージへのアクセス量だ。単価は：

Data Transfer
$0.100 per GB - all data transfer in

Requests
$0.01 per 1,000 PUT, POST, or LIST requests
$0.01 per 10,000 GET and all other requests*

毎月、100億ページを10回DBに保存し、同量読むとする。
圧縮率は10%実際にはこんなにひどくはないはずだが。。
だとすると、DBからの出力は、10G * 10 * 1.5K = 150TB

150K * $0.1 = $15K 1.5万ドル/月
DBへの入力も同様。合計3万ドル/月

PUTが100G回。よって、100G / 1000 * 0.01 = $1M毎月
GETも100G回。よって、100G / 10000 * 0.01 = $100K毎月

合計すると、

インスタンス=毎月1500万ドル
in帯域=15万
out帯域=5万
ストレージ量=165万
ストレージアクセス=1.5万+1.5万
ストレージクエリ数=100万+10万

合計=1850万ドル/月

毎月1850万ドル(年間200億円程度）あればGoogleの大部分をAmazon EC2の上にのせることができる。

もちろんそれを実現するためのソフトウェアがあればの話だが。

Googleの決算資料を見てみる。

Operating Expenses - Operating expenses, other than cost of revenues, were $1.25 billion in the third quarter of 2007, or 30% of revenues, compared to $1.21 billion in the second quarter of 2007, or 31% of revenues. The operating expenses in the third quarter of 2007 included $659 million in payroll-related and facilities expenses, compared to $625 million in the second quarter of 2007.

Googleは四半期に3600億円売り上げて、人件費や設備のために600億円使う。
このうち設備費用がいくらかは明らかになっていない。
全部のサービスを実現するために、毎年200億円をAmazonに支払い続けるよりは、
自前で自社サービスに特化した設備を維持するという判断を現状はしているのだろう。

あるいは、最もコストがかかるインスタンス部分のコストを圧縮するために、
検索専用チップを作って出し抜こうと考えているか。

今後、amazonが数千万というインスタンスを販売することになって、
そのコストダウン効果がGoogleが自社でできる範囲を超え始めたら、
また状況が変わるのかもしれない。

今度Googleの人に会ったら、これを計算してみたことはあるか？
と聞いてみよう。

Posted by ringo : 01:08 | Comment (0) | TrackBack (0)

2008年05月31日土曜日

手段と結果の自由度について

人をタイプわけするのはあまり好きではない。
しかし、人の行動パターンには傾向があることも確実である。
その行動パターンに名前をつけることもできる。

昨日、私が私塾の師としている人と飲むことがあったのだが、
そのときに「経営者タイプ」と「プロデューサータイプ」
という傾向の名前がでた。

彼はこう言う。

「中嶋君はプログラマからプランナーになったところだね。
プランナーの次はプロデューサーか、経営者か、
どっちを目指すのがいいんだろうね。」

プログラマというのはプログラムを書く人だ。
プランナーというのはどんなプログラムを書く必要があるか知った上で、
ゴールへの到達方法を考える人だ。プランナーのゴールの単位は「製品」だ。
だから「製品プランナー」と言ってもいい。
コミュニティーエンジンでは、エンジニアにはこの両方の仕事を期待している。
多くの小さなソフトウェア企業では基本的にそうだろう。
私自身もそのような仕事をしてきたと考えている。

師に、プロデューサーと経営者の違いは何かについてたずねた。
するとこういう意味であるという。

世の中をこうよくしたいとう最終結果Xがあるとする。
Xにはたとえば貧困をなくすとか、病気を無くすとか。
私自身ならば人間の創造性を拡張したいという願いがある。

Xを実現するためには、何らかの手段Yが必要だ。

XのためならYはなんでも良いとする人が経営者、
かなり狭いYを決めてそれでXがいかにして可能かを考える人が
プロデューサーであるという。プロデューサーにとってはXは自由だ。

まとめると、最終結果を固定して手段を柔軟にするのが経営者。
手段を固定して最終結果を柔軟にするのがプロデューサーだ。

彼から見れば、たとえばGoogleでは創業者2人がプロデューサー、
シュミット氏が経営者で、シュミット氏は自分が持っている最終結果に
2人が持っている手段が現時点では合致すると
分かったから参画したのだろうという。

任天堂の岩田社長や久多良木氏はプロデューサー、
スクエニの和田社長は経営者であるという。
アップルのSteve Jobsも、「箱に入ったコンピュータ」
という手段を片手にいかにして最終結果を実現するか、
最終結果を固定せずに考えているように見える。

どちらがいいというのではない。どちらの立場でも、
素晴らしい最終結果を出すことはできるのだ。
この2種の人々は相互に補い合うシステムを作って活動し、
最終結果を実現することができるからだ。
成功している組織では双方のタイプの人が活躍しているのだ。
最終結果をとことん考え続けるのと、手段をとことん考え続けるのと、
両方が必要であることは明らかだ。

どちらか一方だけを選ぶ必要があるというのではない。
スタート地点では補完関係が弱いから、両方を自分でやる必要もあるだろう。
時間と経験が経過するなかで、より自分に合ったほう、好きな方を
選択していくだけだ。
ひとつ言えそうなことは、手段と目的の両方を同時に固定すると、
固定している部分が多すぎて、可能な仕事の範囲が狭まりすぎ、
結果として何も実現できない確率が上がるかもしれない事だ。
たとえば、計算機とネットワークという手段と、
創造性を拡大するという最終結果の両方を固定してしまうのは、
狭くしすぎな可能性がある。
どちらかを自由にしておいたほうがいいかもしれない。
これについても今後考えたいが、まずいまは置いておく。

さて、自分にとってどちらが向いているのかを考える。
私は幼少時代から、計算機とネットワークという手段に魅せられ、
これまでの20数年間、没頭をしてきた。
これについて何の後悔もしていないし、
たぶん今後も没頭を続けるのだろう。この手段が気に入っているのだ。
ある手段に関して、膨大な時間的投資をしたのだから、
そのぶん、自然と、ほかの事には習熟していないのだろう。

「人間の創造性を拡大する」という最終結果に対して、
経営者であれば、学校や教育法を作るとか、知育おもちゃを作るとか、
未踏ソフトウェアのような投資活動をするとか、結果を最大化するための
さまざまな手段について考えをめぐらす事になる。
プロデューサーであれば、計算機とネットワークという手段を活用し、
高めながら、いかにして創造性を拡大するか、
あるいはほかの最終結果を出すことが可能かも含めて考えていく。

師は「中嶋君は経営者よりプロデューサーを目指すのがいいかもしれないね。
エンターテインメントやものづくりの業界は、
プロデューサータイプの人が大きな結果を出しやすいフィールドだと思うよ。」
と言っていた。

人生の金言とは、こういう言葉のことを言うのだ。

すぐに結論を出す必要は当然ないが、
やっぱり今日も、計算機とネットワークについて、
とめどなく探求している自分に気づくのであった。

Posted by ringo : 11:41 | Comment (2) | TrackBack (0)

2008年03月18日火曜日

知識の量が質に変化する瞬間

創造性は、知識の量から成る、と思う。本当にそうか？

ひとと話をしていて、創造性がある！と感じるのはこんなときだ：

A　多数の事の裏にある、誰も気づかない共通点に気づいてしまう。
B　あるひとつの事のはるか先にある、誰も気づかない帰結に気づいてしまう。

どっちも根っこは同じだ。
少なくとも私のまわりの創造性豊かな人たちは同じ根を持っている。
以下、その仕組みを解説する。

まず人間は、多段階の関係を記憶することができる。
エンジニアならこんなことを最初に習うかもしれない。
C言語→中間言語→アセンブリ→中間言語→x86バイナリ

この関係に関する知識を抽象的に表現すればこうだ。
A→B→C→D→E
しかし知識があればC言語を生成する前段階の軽量言語を知っているかもしれない。
またx86バイナリコードの次にくるマイクロコードのフォーマットを知っているかもしれない。
あるいはさらにプロセッサコアのブール代数処理系の構造を知っているかもしれない。

多くの人が知っているように知識というのは途方もない奥行きがある。
→A→B→C→D→E→
左端と右端は通常は閉じていないのだ。
だから自分が知っている関係の鎖は、とても長い鎖の、ごく一部でしかない。

一方、人間は関係を多数記憶することができる。
文献によってその数は100億とも何十兆とも言う。
まあとりあえず多くて数えにくいのだろう。

ほとんどの人が　A→B→C　D→E→F　という知識を持っているようなときに、
X→A　と　X→D　という関係性についての知識を持っている人がいる。
その人はAとDの共通の根っこを簡単に見つけ出すことができる。
あるいは、F→G→H　という知識を持っていたら、
簡単にD→・・・→H　を想像できてしまう。
ひとはこういったことを見ると「創造的である」と言うのだ。
知識の量がある水準を超えると、急激に創造的になったように見えるのだ。
これとパーコレーションの現象は無関係ではない。

「常識のない若者にしかできない創造があるではないか」これは反論にならない。
常識のない若者にしかできない創造は、もちろんある。
しかしこれは、若者が物事を知らないことによるものではなく、
バランスの悪さに起因するもののみである。

つまり、バランスよく問題解決にあたる技術を体得してしまったひとが
絶対にそうしないようなやりかたで、世界のごくごく狭い範囲の問題について、
徹底的かつ執拗かつ異常に、長時間、膨大なエネルギーをかけて
知識を吸収してしまうことができるからなのである。
しかしその分、世界のほかのほとんどの部分に関する知識は著しく欠ける。
私がこれまで見てきた創造的な若者はすべてこの場合に含まれる。
単純な無知は創造につながらないのだ。

現時点では、私は無知による創造性を信じない。

Posted by ringo : 00:02 | Comment (0) | TrackBack (0)

2008年01月22日火曜日

ポジション・ペーパー2008年版

2004年あたりからポジション・ペーパーを年1回更新している。
過去のものを掲載し続けるのは、はっきりいって恥ずかしいのだが、
成長の記録ということで公開しておく。
絶対値ではなく変化量に注目していただきたい。
（しかし派遣会社とかのスキルシートでスキルの絶対値ではなくて、
変化速度に着目して評価している会社は見たことがないな。。）

以下、2008年更新分をコピーしておく。

------------

私は、2007年の目標を以下のように置いていた。
「私に関わっているすべての人の潜在能力が100%発揮されるために、必要なことをすべて実行すること。」
これは、普通に考えると1年で終わるような事ではないし、実際に終わっていない。

「終わっていない」とはどういう事だろうか？

まず去年は、「人の潜在能力が100%発揮されている」とは何なのかを、特に考えていなかったようだ。
だから、終わったのかどうか、どの程度実現ができたのか、いま、ふりかえって評価することができない。
2008年は、これを評価可能な状態にして取り組みたいと思う。

「人の潜在能力が100%発揮されている」こと自体が良いかどうかについては問わず、
まず評価基準を考えてみる。この目標に何らかの意味があったかどうかは、
評価結果が出ればより深く考えることができる。

「人の潜在能力が100%発揮されていない状態」をできるだけシンプルに定義するならどうなるか。
まず何もしない状態と、何かをしている状態があるだろう。
何もしないとは、何かをただ待ってぼーっとしている状態だ。
これはかなり正確に能力を発揮してないと言えそうだ。

次に何かをしている状態はどうか。必要なことをしてる時と、そうでない時がある。
必要ないことをしてる状態でも、これは後になって考えたらやっぱり必要だった、と言えるかもしれない。
ムダや失敗からうまれる発明も多いはずである。
また必要なことでも、それを限界速度よりも遅くやってる状態は、能力を発揮してないと言えるだろう。
ただし、これは実は待ってる状態の派生に近いのではないか。

このように考えると、自分のまわりの人が、自分や他人を待ってる時間を最小にすればよい、
という評価基準で、評価することが可能なのではないか。
まずは、これでいってみたい。

これはどこかで聞いたことがある・・トヨタ生産方式の要素である。

トヨタの待ち時間最短理論は、自動車ならではの平準化された販売が
基本システムとして必要なので、同じ考えはそのままでは通用しないだろう。
というわけで今年は、自分たちの業態に合った待ち時間の評価方法を考えて、
それを最小化することをやってみたい。
ビルドの待ち。欲しいドキュメントが見つからない待ち。
バグによるblocking。要望に対応する時間の長さとか、会議のやり方とか、
営業における提案活動のやり方とか、仕事の中に、待ち時間は山ほどある。
改善できることは山ほどありそうだ。

Posted by ringo : 16:23 | Comment (0) | TrackBack (0)

2008年01月18日金曜日

ロボットの視野

ずいぶん前に「心はプログラムできるか」を読んだ。
著者の有田氏は、計算機による実験を通して、心とは何かを探り続けている人だ。

その本に基づいて考えたエントリなので、
できれば読んでからもういちど見ていただきたい。

本書の後半に、「心の理論」の再帰レベルについて切り込んでいる部分がある。
これは本書の核心部分である。

>レベル 0 「高野は計算機の中に心が作れると信じている」

>レベル 1 後藤は「高野は計算機の中に心が作れると信じている」ことを知っている

>レベル 2 小島は「後藤は「高野は計算機の中に心が作れると信じている」
> ことを知っている」かどうか疑っている

>レベル 3 佐藤は「小島は「後藤は「高野は計算機の中に心が作れると信じている」
> ことを知っている」かどうか疑っている」ことをばかにしている

>レベル 4 松田は「佐藤は「小島は「後藤は「高野は計算機の中に心が作れると信じている」
> ことを知っている」かどうか疑っている」ことをばかにしている」
> ことを気にしている

・・・

チンパンジーはレベル2まで、人間でも普通はレベル4までしか理解できないという。
人間は文字やツールなどの道具を使えるので、
時間さえかければ無尽蔵なレベルを扱うことができるはずだが、
脳の機能を問う場合には、外部のツールを使わずに処理できる限界が問題となる。

「空気を読めない人」という日本語があるが、この言葉は、
「レベル３や４がすぐには理解できない人」なのかもしれない。
これは容易にテストできる。実際、多人数に対して理解度のテストをして、
人間はおよそレベル4だ、という結果が出ている。
人間の能力はおそらくつりがね状の分布をしているのだろう。

有田氏は、このレベルが高ければ高いほど「良い」のか？
どのレベルが最適なのか？　について疑問を抱く。

まず心の理論を計算機の中でシミュレートするには、仮想空間にロボットを入れる。
ロボットは狭い空間の中をできるだけぶつからずに目的地に到達しなければならない。

> レベル0のロボットは、目的地までまっすぐに行こうとする。
> レベル1のロボットは、他のロボットがレベル0であると予想して、他のロボットを避ける
> レベル2のロボットは、他のロボットがレベル1であると予想して・・

というように物理的な挙動にモデル化してしまう。

この結果が面白すぎるのだが全部を書くと本を買う意味がなくなるので
その結果だけを述べると「ロボットの視界の広さ」がすべてなのである。
どの「心の理論」のレベルが最適なのかは、視界の広さによる。
考えてみれば当たりまえのことだが・・いざ言葉になると、おどろいてしまう。

さらに、視界の広さが極端に狭かったり広かったりすると、レベル2が最適、
とかある値に落ち着くが、視界の広さがちょうど良いと、
レベルが高ければ高いほど良くなる。
人間の視界の広さだと、レベルが高ければ高いほど良い、
という結論になる可能性が高いという。
実際、このレベルは、これまでの人類の歴史を通して、じわじわと進化してきているという。

引用が長くなった。

さて、この理論の結果をwebシステムに応用することを相変わらず考える。

gumonji MMO版の運営でわかったこととして、
1. 十分に土地が余っているときは、みんな好き放題遊ぶことができるが、
ほぼ個人的な営みや、ランダムな営みに終わる。
2. 余剰の土地が無くなってきたら、みんな遠慮しはじめ、行動が減ってしまう。
3. ちょうどよい状況のときは、良いコラボレーションが生まれる。

以前MMO版を運営したときは、1から3を経由して2に至ってしまった。
2に至る原因は、人数の増加と、各プレイヤーの行動の蓄積だ。

ロボットによるシミュレーションは、以下のような結論になるという。
a. 視野が大きいと、あまり避けないレベル0やレベル2が多くなる。（最適）
b. 視野が小さいと、大きく避けるレベル1や3（奇数レベル）が多くなる。（最適）
c. 視野がちょうど良いと、無限に進化し続ける。

a. のあまり避けないというのは「好き放題でランダム」に対応し、
b.の大きく避けるのは「遠慮して行動が減る」に対応すると思う。

人間の認知能力に限界があるならば、
人数（人口密度）の増加は視野の縮小を推進するかもしれない。

仮想空間の中でちょうどよいコミュニケーションが産まれるようにするために、
プレイヤーの人口密度を保つだけでなく、
ゲームシステムやゲーム内のコミュニケーションツールの仕組みを
あるプレイヤーが見える範囲という観点から整理してデザインし直せるかもしれない。
多分ひとつ言えるのは、プレイヤーの視野の広さを1個に決めるのではなく、
あとで調整できるような設計にしておくことが肝心である、ということかもしれない。

それを実現するには、基本的には、プレイヤーの行動に関する情報を
可能な限り記録して検索可能な状態にしておくが、
その量は圧倒的に人間の処理能力を越えているようにする
（1プレイヤーあたり数GB以上など）。
そのうえで、必要な情報を探し出すフィルタを用意して、
その時点で適切な視野を与える。このフィルタがデータベースの層と
綺麗にわかれていて、あとで修正しやすいpluggableなものになっていて、
状況にあわせて動的に調整可能であるなら、
初期にデザインを確定させるという危険を冒さなくて済むかもしれない。

Posted by ringo : 11:54 | Comment (3) | TrackBack (0)

2008年01月08日火曜日

TypeTraceと「情報のプロクロニズム」

TypeTraceというソフトウェアのベータ版がリリースされた。

このソフトウェアは、テキスト入力における
「情報のプロクロニズム」を実現するための1歩として開発された。

TypeTraceがどのようなものなのかを知るには、
体験するしかないので、ここでは説明しないが、
TypeTraceによるテキスト年賀状がここにある：
HappyNewYear
TypeTrace開発メンバーであるドミニク氏から頂いたものだ。

私は、TypeTraceがリリースされる前から、アルファ版を使い、
1万文字を越える雑誌記事の執筆のために使っていた。
私は、その作業を通して、いくつかフィードバックをするなど、開発に協力をした。

TypeTraceを使うことによって、いままで計算機を使って入力された
テキストが失っていた情報が、完全ではないにせよ、保存されていることがわかった。
そして何よりも大きな収穫は、「情報のプロクロニズム」の考え方が、
テキスト入力以外の様々な領域に広げて使うことができることがわかったことだ。
TypeTraceを使って書いた、情報のプロクロニズムに関する記事が、
近々、雑誌において公開されるので、それが公開されたらまたお知らせをしたい。

TypeTraceは現在はMacOS用だが、web版など今後は広がりを見せるに違いない。
今後が楽しみなプロジェクトだ。

Posted by ringo : 13:23 | Comment (0) | TrackBack (0)

2007年11月26日月曜日

ロールモデル思考法の実践方法

ウェブ時代をゆく
において梅田氏が提案している、
「ロールモデル思考法」を具体的に実行するためには、
何を理解してどういう行動をすれば良いか？

まず、ロールモデル思考法は結局のところ、
「巨人の肩の上に立つ」ということだ。
技術や文化に関する知識だけではなく、人間の行動パターンにおいても、
巨人の肩の上に立つことが可能であり、価値がある、と梅田氏は言っている。

技術や文化に関しては積極的に本を読んだり美術館に行ったりして
積極的に取り入れる（マネをする）するような人たちでも、
何故か、人間の行動パターンについてはマネをすることを嫌がるときがある。
これは「人間の自由意志」という妄想を信じすぎているからかもしれない。

行動パターンにおいても巨人の肩の上に立つべき、という事については、
私も梅田氏と同意見である。自分の周囲の人にもそれをすすめてゆきたい。

実際に肩の上に乗るには何が必要か？

まず最初にすべきこととして、「他の人の行動をみて、
「良い」と肯定的な言葉を発する」ことが必要だ。
これは、やると決めて練習すればできる。

この次に、以下の要素をチェックして、自分の現状を観察することができる。

＊自分より若い人の行動パターンをマネしたことがあるか？
＊自分よりキャリアの短い、経験の浅い、実績のない人の行動をマネしたことがあるか？
＊異業種の人の行動パターンをマネしたことがあるか？
＊同業でも、職種が異なる人の行動パターンをマネしたことがあるか？
＊外国人の行動パターンをマネしたことがあるか？
＊部下のマネをしたことがあるか？

このように具体的なチェックリストを作って、
自分がどの程度他の人の行動パターンを日常的に
取り入れることができているかを測定することができる。

このリストは、必ずしもその通りにすべき、というリストではない。
現状を把握して自分を観察し、自分にあった変え方を見つけるためバロメータだ。

Posted by ringo : 12:37 | Comment (0) | TrackBack (0)

Site Navigation