ISUCON4 予選 に出場した

Perl

ISUCON4 の予選に出場しました。 同じ大学サークルの友人に釣られ、もう一人後輩を釣って3人で出ました。 アレがアレなのでチームについてはアレします。

予選まで

メンバーを集めて2回勉強会を開きました。

1回目

  • 計測周り、memcached、クエリ高速化についてそれぞれ喋る
  • ISUCON3予選問題をやる

2回目

  • ISUCON3予選問題の前回の続きをやる
  • 当日の動きを詰める
  • アプローチの立て方を研究

本番では自分はアプリケーションサーバ側でやれることをやる感じになったので、9月中はそのことについて調べたりしていました。

EC2のインスタンス用意して練習したかったんですが、クレジットカード持ってないですし、Vプリカ買う余裕もなくて結局やりませんでした。

運営さん！予選もchefのcookbook用意してください！

予選本番

とにかく計測第一ということを勉強会で言われたので、とりあえずアプリを触ってみつつ、スロークエリログを見たりdstat見たりアクセスログみたりしてから動き出しました。

自分がやったこと

  • PSGIサーバをStarmanからStarletに変更
  • テーブルにインデックスを張る

失敗

  • nginxとappの通信をTCPからUNIX domain socketへ
    • app側は変更してサーバ周り担当に投げたものの結局反映させず放置
      • とにかく一番遅い部分を直そうと放置してしまったけど直せばよかった
  • banとlockの判定が重いので高速化
    • 遅いクエリがやっていることをそのままPerl+memcachedに落とし込もうとして失敗
    • ベンチのログを見ると、ログインできないはずがログインできてしまっているのでロジックのバグを疑って再実装
    • 同じエラーが出続けるのでロジックをひたすら弄る
      • 今思えばキャッシュ更新のタイミングが悪かったのでは……

こう見るとなにもしてないですね…… banとlockの判定処理を修正するのに時間かけすぎました。

反省

何度も気をつけようと言っていた無茶なアプローチをやってしまったのが一番くやしい！ ロジックの再実装はまず既存のコードを完全に理解した上でコーディングしなければならなくて、とてつもなく時間がかかるし、デバッグも大変です。 初期実装自体は、よほど酷い何かが無い限り、弄らないで進めた方がよかったのかもしれません。

1つの問題に3人でとりかかってしまっていたこともあったりと、折角のリソースを生かしきれていなかったように感じました。 それぞれが独立して動ける体制が最高ですが、それには全員が技術を持っていないと難しいとも思います。

受け身な感じで単に投げられたアプローチをそのまま実装するといった思考停止していた場面があったので、落ち着いてそれが正しいのか流されず判断できればよかったです。

感想

IT系の競技というと競技プログラミングくらいしか知らなかったので、こんな形で競えるのかという意外性がとても面白かったです。

ACM-ICPCに出た時も感じましたが、チーム制の競技はチームワークが何よりも大事だと思います。 チームで作業している以上、技術よりチームを回す方が大切になります。 コミュニケーションはそれなりに大きいオーバヘッドですが、生かせればそれ以上にいろいろなことができるようになれる気がしました。

もちろん技術不足も作業中に何度も感じました。 特に、問題が起きた時にパッと思い付く原因の可能性がある箇所の数が少ないと、そこから何もできなくなってしまうので、もっとトラブルに遭遇できるようにいろいろ動かしてみたいです。