ISUCON8 で予選を突破したのでまとめる

ディメンジョナルハイソサイエティぬれねずみというチーム名で ISUCON8 に出場しました。言語は Perl を選択しました。結果は 40,867点で、13位 / 528組。

技術的なことについては、すでにチームメンバーの2人が書いてくれているので、自分からは主にそれ以外のことについてまとめます。チームメンバーのブログは以下：

メンバー構成

同じ会社の同僚3人で出ました。

id:hitode909
- アプリケーションエンジニア
- Perl めっちゃ書ける、普段から業務でバリバリ使ってそう
- 出場は3回目
id:shiba_yu36
- アプリケーションエンジニア
- Perl めっちゃ書ける
- 初出場
id:takuya-a
- アプリケーションエンジニア
- Perl は数年書いていたけど、最近はずっと Python を書いている
- 初出場

みんな普段は Web サービスの開発とかをやっています。全員アプリケーションエンジニア（サーバサイドもクライアントサイドも書く）で、オペレーションが専門のエンジニアはいませんでした。自分はあとの二人と一緒に仕事をしたことはなくて、勉強会を一緒にやったりしたくらい。

予選の申込み締切直前にたまたま Slack にいて、偶然暇だったら出ましょう、って言って組みました。当日の予定が空けられるか怪しくて、みんな出れる確率 5% くらいだねって話していたけど、意外と条件が整って全員出られました。

ジェネレータでチーム名を決めたら「ディメンジョナルハイソサイエティぬれねずみ」っていう名前になったけど、ディメンジョナルもハイソサイエティも表記揺れがあって入力が難しいので失敗でした。

事前にやった準備

予選1週間前の昼休みに話し合った
- GitHub のプライベートリポジトリを作り、その場で issue や Wiki を作っていった
  - あとでそのトピックについて会話できるように
- 言語を決めた
  - Go を予習しておいて、問題を見て決める案もあったけど、結局事前に勉強する時間は取れなかった
  - みんな慣れていて運用知見もある Perl でいこうという結論になった
- デプロイ方式を決めた
  - 去年参加した id:hitode909 がよかったということで rsync デプロイに決めた
id:shiba_yu36 が事前に素振りしたり、やることをまとめたりしてくれていた
- 各種スクリプトを整備してリポジトリに置いたりしてくれた
  - デプロイスクリプトは去年 id:hitode909 が作ったものを id:shiba_yu36 が整備
- 当日やるオペレーションを Wiki にまとめてくれた

事前にやってよかったこと

やることリストの整備
- id:shiba_yu36 がメインでまとめてくれたリストが役に立った（参考）
- リスト化しておくことで安心感が生まれ、落ち着きにつながった気がする
rsync デプロイスクリプトを整備
- 手元で修正したものを本番環境ですぐに試せ、高速にトライアンドエラーできた
  - git push したものを各サーバーに pull させる方式だとタイムラグがある
- 今回はベンチマーカーもすぐに回る環境だったので、うまくはまった

予選当日にやったこと

コードやテーブルを眺めつつ作戦を考える
- スキーマ定義を眺めて、テーブル間の関係を把握し、ホワイトボードに描いた
  - MySQL に入って各テーブルの件数を COUNT(*) して追記した
- 思いついた作戦はどんどんホワイトボードに書いていく
  - とくに効きそうなものに + や ++ をつけていった
ペアプロ
- 残りの二人のメンバーのほうが手が速いので、「ペアプロ役やります」って宣言した（自分はほぼコードを書かなかった）
- 基本的には、一人が作業しているあいだ、残りの二人はペアプロ、という動き
- ペアプロ開始時に情報共有する（手を入れようとしているエンドポイントについて、わかったことなど）
- 実装者は安心してコードを書け、結果的にチーム全体のベロシティが最大化したと思う
- 手を動かさない人が最低一人いることで、チームに落ち着きが生まれた気がする
ベンチ中は全台ぶんの dstat/htop/アクセスログ/スローログ/アプリケーションログを眺める
- dstat で全体的なリソースの状況をみる
- htop で各 vCPU の利用率、メモリ、スワップ、負荷の高いプロセスをみる
  - とにかく CPU とメモリが厳しいことが一瞬でわかった
- alp でアクセスログを集計
  - どのエンドポイントが遅いのかの絞り込みに役立った
- pt-query-digest でスローログを見る
  - 今回は MySQL がテーマだったので大活躍した
- journalctl -f | grep -v sshd でアプリケーションなどのログを眺める
  - 今回は CentOS だったので journalctl
- まずはサーバを役割ごとに分けてワークロードを分割し、それぞれの詳細な様子をみよう、という作戦を立てられた
- MySQL だけに負荷がかかるはずのサーバで Plack が上がってきていておかしいとかがわかった
- ホワイトボードの常に見えるところにサーバの構成図を描いておいたのもよかった

今後 ISUCON に参加するときにやるとよさそうなこと

最初のオペレーションが一段落するタイミングで状況共有タイムを入れる
- どういうアプリケーションなのか、データ構造はどうなっているのか
アクセスログをみる
- サマった数字だけじゃなくて、生ログを見るのも大事
各種ログや htop などのパフォーマンスモニタはずっと見えるところに出しておく
- ベンチ中のシステムの挙動をいろんな側面から見られるように
MySQL の general log をみる
- なんかいい感じに集計したい
エンドポイントのルーティングのところにコメントを書く
- なにをするエンドポイントなのか、注目ポイントなど
処理系のメモリの状態を見られるようにしたい
- Perl だと難しそう
Kibana を使ってアクセスログを見られるようにしてみたい
- いい感じの ISUCON 専用ダッシュボード作ってみたい

最後に

素晴らしい問題と環境、そして手厚いサポート体制を用意してくださった ISUCON8 運営の方々に感謝いたします。ありがとうございました。本戦でもよろしくお願いいたします！

stop-the-world

takuya-a のブログ