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

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。

Content-addressable storage -3- 続々・ファイルの一生

というわけで、前回の続き。ILM(Information Lifecycle Management: ジョージ・ルーカスの有名なCGエフェクト集団ではない)ってのが提唱しているファイルのライフサイクルの話。こっちのほうが正しい、と言う話。ちなみに、私自身は ILM の考えは正しいと思うが、ILMという名前はいただけないと思う。FLMだろ、これ。

さて、ILMではファイルの一生を3つに区分けする。

1つ目は赤の領域で、write 優勢。これは前回と同じなので詳しく説明しない。

もんだいは2つ目と3つ目、緑と青の領域だ。これはどちらも read 優勢であることに変わりは無い。
違うのは、ファイルに対する参照頻度。緑は参照頻度が高いが、青は参照頻度が低い。

緑はいっぱい参照されている。ファイルはいっぱい読み出される。もしかするとコピーもいっぱい取られているかもしれない。そのコピーはコピー先で変更されているかもしれない。とにかく読み込み専用ではあっても活発なのだ。

これに対して青は、参照もされない。まったくされないわけではないが、そんなに頻度は高くない。こう…引退して、縁側で渋茶すすっている爺さんって感じ?取り合えず青で表現しているけど気分的には、ロマンスグレー。


このようにファイルの一生を分割すると、図にもう描いてあるように、赤と緑の領域は高速なIOが可能な高性能HDDや、HDDの中でも外周部と呼ばれる読み込みが早い領域に置くのが正しく、青の奴はゆっくりな低性能HDDや、同じHDDの中でも内周部で十分、必要ならばデータ圧縮をかけてさらに小さくしてやれ、という態度でかまわないことが判る。計算機のリソースは高性能なものと低性能なものではやはり値段に差があるのだから、高いものはよくアクセスするファイルに割り当て、安いものはめったにアクセスしないものに割り当てるのが正しい。

「アクセス頻度」を念頭に置くことで平均的なビットの保存単価を下げる事に頭が行っていれば。たとえトップスピードが低くてもいくらでも市場はあったのに orz これは明らかに私が馬鹿だった証拠だ。


ちなみに、このような分類だと、赤い所はやはり NetApp が強い。
緑の所はデフラグ機能がしっかりしている NAS 製品であれば、きっと大抵のものが良いスコアを出す。
そして青の所は、値段とメンテナンサビリティのバランスが取れた製品を使うことができるはずだ。
あとは、ファイルのライフサイクルにあわせて、
赤のマシン → 緑のマシン → 青のマシン
と、ファイルをユーザーから見て透過的になるように移動する機能があればよい。

そう、IBMの時に思いつくべきは「NetApp以上の性能を出せるマシンを作る」事ではなく、NetAppを赤の領域用管理システムとして配下に置く システムだったのだ。

...........................

まぁ、過去に対する反省はこれぐらいにするとして。問題は青の領域。

なにぶん、私も思いつかなかったのだが、他の人も大抵思いついていなかったらしく、この青の領域で何ができるのか、実はあまり製品研究は始まったばかり。そして、その過程でいくつもの
「昔聞いたときは何じゃそりゃだった代物」
が脚光を浴び始めている。

CAS もその一つだ。

というわけで、第4回目にして始めて! 本題に入れるようになった。

Content-addressable storage -2- 続・ファイルの一生

さて、私が考えたのは次のようなものだ。ファイルの一生を大きく2つに分ける。1つは書き込みが結構存在する時代、そしてもう一つは書き込みがほとんど無い時代だ。


赤の領域は書き込み頻度が極めて高い。ここで要求されるのは「書き込み速度の速さ」だ。しかし、これは言うほど簡単ではない。特に NAS のように複数のクライアントから同時に書き込みや読み込み要求が飛んでくる場合は、きわめて難しい。

HDDが、書き込み要求に高速に対応するには、連続した領域に、書けといわれたデータを到着した順に書くのが最も効率が良くなる。というのは、HDDはいったんヘッドの位置を決めてしまえば、そのトラックに対する読み書きの速度は完全に一定になるからだ。つまり、ヘッドがまったく動かない状態が最も高速な書き込み速度で、ヘッドシーク時間が無駄時間になる。書き込み要求を高速にこなす、とはつまり書き込みに際してヘッドシーク時間の割合を減らす、ということに他ならない。と言う事は「あるトラックにヘッドを移動したら最後、トラック一周が完了するまでヘッドを動かさなくて良い」場合が最高速度になる。HDDの「ヘッドシークなしの」書き込み速度は4Gbit/sec 近い速度を誇れるので、本当にそれだけの書き込み要求が1つのファイルについて、シーケンシャルに、存在できるならば最高だ。

しかし実際は、NASであれ、通常のアプリケーションであれ、このような大量のデータを、シーケンシャルに、書き込むよう要求することは、まれだ。実際には複数のクライアントやアプリケーションが、それぞれはちまちまとした分量の書き込みを要求することになる。必然的にファイルシステムに到着するデータは異なるファイルの異なる部位が到着することになる。これを「連続した書き込み」にするには、到着した順にHDDに書いて、なおかつそれを意味のあるものとできる必要がある。


このような性質を持つファイルシステムは存在する。Log Structured File System と言われるものがそうだ。ただし、これは定期的な Garbage Collection を必要とする。この弱点を補ったのが NetApp が彼らの Filer といわれる製品シリーズに利用している WAFL で、バッテリーバックアップの RAM Disk を中間バッファーとして利用し、これが抑えられる範疇でデフラグを施した上で、RAID に一気に書き込む、という事をやっている。


赤の領域の間は、あまり読み込み速度のことは気にしなくて良い。なぜなら、ここで何か読み込み速度のための改善を行っても、次の瞬間にはまた書き込みが発生して、せっかくの改善が水泡に帰すからだ。




緑の領域は書き込みがほとんど無い。つまり、書き込み性能はIO性能にほとんど影響を与えない。この場合、ファイルはデフラグされ、連続した領域に1つのファイル情報が集まっていることが望ましい。というのは、昨今のOSは十分なメモリ容量を背景に、大量の先行読み込みを行うからだ。

HDDのヘッドシークオーバーヘッドという観点からすれば、10kbyteを読むためにあるトラックにヘッドシークを行うのも、1Mbyteを読むためにあるトラックにヘッドシークを行うのもコストは変わらない。であれば、ファイルをなるべくヘッドシーク量が最小ですべて読める領域に配置し、OSの先行読み込み機構に期待すれば、無駄なヘッドシーク量は最小で済み、その分IO性能が上がって見える計算になる。



実はこのような状態には WAFL は非常に不利だ。WAFLは「RAM Disk 1block分」の範囲内ではデフラグを行う能力があるのだが、block 間デフラグをデフォルトでする能力は無い。非常に多くのクライアントがバラバラに、それぞれ複数のファイルの書き込み要求をしてしまうと、1つのファイルの情報が複数の block 間にまたがってしまう。赤の領域では無敵を誇る RAM Disk + バースト書き込み機構は、緑の領域では逆に不利になるわけだ。

で、IBMにいる間に私が提案したのは、

HDD自身にある程度のファイルシステムとしての機能を持たせる

というものだ。具体的には uFS などでいう、inode 管理はHDDが行う。

HDDは、赤の領域に属するファイルに関するものの場合、まるで Log Structured File System のようにプラッターに書き込む。つまり、書き込み順序は到着順序どおりとし、同じファイルのデータがなるべく集中するように、などということは考えない。

逆に緑の領域に属するファイルの場合は、なるべく同じファイルのデータが1箇所に集まるようにレイアウトを決める。

さらに、赤から緑に属性が変化するタイミングで、ディスクの異なる場所へと内容をコピーする。この際にデフラグを行う。また、IOが少なく、暇なタイミングを狙って、赤の領域、緑の領域とも、再デフラグを行う。特に赤の領域は、本当に使っている部分と使っていない部分がまだら模様になるはずなので、これを集約して使える連続領域を確保するのだ。計算機システムにおいてIOが少ないタイミングは2種類ある。1つはメイン計算機が「計算」に謀殺されているとき。もう一つは本当に暇なとき。従来は「本当に暇なとき」にしかデフラグできなかったが、HDDがファイルシステムとしての役割を果たし、ディスク上のレイアウトを決定できるように書き換えれば、通電しておきさえすれば勝手にデフラグし続けることができる。

おそらく、このような HDD 自身に対する大改造を行わない限り、NetApp Filer 以上の性能を出すシステムを開発するのはきわめて困難だろう、というのが私の結論だった。



さて、この結論から5年後。私はEMCに入って、自分が馬鹿だったことに気がつかされる。

EMCが提唱する ILM(Information Lifecycle Management) によるならば、ファイルの一生は次のように分類する。そして、私が考える限り、私が考えた赤緑の2フェーズよりも、この3フェーズモデルのほうが正しい。
というわけで、次回は、この3フェーズモデルについて説明しよう。

…おかしいな、CASに行く前の「前フリ」がこんなに長くなるとは思わなかったぞ?

Content-addressable storage -1- ファイルの一生

日本語版には存在しないが、英語版のWikiPedia の CAS の項には存在する。Content Addressable Storage、略してCAS。EMCの社員研修の一環として教わったことのうち、一般知識に属する項目と、その昔出したアイディア(ただし特許等を出願済なので公知)をちょっと並べてみよう。

昔々、IBMの基礎研究所にいた頃、Linuxを使ったあるプロジェクトが発生した。そのプロジェクト自体は巨万の金額をどぶに投げ捨て、人の話を聞かないリーダーによって大崩壊のうちに終わり、相応の数の首が飛び、それ以上に理不尽な数の人間が不当に低い評価を受け、結果として甚大な人材流出を引き起こしたのだが…まぁ、そのあたりはいいとしよう。


実はこのプロジェクトが終わった直後に、反省会というかなんと言うか、「ようやっと」本来プロジェクトを開始する前に調査するべき事を調べる時間ができたので、

1. そのプロジェクトがターゲットとしていて、 5% の性能も出せなかったライバル製品はどういうつくりになっていたのか、とか
2. そもそもこの問題の本質はどこにあったのか、とか

ま、そういう事を調べることになったわけだ。で、出てきた結論：

1. こんなん、勝てるわけねーべ(理由は後で述べる)
2. 問題の本質はファイルシステムへ向かってのIOアクセスパターンにあり

1 はまぁ、いいとしよう。


問題は2だ。ファイルシステムに対する要求が、ファイルの一生の間に変わっていく事がわかった。これを単一のファイルシステム、単一のサーバーで解決しようと言う点に問題があったのだ。
# もちろん、これは2002年の段階で報告書を出している。

あるファイルの一生と言うものを考えてみよう。どんなファイルでもいいのだが、ごく普通の…そうだな、大学か何かのレポートのテキストファイルを考えてみてほしい。

一番最初。ファイルは作られる。
まったく何もない所に、ファイル名が指定され、デフォルトの属性が与えられる。そして、最初の何バイトかが書き込まれる。そう。ファイルの一生は「書き込み」からはじまる。

しばらくの間、1回読み込むたびに数回の書き込みが行われる。ファイルエディターは一度読み込んだファイルを覚えておいて、セーブ要求があるたびにそれを書き出す。従って、最初のうち、IOの頻度は高く、かつ write/read 比率は 1.0 を超える。

徐々にファイルが完成に近づくに従って、write/read 比率は 1.0 に近づく。このファイルの内容に対する推敲が始まると、原著者だけでなく、推敲のために複数の人間が読み始めるからだ。書き込み頻度は徐々に低くなり、読み込み頻度が上がる。IO頻度全体はこの頃がピークになる。

ファイルがほとんど完成に近づくと、write/read 比率はどんどん 1.0 以下に落ちていく。同時に、読み込み頻度はさらに増えていく。完成版を大勢の人が参照し始めるからだ。

write/read 比率が 1.0 を大幅に下回るようになった頃…そう。0.01ぐらいを下回る頃、IO全体の量が急速に減り始める。情報は他の人達にもいきわたり、このファイルへの参照頻度自体が下がり始めるのだ。

やがて、write の頻度は限りなく0に近づき、read の頻度もかなり少なくなる。このファイルは利用されなくなりつつある。しかし、たまに。ごくまれに、まだ参照されることがある。ほとんど引退まじかといった感じ。

最後に、このファイルは誰からも参照されなくなる。永久にHDDの肥やしになるか、どこかでHDDが飛んでアクセスできなくなるか、「邪魔だっ」の一言と共に消されてしまうか、いずれになるのかはともかく、もう誰もreadもwriteもしなくなる…。ファイルの終焉である。

以上のお話を図にするとこんな感じ。
横軸が時間軸、縦軸がIO頻度。最初は write がドバーッときて、後追いで read がグググーッときて、write がシューンと落ちた後も read はずるずるずるーーーと引きずる…ただ全体的に徐々に落ちていくーー。頭の悪い表現の仕方をすると、こんな感じになる。


当時の解析では、この「あるファイルに対するIOパターン」は大雑把に2種類に分けていた。write/read 比率が 1.0 を超えている時期と、1.0を下回っている時期だ。

CASの世界では、このファイルに対するIOパターン、大雑把に3種類に分割している。なおかつそれぞれが別の性質を持っている、としている。write/read 比率が 1.0 を下回っている時期をさらに2つに分割するわけだ。それぞれがどのような性質を持っているのか…それを次回のテーマにしよう。