2007年9月16日

新社会人にあなたならまず何を教えるか? -5- CS: Focus

こんなシーンをちょっと想像して欲しい。


あなたは吉兆の京都本店にいるとしよう。嵐山にある、あれだ。
あなたはそこでご飯を食べている。もちろん、辺りは和一食…ではなく一色だ。

そこに、サプライズが発生する。KISS の生コンサートだ。そう、ニューヨーク出身のハード・ヘヴィーメタルバンドだ。メンバーがそろそろ全員いい歳だ、というのはちょっと無視しよう。

場所は嵐山。景観は最高だ。
食事は吉兆。食材も、加工技術も超一流と言っていいだろう。
そしてBGMは KISS。ヘヴィーメタルの最高峰…かどうかは異論があるかもしれないが、ちょっとここは最高峰だってことにしておいてくれ。必要なら、自分が最も好きなバンドに差し替えてくれて構わない。

今までの説明の通りだと、それぞれの Technology は最高だ。それを伝えるための技術も最高だろう。

で、あなた、そう、客であるあなたは幸せだろうか?


決して幸せではないはずだ。なぜなら、吉兆でご飯を食べるという段階で、ヘヴィメタを聴くような心境ではないはずだから。あるいはヘヴィメタを聴く心境だった場合、嵐山はただの交通の便が悪いド田舎だし、吉兆のご飯も肩肘が張っているだけで値段に対して味は大して…という心境のはずだ(吉兆の味がどうこう、という意味ではなく、受け入れるような心境には無い、という意味において)。

もし、これがサプライズではなく、最初からそのように予定されており、お客様にそのように伝えられていて、それでこそ良い、というお客様だけが集まったのであれば、これは単に異色の取り合わせでよかったのかもしれない。しかし、サプライズの場合、そこに集まっているお客様は嵐山の景観と吉兆のご飯を、静かな環境で食べたいと思っているのであって、間違ってもヘヴィメタを聴きながらとは思っていないはずだ。


これが Focus だ。


お客様と言うのは、自分が着目しているポイントに関しての Technology を重視し、それに関する説明を熱心に聴く。それ以外のものについては興味は無いのだ。

ある程度までは無視してくれるかもしれないが、邪魔なものがあるという意味においてプラスには取ってもらえない。限界を超えると、もはやマイナスのスコアをつけられてしまう。
「そんな余計なものをつける余力があるなら、
もっと値段を下げるか、
もっと本筋にリソースを集中投下しろっ!!!」
というわけだ。


お客様の Focus から外れた仕事はいかに優れていようとも、いかに説得力に満ち溢れていようとも、評価はしてもらえない。限界を超えて外れているとマイナスの評価さえ受ける。

そう。Technology も Transform/Translate も 0.0 から 1.0 の値をとっていたのに対し、Focus だけは、-1.0 から 1.0 の間の値を取るのだ。そして、お客様が「欲しくない」物について高度な技術が投入され、それがお客様に見える形で提示されると…お客様は激怒する。

なぜかというと、お客様はお金を払っているからだ。そして、その対価として
自分にとって重要なポイントに Focus があたった製品(なりサービスなり)
が欲しいと思っているからだ。自分にとって重要ではないポイントに、投資したお金を使われると、無駄遣いされた、と感じるのは当然だ。この場合、お客様が良く判る形で、無駄遣いされたような印象を与えると、より多くのリソースを無駄遣いされたと感じるようになるので、0.0 ではなく -1.0 の評価を得てしまうわけだ。


新入社員にやらせる仕事の多くは、先輩社員がすでに Focus の調整は済ませてくれているものだ。やるべき仕事のテーマははっきりしており、その内容はすでにお客様の満足度を満たすように調整されている。従って、新入社員の場合、この点を心配する必要は無い。

ただ、新人の段階で Focus の事を十分理解していないと、後で酷い目にもあうし、ひどい迷惑を回りに掛けることにもなる。


Focus が甘いケースと言うのは面白いことに2種類ある。本来あるべき焦点より手前に Focus があたっている場合と、奥にあたっている場合があるのだ。



本来より手前に来てしまった例で私が経験したのは次のようなものだ。

あるプロジェクトが納期を過ぎても完成しなかった。3ヶ月締め切りを延ばしてもらい、新規投入されたマンパワーの一方が私だった。このプロジェクトは Web プログラムを作るプロジェクトだったので、プログラム自体のアイコンが必要になった。で、プロジェクトリーダーはそれを数日掛けて作った。

アイコンの品質は実に素人くさいもので、今回のプロジェクトには丁度良い…つまりどう見ても1-2時間しか掛けていないように見えるものだった。ので、お客様の感想は文字通り
「素人臭い」
だった。これはとても良い兆候だった。プロジェクトは納期を過ぎており、1秒でも早く作れるならば、そのための努力を怠るわけには行かず、無駄なリソースを使っていないように見せる必要があったからだ。しかし、プロジェクトリーダーはそう取らなかった。お客様の満足度を向上させねばならぬ、と思ったのだろう。


リーダーは数日徹夜して、はるかに素晴しいものを作り上げてきた。当然、お客様は激怒した。
素晴しいアイコンを作ったから
お客様は激怒したのだ。そんな所にマンパワーを投入している暇があったら、ドキュメントを1文字でも多く書くべきなのに、ドットをいじっているとは何事か、と言うわけだ。


これは、リーダーがプロジェクトの本質を正しく理解しなかった好例だ。締め切りを過ぎているのだから、アイコンなど「◎」だって良かったはずなのだ。しかし、お客様にとって必要かどうかを熟慮せず、自分の趣味に走った。これは典型的な焦点がお客様よりも自分側にいる例だ。



もう一つは、焦点が逆…つまりお客様のさらに奥に行った例だ。

ある会社がコンサルタントを要求してきた。仮想化技術の将来について現状を評価し、未来を予測して欲しい、というものだった。

このお客様は、仮想化技術を「過去に作ったプログラムを、バイナリレベルで変更せずにいつまで使い続けることが出来るか」という視点に基づいた仮想化技術の評価が欲しいのだ、と言った。プロジェクトリーダーがそれをちゃんと把握できたのかどうかはともかく…調査員はこのことを理解しなかった。

調査員は非常に優秀で、現在ある仮想化技術について、1から100まで調べ上げた。その内容は実に見事なものだった。そして、それをそのまま…つまり「今すでに存在するバイナリを、変更せずに使い続けるための道具としての仮想化」という視点に基づいたフィルタリングをせずに、お客様に提示してしまった。

当然、お客様は混乱する。100 もの情報を与えられ、それを全部噛み砕いて飲み込まないと、その情報の中でどれが自分たちの目的に合った情報なのかわからなかったからだ。そもそも、そんな把握が軽々と出来るならコンサルタントになど雇わない。確かに、与えられた情報は「後で」必要になるかもしれないが、とりあえずは不要なものだ。そのような情報は「削っておいて」欲しかったはずだ。

ちなみにこのリーダーはいまだに何が悪かったのか判っていないらしい…

これはお客様の「先」を「見据えすぎた」例だ。どの情報が必要になるか判らないので、お客様のために「全てを」与えた。結果としてお客様の受容容量を超え、お客様の満足度を下げてしまったわけだ。


ついでだから言っておこう。このお客様が望むような仮想化技術は、ない。

ゲームソフトを仮想マシン上で動かそうとするプロジェクトはあちこちにあるが、微妙なタイミングを無駄なループなどで図っているゲームが意外と多く、タイミングの再生に難儀するそうだ。何しろソフトウェアエミュレーションというのはどんな1命令もハードウェアと同じ速度で実行できるように調整しているわけではないのだからして…

理想的なアプリケーションであれば、仮想化技術で寿命を延ばすのも良いだろう。しかし、そのようなソフトはちょっとした手を加えるだけで、新しい環境に適応する。新しい環境に適応しないのは、ソースコードがなくなっていたり、あってもナニをやっているのやら良く判らない…「いじるな!!! 今動いてるんだから!!!」系のソフトだけだ。そのようなものは、仮想化で寿命を延ばそうにもほとんど伸びない。仮想化ソフトが持っているバグを踏んづけて、ゆとりがなくなってから地獄を見るのがオチだ。

…見ての通り、たった3段落で結論は説明できてしまう。これなら、お客様は一瞬で理解できたに違いない。
100ページを越す大作は、顧客満足度を下げるだけだったのだ。





このように、Focus がきちんとお客様の望むものに当たっている事はとても重要なのだ。お客様に対し、無駄なものを与えるのも、お客様が飲み込めない程の内容を与えるのも、同じぐらい重罪であり、それらはどちらもお客様からは無駄遣いに見えるため -1.0 の評価を受けてしまう。


以上、 Technology, Transform, Focus の3つについての説明は終わった。
Technology と Transform は 0.0 から 1.0 の、Focus は -1.0 から 1.0 までの値をとり、それらの掛け算の結果がお客様の満足度になる。

当然、結果は -1.0 から 1.0 の値をとる。1.0 が大満足、-1.0 はぶん殴られる状態、というわけだ。


…さて、次回は もう一方の重要なポイント、Automation(AT)について説明しよう。Cusotmer Satisfaction だけに注目したのでは、札束で頬を殴られている奴隷と何が違うのかわからなくなってしまうからね。

2007年9月15日

新社会人にあなたならまず何を教えるか? -4- CS: Transfer/Translate/etc..

二つ目のTは伝える力だ。残念ながら、英語でしっくり来るものが無い…

なぜ、しっくりこないかと言うとここでいう伝えるとは、相手を問わないからだ。

もし、相手が計算機ならばプログラムを組んで、あなたの意図通りに動かすことを言う。これに合うのは、どちらかというと意思を「伝達・翻訳」するという意味で Translate がしっくりくる。

しかし、相手が人間の場合は、相手に自分の主張を理解してもらい、納得してもらい、同意してもらい、賛成してもらう事がポイントになる。こうなると本当は Communicate が正しいのだが、そうすると T で始まらない…。いや、それはどうでもいいのだが :p

この能力で大事なのは
  1. 相手に伝えたい事は何かをはっきりさせること
  2. 相手に応じて伝え方を変えること
の2点だ。



判りやすいように計算機のほうから始めよう。

ご存知の通り、計算機は愚直で、単純で、疲れを知らない。正確にいわれたことをやり、いわれていないことはやらない。従って計算機が行うべき作業を緻密に、正確に、指定すれば、その通りに実行してくれる。逆に緻密に、誤って指定すれば、それもその通りに実行する。パフォーマンスがどれぐらい出るのかなども含め、指示次第である。計算機は誤解などしない。計算機に与えた指示が間違っているだけだ。

このような対象である計算機に、計算機が理解できる言語で、何をするべきかを伝えるのがプログラマである。プログラマの仕事は、
  1. その計算機が何をするべきなのかを正しく・漏れなく・重複無く(MECE)理解する
  2. それを 正しく・漏れなく そして…できれば重複無く 計算機が理解できる言語に翻訳する。
メンテナンスを考えないなら後者の『重複無く』は無視しても良い。しかし、大抵の場合間違いは『重複』の部分に存在し、そのせいで直しても直しても『べつの場所』に『同じ間違い』が残っている、という賽の河原が発生するので、出来る限り重複は無くしたい。

計算機に伝えるための言語は、プログラミング言語でありさえすれば何でも良い。もし Linux のように既にあるプログラムに対する機能追加や修正の場合は、Linux がすでに利用している言語(この場合は C言語とアセンブラだが)を使うことになる。それ以外の選択肢は与えられていないからだ。しかし、新しくプログラムを1から作るのであれば、要件を全て記述でき、必要な性能が出るのであれば本質的にはプログラミング言語は何でも良いのだ。

別の言い方をすれば、優秀なプログラマの要件の1つは多くのプログラミング言語を知っている、という事だ。あえて言うならば、計算機をプログラムするに当たっての最も Primitive な言語である Assembler は理解しておいたほうが良い、と言う程度だろう。


伝える内容は最初のT, Technology で指定された内容になる。

伝えるべき内容が 0 であれば、プログラミング言語をいくら知っていても出力は 0 だ。逆に伝えるべき内容が判っていても、プログラミング言語を知らなければ、やはり出力は 0 になる。



理解しにくいのは次の「人間を相手にした場合」だろう。実際私も得意ではないので、なかなか上手に伝えられないのだが…。

「シッタールダ王子は何が偉かったのか?」

という命題がある。シッタールダ王子というのは、ご存知『仏陀』になった人だが、この人は

悟りを開いたのがえらいのではない

えらいのは、

「悟りを開いていない」人に、
「自分は悟りを開いたのだ」と言う事を、
伝える能力があった


と言う点だ。もしかしたら、彼以前にも悟りを開いた人はいたかもしれない。でも、まだ悟っていない人にその事を伝えられないのでは誰も弟子にはならないし、当然他人を悟りに導くことも出来ない。

仏陀の仏陀たる所以は、「悟っていない人に、自分は悟っており、相手を悟らせることが出来る」と説得できたことにあるのだ。


ここでいう「悟る」というのが Technology にあたる。人間を相手に Communication をはかる場合に重要なのは、

技術を理解していない相手に、
自分は技術を理解している事を伝える


事なのだ。

もちろん、世の中には「天才は天才を知る」という言葉があるように、本当に超高度な Technology を厳密に伝え合うためには、相手も自分も同じ Technology をほとんど全て理解し、扱えなくてはいけないだろう。「相手に自分が知っていることを全て伝える」事が常に可能なわけではない。

しかし、思い出して欲しい。我々は「お客様を満足させるために」Communication をはかろうとしているのだ。何もお客様と、ユニゾンをはかろうとか、
「あなたと一つになりたい」
などとエヴァンゲリオンのテーマのようなことがやりたいわけではないのだ。であれば、全てを伝える必要など無いではないか。

人間と言うのは「信じる」という行為を取ってくれる。ある一定以上、相手が正しいことを理解したら、「前提と結論との結びつきがまったく理解できないにもかかわらず」その結論が正しい、としてくれるのだ。

このような場合、大事なのは 1から100まで全てを伝えることではない。乱暴かもしれないが、
  • まず、相手に自分がいう事を信じるように仕向けること
  • 次に必要最小限の前提と結論を覚えてもらうこと
  • 運がよければ、その中のいくつかについては理由も理解してもらうこと
程度を目標にするので構わないのだ。


判ると思うが、「最小限度」というこの条件を満たすためには MECE の考え方は役に立つ。重複があると、情報量としてのエントロピーは増えないのに送受信しなくてはいけないビット数は増えてしまうのだ。人間は「飽きる」し「疲れる」ので、余計な1ビットがあるとそれだけで受信ミスを起こしたり、受信拒否を起こす確率が跳ね上がってしまう。

もう一つ大事なのは、文法上の間違いやあいまいさを排除する事だ。最後まで読めば意味が一意に決定するが、途中では何通りも解釈がありえる、なんてのもダメだ。読むほうにすれば、1つの文章を読んでいるだけで何通り分もの脳みそを使えと言われたことになる。見る見るうちに疲れ果て、読む気を失うのが先か、読み間違えるのが先か…いずれにせよ、あなたの目的は果たせないだろう。

このように、ちゃんと受信してもらえるようにすること、Transfer が人間の場合重要なキーポイントになる。




このように、相手によって、何をどのように伝えるべきなのかは変わる。

これは「伝える」事そのものが目的なのではなく、

お客様に満足いただくために
情報を伝えている

からだ。

お客様に満足いただくために、計算機に正しく動いて欲しいから、正確に、厳密に、漏れなく、重複無く、計算機にやるべきことを伝えなくてはいけない。
お客様に満足いただくために、お客様が理解しなくてはいけないことを、お客様が受け付けてくれる形で伝えなくてはいけない(あるいは、お客様以外の人であっても同じだが)。


私の場合、多くの新人は理系の学部を出ている。そのためか「日本語の文章が不自由」な人が多い。この blog にも誤字脱字、文法の間違いは多いが、この何万倍も酷い間違いをして、なおかつどこが間違っているのか判らない、と言う人が多くやってくる。

この場合、Technology は問題ない。また、計算機への Translate も問題ない。しかし、人間への Transfer に問題があるわけだ。

可哀想だが、やることは一つ。作文の特訓である。
だいたい2年ぐらいかけると、誰でもわかりやすい文章を書けるようになる。そして、そうなると、その新人の評価はぐっと高まる。
T x T

の左の T は最初から高い数値だったのに、右の T の値が低かったため、計算結果が小さな値になっていたのに過ぎないからだ。ちゃんと他の人に伝える能力がつけば、評価は高くなって当然である。



新人の間はこれでほとんど問題は無い。しかしたまに、転職組などで問題が出るケースがある。それが第3番目の項目、F がきちんと出来ていない場合だ。新人の場合は仕事の範囲が狭いため、Focus がぶれることは無い。しかし、転職組の場合はもう少し幅広いレンジを相手にすることが求められる。すると Focus の問題が発生するのだ。従って、新人の段階から Focus についても説明することにしている。ただし、彼らがそれについて実感するのは3年目以降になるだろうが…

というわけで、次回は Focus について説明しよう…。

2007年9月9日

新社会人にあなたならまず何を教えるか? -3- CS: Technology

順番に行こう。

まずは最初のT、Technology = 技術だ。

大昔、各人、あるいは家族単位で必要なものを全て自己調達していた時代はあった。しかし、現代では全てのものを自己調達している人はほとんどいない。大抵の人は家を専門家である大工さんに作ってもらう。大工さんはトンカチや釘、木材を自分で作ったりはしない。これらを作るのは別の職人さんだ。

このように現代の職業は分業で成り立っている。分業することで、各自自分が専門とするものに集中でき、結果として社会全体がより高い品質の製品やサービスを手に入れられるようになった。この「分業」の単位になるものの一つが技術だ。

ここでいう技術は、単に何かを作る、というだけではない。もちろん、作るにしたって製鉄から、板金から、プログラムから…と色々あるわけだが、他にも魚を捕まえる技術、植物を育てる技術なども考えられる。レストランに行った場合、客の後ろから食器を並べるのだって技術だ。


基本的に私自身はコンピューターのソフトウェアを作るのが本業になるので、その系統の技術レベルは高い。当然教育する相手に最初に伝えるのもそのような技術になる。しかし、大抵の人はそれ以外の特技なり何なりを持っている。それらも含めての技術、と言う事になる。

私の職能上、後輩がこのエリアに問題がある事はほとんど無い。大学などでそこそこ学習してきているからだ。逆に言うと、ここに問題がある場合は、学校と同じように教育するしかない。ただし、社会人になっているので「スパルタ」方式を使うが。


一つ重要なポイントがある。たとえばプログラムを作る場合、「C言語を理解できる」とか「アセンブラが読める」などの特性は、実は Technologyには含めない。それは Transfer/Translate のTの方に属する。プログラムの場合はその数学的な構造が理解できるとか、構造を作り上げることが出来る、と言ったものが技術であって、C言語は文字通り「言語」に属する特性なのだ。


この技術というものは純粋化していくと、数学に帰着する。釘の打ち方、鍋の振り方でさえ、数学に帰着するのだ。大抵の人は「帰着するまで深く考え抜かない」だけであって、そこに数学が無いわけではない。

このため、世の中の様々なことを適切な数学モデルに翻訳できた場合、応用性が非常に高い。ジェネラリストを育てたかったらまずスペシャリストになれ、最初にジェネラリストを目指そうとすると、太鼓もち以上にならない、というのはこれゆえである。

2007年9月8日

新社会人にあなたならまず何を教えるか? -2- CS

会社に勤めている場合、最も重要なのはお給料である。

そもそも、給料をもらわなくても生きていけるのであれば、仕事なんぞする必要は無い。好きなことをして生きていればいいのである。

しかし、それでは実は生活が成り立たない。だから仕事をするわけだ。学生までの時代と社会人との最大の違いは、「生活が成り立たない」経済状態に対し他者が支えてくれるかどうかだ、と言う事も出来る。


さて、そのお給料だが、一体誰が払ってくれているのだろうか?

あなたの会社の社長だろうか? それともアナタの上司?
営業マン?
研究員のような非営利部門の場合、営利部門である開発部隊とかだろうか?

全部間違いだ。あなたのお給料になるお金を払ってくれているのは、

あなたの会社にお金を払ってくれているお客様だ。


さて、次の問題。

お客様に何か物を売って、利益を得たとする。その利益の中からアナタの給料が払われるわけだが…そのお客様が
「もう二度と、あいつらから物を買うものか」
と思ったらどうなるだろう?


実は2つ問題が発生する。

1つ目の問題は「風評」というものだ。

あるお客様が「二度とあそこから買うものか」と思った場合、そのお客様は単にそう思うだけではなく、その事を周囲に伝えるはずなのだ。そういう話を聞いた周囲の人の何割かは
「じゃぁ、あそこから物を買おうかと思っていたが、止めようか」
という判断を下すだろう。

つまり一人のお客様が不満一杯な状態で契約を終了すると、何人かの潜在的なお客様を失っている事に等しい状態が生まれるのだ。当然、そうなればあなたの給料になるべきお金が会社に入らなくなってしまう。


2つ目の問題は「リピーター」という問題だ。

今、世界中で人口は 60億人しかいない。その20% 以上は一日の生活費が一人1円程度…というレベルにある。このような世界で、一度しか商売の相手になってくれない人ばかり増やせば、一人当たり1円づつ利益をあげられても、総額で60億円しか儲けられない。

一人1000円づつにして、その代わり全人口の1割を相手にするとしても、6000億円で止まってしまうのだ。平均年俸が600万円の社員を抱えている場合、10万回しか給料は払えない。1万人を雇って10ヶ月で破綻するのか、1000人で8年ぐらい持たせるのかはともかく、その程度しか稼げないのである。

これは金額がいくらであっても同じだ。有限の人口を相手に、一人当たり有限回数しか商売しないとするならば、あなたの会社の収益の上限はたかが知れてしまうのだ。この限界を打破するには、おなじお客様から何度も利益を戴くしかない。


以上2つの点から、売買でもサービス契約でもいいから、商売をした場合、お客様に
「あぁ、この人達から物を買ってよかった」
と満足してもらわなくてはいけない。そうして
「もう一度、この人達から物を買ってもいいかな」
と思ってもらわなくてはいけない。

このお客様に満足してもらうこと。これが顧客満足… Customer Satisfaction というものだ。


あなたが会社で仕事をしているのは、お給料をもらうためであり、そのお給料はお客様が払うお金から出来ている。もし、あなたが給料を払い続けて欲しいと考えているなら、お客様に「お金を払い続けたい」と思わせなくてはいけない。

社長でも、上司でも、営業でも、営利部隊でもない。
お金を払ってくれるお客様の満足 につながるような内容を仕事としなくてはいけない。
極端に言えば、社長や上司や営業の意向なんぞどうでもよいのだ。


顧客満足の向上には何をすればいいのか、顧客満足ってどうやって測ればいいのか、などなどこのテーマは結構深いのだが、新入社員にそんなことを言って混乱させてもしょうがない。ので、私は

CS = T × T × F


を説明している。なお、最後のFはここ数年で、重要だと思うようになった。

さて、それぞれ何の略かと言うと:


最初のTTechnology つまり 「技術力」
次のTTransfer/Translate つまり 「伝える力」
FFocus 「焦点」


2つの T は0.0 ~ 1.0 の間の値を、最後の F は -1.0 ~ 1.0 の値を取る。掛け算の結果が顧客満足度というもので -1.0 から 1.0 の間の値を取る。満足度は 0.0 が「まったく満足していない(無価値と評価される)」、1.0が「完璧な満足」と定義する。-1.0 は「ふざけるなこの野郎」で、「損害を与えた」と思われている、という状態を意味する。

この3つを正しく理解し、正しく実行しないと、わけのわからないことをやることになってしまう。

というわけで、次はこの3つについての説明だ…。

2007年8月31日

新社会人にあなたならまず何を教えるか? -1- CS と AT

数日前、会社で "mentee training" という謎のトレーニングがあった。 mentor training ではなく
mentor から指導を受ける mentee
のトレーニングだ。

mentor が本来きちんとなすべきことを mentee 側が意識して mentor を誘導する必要がある段階で、もはや mentor : mentee の立場が逆転しているも同然なのだが…それはともかく。


このときふと、

私が新社会人のトレーニングを受け持ったら、最低限何を教えるだろうか?

というテーマでここに書いていない、という事に気が付いた。また、これらをきちんと理解している人が、今の会社にも少ない…身分上の上から下まで、ことごとく少ないうえに、年齢を食っている人の中にも理解していないものがかなりいる。

HR の TかSがさんにはその場で話したはものの、TかSがさんの反応も鈍い…
これはいけない。というわけで、書く事にした。


私の場合、一貫して2つのことだけ意識する事を伝えようとしている。細かい社則はマネージャーの方が詳しいし、人には得手・不得手があるので、私と資質がある程度合致していないと私のやり方はきっと参考にならないからだ。


普段、私はこの「2つの事」を CS と AT と略している。

CS: Customer Satisfaction
AT: Automation

の事だ。



で、実はなぜこの2つが大事で、この2つだけは最低限理解して欲しいことで、他は「個性」で済ませてしまうぐらいどうでもよいことなのか、それを理解してもらうのが実は本質だったりするのだが…という所で、次回に続く。

2007年8月17日

雨が降るーー

うれしい。

やっと雨が降ってくれた。
外気温がものすさまじい勢いで下がり、降雨前32度あったのが先ほどの車の温度計では26度に下がっている。

今日は軽度の熱中症で調子を崩していただけに、ハッピーハッピー。

あとはこの涼しさを利用して大爆睡すれば健康状態は回復だっ!

2007年7月24日

「考え方」と「インターネットの実装のされ方」: その3

「あなーたをー、感じてーいーたーいー」

しまった、これは坂井泉水さんの歌だったのか…。どうやら森高千里とZARDが一部混ざっているらしい…。



まずはこれを書いている段階で、もらった答を一つ紹介しましょう。
匿名 さんは書きました...

問3の答え:
小学校時代に読んだ本の中に書かれていたガウスの逸話を思い出して、そこに書かれていた解法をなぞりました。
「なぜ思い出したか」に対しては「1から100までの数」「合計」という語から私の脳において連想記憶が働いたのだと思います。

ふむ、微妙な答ですね。

入力を「1から100までの数」と「合計」を入れると、black box があってそれが「連想記憶」というシステムで解き方を引き出してくれたわけですか。

この答には4つのさらなる質問が発生します。

1) その「連想記憶」という black box はどういう実装になっているのでしょうか?

2) その「連想記憶」というメカニズムを「使おう」という意思判断はどのようにして実装されているのでしょう?

3) その検索されてきた「解き方」が正しい(つまり間違った答を引っ張ってきたのではない)
かどうかはどうやって判断したのでしょうか? また、計算結果はどのようにして検算したのでしょう?

4) そもそも、あなたの頭の中に「連想記憶」システムがあると言うことはどうやって検証したの?

意地悪? そうかもしれない。でも「考える」という動作を分解していくと必ずこうなります。


1つのブラックボックスは、かならず「入力」と「出力」を持ちます。ブラックボックスを分解しようとすると、2つ以上の「入力と出力を持つブラックボックス」の組み合わせが出てきます。しかし、「最小単位」が判らない限り、「ブラックボックス」はどこまでもブラックボックスに分解できてしまうという性質を持ちます。しかも、あるところにブラックボックスを想定すると、そのブラックボックスを使おうとしたメカニズムも必要になります。

「電子回路ならトランジスタに帰着するじゃないか」というのは原因と結果を取り違えています。「トランジスタに帰着する」のではなく、

「トランジスタを使って、論理回路の最小セットを作り上げ、
それで十分であることを数学的に証明した人がいる」

のです。その上で、論理回路の組み合わせを考えて、等価な出力を得るために必要なトランジスタ数を減らしていく、という努力(時には、トランジスタ数を増やして出力を得るまでの時間を短くする、という努力だったりもしますが)の結果が、今の電子回路なのに過ぎません。電子回路はあくまでも演繹によってもたらされたものであって、帰納的分解法の結果ではないのです。

ブラックボックスをトップダウンで分解していくと、Atomic 回路を定義しない限り、どこかで nand 回路になり、nand 回路は not 回路と and 回路になり、not 回路も and 回路も nand 回路で表現でき…と、どこまでも分解できます。意味の無い分解ではありますが、どこまでも分解できるのです。従って、ブラックボックスモデルは、回答へ導いてくれるわけではないのです。


きちんと証明できるわけではありませんが、思考というのは言葉で説明できる中間状態とその中間状態を繋ぐ、言葉で説明できないネットワークでできているのだ、と言うことができます。我々が共有できるのは 言葉で説明できる中間状態 だけであって、中間状態を繋ぐ言葉では説明できないネットワーク は説明もできなければ共有もできないのです。

「どうやってその結論に至ったのですか?」

という質問に対して、「中間状態の羅列」で答えてくる人しかいない事がこのモデルの一面の正しさを物語っています。


しかし、「考え方」というのは、実は 言葉で説明できる中間状態 のことではなく、ネットワークの方です。

中間状態 A から中間状態 B へと遷移するのと同じように、中間状態 A' から 中間状態 B' へと遷移することで結論Z'へと到着する、という考え方のパターンは「中間状態」で説明できるものではありません。逆にネットワーク的には中間状態 A → B → C →… →W→X→Y→Z という経由さえたどっていれば、各矢印の部分がどのように作られていようと「等価である」とする以外ありません。

しかし、それではたまに存在する天才がいきなり A → Z へとジャンプしてみせる場合の考え方を説明することはできません。この人が、BからYまでのどこを経由したのかすら、知ることはできないのです。


これは The Internet におけるパケットの伝達と似ています。IP パケットは発信源からスタートして、複数の router を経由して目的地に到着します。router がいくつあって、それぞれがどういう IP アドレスなのかは、traceroute などの技術を使うと追跡することが(ある程度は)可能です。

しかし、発信源から router、router から router、router から目的地へと、パケットがどのように伝達されるべきなのか、Internet は定義しません。Ethernet だろうが Token Ring だろうが、伝書鳩だろうが、何であっても構わないのです。まさに Internet は「network が存在する」事を大前提として、それらを繋ぐ方法を提供しているのであって、

networkを実装する方法

を提供しているのではありません。しかし、「このパケットはどうやってここからそちらに届くの?」という質問が本当に尋ねているのは、network の実装方法であって、Internet が network をどうやって繋いでいるのか、ではありません。それは似て非なる問題をミスリードして解いているのに過ぎない。


network が非現実的な性能しか出せないなら Internet に価値が無いのと同様、いくら中間状態を説明できても、その中間状態同士をどうやって繋ぐのか判らないのでは、「考え方」は学習できません。いくら中間状態を教えても、それだけでだと

運よく中間状態同士を繋げた人だけ

しか考え方は判らないのです。その意味において、考え方は「見せる」ことはできません。


いや、それだけではありません。中間状態同士の接続が正しいかどうか検証できないのですから、「実行してみることなしに」検証することもできません。しかも実行してみるとなると、turing の定理が悪さをします。そう「正しさ」を検証するすべは無く、運が良くても「あなたは間違っている」事が判る程度なのです。今回、こんなに長い時間が経由してから「あなたを感じていたい」は 森高千里の歌ではない、という事を発見した私のように…

「考え方」と「インターネットの実装のされ方」: その2

いけない!
一月も更新をサボってしまった。

Ottawa Linux Symposium 2007 とか、帰ってきたらお客様の所での障害がえらいことになっているとか、いくつか要素が固まって、落ち着いて考える暇がなくなってた…というのはいいわけだな。

さて、話を1ヶ月前に戻して。

ちょっとした例を考えよう。

「1から100までの数を全部足した合計を求めなさい」

という問題があったとする。これを解いて欲しい。

一応答を先に行っておくと 答は 5050 なのだが、重要なのは 5050 という数字ではない。
どうやってその 5050 という答にたどり着いたのか、だ。


まずもって、1+2+3+4+....とやった人はそんなに多くはいないだろう。いないだろうが、いるかもしれない。その人は次の質問に答えて欲しい:
問1) もっと早く解く方法があったかもしれないのに、真面目に 1から 100までを足すことに腐心した理由は何?
多くの人は 『1から nまでの和は n*(n+1)/2 で求められる』という公式を使ったと思う。確か中学ぐらいで教わったはずだ。その人は次の質問に答えて欲しい:
問2) その中学のときに教わった公式は、どうやって思い出しましたか?
少なくともこの問題を読むまではこの公式を思い出してなどいなかったはずです。と言うことはこの問題を読んでから、何らかの思考が働いて、この公式を思い出したわけですよね?その思考パスを説明しなさい、という意味です。
中には「一から n*(n+1)/2 の公式を求めた」あるいは、「1+2+3+4+ ....+100 という式と、100+99+98+....+1 という式を縦に並べて、両方足すと 101 が 100個になる。2回同じ式を足しているから2で割った」というやり方をしている人がいるかもしれません。多分、このパターンが一番頭がいいんでしょうが、そういう人は多分この質問の答が難しいことも知っていると思います:
問3) 問題を読んでから、あなたがそのやり方に到着するまでの思考を他人が判るように説明しなさい。

問1から問3までは全て、同じ事を聞いています。
あなたの頭はどのように動作しているのですか? というのが問いです。

もし、この問いの真の答を世の中の平均より少し優れた人から聞くことができたら、それだけで世界中の人々の知性は少しだけ向上するはずです。最高の天才から答が得られたら、世界中の人々の知性は相当に向上するでしょう。芸術家からこの答が得られたなら、芸術のバリエーションは一気に広がるに違いありません。

いや、もっと身近な例でも。親が子供に「ものの考え方」を直接伝達できたなら、子供は学習にかかる手間を相当省けるでしょうし、子供の学力の最低ラインは親によって保証されている、と考えてもいいでしょう。

しかし、実際にはこのようなことは一度も起こっていません。
「考え方」の本質を教わって全人類のレベルが一斉にあがったことなど過去に一度もありません。
天才によるそのような貢献もありません。
芸術家は、自分がどうしてその芸術作品に行き着いたのか、ろくに説明できたためしがありません。

そして、どんな人間も生まれてからこの方、1から物事を学習し、考え方も自分で開発する必要があったために、「鳶が鷹を産む」のの何倍もの確率で 鷹が鳶を生む という状態に陥っています。


そして何よりも悲惨なことに、「考え方」を表現する方法が無いこと自体を理解しない「考え」の持ち主を生み出してしまいます。


さ、真の謎は2つです。

1) 考え方を表現できないのはなぜか?
当然理由があるはずです。

2) 考え方を伝えられないのはなぜか?
プラナリアのような下等生物は、ぶった切ってもそれぞれが個体になって
生き続けることができますが、その際に切る前の個体が持っていた記憶をある程度
継承するそうです。

また、プラナリアに「光と電撃」を条件反射として学習させた後、そのプラナリアをぶつ切りにして
別のプラナリアに食べさせると、「学習したプラナリアを食べたプラナリア」も「光」に反応する…
つまり条件反射が「伝わる」そうです。

ということは、頭の中身を伝える、という機能は少なくともプロトタイプは存在していることに
なります。なぜ、進化の過程でそれが人間に継承されなかったのか? 何か都合が悪いのか?
それともその機能を持った生物が進化するにはもっと時間が必要なのか?
これも楽しそうなテーマです。

というのを楽しみに、問1-3の内、自分が該当するものを解いてみてください。

2007年6月19日

「考え方」と「インターネットの実装のされ方」: その1

6/10 から、マサチューセッツ州Hopkintonの周りに来ている。Training を受けるのが理由の一部、知り合いに会うのが理由の一部、OLS2007に参加するのが理由の一部だ。

で、最初の1週間は Training。タイトルは "IP Network Troubleshooting"。タイトルどおり、Internet を使ったネットワークにおける障害解析についての初歩入門コースだ。障害解析をするためには、当然

Internet ってどうやって機能しているの?

という点を教えなくてはいけない。ので、最初の3日ぐらいが学習、あとの2日が実習になっている。ISO/OSI モデルにマップした上で、下位4層… TCP port の辺りまでを主に説明するのだが、

滅茶苦茶楽しかった

いや、やっぱりこっちのプロの講師は本当に上手だわ。英語でガンガン説明されているはずなのに、全然辛くない。いや、その内容を全部知っていたのだから言語的に辛くないのは当然なのだが、逆に退屈することも無いのだ。話し方といい、例の出し方といい、自然に見えて実は結構研鑽を積んだ結果に違いない。



で、丁度夜が暇…というか腹が一杯で動けない状態に陥っているので、/.J の日記を見ていたのだが…まさか「考え方」ってどういうものなのか、知らない人がいるとは思わなかった。まさに

「は?」

と言う感じ。


びっくりしたときは blog のネタである。せっかくなので、習ったばかりのネットワークの話にマップして、「考え方」がなぜ説明できないのか、を説明してみよう。

今回のネタはさすがにすさまじく思いつきなので、上手くいかないかもしれないが、ま、とりあえずごろうじろ。

2007年6月12日

Content-addressable storage -6- CASをどこに使うのか?

さて、第3回の時に青の領域で使う技術として CAS が出てきている、と言う話を終わりのほうに書きました。それはどういう意味なのか?


青の領域はIOが少ない。中でも write はもう滅茶苦茶に少ない。と言うことは、ファイルの内容が変更される可能性はほとんどない、と言うことです。

このような状態のファイルを集めてきましょう。多分、あなたのPC上のファイルだって、1年ぐらい使い続けていればそのようなファイルが結構あるはずです。普段は使うわけではないのですが、HDD上に無いとそれはそれで困るようなファイル。生半可にHDDの肥やしとなっているようなファイル。それらのファイルを CAS に入れることを考えてみましょう。



まず、そのようなファイル、実はあちらこちらのディレクトリに同じファイルが複数あったりしませんか?ここでいう「同じ」というのは、中身がまったく同じと言うこと。なぜそのようなファイルに着目するかと言うと、CAS の場合中身がまったく同じファイルは同じファイルとして扱うことになるから。つまり、ディスクスペースがそれだけで何分の一かになるわけです。一種のデータ圧縮がかけられる。


次に、青の領域にいるファイルの定義からして、当然そうなわけですが滅多にアクセスされることは無いという特徴もあるはずです。と言うことは、IO速度は気にしなくていいから、遅いHDD上にCASを作ってそこに置けば、かなり「保存ビット単価」が下げられるはずです。たとえば 15,000rpmのHDDって滅茶苦茶早いですけれど、価格.com によると、73.4Gbyte で26,979円っていう値段だったりします。
367.5円/1Gbyte。SAS。

これが 5400rpm のHDDになると12388円で 500Gbyte…24.7円/1Gbyteにまで落ちてしまうわけです。SATA。値段は 1/15 です。滅多にアクセスが無いならこれでかまわない。壊れやすさとかは念頭におく必要がありますが、それでもRAID1で5重化するという、ウルトラリッチなモデルを作っても、ビット保存単価はまだ 1/3 です。5重化を全部遠隔地に分散させても痛くもかゆくも無い。だってアクセスしないんだもの。とは言え、これで本当に性能が足りるのか?

CASではファイルが上書きされることはありません。と言うことは、ファイルシステムに対するデフラグをかけると、ものすごく効果的である、と言うこと。しょっちゅう書き換えられるファイルを管理する NAS ではフラグメンテーションによる動作効率低下が結構問題になって、それを解決するために高速なHDDを使ったりするんですが、CASの場合はちゃんとデフラグすればその効果は一生もの。と言うことは、HDDの回転速度が遅くても、ファイルを読むために必要なヘッドシーク量が少なくできるCASの場合、実は性能劣化は通常のファイルシステムにおける15000rpm対5400rpm ほどは発生しないと言うことで…ただし、CAS用に使うファイルシステムが、ちゃんとしたデフラグ機能を持っている必要がありますけどね。

CASでもファイルシステムなので、管理情報は更新されていきます。これに対してファイル本体はほとんど更新されません。と言う事は、管理情報はHDDの高速な部分(外周部)に、データ本体は内周部に置くと効果があるわけで…。



CASはファイルシステムとしてはほとんど変わることがありません。と言うことは、ここにかんしてはデータを一度バックアップしたら、新規データが保存されるまで、バックアップは必要ない、と言うことです。また、そのバックアップも極力差分バックアップでよい。と言うのは、古いファイルを上書きすることが無いので、新しい更新は常に新しいファイルの発生を意味するからです。新しいファイルの発声しか存在しないなら、古いバックアップイメージ中に無駄なビットは存在していない、と言うこと。全体のバックアップを取り直しても意味はありません…。

CAS の部分は5重化してデータを持っていても大丈夫、と言いました。また、それらは遠隔地にあっても痛くは無い、と。また、前回、Lazy にファイルのレプリカを取るシステムの話をしました。どこかから、CASにファイルを移動する際に、CAS同士のレプリケーションが3重以上になったら「大本」を消す、というルールを適用できるような移行システムがあったら…多重化に必要な時間を大きく気にする必要はなくなります。「いっせーのーでー」という感じで同期しようとするからいけないんです。Lazyに、ずるずると多重化するなら、むしろ気楽になる。



どうでしょう? 何か見えてきましたか? そう、青の領域のファイルを意識し、CASというシステムを導入すると、従来サーバ用途としては使い物にならないとされてきたHDDや、HDDの内周部分などの使い道が出てくる、と言うことです。これらをCAS用に使い、従来の高性能な部分を赤や緑の領域用にと専門に割り振ることで、全体の性能を向上させつつ、ビット保存単価を下げることができるようになる、と言うことです。赤や緑の箇所が1年経っても2年経っても、システムの50%以上を占めているとするなら…もし、企業であれば何かおかしい、と考えたほうが良いでしょう。青い部分のファイルが勝手に消えている危険性があります。

実際、赤の領域は NetApp の Filer に、緑の部分は高性能な NAS に、青の部分は CAS に割り振り、ファイルをその間で自動的に移行させながら、データを管理するのが最も効率よくなるはずです。



別の考え方として、HDDをパーティションに分割するのをやめて、単一ファイルシステムで全てを管理させてしまう、という考え方もあります。赤、緑、青の各世代にあるファイルを、どのように管理するのか、その管理方法を世代ごとに変更する。赤はHDDの最外周の高速な所に、青はCAS 型管理にしてHDDの最内周の低速なところに集めた上で、デフラグをしっかりかけ、多重化して持っているデータは(unix file system における、ハードリンクの要領で)重複を消してしまう。



他にもこういう使い方が考えられますね。



CAS はファイルの変更が起こらない。と言うことは、内容をよく精査して、Indexing などをしっかり行えば、検索が速くできる。

検索…そう、Google が行っているサービスなんかも、実は CAS に対する検索の高速化、とみなすことができます。Web上にあるページのコピーをとる。このコピーは、Google に到着した後は変更されない。この段階で一種の CAS のように管理できるようになります。で、このCAS内のファイルに対する Indexing を行う。Google の場合、同一HDD上の多重化を消して、代わりに複数のサーバが互いに持っているイメージは互いが互いのレプリカとして考える事にすれば、バックアップはすでに取られている状態になる。

日付が変更されて、同じ内容のままなページは過去に行われた Indexing の結果を引っ張ってくれば終わり。新しく変更されたものだけ Indexing を行えばよい…。

こう考えると、Google のサーチエンジンは、CAS の考え方が背後に存在する、とみなすと、その多重化、高速性能、分散性などが一気に判り易くなります。あれは CAS 相手だからこそ、多重化できるし、複数に分散しているもの同士の「同一性」が判別できる。




Winny の話を前回しました。Winny を使ったことがある人なら判るでしょうが、Winny には「分割ダウンロード」の機能があります。つまり同じファイルイメージを複数のマシンが持っている場合、各サーバからはそれぞれが持っているファイルイメージの一部分だけを送ってもらい、手元で再結合して全体を再構成する機能があります。

これは CAS のように「同一の内容」を識別しているからこそできることですが、実はこれをやると、分散ファイルサーバにとって、とても効率の良い状態が発生します。

RAM が 1Gbyte しかないマシンが10台あるとしましょう。ダウンロードしたいファイルは 3Gbyte あります。このファイルを一度に4台のクライアントが欲しい、と言い出したとします。

従来の NAS などですと、4つのサーバがそれぞれのリクエストを担当します。各サーバには 1Gbyte しかメモリがありませんから、結局 HDD が 3Gbyte 読み出す速度でしか、クライアントに答えることはできません。

しかし、この分割方式ですと、10台のサーバがそれぞれ 300Mbyte を読み出し、それをキャッシュに貯め、4台のクライアントに向かって送信すればよいことになります。1台目のクライアントは HDD の速度でしか転送できませんが、残り3台は Cache に乗った状態の速度で転送できるようになる。

10台のサーバが、同期問題を抱えているのでは、このようなことはできません。むしろ、300Mbyte づつに分割したせいで、どこかのタイミングで「書き込み」リクエストが来た場合に、変更するべき部分を持っているのは誰? という疑問に答えるための準備をしつづける、というびくびくした状態で動作し続ける必要があります。CAS であれば、そのような心配は絶対ありません。



今までの話をまとめなおすとこうなります(一部、前回以前に出てきている話も含めてあります)。

  • 既存のNASサーバは、アクセス頻度を調べた上で、透過的に CAS 上に動かしたほうが良いファイルを CAS に動かすとよい。結果として高速アクセスが必要なファイルだけに、速度を稼ぐための投資を集中させることができ、システム全体のパフォーマンスが向上する。
  • ファイルシステムは、ファイルのライフサイクルを意識したファイル管理を行うようにするとよい。特にCAS化したものに対するデフラグと、重複の除去、それらを HDD などのメディアの低速域に押し込む、などという事を意識したつくりになっていると、まったく新しいアイディアを盛り込むことができる。
  • Winny は分散 CAS の一種である。というか、もっと分散 CAS としての性質を前面に押し出すと、その構造は「分散システム全体としての、ファイルシステムの IO 性能」向上のためのヒントが隠れている
  • Google の分散サーチエンジンシステムは、背後に CAS の考え方があるからこそ、あのすさまじい分散構造を作ることができる。
これら全てが、青の領域に CAS の考えを取り入れることによって発生しているわけです。


というわけで、おそらく、今後、CAS と言うものに対する「注目」はもっともっと必要になると思います。また、製品を作る際に CAS の考えを取り入れるのは重要になると思います。

そして最後に、EMC の CAS 製品にとって最大のライバルは、Winny と Google である、と言うことも判ったかと思います。

と言うわけで、(今回も)長くなりましたが、CAS に関する話、今回は以上とさせていただきます。

2007年6月2日

Content-addressable storage -5- CASの特徴

CAS は SAS や NAS に比べて何が特徴で、何がうれしいのさ??

ごもっともな質問でございます。それに答えるには、やはり SAS や NAS との比較が一番でしょう。


SAS の場合、セクター番号を指定するとセクターの中身を教えてくれます。セクター番号を指定して、データ列を指定すると、そのセクターが保持しているデータを書き換えることができます。

と言う事は、SAS にセクター番号を指定すると、何が返ってくるのかは判らない、ということです。まぁ、当たり前ですよね? SAS は「自分が格納したいデータを保存する場所」であり、その内容は日々更新できるからこそ意味がある。一度書いたら二度と変更できない HDD なんて…5年もしたら、使えるセクターがほとんど残らないじゃないですか。


NAS の場合も似ています。ファイル名を指定するとファイルの中身を教えてくれます。ファイル名を指定して、データ列を指定すると、そのファイルが保持しているデータを書き換えることができます。

このように、検索キーに対して出てくるデータの内容を変更できる事を更新可能性といいます。この更新可能性は、ごくごく当たり前の機能なんですが、システムの複製と保全 という観点からは実は非常に厄介な問題とペアになっています。この問題の名前を 同期問題 といいます。


コンピューターシステムに限らず、多くの高信頼システムは多重化というデザインによって高信頼性を確保しています。Storage ですと Raid なんかがそうですね。Raid 1 から 5 までのデザインは、すべて

データを複数の HDD で重複して持たせよう。
そうすればひとつひとつの HDD は簡単に壊れても、
Raid 全体が提供できる機能は HDD 単体よりもずっと長持ちする。
安物のHDDをたくさん使う事でコストを下げれば
トータルで見たコストも下がるに違いない

というコンセプトで成り立っています。どう重複させるか、そのやりようが違うだけです。


このコンセプト、確かに正しいんですが、一つ弱点があります。たとえば Raid 1 のミラーを考えてください。あるセクター番号 xxxx にデータを書き込むとします。

HDD単体にデータを書き込む場合は、文字通りその HDD のセクター番号 xxxx に対応するセクターにデータを書き込めば終わりです。

しかしミラーリングをしている場合、Raid が仮想的に見せているセクター番号 xxxx に対応するセクターは複数(HDD の数だけ)あるはずです。並列に書き込めるとはいえ、ミラーリングにおいては全部のセクターに書き込みが終わらない限り、セクターへの書き込みが終わったといってはならないはずです。

たとえば、ある HDD ではデータ更新が完了しており、別の HDD ではデータ更新が完了していない状態で、「データ更新が完了した側の HDD が壊れたら」 Raid 全体としてはデータ書き込みがまだ終わっていない状態のセクターしか残っていないことになってしまいます。ここで、さらに電源断のような障害が発生したら、そのデータは完全にロストしてしまうでしょう。OS などに「書き込み終わったよ」と報告しておきながら、データがなくなってしまうのは許される状態ではありません。そのような Storage は信頼できないからです。

すべての HDD が所定のセクターへの書き込みが終わるまで待つ、というこのような動作を同期といいます。同期を必要とするシステムは全て、一番遅い奴に足を引っ張られるという特徴があります。結果として、平均IO速度は通常の HDD よりもどうしても遅くなってしまいます。


この問題は、SAS やNAS 一般に議論を拡張しても同じでして、データを保護する、となると2つ以上の Storage にデータを書くことになります。それぞれの Storage が『書き込み完了』と報告してくるはずですが、その報告が全てそろってからでないと、SAS として、あるいは NAS として、書き込みが完了したことにしてはいけないわけです。

天災などを回避するために、多重化した Storage のいくつかが、遠隔地に存在する場合、遠隔地との通信による遅延も発生します。一般に10m以内の計算機同士で通信するより、100km離れた場所にある計算機との通信のほうが遅くて、時間がかかるものです。

遠隔地での書き込みを待たずに処理を行う方法もあります。この場合、遠隔地にある Storage には最新のデータはおいてありません。何らかの理由で遠隔地の Storage を使う必要が出た場合、最新の更新データは一部失われることになります。どれぐらい失われるのか、というのは通信回線やシステムデザインとのご相談になりますし、それを許容できるかどうかはアプリケーションならびに計算機全体が提供するサービスの要求仕様に依存します。一般に距離の3乗に比例してコストは跳ね上がっていく、といわれます。

この同期問題を考えないで、SAS や NAS の複製を作りますと、検索するたびにあっちのマシンやこっちのマシンから別々なデータイメージが飛んできます。あるものは ver 2.0, べつのものは ver 6.2…ちゃんとバージョン管理されていてその情報も飛んでくるならいいほうです。いつのバージョンだか判らないものが飛んできた日には…もうどれを信頼すればいいのか、client からはさっぱり。

かといって、これらを信頼できるようにすると…今度はめちゃくちゃ遅いシステムになってしまう…そういうジレンマがあります。


さて、これに対して。CAS の場合はどうでしょう?

CAS の場合、ファイルの内容でファイルの本体を検索します。特にファイル内容の完全一致に対応するのが絶対条件。となりますと、面白い性質が出てきます。

CAS にはファイルを作る・消すという操作はありえても、更新可能性は無いんですよ。ファイルの内容を変更すると、それは別のファイルにせざるを得ない。なぜなら「変更前」のファイルを検索するために使える検索キーと、「変更後」のファイルを検索するために使える検索キーは違うから。検索キーが違っちゃうって事は、前の検索キーで更新後のファイルは探せないって事で…。

これを、CAS は WORM (Write Once Read Many) の性質がある、と表現します。
別の言い方をしましょう。 CAS に乗っているファイルは、全て ver 1.0 しか存在しない んです。


この性質は多重化された Storage の同期問題に画期的な解決策をもたらします。

話を簡単にするために、一番最初は手元の CAS Storage にしかコピーをおかないことを考えましょう。で、CAS システムは自動的に、かつダラダラと暇なときに、こいつのコピーをレプリカサーバーにコピーしていくとします。

あるとき、このファイルに対する検索をかけたとします。まぁ、もちろん手元の Storage が答えてくれてもいいんですが、たまたまこいつが手一杯だったとします。で、遠隔地のサーバーが答えた。「あるよ」って。

NAS や SAS の場合、
「それは本当に最新のもんですかぃ?」
と疑わなくちゃいけないんですが、CAS の場合この心配をしなくていい。

- ファイルの内容が変更できないから -

あるといわれたら、ある。ないといわれたら、ない。

したがって、CASの場合
  • 取り合えず一番手近な Storage に書き込んでおく(この段階ではまだ信頼性は低い。データを失う可能性がある)。
  • で、徐々にコピーを別の CAS にも分散させていく(時間が経つに従って信頼性があがっていく)
などという、こジャレたシステムの作り方ができる。


もし、ファイル共有ソフト…えー Bit Torrelant でも Winny でもいいんですが、使ったことが一度でもある人なら判るでしょう。この挙動、ファイル共有ソフトのそれと同じだ、という事がわかると思います。

これらのソフトにおいて、ファイルの「ファイル名」ってのはあまり意味を持ちません。同じファイル名の、ファイルサイズだの ID だのが違う代物がいっぱい出回っています。

でも、同じ ID のものは1種類しかない。最初誰かがこのファイルを ファイル共有のネットワークに登録したときに、割り振った ID があって、多分それはファイルのバイト列からhash値を作ってそれをベースに作っている。

ファイル共有ソフトはこのファイルのレプリカを周囲の PC に作っていく。自動的に、だらだらと。

で、どこかのPCがそのコピーが欲しい、と言ったら誰が持っているのか教えてくれるけれど、IDが中身から作られているから、IDが一致していれば中身は絶対一致していると考えていい。だから、いちいち中央サーバーなんか作らなくても P2P でファイルをダウンロードするので間に合う。

最初のうちは、コピーは1箇所ぐらいにしかないからそのPCが止まっている間は欲しいデータは入手できない。でも徐々にコピーが広まるに従って Servicability が向上して、いつでも手に入るようになる。また手近なマシンから手に入るようになるので、徐々にダウンロード速度もあがっていく。


CAS ってのは、このようなファイル共有ソフトのP2P通信の部分を取り除いたようなものだ、と表現することができます。


で、その CAS がファイルの一生とどう関わるのか? それは、刮目して待て、次号!!
#誰が少年探偵団だ。

2007年5月29日

Content-addressable storage -4- CASの定義

枕を話し始めたら興が乗ってしまって、いつまでも本ネタに入れなくなった落語家のような状態ではあるが、ようやっと本題だ。というわけで CAS。

CAS の定義はその名前そのもの「Content」で「addressable」な「Storage」のことだ。
……ぜんぜんわからねぇ…… orz

というわけで、比較のために、もう2つ単語を定義する。SASとNASだ。

SAS: Sector Addressable Storage
NAS: Name Addressable Storage

先に断っておくと、SAS も NAS もここで定義しているようなものは、この場限りの定義だから。EMC用語でもないし、IBM用語にも無い。世の中一般にもこんな風には言わない。なので、SASとかNASをこれから定義する意味で使って、意図が通じなくても文句は言わないように。


あ、そうか。用語の定義から。

Storage:
これは判ると思っていいよね? HDDとかフラッシュROMとか…とにかく、「外部からの電力供給を断っても、(しばらくの間)データを保持してくれる外部デバイス」のこと。外部というからには内部があるわけで、それはメモリとかCPUとかの事を言う。
深く突っ込まないが、この辺も歴史的な背景があってこういう名前になっているものなので、あまりこだわらないように。

Addressable:
うーん。アドレス指定できるとかそういう意味になるのだが、この場合は「検索できる」とか「見つけられる」という風に捕らえるとよいかと。つまり
「この条件のものがほしいんですが?」
と言うと
「ほぃ、これね?」
と出してくれるもの。できれば O(1) …つまり常に一定時間で。ただし、最近はO(1)はだんだん難しくなっているらしくて、O(log n)とかでも許しちゃうけど。




で、まずはSAS。これは「セクターを指定すると、そのセクターに存在するデータを返してくれる」Storage。HDDとかがそうだ、といえば判りやすかろう。

昔は シリンダーだの、プラッターだのを指定した上での「このトラック上の何番目のセクター」とか言っていたが、最近はもう ATA だと48bit, SCSI だと 64bit のアドレス空間を目いっぱい使って、
「全体を通じて xxxx 番目のセクターを頂戴」
と言うと、1セクター分のデータをくれる。


実は、あなたの HDD の中にあるセクター数は、あなたが使えるセクター数よりも多い。あるセクターが調子が悪くなった場合、HDDは勝手に代替セクターというものにデータを移し変えてくれたりするのだが、この「代替セクター」は全体の 1/4 も用意してあったりする。勝手に移し変えられるのは、ユーザーから見ると、前に使っていたセクターも代替セクターも同じ「xxxx番目のセクター」でアクセスできるからだ。

だから、「xxxx番目のセクター」と言っても、使いはじめと、5年ぐらいたってからでは、物理的なセクターの位置は違っている可能性がある。と言う事は、実は「xxxx番目のセクター」とあなたが言ったとき、HDDは内部で
「はて、こいつが言う xxxx 番目のセクターって本当はどこ?」
という検索を行っているのだ。逆に言えば、ちゃんと検索して正しい答えを返してくれさえすれば、もう内部構造なんてどうなっていても良い。垂直磁気だろうが、小人さんがいようがかまわないのだ。そう。xxxx というセクター番号は仮想的な番号なんである。

SANはこの「セクター番号なんて仮想的なものだ」に「物理的なHDDだって仮想的ジャン」という考えをつないで、さらに「ネットワークでつなげば仮想かどうかはばれないよね」という考えにいたった SAS の最終進化系だ、と言うこともできる。



NAS: Name Addressable Storage。そう。名前を指定すると内容を教えてくれる Storage。

ようするに Network Attached Storage、通常言うところの NAS と同じ。ファイル名というか、パス名を与えると、
「あぁ、そのファイルはこれでございますな」
と内容を教えてくれる(あるいは、「それはあなた様は触ってはいけないものでございます」と文句を言われるかもしれないが)。別の言い方をすると、パス名をキーにファイル実体を検索してくれるわけだ。

ファイルシステムって全体的にそうだよね。ただ、「物理的な箱」という感じで言うと普通に言う NAS なんかがこれにあたる。もちろん、プロトコルはいっぱいあって NFSv2,v3,v4, SMB, CIFS なんかのほかに AFS, DFS, などなど。NFSv2,v3 や SMB, CIFS は NAS としては結構初歩的な機能しかなかったりするので、これがはやる理由が良く判らない(SIer が不勉強であるっていう場合以外は)。

まぁ、とにかく。これは多分一番判りやすいと思う。



で、これで考えると CAS ってのは
「すみません。『hogehoge. Ahage,ufuu … Heppero-pon』という内容のファイルがほしいんですが」
と言うと
「あぁ、ありますよ。これですね。中身は『hogehoge. Ahage,ufuu … Heppero-pon』です」
と言ってくるという…そういう Storage。ファイルの中身をキーにファイルを検索するわけだ。

え? ファイルを指定するのに中身を指定しなくちゃいけないなんて、間抜けだ?! まずもって、その感想は正しい。でも、こういう場合を考えてごらん。

a) 「すみません。ファイルの中身のハッシュ値が 58200g8d7sd.....Z なファイルがほしいんですが」
「あぁ、ありますよ。中身は『hogehoge. Ahage,ufuu … Heppero-pon』です」

b)「すみません。ファイルの中に Ahage という文字列があるファイルがほしいんですが」
「あぁ、ありますよ。中身は『hogehoge. Ahage,ufuu … Heppero-pon』です」

c) 「すみません。ファイルの中身が MS-Word のフォーマットになっているファイルがほしいんですが」
「えーーー、それは無いですね、今は」

c は unix でいう find コマンドと、file コマンドの組み合わせみたいな感じだよね。

b は自分のマシンだけだと grep とか、google desktop とかで、インターネット全体になると検索エンジンそのものだ。

a … a の例ねぇ。ファイルを指定するのに中身のハッシュ値を使う、有名なものとなると… Winny!! そう、Winny の ID ってのはようするにそういうものですな。こう考えると、Winny ってのも CAS の一種です。


このように「ファイルの中身」から「ファイル」を指定するものを一般に CAS と言います。



で、ここからが問題。CAS の何がそんなにいいのさ? …これが次回のテーマになります。
ヒントは Winny。