かきあげせいろはラーメンがたべたい

技術プログラミングいろいろ記録メモ備忘にゃーん!

【祝】ISUCON14に参加しました【前回より100倍以上の点数】

タイトルは空元気です。前回は0点でフィニッシュだったので、0 × 100 = 0となり今回が100点とれていれば"100倍以上"を達成したことになります(血涙)

練習

今回は練習時間がとれませんでした。自分がもっているチートシートと、前回/前々回のやったことメモを見返しただけで本番に臨みました。

やったこと

やったことは前回までは手動やったことログを記録していたのですが、前回までで記録は十分かなと感じたことと、今回練習が不十分であることからさぼることにしました。なのでここに記載しているのはほんのりした記憶です。

  • 10:00
    • マニュアルなどを読む
    • CloudFormationで環境構築
    • sshしてDBのテーブル確認
    • コードの場所を確認
    • alpなどの計測ツール準備
    • 初回ベンチ(700~800点ぐらい)でtop確認
  • 11:00ぐらい
    • topでMySQLの負荷が高いのでここから着手
    • chair_locationsテーブルにchair_id, created_atの複合index追加
    • ride_statusesテーブルにride_id, created_at, statusの複合index追加
    • ベンチで1100点ぐらいになる
  • 12:00ぐらい
    • まだtopでMySQLの負荷が高く、query-digester で次に負荷が高いSQLがride_statusesテーブルから最新のレコードを取得するものだった
    • 上記のSQLは/api/chair/notificationや/api/app/notificationから呼び出されており、alpでもこれらのAPIの呼出し回数(ベンチ一回あたり)が非常に多かった(多い方で8000回ぐらい)
    • 最新のレコードがない場合はデフォルト扱いのレコード?を取得する実装になっていたので、一回のSQLで両方取得するようにしたが、点数に変化がなかった。このことから、デフォルト扱いのレコード?を取得する部分が大したものではないと判断し、APIの呼出し回数を減らせないか考えるように
    • ここでSSEについてマニュアルで言及されていたことを思いだし、SSE化を進める
  • 17:00
    • SSE化できたが点数が700点ぐらいになる
    • ロールバックするか悩んだが、SSE化からさらにチューニングしたときに点数が上がるのでは?と考えそのままにする
    • 明確にボトルネックとなっている部分を見つけられず、残り時間が少ないので全てのテーブル定義を見て(実装はみない)それっぽいindexを貼ってみたが点数がかわらず

ふりかえり

  • 練習時間の確保
    • 今回はほぼなかった。素振りしていなくて、今までのメモなどを見返してイメージしてただけ
  • 前回の反省点を改善していない
    • 完全にnext actionをissue化していない問題。競技が終わると燃え尽きているのが原因
  • システムの要素を理解していないし使えていない
  • 仕様がなぜあるのかを推察できていない
  • SSEでちょっと手が止まったが、問題の大物だと判断しがんばる決心ができた
  • alpとスロークエリだけでは計測が正しくないかもしれない。去年もだがちゃんとボトルネックを特定できてるかどうかも怪しいので、点数が伸びていない可能性がある
  • indexが機能しているか怪しい(適切に貼れていない?)
  • 仕様を調整する方向に頭が働かなかった
  • 他の人の回答をみても、なぜそれをやっているのかを理解できていない
  • ベンチのログがなんもわかってない(WARNとかはせめて向き合うべきに思う)
  • goのコードの場所
    • systemctlの定義ファイルからバイナリの場所がわかる
    • 最初に開発用のコードが置いてある場所が実際に動いているコードだと誤解してしまった
  • コードをローカルにダウンロードして進めるか、サーバー上でvimでがんばるかを明確に決めた方が良さそう。今回はサーバー上vimでやってた(ただ大きく不自由だったわけではないので、このままでよいかも?)
  • SSEに立ち向かったのはよかったが、SSEをやるべきという確信を得ていない
    • SSEで書き換えるエンドポイントから呼ばれているSQLの回数がボトルネックだったが、書き換えで呼出し回数が減ることを理解していないままやった。減るのか?
  • マニュアルを呼んでいるが、理解が浅いように感じる。
    • 呼んでいるだけで頭に入っていないというか、チューニングの要素として扱えていないような
    • 書いてあることを写経というわけではないが、図で書いてみるぐらいやっても良いかも
      • 前回は音読しているが、これでは足りていないかも
    • 練習時点で一旦やってみて、どれくらいの理解度が理想?なのかを把握しておかなければ、本番でどれくらいの理解をすればいいのかもわからなそう
  • 自分のメモ(チートシート)は手順だけを記載している。使い方や、コマンドのカスタム(alpの-m(正規表現でリクエストまとめる機能))などもサンプルだけではなく、どのように使うかや、前回ドのように使ったかなども書いた方が良いかもしれない
    • 今回はdstatをインストールしているが、手癖で慣れているtopを使っておりdstatのことを忘れてた
      • パッと使い方を思い出せるようなメモがあればよかったかも
        • そもそも慣れるぐらいに素振りしておく
          • 今回は準備に時間がとれなかった。こういう時もまああるのでやっぱり使い方メモとかあったほうが良い
  • ベンチによって副作用があることを理解していなかった
    • 少なくとも今回はレコードが増えていた(たぶん)
    • 十分にチューニングできていれば複数回のベンチぐらいならちゃんと捌いたり出来るはず
      • シミュレータのマッチング部分が動かなかったのは、初期状態からベンチを動かしたあとだとこうなるらしい(自分で未確認)
    • なぜかベンチは綺麗な状態を維持してくれているという思い込みがあった
      • ログローテートとかを自分でやってるのに、レコードは別だとなぜか思っていた
  • 初めて0点フィニッシュを脱出した!!!!!!!!!

感想

練習をしていない罪悪感もあり、終わった後にズーンとなっていた。練習できていないことは仕方がないが、この記事でふりかえった内容を全部とまでは行かなくてもある程度解消できるようにしたい。今回一番やりたいのは理解するという部分。講評やコードが公開されたらちゃんと中身を見て、他の人のチューニングを意図を理解できるところまではがんばりたい!

ひいん...