2006年07月13日

第65回カーネル読書会「mixiの話」のメモ

7月6日(木)の第65回カーネル読書会「mixi.jp: Scaling Out With Open Source 」に行ったときのメモ。

忘れてきつつあるのでメモをブログへあげとこうと思ったら、レポートを書かかれているブログがいくつかあった。

 にぽたん研究所「BKCon 2006」
 ようの日記「今回のカーネル読書会はmixiの中の人」
 ユメのチカラ「500万倍のスケーラビリティ」
 ユメのチカラ「LiveJournalのアーキテクチャ」
 カイハツニッキ「第65回カーネル読書会レポート」

上のブログの記事で聞いた内容のほとんどカバーされている上に、私よりはるかに正確な気がする。

まあいいか、復習のためにメモしておこう。


DBまわりが肝という結論だったのだけど、DBはあまり知らないので肝心なところがついていけてなかったなあ。

お話が日本語、パワーポイントが英語ということもあってメモ取りに苦戦、いつも以上にメモが不正確かも。


以下メモ
----
Batara Kesuma
CTO of mixi,inc

●mixiの歴史
 2003年10月から
 当初は企画からコーディングまで(Bataraさん)一人で
 2004年2月オープン

●ユーザ数
 オープンして2ヵ月後にユーザ1万人突破
 1年目:600人→
 2年目:21万人→200万人
 今は450万人くらい

 70%くらいがアクティブユーザ。オープンころからこの比率はかわらない
  アクティブユーザ:72時間以内にログインしたユーザ

 1人あたりの滞在は、1週間で3時間20分
  Yahoo!よりも高いみたい

●システム構成
 Linux 2.6
 Apache 2.0
 MySQL バージョンバラバラ
 Perl 5.8
 memcached (キャッシュ)
 Squid

 リクエスト→mod_perl→memcached
  mod_perl→memcached になかったらDBへ

●MySQL
 100〜200くらい
 月に10台くらい増えている
 Non-persistent connection
 InnoDB
 partitioningを沢山つかっている


 自社で開発したパーティショニング
 mod_perlがDBでなく、一度ライブラリ経由してクエリの種類をみてそいつが分散してくれる

●最初は・・・
 DBは1つからスタート。
 スレーブをひたすら追加
  writeはマスター
  readはスレーブ
 →更新が多いと追いつかなくなる

 ◆日記
  Read 85%
  Write 15%
 ◆メッセージ
  Read 75%
  Write 25%

●どうやってsplitするか?
 最初検討したのはバーティカル
  ユーザごとにDBを分ける
  →問題は一気に移行するデータが多くて、サービス止められない

 メッセージ関連のDBを別のサーバに
  レベル1のパーティション(と呼ぶ)

●レベル1のパーティション
 スタティックである
  ユーザが入ってきてもテーブルが変わらない
  全部configurationファイルに入れていた

●レベル1への移行
 新旧2つのDBにWriteして、裏で(旧のデータを)旧から新へコピー
 何かあったらロールバックできる
 問題なかったらOLDのDBを消す

●問題
 JOINが使えない
  2回SELECTしたほうが早かった
   メッセージ送ったのは誰だ?
    ニックネーム取らないと
   アプリケーションで組み合わせて

●レベル1での問題
 日記だけが重くなったり、メッセージだけ重くなった

●レベル2でのパーティショニングキー
  インデックスの選び方と同じ、なんでもいい。
 ◆userIDでわける
   あまり細かく分けられない。特定の人だけ重いとか
 ◆messergeIDでわける
   細かく分けれる。パーティションがでかくなる
 
 →userIDでわけた
  1つのリストで沢山ださないといけないので

●レベル2でのパーティションマップ
 ◆マネージャベース
  情報をどこかに書き込んで、最初にとってくる
  Manager DB にノードを問い合わせ
  メリット:
   管理しやすい。新しいノード追加、ノード間の移行もできる
   性能が)弱いマシンだからあまり人をいれたくないとかもできる
  デメリット:
   ノードの問い合わせをいちいちマネージャに聞きに行く必要がある

 ◆アルゴリズムベース
  更新側と同じアルゴリズム
  メリット:
   アプリが勝手にノードIDを計算する
  デメリット:
   同じスペックでないとやりにくい。
   新しいマシンを追加したとき、アプリケーションの変更が必要
    2つへ書き込みつつコピー

●レベル2の問題点
 DBへのアクセスが多くなる
 マイミクの画像を出すのにいろんなノードに問い合わせが必要に
  オーバーヘッドが大きい
  →小さいデータなので全部メモリ上にキャッシュ。これでロードが早くなった

●キャッシュ
 memcached を使用
  いろんなサーバのメモリが1つにみえる
  CPUもあまり食わない
  mod_perl はCPUをメチャ食ってメモリは食わない
  →mod_perl と memcached を同じマシンで実行
  39台×2GBのメモリ
  1台6000コネクションくらい。負荷もあがらないのでメモリさえあればいくらでも

●イメージサーバ
 半年前で8TBくらい
 1日あたり、23GBくらい増加
 メタデータ用にMySQL
 画像はファイルで保存

●画像は2種類
 ◆サイズが小さく数も少ないが、アクセスが多い
  ユーザの写真、コミュニティのロゴ
 ◆アクセスは少ないがサイズが大きい
  日記の写真、アルバム、コミュニティの掲示板の中の画像

 FTPで保存して、Squidで配信

●アクセスの多い画像
 キャッシュのヒット率96%くらい
●アクセスの少ない画像
 サイズが大きくストレージが厳しい
 新しいファイルほどアクセスされやすい
 キャッシュのヒットは10回くらい
 Squid使わずストレージから直接配信

●アップロード
 mod_perl→manager DB(エリアを返す)
 mod_perl→ストレージへアップロード

●表示
 ユーザ→mod_perl→manager DB
     mod_perl←(エリアのIDを返す)
 ユーザ←mod_perlがFQDNのホスト部を追加
 ユーザ→直接ストレージへ

●TODO
 レベル3へ
  今は日記が多いと重い
  →時系列でsplit

----
質疑応答
Q:今も余裕はありますか?
 A:マシンさえ増えれば大丈夫

Q:エンジニアは何人?
 A:20人弱

Q:コード変更のダウンタイムは?
 A:全部を止めずに一部だけに。ユーザごとにずらすなど

Q:DBが壊れたときアクセスできなくなるデータは?
 A:全部データはレプリケーションされているので、データセンタがつぶれない限りデータはなくならないはず

Q:データマイニングしている?
 A:ロケーションバナーを性別で変えたり

Q:アクセスログのパターンからのチューニングは?
 A:それもやってます。チューニングするのも一番アクセスされるページから

Q:トランザクションは使われている?
 A:できるだけ使わないようにしている。どうしてもという時は使う。
  複数DBでのトランザクションはない。

Q:一から作るとしたら同じものを作る?
 A:今のがベストと思っている

Q:ストレージは?SANを使っている?
 A:普通にSCSIのHDD

Q:負荷が偏ってしまうものは?
 A:アルゴリズムベースだとある。
  足跡などで使っている。30個しかないので
  ばらつきが出そうなものだとマネージャベースにしている

Q:ニュースなどで想像つかない負荷がかかってどうしようもなくなったことは?
 A:今まではなかった。

Q:WAN側のネットワーク帯域は?
 A:内緒

Q:エラーを監視しているのか?
 A:Nagosで監視。
  自動でフェールオーバーできるものもある。できるだけ自動化したい

Q:カーネルやOSが原因でサーバが停止することは?
 A:あんまりない。HDD系が良くある。
  Fedoraの4と5を使っている

Q:どれくらいでボトルネックの対応を?
 A:多少重いなと感じてきたときにちょくちょく。常にやってきた感じ。

Q:1人のマイミクに1件しか日記が表示されないように変更した理由は
 A:企画的な理由。技術だけの問題ではない

Q:ログの収集は?
 A:最近そこらへんさわってないので。
  昔はPerlでやってておいつかなくてCへ

Q:WriteよりReadが多い中でInoDBを選んでいるわけは?
 A:Readが多いかもしれないが比率で見ると少ない

Q:DBが走ったときにキャッシュを破棄していると思うが方法は?
 A:キャッシュはエクスパイアタイムがついている
  何かが変わったときにアプリケーションのをクリアしている

Q:LSIサーバを使っているのか?
 A:検証しただけ

Q:SQL文のチューニングは?
 A:一番最初にやった

Q:RDBのチューニングは?
 A:していない

Q:友達の日記の新着をだすときにアルゴリズムは複雑に。工夫は?
 A:テーブルを小さくしてひとつのところにまとめる

Q:構築・運用での工夫は?
 A:DBやmod_perl用の独自インストーラはある。
  Fedora自体はそのまま使っている

Q:Fedoraを利用している理由は?
 A:DebianとかNICを認識してくれなくて。
  Fedoraだと一発でいけたので。

Q:akamaiはどこに使っている?
 A:アイコンだったり、小さい画像に

Q:開発と運用をわけている?
 A:ある程度までは開発、それ以上は運用

Q:障害対応は?
 A:障害対応チームがある

Q:メールを大量に吐いていると思うがメール配信で苦労は?
 A:メールは特に問題ない
  Postfixで吐き出している

Q:携帯キャリアにアクセスロックされたりは?
 A:聞いていない

Q:Fedoraのバージョンが混成しているが、構成管理は?
 A:バージョン管理はしていない。
  アプリケーションでバージョンに依存しないようにしている

Q:アプリケーションのサーバへの配信は?
 A:自社でつくったもので配信
  リスタートが必要なときはプロキシリストからはずしてから

Q:アップデートはしないのか?
 A:ライブラリのアップデートという形

Q:managerDBがこけたら大変?
 A:マスター・スレーブやマスター・マスターにしている

Q:ローカルのHDDがいっぱいになったときは?
 A:そうならないうちに増やしている

Q:複雑になっているが機能拡張の時はどうする?
 A:企画の話なので答えられない

Q:サーバーを追加するコストが高いが手順などの工夫は?
 A:定型化している。
  リスト化して誰でもわかるように

Q:テストは誰が?
 A:書いた本人が

Q:テスト用環境は?
 A:規模は違うが仕組みがほぼ同じテスト環境がある。

Q:64ビットマシンは?
 A:数台ある

Q:新しいサーバと古いサーバが混じっているのは大変では?古いサーバは捨てている?バランシング?
 A:アルゴリズムベースでは新しくしていくしかない
  マネージャベースではバランシング

Q:バックアップは?
 A:マスター・スレーブかマスター・マスターで
  あとはHDDへスナップショット

posted by 端っこなひと at 01:33| Comment(1) | TrackBack(1) | セミナー・勉強会 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
こんなの見つけちゃったんだけど、これってどう思う?
mixiで不労所得を得る具体的な手順(pdfファイル・A4版・108ページ)
http://jouho.jp/mixisecret/
ちょっと迷ってる私です。(¨;)やっぱこういうのやめたほうがいいのかなぁ。
Posted by mimi at 2007年02月20日 16:03
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]


この記事へのトラックバック

【geek】日本最大のBtoCのトラフィック
Excerpt: 数日前のエントリーで、geekな同士へ [2007年01月16日(火)]を、書いたわけだが、そのmixiの新卒限定のセミナーに後輩が行って来た。それも二人も。そもそも、30名募集して、30名いなかった..
Weblog: 増澤@ドリコム(入社予定)の世界地図。
Tracked: 2007-01-26 00:41