自分のチームのISUCONでの戦い方

具体的にISUCONで自分がどういう戦略で進めているのか、書いてみようと思います。他のチームがどういう方法でやっているのか気になるので他の人も書いてくれるとうれしいです。

最初の30分間にやることを決めておく

ISUCONは3人チームで戦う大会です。どういう問題が出るかはわかりませんが、最初の30分間はどういう問題が出てもやることは大きく変わりません。
なので事前最初の30分間にチームメンバーがお互い何をやるか決めて、お互い事前に把握するようにしています。こうすることで最初はお互い黙々と作業をするだけになります。

具体的には以下のような作業分担です。

インフラ担当

• ポータルサイトにログインしてsshできることを確認
• 全メンバーのssh鍵を登録する
• 必要なパッケージなどインストール
• 何もせずにベンチマークを流す
• Go実装に切り替えてベンチマークを流す
• nginxで計測できるようにする（parse.rbを使う）
• ハードウェアの構成を調べる
• 動作しているプロセスを確認しておおよその構成を理解する
• データベースなど各アプリケーションの設定値を確認してgitにコミットする

アプリケーション担当1

• コードを読んでGitHubのissueに書く（cf: スクショ・各パスの役割・どういうアプリケーションか・キーになる関数 catatsuy/isucon7-qualifier）
• 実際に使ってみてどういうアプリケーションなのか把握しつつ、スクショを取って共有する
• パスの一覧を共有
• スキーマ一覧を共有
• キーになる関数があれば特定する

アプリケーション担当2

• 全員共通の~/.ssh/configを作る
• GitHubに手軽にpushできるように、deploy keyをサーバー上のisuconユーザーに入れておく
• コードをリポジトリにpushする
• ローカルで開発環境を作れないか考えて、作れそうなら作る
• MySQL・画像などのバックアップを開発環境用に作成
• デプロイスクリプトを作る

意図と解説

まずインフラ担当ですが、基本的にこの人はサーバー構成をいじることが中心になります。

サーバー構成を複数人で情報を共有するのはISUCONのような時間が限られている大会では難しいので、基本的にこの人以外は複雑な操作をサーバー上では行いません。
また最近は予選でも複数台構成が当たり前になりつつあるので、複数台をどう使うのかなども考える役目になります。

特に本選の場合はフロントサーバーがnginxでないこともあるし、簡単に計測できない可能性もあります。そういう場合はケースバイケースで対応する必要がありますが、これはすべての役目の人に言えることです。

アプリケーション担当1の人はコードを読んだり、そもそもどういうアプリケーションなのかを把握します。
この役目の人が他のメンバーにどういうアプリケーションなのか解説し、問題となりそうなコードの解説を行います。
開始から30分後にそれぞれのメンバーが次に何をするのか考える必要がありますが、この役目の人がその時に非常に重要な役目を果たすことになります。

アプリケーション担当2の人はGitHubにソースコードをpushしたり、開発環境やバックアップなどを作成します。
バックアップは簡単に作れないケースもありますが、ISUCONでは操作ミスで全データを削除するなどの事故を起こす可能性もあります。
ISUCONでは基本的に競技者の操作ミスによる救済は得られないので、そこで負けが確定してしまいます。バックアップさえあれば復旧できるので多少のコストをかけても取りたいところです。

またバックアップを手元で使うことで手元で開発環境を作ることができる可能性があります。
手元で動く開発環境を作れるかどうかでその後の開発スピードにかなりの差が出るのでできれば作りたいです。
例年の傾向で言うと、予選問題については基本的に手元で作れることがほとんどです。ただし本選の場合は作ることが困難なことがあります。
手元での開発環境が作れそうかどうかも含めて、この役目の人が判断します。

またこの役目の人が作れそうならデプロイスクリプトも作成します。Go言語の場合、手元でLinuxバイナリをbuildしてrsyncしてから、アプリケーションを再起動することで大筋作ることができます。

ちなみに私はどの役目をやっているかというと、チームメンバーによって変えています。
初出場したISUCON4とISUCON5ではインフラ担当でしたが、ISUCON7ではアプリケーション担当1、ISUCON8ではアプリケーション担当2を担当しました（ISUCON6は運営側）。

手元の環境をある程度統一する

Go言語を使用する場合はGoのバージョンを事前に合わせておきます。

またgoimportsを使うかどうかでimportの順番が変わるため、毎回コードに差分が出てしまいます。こういったツールで発生するコードの差分がISUCON当日に発生するのはトラブルの元になるので事前に解決しておきます。

また後述するnotify_slackの設定ファイルを事前に各自のマシンに配置しておきます。

情報共有方法

SlackとGitHubを使っていますが、それらのISUCONでの活用方法を紹介します。

GitHub

GitHubのissueではスクショもコピペでできたり、Slackの通知も簡単に設定できます。
GitHubは有料会員になるとプライベートリポジトリを作り放題です。あらかじめ空のリポジトリを作っておき、Slackへの通知設定を済ませておきます。

ちなみにGitHubにはwiki機能もありますが、Slackへの通知が設定できなさそうだったり、スクショのコピペができなかったりと微妙に機能が足りません。
ISUCONでは情報共有する場所が決まっていれば問題ないので、すべてissueで統一しています。

デプロイスクリプト

共有したい情報はこれだけではありません。デプロイ時のログなどもSlackに流したいところです。そんなときに便利なやつを作りました。必要性や使い方などは以下のエントリーで紹介しています。

今回は notify_slack を活用して最小コストでデプロイスクリプトを作成する方法を紹介します。当然設定ファイルは各自のマシンに置いておきます。

デプロイ時に実行する以下のようなdeploy.shを作成します。

#!/bin/bash -x

./deploy_body.sh | notify_slack

そしてデプロイ本体であるdeploy_body.shを作ります。

#!/bin/bash -x

echo "start deploy ${USER}"

# デプロイの処理

echo "finish deploy ${USER}"

こうすると各自のPCのユーザー名でSlackに通知されます。誰がデプロイ中か一目でわかります。notify_slackを使っているので手元で普通に実行しているだけでチームメンバーにも何が起こっているのか伝えることができます。
デプロイ処理に追加する必要があるならdeploy_body.shに処理を追加します。スピードが重要なISUCONでは最適な方法だと思います。

アクセスログの集計結果やスロークエリなどのファイル

アクセスログの集計結果やスロークエリなどのファイルをサーバー上で作ると思います。
もちろんscpで手元に持ってきてからアップロードするとか、色々方法はあると思いますが、ISUCONではサーバー上でサクッと投稿できた方が圧倒的に楽です。

以前はanonymous gistが使えたので、雑にgistに投稿するという方法が使えました。しかし現在では使えず、gistに投稿するにはトークンを発行する必要があります。

これは先ほど紹介したnotify_slackにSlackのsnippet投稿機能を追加したので現在はそれを使っています。

まとめ

最初の30分間の作業内容は事前に決めておくと最初に戸惑うことがほぼなくなるのでおすすめです。

またnotify_slackはISUCONでの情報共有のために作られたツールなので、ISUCONでは大活躍すると思います。是非使ってください。またもし使っている場合は教えてもらえると今後もメンテナンスがされるかもしれません。