ISUCON 夏期講習 2020 を開催しました（資料と動画あり）
Iikanjini Speed Up Contest
外形仕様を変更せずに高速化
- レスポンスタイムが小さい
- スループットが高い
- リソースの使用率が高い
パフォーマンスチューニング → 計測し、ボトルネックを見つける
一番遅いところを直さないといけない
「サービス」「チーム」「開発」のボトルネックを解消するコンテスト
チーム参加#
3 人分担においてはコミュニケーションのコストが高い
App - App - DB/Infra バランス型
App - DB - Infra インフラ重視型
- 全員の手が止まらないように作業の分担
- お互いの作業の邪魔をしない
- 間違ったらすぐ戻すことができる開発環境
Tips#
闇雲にコードを書かない
最初 30 分はコードを書かない。まずはドキュメント
レギュレーションを読む#
レギュレーションの読みあわせをしといたほうがいい
- ストレージの永続化
- ssh スニペット
- 当日マニュアルを読む！
- 再起動試験がある(インスタンスの順番はランダム)
- GitHub のプライベートレポは作っておく
アプリケーションを読む・仕様を理解する#
まずは当日公開のマニュアル・ドキュメントを読もう
ユーザーストーリーでイメージを掴む
ベンチマークの動作を確認
スコア計算を確認
練習#
言語#
言語を 1 つに決めてチーム内でバージョン(最新版を推奨)を揃えてインストールする
Go が強いと言われている。(慣れてる言語がチーム中で合えばそれを採用)
お互いの環境の差を理解しておいて config を書く
チーム全員が活用できる開発環境を
pyenv goenv docker ... docker 使うならキャッシュを活用できる Dockerfile を書く能力が必要
作業#
作業領域を決めておく
飛び道具(プロキシ)作ったりした。分担してると安心できる
開始 50 分でやることを予め決めておく。
紙に ER 図を書いて、チーム内のドキュメントを作成した Zoom で常に繋ぎっぱなし・ずっと画面共有ペアプロとかいいかも
よくある作業(ssh nginx mysql config)は手順を確立しておく
環境変数の扱い重要
情報共有#
メトリクスなどを Slack・GitHub issue にすべて共有
大きいパッチはプルリクへ(プルリクページから revert できる)
GitHub 落ちたときの代替サービス準備しといたほうがいい?
デプロイ#
デプロイは shell script で 1 コマンド
デプロイ・ベンチマーク担当 1 人決めとく
渋滞しないワークフロー設計をチーム内で行っておく
ベンチが通ったらスコアをタグ付けした
コミット#
コミットは小さく
コミットログをきちんと書く
ISUCON は fail で 0 点になるので必ずロールバックできるように
コミュニケーション#
HRT
謙虚・尊敬・信頼
お互いのできること・得意分野とかの共有はしっかりと
相互理解・議論できる仲に
過去問を解くときはスコアよりもチームビルディングを意識
ボトルネック#
ボトルネックの見つけ方
計測結果の分析#
ベンチマークスコアは高速化の指針にはならない。気にしない。
各言語、DB のどこにボトルネックがあるか計測結果から分析できるようにしておく
仕様の理解・スコア評価の理解#
過去問の講評と解説を読んでストーリーを理解してコードを読んでみる
重要なエンドポイントはどこか、遅くていいエンドポイントはどこか理解する
キャッシュは何秒までどれくらいしてもいいのか
高速化手法はいっぱいある。パターンを把握しておく
焦らずにドキュメント・コードを読む
ベンチマーク#
- 開始直後
- 計測系挿入後(計測は遅くなる)
- 施策投入後
FAIL したら revrt か修正する。FAIL を放置しない
直らなかったら戻す
GitHub#
プルリクの revert がページからできるのは楽
練習して慣れよう
過去問#
ISUCON9 予選おすすめ
スコアよりもチーム習熟と手順の確認を意識しよう
作問してみるのは良い練習になる
ベンチマーカーを書いてみるとボトルネックの考え方が身につく