関西オープンソース2008（はてな流大規模データ処理／Ruby関西のLT）
二週間前に、関西オープンソース2008というイベントに行ってきました。
毎年開催されている大規模なイベントなのですが、去年まで全くその存在に気づいていなかったので、もったいないことをしていたようで残念に思っています。こちら方面にアンテナ張るようになったのが最近のことなので、しょうがないのですが…
驚いたのはそのボリューム感です。一日の間に６コマのセッションが３つ並列に開催されているので、どれを選ぶかで事前にすごく迷ってしまいますね。とても満足感の高いイベントだと思いました。
はてな流大規模データ処理（伊藤直也氏）
朝一のセッションは御多分に洩れず、やはりここからスタートしてしまいました。
「サーバ／インフラを支える技術」は、未だ積ん読状態ですが、５０分のセッションだったら無理なく楽しんで聴けるだろうと思って、これにしました。
はてなの学生インターン向けセッションで一番人気だったものらしいですね。
はてブのデータサイズ
まず冒頭で、現在のはてブで扱っているデータの総容量が公開されていました。
このくらいの規模のデータをどうやって扱うかということを、OS/DBMS/アプリの３つのレイヤから解説していきますよという前フリだったのですが、私が想像していたよりも少ないデータ量だったので、まずここでちょっと驚いてしまいました。
これについてはセッション終盤で、現在はギガバイトクラスのデータで収まっているが、今後テラやペタまで増加していった時に、どうやって対応していくのかが課題だとおっしゃっていました。
OS
- CPU負荷とI/O負荷
大規模データに対して何も考えずにクエリを投げると止まってしまうのは、メモリ内で処理が完結せずにディスクアクセスが大量に発生するからだということで、CPU負荷のスケーリングよりI/O負荷のスケーリングの方が重要だということでした。
CPU負荷のスケーリングは、単にサーバを増やすことで対応できるけれども、I/O負荷については、問題が単純ではないということですね。
- キャッシュ特性
LINUXのキャッシュ特性として、ディスクから読み込んだ際にメモリが空いていればそれらをキャッシュする仕組みになっているので、単にメモリを増やすことでI/O負荷が軽減できるそうです。
I/O負荷軽減に伴い、CPU使用率が上がる（ボトルネックが解消され、稼働率が上がる）ので、そこから先はサーバ追加で対応が可能となります。
「データ規模＜物理メモリ」になっていれば、全てキャッシュできるわけですが、コストパフォーマンスを鑑みると、現状では8G〜16Gくらいがちょうどよいサイズだそうです。
- キャッシュの局所性
メモリ追加でもキャッシュしきれない場合には、データ分割する必要があるのですが、これが単純にはできなくて、キャッシュの局所性を意識した分割が必要だそうです。
ここで、「テーブル単位の分割」「検索インデックス単位の分割」「リクエストパターンでの分割」という、３つのデータ分散に対する考え方が提示されます。
その他にも、色々現場で気づいたり学んだりしたことをお話されていたのですが、実際にいろいろとモニタリングしてみた結果から、大規模データを扱う際に、下層レイヤでは何が起こっているのかを推察し、それに対して具体的に手を打っていく様子がわかって非常に興味深かったです。
DBMS
ハードやOSレベルでの対応の次は、一段上がってDBMSですね。
ここでは、MySQLで大規模データを扱う場合の考え方について、順を追って解説されていました。
以下、メモ書きをつらつらと。
- 「データ規模＜物理メモリ」を意識する。
- インデックスを意識する。（シーケンシャルサーチとバイナリサーチ）
- データ分散を考える
⇒参照系（スレーブ）３台に対して、更新系（マスタ）を１台立てて、データは定期的にマスタからスレーブへ反映されるようにする。アプリケーションから飛んできたリクエストはロードバランサ経由で各サーバへとさばかれる。スレーブはメモリやサーバ追加などでスケールできるが、マスタはスケールできない。だが、リクエストの９割は参照なので、問題になりにくい。
- パーティショニングを意識した設計。
⇒JOINを使わない。テーブル単位での処理を複数回に分けて行うことが大規模データにとってはよい。最近ではそのあたりのことはO/Rマッパで吸収されている。が、ミラーリング時の運用が複雑になる。
私は普段、階層型のDBMSを扱っているのですが、このあたりのお話には妙に納得してしまいました。階層型ではJOINなんて使えないので…階層型が速いのは、おそらく内部で複雑なことをやっていないからなんでしょうね。やっぱり速くしようと思ったら、仕組みをシンプルにするしかないのかなと思ってしまいました。
アプリ
最後は、アプリケーションレベルでの対応についてのお話でした。
これについては、特定のDBMSを使わずに自分専用のデータ構造を作成してしまうという内容になっていました。一般的なDBMSは汎用的に作られているため、特定の検索に特化した用途には向かないので、パフォーマンスを上げる為には専用の仕組みを作る必要があるということですね。
以下、メモ書きです。
- データを定期的にダンプするThrift
⇒文書から単語の出現回数を算出して、スパムの判断に使用している。
- テキスト走査
- 転置インデックス
⇒辞書はアルファベット順／文書はID順にしておくと、圧縮・検索時に有利。
⇒圧縮の意義とは、かつてはストレージ容量やネットワーク帯域の節約の為だったが、最近はいかにディスクI/Oを減らすかということが目的になっている。
- 検索結果のスコアリング（ベクトル空間モデル）
- 大規模バッチ処理
⇒一台で処理しきれない場合は、複数サーバで並列分散処理する。MapReduce（メモリ内部で分割して分散処理を行う仕組み。）
自分専用のデータ構造を設計したり実装していくのって、面白そうですね。ここで工夫を凝らして産まれたものの中から、将来的に汎用的なものに成長していくものが現れたりするのでしょうか。
伊藤さんの技術的なプレゼンを聴くのはこれが始めてだったのですが、自分にも理解できる内容でとても勉強になりました。こんな風に、難解な内容を平易な言葉で噛み砕いて解説していくことは、すごく難しいことだと思うのですが、それをさらりとやってのけるのがすごいですね。
私はメインフレームの世界で、インフラ周りの面倒を長年みてきているので、OS/DB/APの三段階で対策を打って行く過程や、それぞれの考え方なんかは、自分自身の日常業務に通じるものがあり、そういう意味でも興味深く聴かせていただきました。
Ruby関西のLT
次は、Ruby関西のLTを聴いてみました。
全体的になごやかムードで、LT特有の、あの時間に追われる殺伐とした感じが全くないのが不思議でした…
メイドメール
自作Webサービスの紹介だったのですが、ネタ系かとおもいきや、しっかり実用的になっているところが素晴らしかったです。けれども、その手の趣味のない人にはちょっとアレなので、秘書バージョンも是非出してほしいところですね。
男前Ruby
ネタ系ですが、あの雰囲気の中で笑いをとるのは結構厳しいと思いました。
内輪のようで、微妙に内輪でないところが…
Console on Rails
Lazy Lists
マニア系なので、何をされているのか全く理解できませんでしたが、お二人ともいい感じに脱力したトークが面白かったです。
