ハードディスク、ストレージ、ファイルシステム、データ構造、それから『Googleを支える技術』

分かっているようでしっかり分かっていないことのおさらい。

https://youtu.be/KN8YgJnShPM

コンピュータは物理的に記録されているデータを、ファイルシステムという形で抽象化している。ぼくたちはファイルをドラッグして動かすみたいな操作をしているけど、それはこういう抽象化が積み重なってのことなんだね。

https://youtu.be/TQCr9RV7twk

こっちではメモリとストレージのデータ保存の性質における階層構造が学習できた。ストレージのハードウェアの変化もしていて使っているMacBookに載っているSSDについても理解が深まった。

このおさらいに行き着いたのはこの本を読んでいて、Google File Systemの説明のところで気になったから。

Googleを支える技術 ?巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)

この本は数年前に一度読んだんだけど、あのときは何も理解していなかったんだなといま感じられる。この本は論文を簡単な言葉で説明してくれているが、それでも今もまだ知識が追いついていない。しかもこの本は2008年刊行なので10年のブランクがあるみたいなんだな、ふうー。

Bjgtableは既存のデータベースでは扱えないほどの巨大なテーブルを作ることができる。そこに格納するデータ構造は開発者が自分で設計し、どのようにデータを分散させるかをコントロールできるようになっている。データ構造についてどのような設計を行うかは、プログラム（アルゴリズム）の効率に大きく影響する。Googleは速くて正確な検索を行えるようなデータ構造を採用したということ。データ構造に関してはこの動画でおさらいした。

Googleの分散ファイルシステムの整備がビジネス面で果たした役割については、当時開発メンバーだったMohit Aronのこの記事もとても参考になる。

Yahooの場合、NetAppシステムという形で必要とされるサーバー数の猛烈な速度での増大に対処しようとした。YahooのほとんどのサービスはNetAppストレージ・デバイス上で作動するようになり、同社のサーバーの設定と追加は非常に簡単になった。これによりYahooは需要に対応することに成功し、自身としてもNetAppデバイスの最大のユーザーとなった。

しかし（たまたま近所のマウンテンビューに本社を構えた） Googleは独自開発のソフトウェアをインフラとする戦略を採用した。これはその後GFS―Google File Systemとして知られるようになったが、専用ハードウェアではなく、あらゆるサービスに対応可能な汎用性の高いソフトウェアを中心としたエコシステムを構築しようというものだった

 そして彼はこういう教訓を伝えている。

往々にして「ゼロから考える」ことは目先の成長を犠牲にする場合がある。動きの速いシリコンバレー企業にとっては、その意味で「苦い薬」だが、長期的な持続可能性を考えたとき避けては通れない。即効性はあるもののその場限りの対応は結局のところ複雑性と処理コストを加速度的に増大させるというはるかに重大なリスクを持ち込むことを意味する。Googleはあらゆるウェブ・サービスに適用可能な柔軟性と単純性を目標としてGFSを開発した。それに対してYahooの複雑なインフラは、一時的に成功を収めたものの、長期的にはYahooのビジネスに今日見られるような限界を持ち込む原因となった。

人間は似たような過ちを繰り返しているのは、歴史の教科書が教えてくれる数少ない教訓の一つだと思う。

僕はまだこれに成功していると思う。パブリッシャーというものの機能や、コンテンツ製作をゼロから考え直してきた。目に見える成果がないときに、こういう方針は、人を説得しにくい。だから私はずっと1人でAxionというプロジェクトを進めてきているけど、条件が揃ってくれば有意な遠回りを評価できるメンバーが揃ってくるはずだ。

Googleのシステムは汎用性、スケーラビリティ確保しているが、ビジネス面に視点を変えてGoogleを眺めてみても、コンテクストは違えど汎用性とスケーラビリティという性質を持っており他を圧倒している。

第1章の検索の仕組み、第2章の大規模化も楽しく読んだ。Mapreduceについてはまだうまく飲み込めていない。学習することはまだまだたくさんあるんだね。