#isucon 本選惨敗！！！！

by @dekokun on 2013/11/09 15:33

Tagged as: contest.

今日はISUCON本選でした！！！！！

後輩二人(@jyegan, @Altsencturely)と参加してきました！！！

今回は私のせいで相当時間をロスさせてしまい、最終的にfailして懺悔懺悔です！！！！(懺悔内容は最下部に記載)

が、まぁ、今回もやったことなどをまとめていきたいと思います。今回は、私が発生させた謎のエラーにハマり続けたのであまりいろいろできなかったのですが…

failしなかったチームは7チームでして、一応順位としては8位(まぁ、8位かつ最下位なわけだが)になるんですかね

今回のお題アプリケーションについて

  • 画像投稿版Twitterみたいなもの
  • 公開範囲を決めて画像投稿可能
    • これにより、安易に画像の静的配信はできませんよ
  • サーバが1台あたり100Mbpsに絞られているという話だったため、画像投稿サイトということもあり、そこがボトルネックになるかなぁと思っておりましたがそれ以前の問題だった(ように見えるがそもそも通信量とかみてなかったのでなんとも)

基本的にやっていたこと

xhprofでのプロファイリング

今回も素晴らしい効果を発揮する…はずでしたが、最初に「execが圧倒的に遅い」というところが判明した以降は、そのボトルネックを最後まで解消せずに終わってしまいました…

New Relicでのプロファイリング

New Relicのおかげで画像表示部分が圧倒的に遅いですね！ということがわかりました。xhprofでの結果と併せて、execが遅いせいですね！という結論が出た以降状態が変わらず終わりました。 New RelicといえばRubyで注目されがちですが、本来はPHPでもめちゃくちゃ便利なツールなんですけどね。今回はボトルネックの再確認ツールというくらいの活躍ぶりでした。

ルーティング判別部分はFuelPHPで３種のprofilerを使ってみたを参考に、設定しました。

スロークエリログの解析

「DBが全くボトルネックじゃないね」ということがわかった以降何も進まず終わった

その他やったこと

ある程度時系列順に

  • 全グループメンバーから全サーバ及び全サーバから他の全サーバに対してsshのパスワードなしで接続できるように設定
  • 各自の開発環境を同じサーバ上の別ポートで立ち上げ、git管理した
  • git pullによる各サーバへのデプロイ環境を構築した(“isu deploy”コマンドを打つことによって開発環境からpushして全サーバへのデプロイ可能に)
    • が、結局サーバは1台だけしか使えず終わった…
  • 上記“isu deploy”以外にも予選から使用していた“isu”コマンドの機能拡充
    • “isu allcommand”で全ホストにコマンドをばらまくとか、isu currentで前回のベンチマーク結果を取得できるとか、“isu slow-show”でmysqldumpslowの結果を出力して見られるとか
  • my.cnfを編集し、127.0.0.1以外からもアクセス可能なように修正
    • 「mysqlDBの中のuserテーブルの中ではちゃんと設定されているのになぁ」などと若干ハマった…
  • 上記各種プロファイリングの設定
  • 思えばここまではまだ順調だった…
  • 画像にアクセスが来る度に画像生成していたため、一度生成した画像はディレクトリに置いて次からのアクセスはそれを返すようにした
  • このあたりから、以下懺悔しているような状態が発生しベンチマークが失敗し続けいろいろ巻き戻したりが始まった。ラスト1時間くらいまでベンチマークが失敗し続けていた。辛かった
  • 最終的に、ラスト30分くらいで、「DBではなくexecがネックなので他のサーバを使用すれば使用した分だけスケールするのはわかりきったこと！！スケールアウトしよう！ローカルに保存している画像はMemcachedにしよう！」という実装をガツッとやりましたが、一部うまくいかず結局スケールアウトはできず
  • 最終的にfailして終了
  • なお、Memcachedが1キーに対してデフォルト1MBまでしか保存できないのは知らなかった
    • この辺りはいい勉強になりましたね

感想

  • 前回予選でちょっと良い成績だったからと言って色々調子乗った発言(「LINE選抜を抜けそうだったが抜けなかった。次は抜く」だとか「白金動物園に勝てて嬉しい」とか)を繰り返していましたが今回ダメだった。めちゃくちゃ悔しい
  • 「くらげとみかんと江戸幕府」チームが前回PHPで出場していたため、「PHP仲間だー」と思っていたら今回PHP実装は我々だけだった
    • これに伴い(?)最後までApacheで戦ったのも我々のチームだけでしたね
    • PHPの威光を世に知らしめたかったが全くもって力及ばず
    • 「くらげとみかんと江戸幕府」は今回はRubyだったとのこと
  • 優勝チームのtagomorisさんとお話しまして、「最初の一時間半くらいはひたすら戦略をねっていた」という話を聞き、最後に勝つのはちゃんと最初に戦略をたててチームかという思いが強く残った
  • 来年(あれば)必ずリベンジしたい
  • 問題作成、運営、会場及び賞金提供、サーバや食料提供の皆様ありがとうございました！！
  • 私はいつも基本的にぼっちなのですが、今日は懇親会で積極的に皆さんとお話出来てよかったです
    • くらげとみかんと江戸幕府の皆さんとか、山形組のかたとか、LINEやCOOKPADの方々など

チームメイトへの懺悔

ベンチマークスクリプトのオプションを誤り(サーバ指定するオプションとワークロード指定するオプションを逆にみていた)、「よし、ワークロードを2に増やそう」と言ってワークロードではなくアクセス先のサーバIDのほうを編集してしまい、その後、その変更によってまだアプリケーションが動いていないサーバ2に対してベンチマークが走りベンチマークが失敗し続け原因解明に2~3時間くらいかかってしまったのではないでしょうか…

ベンチマーク実施した瞬間になぜか正しいサーバにもアクセスが来ていたように見えていた(原因は不明。UAはちゃんとISUCONのベンチマークツールだったように思っていたが。まぁ当時は焦っていたからあまり記憶はあてになりませんね…)ため、全然きづけなかった　…「何度やってもfailし続ける！しかもログ上では200番を返している！！！gitで最初の状態にアプリケーションを巻き戻してもダメ！！！！」という感じだった。

すみませんすみません。。。これのせいでかなりの時間を無駄にしてしまいましたね。。。

懺悔からわかる反省点

  • ベンチマークをラップするようなコマンドを作成しており、それが誤っていたせいでベンチマークが失敗し続けていましたのですが、ラップするものを皆が見られる状態にあまりしていなかったのが良くなかった - 一応、“isu vi”コマンドでラップスクリプト自体を編集できる機能はあったが、若干周知不足
    • それ以外でも、isuコマンドは機能追加してもあまり周知することができていなかった
  • ベンチマークのラップコマンドを編集したことを周りに伝えなかったのが一番悪かった
  • ベンチマークのラップコマンドをWebUIと一緒にバージョン管理していればよかった。そうしていなかっったため周りが変更に気づく土壌がなかった
  • 他のサーバのアクセスも監視していれば間違えに気づけた
  • オプションを変更したらちゃんと動きを確認しましょう

一日一日を大切に、反撃の牙を磨くのです！！！！！！

comments powered by Disqus