大規模サービス技術入門

nifty で「ココログ」を作り、はてなで「はてなブックマーク」を作り CTO をやっていた伊藤さんの本。これから僕も大規模サービスやるので今更ながら読んでみました。

自分なりにざっくりと内容をまとめると、以下でしょうか。

１．ユーザー・情報が膨大となった時、単にスケールするだけはでなく、仕組み自体を変えないといけない

２．その時考えるべきは、キャッシュ、データ構造、アルゴリズムの３つ

せっかくなので簡単にこの２つについて書きます。

１．ユーザー・情報が膨大となった時、単にスケールするだけはでなく、仕組み自体を変えないといけない

データベースについての話が一番おもしろかったのでここで取り上げます。

ご存知の通りデータベースには様々な情報を格納することができますが、様々な制限から無限に情報を格納できるわけではなくて、必ず限界があります。扱う情報が膨大となり、その限界を超えてしまうことは容易に想像できます。その時どうするかという話です。

現状よくやられる対応として、情報を分割して複数のデータベースに分けて格納するというものがあります。例えば 100 しか入らないデータベースに 10,000 を入れたければ、情報を 100 ずつ 100 個に分割して、100 のデータベースに分けて格納する感じです。当然分割には規則があり、欲しい情報がどのデータベースにあるかは分かるようになっています。

発想としてはわりと単純ですが、データベースを複数台用意するコスト、複数台から目的の情報を持ったデータベースを選択するコストがわりと小さいので、現状とても現実的な方法と言えます。

# しかしながらやっぱりそれ面倒くさいよってことで、次世代のデータストアとしてその辺よしなにやってくれる Cassandra などが注目されているようです。（補足１）

２．その時考えるべきは、キャッシュ、データ構造、アルゴリズムの３つ

キャッシュ、データ構造、アルゴリズムと書きましたが、結局のところ、データへのアクセス速度をできる限り上げて、計算量をできる限り減らそうということです。

キャッシュが重要というのは、メモリからの読み出し速度がハードディスクと比べて  10 万から 100 万倍速いためです。ほしい情報ができるだけメモリから読み出せれば、それだけでかなり高速化できるということです。僕も昔これで 3h の処理が ~10s になりました。使いそうな情報はできるだけメモリに乗せちゃいましょう。

# memcached とかまさにこの仕組みで、キャッシュからの読み出しで高速に動作し、大量のリクエストをさばきます。Facebook, Twitter も使っているやらいないやら。（補足２）

データ構造とアルゴリズムですが、n^2 のオーダーには気をつけましょう、インデックス張りましょうというよくある話です。基本的な事項ですが無視すると大変なことになるのでとても重要ですね。

最後に

大規模サービスとかその辺の話はノウハウベースの色が強くて、正直やってみないと分からないと思ってましたが、この本を読んで大分イメージが湧きました。また大規模なサービスに関係ない人もキャッシュの話は一般論としてとても大切だと思うので読んでおいて損はないかと思いました。

以上。
# あーなんかすげー長くなってしまった。。

補足１：
Cassandra実践入門―Twitter，Facebookが採用するNoSQLシステム
TwitterとDiggがNoSQLの「Cassandra」を選ぶ理由

補足２（ちょい古い）：
Twitterの大規模システム運用技術、あるいはクジラの腹の中（後編）
Facebookが大規模スケーラビリティへの挑戦で学んだこと（後編）