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つに分割するわけだ。それぞれがどのような性質を持っているのか…それを次回のテーマにしよう。