【福岡】インフラ勉強会で ISUCON を疑似体験してきました。

インフラ勉強会に参加しました。

第6回 ITインフラ勉強会＠福岡 （ISUCON夏期講習のAMIで、もくもくチューニング）
http://fukinfra.doorkeeper.jp/events/5367

普段、Web アプリケーションの開発業務に携わらせて頂いてる関係上、フロントエンド、サーバーサイド、インフラとまんべんなく触る機会があります。中・大規模の Web アプリケーション基盤の構築に興味がありますが、お仕事となるとなかなか機会に恵まれません。技術的に未熟なのは承知の上でしたが、実際に現場で闘われているエンジニアの方が、どういう風に考え、手を動かしているのかを勉強できたらいいなぁという気持ちで参加しました。

参加してみて

技術的な側面で、課題を見つけたこと、学んだことも多いですが、それ以上に自分の至らなさを痛感して、もっと頑張らねば！と言う気になったのが、一番の収穫です。すごい人たちはたくさんいらっしゃるし、上を見始めるとキリがないですが、その底のなさが、面白い！

もくもく会の内容について

こちらで作成された AMI を使って、チューニング・高速化を行おうという趣旨でした。私は @take_3 さんと @minimum2scp さんのチームに配属されました。アプリケーションは java, perl, ruby, nodojs など色々な言語で実装されているので、好きな言語を選択してよいとのことです。DB は MySQL が使われています。

言語については、なんとなく perl で進めることに。@minimum2scp さんが perl を使えましたので、アプリケーション側はお任せすることに。私は、わからないところも多かったので、今回はお勉強ということでお二人の作業を見ていることにしました。


まず、高速化のアプローチですが、「サーバ/インフラを支える技術」にも書かれてありましたが、

「推測するな、計測せよ」

が鉄則です。

チームとしてはまず、アプリケーションのベンチマークを走らせて、ボトルネックの調査から開始しました。サーバーの負荷監視には「dstat」を使います。

以下、終了後の講評のときに出ていた話ですが、
サーバー負荷の調査には、みなさんおおよそ次の方法を取られるそうです。

・「dstat」 と 「top」 コマンドを使って、サーバー負荷のザックリとした傾向を調べる。
    > CPU 負荷が大きいのか
    > I/O 負荷が大きいのか
・それよりも、さらに詳細に調べたいときには「sar」コマンドを使う。

最初のベンチマークの結果は、CPU負荷が 100% 近く、I/O 負荷・ディスク書き出し等はあまり起きていない感じでした。メモリもかなり余裕があり、ほとんど使われていないような状態になってました。

今回はアプリケーションと、DB が同じサーバー内で動いていましたので、アプリケーションとデータベースのどちらに負荷が寄っているのかを調べました。「top」コマンドで確認した所、mysql のプロセスがかなり大きめの CPU 負荷を持っているように見えました。

@take_3 さんが、ここで mysql のスロークエリの監視と、sql の統計を取ってくれました。それによると、SELECT の発行コストが大きいのが目につきました。該当する SQL を explain すると、全表検索してる..。ここでインデックスを整理すること、ベンチマークの結果が２倍くらいの伸びました。



終わってみると、スコア面ではここで壁にぶつかってしまっていたような感じで、いろいろ施策をするが、いずれもスコアには微増・微減という感じのまま時間切れとなってしまいました。それにしても @take_3 さんも @minimum2scp さんも、5〜6時間ぶっ続けで作業されてて、すごい集中力だなぁと思いました。


タイムアップまでにやったことを、覚えている範囲で列挙すると...。

  • MySQL の設定ファイルの見直し
    • そもそも初期状態で、そんなに変な設定にはなっていなかったらしいです。
  • システム負荷も少し見られたので、カーネルチューニング
  • Web サーバーを Starman → Starlet に変更
    • 初期設定レベルでは、スコアに対してはほとんど影響なし...？
  • Perl のバージョンアップ
    • ほとんど影響なし？


今回、アプリケーション側にはほとんど手を入れなかったのですが、終了後の講評で、実際の isucon の話をきくと、高スコアをたたき出しているチームは、ほとんどアプリケーション側に手を入れていたそうです。５時間でアプリケーションを全部書きなおしたチームや、MySQL → Redis に移行して、アプリケーションを書き換えたチームもあったそうです。

世の中には素敵な変態さんが、たくさんいらっしゃるなぁと、己の平凡さを痛感した一日となりました...。

まだまだ勉強することはたくさんありますね。

たくさんのやる気と、知恵をいただけた一日でした。
主催の @matsumana さん。
会場でお会いしたみなさん、ありがとうございましたー m(_ _)m


終わった後で、isucon 優勝チームのブログを見てみた

わ、わからん。。



以下、自分のメモ

  • MySQL の負荷監視には何をするべきか？
    • スロークエリを確認する。
    • 実行計画を確認する場合は explain。
    • explain は読み方を覚えておかないと、読めない...。
  • zsh（zシェル）
    • @minimum2scp さんいわく、「zsh を使うと、もう戻れませんよ」
    • 踏み出すと戻れない道のような気がしました → zsh
  • 「etckeeper」
  • 「Varnish Cache」