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

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

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

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

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

滅茶苦茶楽しかった

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



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

「は？」

と言う感じ。


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

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

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 に関する話、今回は以上とさせていただきます。

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 がファイルの一生とどう関わるのか? それは、刮目して待て、次号!!
#誰が少年探偵団だ。