Edited at

ISUCON8に参加して轟沈した話


ISUCON8に参加して轟沈した話

ISUCON8に参加したのでその時のログ。

まとまりきらないので箇条書きでがっさがっさと残しておきます。


tl;td;


  • ポータルサイトを舐めろ。話はそれからだ。

  • 事前準備は大事。

  • 取れるデータは一発で全て見ろ


チームとメンバー(TwitterID)

チーム : typoの達人


やった準備


  • slackワークグループを作成してメンバとの会話を集約

  • VMを4つほど立ててメンバそれぞれが自習できる環境を用意

  • zabbix-grafanaを建ててすぐ監視できるように

  • ansible,gitを建ててzabbixインストールとバックアップができるように

  • isucon6を軽く解いてみる

  • 役割分担


やった準備(個人)


  • 各種メトリクスの取り方を色々試す

  • Golang勉強する


    • ついでにpprofが出力するpngをslackに投げるツールを書いた。




いざ本番、しかし…


  • とりあえずGo実装に変更(ディケイド+waku)


    • 公式のマニュアルに気づかず10分ほど自力で探してた。



  • 公開鍵を配置、hosts書き換えて相互にsshできるように(でるた)


    • 上手くデプロイする方法が無くて手動...



  • ansible-playbookを流して監視スタート、ディレクトリをバックアップして有事に備える(でるた)


    • バックアップに結構時間かかったので、途中からzabbixだけ並行で流す。

    • tag付けて個別実行に備えていたのが効いた



  • h2oをnginxに変更 (ディケイド)

  • giteaにwebappをデプロイ、以降git管理に(waku)


    • この辺で10:30



  • netdata配置(ディケイド)

  • pprof配置(でるた+waku)

  • デプロイ態勢変更、goバイナリだけ投げるようにした(ディケイド)


    • この辺からデプロイ作業がwakuさん専任になってしまった



  • ク○SQLの撲滅開始(waku)

  • app.goの高速化開始(でるた)


    • ここでgetEventsの修正を始めてしまったのがマズかった…



  • キャッシュ機構追加、があまり効果が出せず(ディケイド)

    -- お昼 --


  • LB挟むと死ねると思われたので、APP+DB の2台体制で挑むことに(でるた)

  • ここからしばらくの間ベンチに失敗するように


    • 2台体制にした際に、初期化スクリプトが正常に動かないトラップだった

    • 幸い、SUZUKIが悪さしている事は即わかったので手動でリセットしてしばらく回してた

    • 気づいて修正できたのは15:30過ぎた頃



  • 並行して高速化を測るが、goぢからの不足により難航……(でるた)

  • SQLでハッシュを求めていた所をgoに移動するもスコア上がらず(waku)

  • アプリのデプロイ作業をJenkinsおじさんに任せるべく構築(ディケイド)


    • しかしアプリ改修に追われて利用できず…

    • 既に16:00



  • そういえばまだ取ってないと思ってSQLのslow_logを取る。(でるた)



    • getEvents ではなくGetEventが遅い事に気づく

    • これが17:00頃。時既に🍣



  • でも諦めるか。ここからgo修正猛ダッシュ(でるた)


    • DBの中のデータとGetEventを見て、次々と湧き上がる疑問と○ソコード。

    • 席数固定だよねこれ? 固定値書いていいよね?!

    • 残席数とか計算で出てくるよね? 席数引くだけだよね?!



  • 18:00、間に合うことはなく無事fail


反省点



  • 何故最初にslow_logを取らなかった


    • これに尽きる。これさえ行っていれば、無駄な場所を効率化して消耗することはなかった。



  • goアプリのデプロイ方法が一人にしかできない状況だった


    • デプロイ方法なら共有できたはず…… 事前にスクリプト書いて全員できるようにしておけば楽だった。



  • golangちから/デバック環境の不足


    • シンタックスエラーとかはgofmtで検出できたのだが、変数の定義ミスとかは検出できる環境がそろっておらずデプロイ速度が下がってた。



  • 最初はマニュアルを読むべきだった -> ポータルサイトを一通り見渡すべきだった。


    • マニュアルに実装の切り替え方法やホストの情報etc、大量のデータが転がっていたが気づけなかった。




改善方法


  • 事前準備をもっと頑張る


    • 具体的には各種ログのON、集積,ローテートスクリプトまではだいたい共通のハズ。全部Ansibleで投下できればかなりスピードアップできそう。

    • golangのデバック環境を作る。DBを先に入れておいてローカルでアプリが動けばなおよし。



  • 競技開始と同時にポータルサイトを全部見る。


    • 環境にログインするのは少し待つ。



  • 監視はできるだけ全部一発で見る


    • それぞれ見比べて、どれが一番重いかを踏まえたうえで挑む。

    • 本当のボトルネックを探すのだ。




やっといてよかったこと


  • 役割分担


    • これのおかげで競技開始から午前中あたりまでは各自が独自にもくもくできて効率よかった気がする。



  • slackに画像をぶん投げるツールをgoで書いたこと


    • golangの扱いが大分わかったし、pprofの画像をコピーする手間が省けてかなり楽だった。

    • 競技終了後に気づいたが、 slackcatなるツールが既に存在する。先人は偉大である。
      こんな感じに投稿される

      slackyomibot.png