読者です 読者をやめる 読者になる 読者になる

まいんだーのはてなブログ

はてブなのはてブロなのどっちなの

ISUCON3 本戦参加報告

引き続きチーム「50ms or die.」で本戦に参加してきました。

f:id:myfinder:20131109100811j:plain

謝辞

はじめに運営の皆様、出題の @fujiwara さん、サーバ提供のデータホテルさまには予選含め、限られた時間でいろいろ絞り出して戦うという、とても得難い機会を頂けたことを感謝申し上げます。

結果

1800なんぼでfailという結果に終わりました。いわゆる「die.」です。
スコアレスでdieしてしまった前回よりはマシだけど、結果に結びつかなかった点は反省して次に繋げたい。

ただ、前回のような絶望感はなく、いかに時間内にやり切るかという挑戦ができたのでとても充実した時間になりました、この点は自身進歩したなと感じてます。

詳細はチームの @__kan さんや @bonnu も書いてくれると思いますが、私も覚えている限り何を思って取り組んだかといったあたりはまとめておきます。

やったことのまとめ

  • プロファイリング

@bonnu さんに Devel::NYTProf を使ってどういうところが問題になりそうか調べてもらいました。
結果としてコード読んだらすぐわかるconvertまわり以外は特に何もなかったという結論に。。

  • DB の slowlog チェック

コード読んだら join したりサブクエリ発行してたりする所があったのでこの辺怪しいかもと思って slowlog 出したり explain して確認したけど、まったくボトルネックではなかった。。

  • 課題解決へのアプローチ

DBもアプリもボトルネックではないので、配信をスケールさせること、という認識は昼までのプロファイリングやslowlogを見てわかったので、まず1台で高速化し、その後スケールアウトさせるアプローチを考えました。

  • 時間内に出来た実装

複数台でリクエストを受付、投稿された画像がどのサーバに入っているかをDBに入れておき、reploxyするという戦略で実装していきました。
が、最初の「1台で速くする」というアプローチを引きずり、初期データの収容先を1台に集中させてしまったため、そのサーバがサチる状況になっていたのは明らかにミスでした。
これを解消するために初期データを散らそうと対応を始めた所でタイムアップして終了でした。

当日までの流れ

以降は上記にまとめた内容がどんな流れで進んでいったかという記録です。

前日まで

予選の反省を踏まえて、できるだけ即手を入れていくのではなく、素の状態からボトルネックを列挙して優先度つけて潰していこう的な方針を確認しつつ、事前に「まずやること分担」を決めた。

  • サーバのログイン環境/nginx化/nginxのログ/mysqldumpslowをdocrootにおいちゃう対応: myfinder
  • 一発デプロイ/データクリーンアップ対応: kan
  • NYTProf等のプロファイリング対応: bonnu

あとgithubにprivate repoを作ってwikiを使えるようにしたりなどはしておいた。

当日の昼まで

奥の会議室が確保でき、他のチームを気にせず喋れたのでチャットログはほとんど残っていないけど、プロファイリングを取ったりslowlogを確認したりをまず進めた。

結果的にプロファイル見てもslowlog見ても問題になりそうなのがsystem関数呼んで変換しているところが圧倒的すぎたし、DBのデータサイズも大したことがなかったのでこのへんは全くボトルネックにならないということはすぐにわかった。

なので、この時点で「帯域小さいからスケールアウトさせて、サーバ間での画像共有どうするか」に問題を絞って構成を皆で考えて進めればよかったのだが、1台で速くするという所をすぐ捨て去ることができなかった。

当日の昼以降

1台ではどう頑張ってもアレ以上行かないね〜となったタイミングで、複数台化に取りかかりはじめた。これが15時〜16時頃だった記憶。
複数台でリクエストを受付、投稿された画像がどのサーバに入っているかをDBに入れておき、reploxyするという戦略を取るつもりだった。
時間内にできた実装では、初期画像のリクエストがすべて1台に集中し、その1台が帯域を食いつぶしてスループットが上がらないという問題を抱えていた。
初期画像はすべてのサーバに置いていたので、すべてのサーバで初期画像の保持を分散させておけばよかったわけだが、この時点で残り30分だったため、あがいたけど結局間に合わなかった。

構成変更の判断が遅かったため、大きくスコアを伸ばすところに至らず時間切れという結果に。

おわりに

DB設計変更、アプリケーションの書き換えやMySQLのチューニングが今までの主戦場だった所から、今回は大幅に変わった点は脱帽で、 @fujiwara++ でした。
まさに総合力勝負だったと思います、引き続きこの戦いを生き抜けるよう研鑽に励みたいと思っております。