BKCon 2006

昨日は BKCon 2006 に行ってきた。
BK というのは「一般的にはバッドノウハウの事」なんですが、昨日のは、BKCon と言っても、かつて開催された Bad Knowhow Conference 2004 の続編とかではなく、"B"atara "K"esuma "Con"ference 2006 です。

※正しくは横浜 Linux ユーザグループ主催の「第 65 回カーネル読書会」のテーマ "mixi.jp: Scaling Out With Open Source" です。

ちなみに、Batara Kesuma さんというのは、株式会社ミクシィの取締役。
mixi の裏側を見せますというか、ちょっと hip な言いかたをすれば "Inside mixi's backend" ってカンジです。

とりあえず、プレゼン内容は YAPC::Asia の時と大凡同じでしたが、プレゼンの持ち時間や、質疑応答の時間が長かった分、YAPC::Asia の時よりは内容が濃かったように思えます。
ザックリまとめてみました。

<プレゼン内容>

• mixi とは
• Alexa によると、アクセス数は国内 3 位
• アクティブユーザ率 70%
• 1 ユーザあたりの平均滞在時間は国内一位 (ネットレイティングス調べ)
• システム構成
• 所謂 "LAMP" と呼ばれる構成
• Linux 2.6
• Apache 2.0
• MySQL (4.0, 4.1, 5.0)
• Perl 5.8
• memcached
• Squid
• mod_perl から memcached に保存された HOT OBJECT を引き、保存されていなければ DB から引く。
• MySQL
• 現在は 100 台以上
• 月 10 台ペースで増設
• non-persistent connection
• 殆どの Table Type (Strage Engine) が InnoDB (ログ系は MyISAM)
• DB partitioning
• --skip-grant-tables (権限や認証を無しにしてビルドにする起動オプションを利用して高速化)
• 初期の DB
• slave をひたすら増やし、write は master、read は slave へ
• read は分散出来たが write 頻度が高過ぎて追い付かなくなり、データの遅延が発生した
• MySQL の参照と更新の比率
• 日記
• read 85%
• write 15%
• メッセージ
• read 75%
• write 25%
• DB partitioning (DB スケール)
• vertical partition - 縦方向 (ユーザ別) のスケール -
• 一気に作業しなくてはいけない場合に、リアルタイムで移行するのが難しい。
• horizontal partition - 横方向 (テーブル別) のスケール -
• 対象は重いテーブル (メッセージ、日記等)
• → level 1 と称し、その方法を取った
• level 1 へ移行手順
• OLD DB と NEW DB に同時に write しつつ、read は OLD から
• OLD から NEW に INSERT (移行) が完了してから、NEW から read させる
• partitioning の問題点
• JOIN が出来ない
• benchmark を取った結果、JOIN をするより、アプリケーション側で二度引いたほうが高速だったので問題ない
• level 1 での問題点
• それでも日記やメッセージ等の partitioning だけで重くなってきた
• → level 2 (vertical partition) を取った
• level 2 の partitioning key
• user id, message id 等
• 細かく partitioning すればパフォーマンスチューニングは楽だが、partition map が肥大化する
• partition map for level 2
• 簡単に configuration file とかに入れるようには出来ない
• manager base
• DB に書き込む
• algorithm base
• 更新と参照する先をアルゴリズムにより算出させれば read と write が同じノードになる
• manager base
• 例えば user_id = 14 のノードがどこかを manager DB に問い合わせる
• メリット
• 管理しやすい
• 新規ノードの追加が容易に行える
• ノード間のデータ移行が容易に行える
• デメリット
• ノード問い合わせのクエリが manager DB に都度発生してしまう
• algorithm base
• node_id = (member_id % 2) + 1
• メリット
• manager DB への問い合わせが不要
• デメリット
• 管理しづらい
• バランシングしづらい
• 同スペックのマシンを並列稼動させないと難しい
• ノードの追加方法
• old_node_id = (member_id % 2) + 1
• new_node_id = (member_id % 4) + 1
• write 先の算出。上記二つの計算結果がもし異なれば、write を二箇所に行う
• read は追加前は old に対して行う
• 移行が完了したら、read も write も新しいノードに行い、古いノードからデータを消す
• partitioning の問題点
• メンバーのニックネームや、コミュニティ名等を表示するための DB への問い合わせ回数が多くなってしまう
• ごく小さなデータは memcached に保存する
• キャッシング
• memcached を利用
• memcached と mod_perl を同じマシンに入れて運用
• メモリは memcached で 2GB 確保し、mod_perl で 2GB 利用 (4GB 登載)
• memcached は 39 台ある
• persistent connection にし、一台あたり約 6,000 コネクションある
• 画像
• 半年前ぐらいは、8TB ぐらいあった
• 1 日あたり約 23GB 増えている
• 管理は MySQL を利用し、実際の画像はファイルシステム上に保存
• 画像ファイルに 2 つの性質がある
• 数は少ないが、アクセス頻度が高い画像
• ユーザのアイコン
• コミュニティのアイコン
• 数も多く、サイズも大きいが、アクセス頻度が低い画像
• 日記の写真
• アルバム
• コミュニティ掲示板にアップされた写真
• アクセス頻度が高い画像
• サイズ的には数百 GB 程度
• FTP で保存して、Squid を介す
• 3rd party CDN を利用
• キャッシュのヒット率が高い (約 96%) ため、ストレージへのヒット率が低い
• アクセス頻度が低い画像
• サイズ的には数 TB もある
• 配信よりも、ストレージングに難あり
• 新しいファイルほどよくアクセスされるという特性
• キャッシュのヒット率がかなり低い (1 つあたり 10 回も満たない程度)
• Squid を使わず、ストレージから直接配信させる
• manager DB
• 画像の保存先を manager DB に問い合わせる
• 問い合わせ結果は 2 箇所になるようにしている
• その 2 箇所に保存 (バックアップ等の目的)
• 表示方法は、mod_perl 側で manager DB に画像の保存先を問い合わせ、FQDN を構成し、ユーザ側からその URL を直接叩いて表示
• TO DO
• MySQL Cluster 等の使用も検討してみたい
• アルゴリズムベースは難しいな
• consistent hashing
• linear hashing
• level 3 partitioning
• 例えば、時系列で split させてみたり

Batara さんの発表はここまで。
基本的に MySQL 周りが一番キモということですね。

実践ハイパフォーマンスMySQL

ジェレミ・D. ザウドニ デレク・J. ベリング Jeremy D. Zawodny Derek J. Balling 林 秀幸
オライリージャパン (2004/10)

Amazon.co.jp で詳細を見る

MySQL全機能リファレンス

鈴木 啓修
技術評論社 (2004/11)

Amazon.co.jp で詳細を見る

構成とか、考えかたは、この前 WEB+DB PRESS vol.33 に書かせていただいたものに結構近いものを感じました。
違いは horizontal partition とか algorithm base 云々ってのが無いぐらい。

WEB+DB PRESS Vol.33

WEB+DB PRESS編集部
技術評論社 (2006/06/22)

Amazon.co.jp で詳細を見る

で、ここからは質疑応答時間になりました。
Batara さんは「大豆ノススメ」を飲みながら答えてくれました。
ザックリ覚えてる範囲で…

<質疑応答>

• 開発メンバーってどのぐらいいるの？
• 20 人ぐらいだよ
• DB が破損した場合どうするの？
• レプリケーションしてるから復旧は簡単さ
• トランザクションとか使ってる？
• あまり使ってないが、使わなくてはいけないクエリもあるよ
• 事件とかニュースとかの影響で突発的な負荷とか来た場合の対策とかしてる？
• 現状の構成で余裕あるから特にはしてないよ
• 監視とかどうしてんの？
• Nagios とか使ってるよ。一応 failover とか工夫してるけどね
• OS とかカーネルの停止が起こったらどうしてんの？
• Fedora の 4, 5 を使ってるけど、そんなこと一度もないよ
• 参照頻度のほうが高いのに何で InnoDB を使ってるの？
• 実際には一台一台の参照頻度がそんなに高いわけでもないし、ロックさせるのにテーブルロックとかしたくないからさ
• アプリケーションのエラーとかで memcached 上のキャッシュと実データとの不整合が起きる可能性があるけど回避策は？
• キャッシュ時に expire time をセットしているぐらいかな
• expire time ってどのぐらい？
• データの性質によって変えてるよ
• 静的コンテンツ用に LSI サーバを使ってるとかどっかの日記で見たんだけどホント？
• 検証で使ってみたぐらいだよ
• 友達の新着日記とかってノードを跨ぐからアルゴリズムとか複雑じゃない？
• それ用の小さいテーブルを作っておいて一カ所のノードにまとめてるよ
• なんで Fedora を使ってるの？
• 最初 Debian とか使ってみたけど、NIC を認識してくれなくて、ドライバとか入れるのがウザかったんだよね
• mixi が使ってるホスト名のいくつかを正引きすると Akamai とか入ってるよね？
• さっき言ってた「アクセス頻度が高い画像」の 3rd party CDN だよ
• 障害対応ってどうしてんの？
• 基本的には障害対応チームがやるよ
• メールとか大量に配信してて、苦労してそうだけど、どういう仕組み使ってるの？
• 特に苦労はしてないなぁ。postfix を使ってるよ
• 携帯のキャリアとかに大量に配信したら SPAM 業者扱いでブロックされたりしてないの？
• そんな話聞いたことないなぁ
• 色々なバージョンが混在してるみたいだけど管理してないの？
• してないなぁ。どのバージョンで動かしてもちゃんと動くようにアプリケーションを実装してるよ
• deploy の方法ってどうしてる？
• 自社で作った専用のやつを使ってるよ
• サーバの restart とかはどうしてるの？
• restart するマシンを proxy のリストから外して、restart して、restart し終ったら proxy リストに戻すっていう処理を自動的にやってるよ
• manager DB とか応答しなくなったらどうすんの？
• 一応 master - slave の構成にしてて、failover とかもやってるからコケないようにはしてるよ
• disk full とかになったらどうすんの？
• なる前に対策打ってサーバ増やしてるよ
• サーバ追加作業って大変じゃない？
• 誰が見てもわかるような手順書があるから大丈夫だよ
• 新しい機能とか追加された時のテストとかってどうしてんの？
• 作った本人が一番テストしてるんじゃないかな？でもテストチームとかそういうのは無いよ
• テスト用の環境ってどうなってんの？
• ほぼ本番と同じ構成のものがあるよ
• 64bit 機ってどのぐらいある？
• そんなにないなぁ。ほんの数台だよ。コストパフォーマンスとか次第かな

postfix ってのは意外でした。

Postfix: The Definitive Guide

Kyle D. Dent
Oreilly & Associates Inc (2003/12)

Amazon.co.jp で詳細を見る

この後の懇親会は、案の定、Larry Wall や Ingy döt Net や Dave Rolsky や Audrey Tang、あとまつもとゆきひろ氏や David Heinemeier Hansson が入りたくても入れないという、サブテクの「悪ノリ飲み会」状態になってしまって、明らかにサブテク界隈だけ周囲との空気が違い過ぎました。

内容は…とてもじゃありませんが公開出来ません。
非常に残念です。


昨日の迷言:
株式会社はてなの「はてながやまん」こと、幹事 2.0 id:nagayama が放った一言。
「このあとちょっと酔いをさますのに、ホット Boofy とか飲もうっかなーって思いまして」

はてなってへんな会社ですね。

ビバ w@r3z

「へんな会社」のつくり方

近藤 淳也
翔泳社 (2006/02/13)

Amazon.co.jp で詳細を見る