MySQL Conference & Expo 2007

一昨日から今日まで3日間の日程で開催されていた、MySQL Conference & Expo 2007に行ってきました。日帰り圏内どころか、自転車圏内で、こういうカンファレンスがあるのは、素晴しいです。

詳細は、随時アップされるであろうプレゼン資料と、Planet MySQLに大量の報告があります(全部英語ですけど)。

個人的に注目していたのは、Digg.com、Flickr.comとYoutube.comのDB周りアーキテクチャのセッションでした。あとは、http://www.mysqlperformaceblog.com/の人のセッションは、細かいTipsが多く、具体的にだいぶ役に立ちそうです。

というわけで、簡単に注目したセッションの内容を紹介してみます。ちなみに、内容の正確さは無保証です:P 気が向けば、もっといろいろ考察してみるかもしれません。


Technology at Digg.com, Eli White, Tim Ellis

http://www.mysqlconf.com/cs/mysqluc2007/view/e_sess/12204

成長著しいDiggのインフラの話。わりと普通のアーキテクチャという印象です。

  • 最初は、Apache 1.3, PHP 4.xから1台で初めた。徐々に、MySQL 4.0 myisam, MySQL full-text search, myisam -> innodb, replication, memcached, php 5.xと進化していった。
  • 現在の標準構成
    • load balancer + PHP Servers, MySQL master + slaves
    • phpとmysqlの関係はランダムで決定
  • Memcachedを使う
    • ダイナミックなページにもキャッシュデータを使うことができる。FailoverやRedundancyもある。
    • サーバ故障時の失敗したデータを除去・無視できる
    • レプリの遅延を隠すことができる。
      • Writeする時にmemcacachedのデータもupdateしている。いつなにをキャッシュするかが重要
  • データ分割
    • 一つのDBを複数に分割することで、性能向上とスケーラビリティを得る
    • JOINなどの一部のSQLが使えなくなる / PHPの負荷が増える / アプリケーションコードが複雑になる
  • 現在のDB関連チャレンジ
    • RAMを増やしてもスケールしなくなってきた
    • I/O負荷が高く、SQLを書き直したい
    • マスタがSPOF (でも、言うほど悪いものじゃない)
    • Use diskTest.pl from http://faemalia.net/mysqlUtils
  • データセンタを冗長化のために複数使っている
  • 全文検索には、Luceneを使っている
  • http://eliw.com/conference/ に資料はあるよ

Federation at Flickr: Doing Billions of Queries Per Day, Dathan Pattishall

http://www.mysqlconf.com/cs/mysqluc2007/view/e_sess/11925

  • FlickrのDB担当の人
  • Flickrでの問題
    • 一つのMasterに多数のSlaveという構成
    • Slaveへの遅延
    • たくさんのSPOF
    • ページを返すのに秒単位の時間がかかる
  • 解決案
    • Shard(破片)にデータベースを分割し、PHPロジックで、それらの結合と一貫性維持を行なう
    • Shardは、Master-Master構成
      • ユーザを特定のShardに固定する
      • 負荷に応じて、Shard間を移動させる
    • 分割できないデータは、Global Ringに配置して、memcacheさせる
    • 負荷は50%に抑えておいて、メンテ時や障害時にも問題なく処理できるようにする
  • 一日、数億のクエリを処理する
  • ハードウェア
    • EMT64, RHEL4 with 16GB ram, 6 disk 15 rpm raid-10
    • 12 TB of user data (ちなみに他のプレゼンで、写真用ファイルサーバの容量は2ペタとか。奥さん、ペタですよペタ)

Scaling MySQL at YouTube, Paul Tuckfield

http://www.mysqlconf.com/cs/mysqluc2007/view/e_sess/14292

YouTubeの爆発的な成長と、それをささえるインフラの話。すごい人気で、終った後も、会場の外で、ずっと質疑をしていました。キャッシュの有効利用、IOの徹底的な並列化の追及と、独自レプリケーションシステムが、Youtubeのスケーラビリティの肝ということらしい。

  • Paul Tuckfield
    • Sysadmin for nearly 25 years, Oracle dba for 15 years, MySQL dba for 8 months
  • MySQLはスケーラビリティの要素の一つ(PHP, Memcache, MySQL replication)。基本は、InnoDB。
  • Replicationの遅延が問題となった。Replicationは早くない。→ 特定のページと特定のレプリの関係を固定する
  • DB障害対策
    • InnoDBはリカバリに時間がかかる
    • オペミスに対処するために、わざとレプリを遅延させているところもある
    • マスターに障害が起きた時は、レプリをマスタに昇格させる。
      • できるだけ早くDBを複製する仕組みを作った
  • ハードウェア
    • 最初: 2x1.5GHz CPU, 512M ram, 2x 300G disk
    • ダメなアップグレード: 4x4GHz CPU, 2G ram, 2x700G disk
    • よいアップグレード: 2x1,5GHz CPU, 16G ram, 10x 10krpm disk
  • DBをメモリにフィットさせる。そうでないなら、、
    • Writeは、RAID controllerにキャッシュさせる(OSにはキャッシュさせない)
    • Readは、DBにのみキャッシュさせる。(RAID ControllerやOSにはキャッシュさせない)
    • ランダムアクセス性能の並列性をチェックするべき
    • OSにキャッシュさせないのは、OSのキャッシュは、DBやRAID Controllerのそれと役割りが同じでオーバーヘッドにしかならないため
    • RAIDする時のstrip/chunkを大きくすることで並列性を上げられる。(DB Blockサイズ(16k)より大きくする)
  • IOが正しく並列化されていることを確認する
  • Masterへの書込みは並列化できても、Slaveへのレプリは直列のまま