wtatsuruの技術方面のブログ

はてなスタッフ id:wtatsuru です。日常ブログはこちら https://tatsuru.hatenablog.com/

ISUCON9 予選に出て敗退した

だいぶたってしまったけど、ISUCON9 の思い出を供養しておく。
サザン不定形ストーリーズというチームで出て、結果は予選敗退だった。
isucon.net

チーム編成と事前準備

出るぞとだけ言ってギリギリまで何もしてなかったのだけど、直前に誘ってもらったチームがあったので入れてもらった。
事前に集まって、多少準備をしてた。これまでチームメンバは出たことあるメンバで組むことが多かったので、コミュニケーションチャンネルなど1から整理していったのが新鮮だった。

  • Alibaba Cloud アカウントを作ってみんなで触る練習
  • GitHub リポジトリ、Slack チャンネル、Scrapboxページなど準備
  • 言語、当日の集合
  • 予習ネタ集める

当日の動き

当日、明らかに一番コード書けないのが自分だったので、足回りの整備と作戦とりまとめみたいな動きを主にしていた。

  • 10:00 ルール読み
    • 他のメンバは、最速でアプリケーション動かしてコードを読む担当、Alibaba Cloud でインスタンス起動して全員サインインできるようにする、などやってもらってた
  • 10:30 nginx ログ設定だけ入れて初期ベンチ回す
    • alp でログ解析するところまで。alp 予選前日にリリースされてるし、Starも増えててISUCON専用ツールとして存在感を増している感がある。
    • 他のメンバは、コード読みとデプロイ整備をやってもらった。デプロイスクリプトは前日にひな形置いてたやつベース。
  • 11:00 作戦会議
    • 各自の作業概要共有、大まかな方針確認。
    • ここでキャンペーン試行錯誤すべきか、なども会話できた。順調だった。
  • 初手の改善
    • 自分は、デプロイからスムーズに動くまでをやってた。手元からログ解析打てるようにする、デプロイ直しつつ nginx で static file 配信、ついでにルーティングファイルからエンドポイントごとに nginx location 分離。画像アップロード先修正忘れてたので対応したり。
    • 他の2人で N+1 ペアプロ、カテゴリを初期化時にオンメモリで持つように。
    • キャンペーンの値もちょっといじってみて様子を観察。
  • 13:32 作戦会議2
    • やることはやった段階での作戦会議。
    • キャンペーンやると購入リクエストが殺到する、/buy が遅くて売上られていない、外部APIがたまにタイムアウトしてる、ということはわかってたので、対応を検討。
      • API リトライって話も出てたけどなんでやらなかったんだっけ...
  • 複数台化、リクエスト試行錯誤
    • 自分は粛々と作業して複数台化。MySQL 外部からアクセスしてアクセス先IP固定、初期化やアップロード関連など一部の処理だけ01に振る、など粛々と作業。
    • アプリケーション的には、トランザクションが長い対策として for update 消せるやつは消したりしてた。
    • innodb_lock_timeout = 3 で意外と簡単にタイムアウトしてくれた。実際に使ってみたのは初めてだった。
  • 14:30 作戦会議3
    • 複数台化の残作業。カテゴリをオンメモリ化した関係で全台に initialize 渡す必要がある > ここは自分が担当
    • 購入リクエストのトランザクションがとにかく長いので、「購入中」というステータスを作って分離することを考える。がっつりペアプロしてもらった。自分はこっちは戦力外。
  • 16:00 作戦会議4
    • /buy 分割したことでボトルネックが移った。買えないときに素早く失敗してる。
    • item 関連、user 関連タイムラインが遅いのでインデックス貼っていく。/login は遅いけど bcrypt だしレギュレーション的にどうしようもないねって会話した。
  • 17:00
    • 複数台でリクエスト受けた瞬間に fail 多発
    • 並列でAPI投げてる？など疑って httpclient 使いまわしてみたり
    • キャンペーンガチャやってみても同様に fail が多発する
  • 18:00
    • 最後に fail しなかったそれっぽいスコアで終了。たしか2700くらい
    • 3710 がベストスコアだった。

振り返り

  • 準備はまあまあよかった
    • 起動してデプロイしてログを観察する、まで含めて
  • 問題は適度に複雑でよかった
  • 最初は状況認識はできていた
    • 上と合わせて、良くも悪くもISUCONに慣れてるということ
  • 途中から焦りがでた
    • APIのリトライ、あとでやろうとして忘れ去っていた案があった。
  • 落ち着いてシステムの理解ができていなかった
    • ホワイトボードに描いてコードも眺めてたつもりだったが、結果としては状態遷移の考慮が甘かったのが敗因となっている。
    • ユーザ視点、システムが実現しようとしていること、を落ち着いて考えることが必要だった。自分はそこができた立場だっただけにちょっと悔しい。
  • Go 言語にみんな慣れてなかった
    • 仕事で使い込んではいないメンバ。APIエラーをダンプするだけでもそれなりに時間を食ったり何かとアクションが遅かった。
    • 自分はコード書くの遅かった
      • ミドルウェアあたりはサクサクいく、サーバサイドのコードに手を入れようとしたときに何かと遅れる。
      • 最近自分で手を動かすことが減っており、趣味においても技術系やそれ以外のこと含めインプットに比重が置かれている。多少は手を動かせる状態でありたい。

まとめ

こういうアドレナリンが出るイベント、たまにはいいなと思った。現場感覚持っておきたい。そろそろ決勝に行くのもきつくなってきた最近だけど、もう一回くらい行きたいな。

はてなで一緒に働きませんか？