Hatena::ブログ(Diary)

koyachiの日記 このページをアンテナに追加 RSSフィード

2005/11/27

Flickrの中のヒトのLAMP構成プレゼン(Hardware Layouts for LAMP Installations)訳

del.icio.us見てたら面白いファイルがあったので訳しながらはてな記法ワープロでメモったものを公開します。2005/10/18-25に行われたZend/PHP Conference & ExpoにてFlickrのJohn Allspaw氏が発表されたプレゼンの内容のようです。英語読めるヒトは本物のほうをご覧ください。そもそもプレゼンなので長文はほとんどないし、図も入ってるので。天丼に親近感を覚えました。

あと はてな記法ワープロいいですね。ついでにはてな記法プレゼンツールも是非作ってください!!!

普通にSQL書いてMySQL使うのは出来るけど負荷とかほとんど考えたことないなーと思って「実践ハイパフォーマンスMySQL」読んでたところでhttp://del.icio.us/tag/flickr+mysqlあたりで見つけました。「実践ハイパフォーマンスMySQL」だと6章から9章辺りが関係あります。

このプレゼンの中では前半部はよく見る内容だなと思って見てたんですけど、ロードバランシング以降の話(port exhaustion,10k vs 15k drive, SQUID辺りの具体的な数値とか)は知らなかったので勉強になりました。


このプレゼンの構成

  • MySQL構成
  • その他、(運営していて学んだ?)秘技
  • キャッシュコンテンツに関する考察

One box

ボトルネック

Two Box

ボトルネック

レプリケーションを使った多マシン構成

スレーブ遅延

  • スレーブがレプリケーションについていけなくなる状態。以下の2要因による。
  • 次のような現象が発生
    • ユーザが入力したデータ(写真、コメント等)がすぐに出てこない
    • その結果ユーザは何度もアクション(再投稿、再読み込み)を起こす。これが更に負荷を高める

Hardware load balancing mysql

  • 標準的なMySQLマスタ/スレーブ レプリケーション
  • 全ての書き込み(insert/update/delete)はマスタへ。
  • 全ての読み込み(select)はロードバランサへ行き、そこから全てのスレーブに拡散される

ロードバランシングの良い点

  • アトミックなクエリにより、アプリケーションに影響を与えずにスレーブに追加・削除が可能
  • モニタリングポイントの追加と異常処理の自動化
  • スレーブプールを一つのリソースとして扱うことができ、許容限度を知っていれば許容量工数計画を更に簡単に出来る

各スレーブの許容限度(最大QPS能力)の測定方法

  1. まずベンチマークして予測する(またはトム(誰)ハードウェアベンチマーク(http://www.tomshardware.com/ )結果かanadtech.comを参照する)
  2. 予想より多くのマシンを用意
  3. 恐ろしい(?):遅延検出中に、トラフィックが安定している時の製品のスレーブプールからマシンを削除
  4. スレーブ遅延が発生する直前のQPSが許容限度である

ロードバランシングの悪い/困難なところ

  • 全てのロードバランサが均一に作られるとは限らない。全てのロードバランサ会社がこの使い方を想定しているとは限らないので、サポートも受けられないかもしれない
  • 高ボリューム状態で試している人が少ないため、コミュニティでのサポートも期待出来ない
  • わかったこと

ポートの消耗(Port exhaustion)

問題
  • ロードバランサは交通巡査でしかない
  • 多くのコネクションを持つことによる影響:各IP(VIP)毎に64,511ポートまでしか使用できない
  • 64,511 ports / 120 sec.ポート毎だと...
  • IP毎に同時実行可能なコネクションは最大535*1

ポートの消耗(Port exhaustion(cont'd*2続き))

解決
  • データベース スレーブ/ファーム側のIPプールの使用(Netscalerでは"subnet IPs",Alteonでは"PiPs"と呼んでいる)
  • port/connection使用率をモニタし、追加タイミングを知る

ヘルスチェック

  • ロードバランサはMySQLスレーブの状態について関与しないが、3306ポートが応答を返す間はトラフィックを分配する
  • ロードバランサはSQLをしゃべらない。ふるいTCP,HTTP/S,FTPくらい

ヘルスチェック(cont'd続き)

二つのオプション
  • 汚い、が有効な方法
    • サーバにモニタを設置し、MySQL動作中はポート3306を切る(またはfirewall)
  • きれいだが、少し動作が増える方法
    • サーバにモニタを設置し、xinetd(nagios monitorとか)でチェックを走らせる
    • ロードバランサがポート3306に問いかけてきたら"OK"を返す。そうでない場合はプールから自動的に外される
    • スレーブ遅延の発生とその自動処理の分離検出とそれに対する対抗処理には良い

バランシンアルゴリズム

  • ロードバランサはHTTP,FTP,基本的なTCPは知っているが、SQLは知らない
  • 注意事項二点
    • そのサーバのプール内にいるべきか?(ヘルスチェック)
    • 負荷はどのように平衡を保つべきか?
      • "最低接続数","最低帯域幅","最低hoge hoge" ->駄目
      • 何故なら全てのSQLが均一に生成されるわけではないから
      • "ラウンドロビン"か"ランダム"を使え
      • 何のことかわからない人は:Evil Favoritism(TM)

一方、"in-the-box"考察

  • メモリインターリーブは違いを「生む」
  • 常にRAID10を(あなたが狂人ならRAID0でも)。RAID5は駄目(Innodbでは常に)
  • RAID10は多くの読み込み能力と書き込みペナルティを持つが、RAID5はそうでは無い
  • 常にHW RAID書き込みキャッシュのためのバッテリバックアップを持つ

"in-the-box"考察(cont'd続き)

  • 常に不正/再構築ドライブのための専用モニタ(nagiosとか)を持つ
  • SATA or SCSI? SCSIがいいよ!
  • 10k or 15k RPM? 15kがいいよ!

(ディスク制限されている時に比べて最大20%のパフォーマンス増か)

  • 64bit Linux(AMD64 or EM64T)向け:
    • Innodb バッファプール用にRAMを再大容量にせよ
    • スワッピングは悪、以下のどちらかにせよ
      • 切る(ちょっと怖い)
      • 取り除いて代わりに /proc/sys/vm/swapiness = 0をセットする

10k v.s. 15kドライブはそれほど重要なことか? ->実測値による証明(10k vs 15kなスレーブ遅延発生グラフ)

SAN(Storage Area Network)でMySQLを使う

静的コンテンツのキャッシング

  • SQUID、いいじゃない
  • PHPフロントエンドマシンから変化しないデータを参照する負荷を和らげる
  • 静的ページを生成し、それらをsquidでキャッシィングしよう。

静的コンテンツのキャッシング(cont'd続き)

SQUIDの基本レイアウト

高容量SQUIDingのための良いHWレイアウト

Flickr:How We Roll

図参照

すばらしいSQUID統計:


2005/11/29 04:29 一部修正しました。

id:kdaibaさん、id:rhosoiさん、ご指摘ありがとうございます。

*1:正確ではない。tcp_tw_recycle,tcp_tw_reuseに関連する

*2:cont'dの意味がわからないのでそのまま

kdaibakdaiba 2005/11/28 00:55 *2:cont’d って continued の略で要は「続き」ですが,そういうことではないですか?

koyachikoyachi 2005/11/28 04:11 あ、そうなんですか。単純に知らなかったのでそこは英語のままにしておいただけです。文脈から判断しても多分「続き」であってるのでそうなんですね。
ご指摘ありがとうございます。

rhosoirhosoi 2005/11/28 09:13 「トムのハードウェア」は「Tom’ Hardware Guide http://www.tomshardware.com/ 」のことですね
あと、個人的にはsquidのreverse-proxyは、昔からよく使われてますが、チューニングが必要などんな場合でも、一番最初に検討してみるべき方法だと思います

koyachikoyachi 2005/11/29 04:44 John Allspaw氏の同僚なんだと思ってました>トムさん
こういう便利なページもあるんですね、知らなかった。
SQUIDはlinux始めると結構聞きますね。とはいってもまだ自分では使ったことないです。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

記事一覧を見る / 言及キーワード一覧 / Bookmark / Playlist / About : koyachiのはてなダイヤリー RSSフィード
Error : RSSが取得できませんでした。