「実現したいことを計算機の問題に置き換えることが『技術力』」、伊藤CTOが“はてな流”大規模データ処理の極意を語る

関西オープンソースカンファレンス2008セッションレポート

　大阪南港ATCで開催された「関西オープンソース2008」の2日目（11月8日）午前中のセッションで、株式会社はてなCTOの伊藤直也氏が「はてな流大規模データ処理」と題した発表を行った。その模様をお伝えする。

　大阪南港ATCで開催された「関西オープンソース2008」の2日目（11月8日）午前中のセッションで、株式会社はてなCTOの伊藤直也氏が「はてな流大規模データ処理」と題した発表を行った。このカンファレンスの目玉企画であり、立ち見が出るほど盛況を博したこのセッションでは、大量のデータを扱うWebサービスがどのように設計・運用されているかについて、伊藤氏自身が開発に携わってきた「はてなブックマーク」を題材に、現実的な手法が語られた。

会場は立ち見が出るほどの盛況ぶりだった

大規模なデータとスケーリング

　はてなブックマークでは、GB単位の大量のデータを扱っている。

はてなブックマークのデータ規模。1ページあたり平均3人がブックマークしている計算になる（発表資料より作成）

	レコ―ド数	データサイズ
エントリー	1,073万	2.5GB
ブックマーク	3,134万	4GB
タグ	4,743万	3.4GB
全文検索用HTML	――	100GB超（zlibで圧縮した状態）

　大規模データのI/Oでは、メモリ（キャッシュ）とハードディスクの速度差を意識しなくてはならない。hdpermコマンドで計測すると、データの転送速度では、メモリはディスクの100倍以上高速。シークの差で言えばディスクがms単位、メモリがns単位で、その差は数十万倍にもなるという。つまり、メモリの中で処理ができなくなりディスクにデータを読みに行った時点で、負けなのだ。

メモリとディスクの速度差（※発表資料より）

% sudo /sbin/hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 15012 MB in 1.99 seconds ＝ 7525.03 MB/sec
Timing buffered disk reads: 176 MB in 3.02 seconds ＝ 58.37 MB/sec

　上がキャッシュリード（メモリにあるOSのページキャッシュからの読み込み）で、1秒に8GBくらいを読み込んでいる。下がディスクのシーケンシャルリードで、60～70MB/sの速度しか出ない。

　開発機で快適に動作しているサービスが、オープンした瞬間に何の変哲もないSQLが詰まって落ちることがある。これは、開発環境ではアクセスするデータがせいぜい決まってるので大抵キャッシュに乗っているが、本番環境に持っていくと、ユーザーがアクセスするデータの範囲が急に広くなるので、どうしてもディスクにデータを読みに行ってしまい、SQLが返ってこなくなるためだ。

　大規模データをI/Oするコツは、「いかにメモリだけで済ませるか」。OSのキャッシュの仕組みを理解すること、局所性を活かすようにシステムを設計し、分散を考慮してRDBを運営することが重要だと伊藤氏は語る。

　さらに、RDBだけに頼るのではなく、大規模データを扱う自前のアプリケーションを用意することも重要だ。データ量の増加に強いアルゴリズムやデータ構造を利用し、情報圧縮技術や情報検索技術を活用する。最近では、はてなでも検索技術を掘り下げているという。