# ISUCON座学
8時間で基本終わらない量のことをやってる
計算リソースとしては1-3台のLinuxサーバーが渡される
リソース配分は自由

パブリッククラウドを使用する場合(予選)MachineTypeが予測できるが、特定企業さんが提供してくれてるクラウドの場合(本戦)ではMachineTypeなどは不明。
CPUアーキテクチャに左右される可能性はあるかも？急にGravitonが来るとか

## 強いチームがすること
fujiwara組長みたいに強い人は何やってるか(練習はしていないそう)

## 強いチームがしないこと
何もわかないけどとりあえず遅いっぽいとこを潰す、というのはしない
- パフォーマンスに効くことしないと意味ない
- revertしてしまう可能性
- 遅いっぽいとこがどこで効果発揮したか分からないと巻き戻りできない
- 勝利者インタビューで「何が効いたか分からない」はあり得ない
- 分からないことやってるウチは勝てない
- デプロイに1分以上かけない
- デプロイします → デプロイしましたのリードタイムを1分以内に
- gitのコマンドでもたついてる暇はない
- サーバーにGUIのgitはない
- gitのデプロイはpullだけでしょ、てことはない
- 分散協調して動くようにしてする変更が必要
- 試行回数が減るほど情報量が減る
- 使い慣れたミドルウェアのconfigを1から書かない
- 大抵の参加者は自分用の秘伝のタレを持っている
- システム次第で切り替えるところは注釈を入れておくと、当日の調整ノブになり、当日調整できる
- 全部眺めてる暇はない
- 調整ノブをいじってベストパフォーマンスの状態を目指す
### => 事前にメジャーなミドルウェアの秘伝のタレを作れ！！！！
- ISUCON用のデプロイスクリプトを作って実行する
- portalのスクレイピングを当日やったりは流石に間に合わない
- 準備/把握に時間かかることはしない
- やったことがないことをやらない
- 8時間を新技術習得に充てる時間はない
- 練習せずに臨むならいつも仕事で使ってるものを
- 練習して『いつものやつ』をチームで作る必要がある
- どうしてもやったことがないことをする必要があれば。"やったことがないことをやること"をうまくなろう
- MySQL5.6 => 8 とか上げて動かなかったらどうするの？のリスク取り
- 慣れてるものでやる方が強いに決まってる

## 当日のタイムライン
- 9時に起床する
- チーム間のコミュニケーション手法が決まってる
- Githubのリポジトリ
- Slack/Discord
- Zoom/GoogleMeet
- ペアプロする時の方法
- VSCodeRemoteが楽かも...?
- Pushした時の通知などどうするの、とか
- 10時
- レギュレーションとマニュアル読む
- アプリケーション仕様書読む
- **他にも色々。。。。**
- DBスキーマがどう定義されているか調べる ← 重要そう
- memcachedと思っていたものがmysqlだった
- デプロイをどのようにするか決める・構築開始
- 使われているミドルウェアの種類とバージョンを調べる
- 使っているサーバーのスペックを各台調査する
- 初手何も考えずベンチマークをとりあえず回す。何も考えず一旦動かせ。言語切り替えもやる。マニュアルに書いてある。
- 11時
- ドキュメントとサービスから得られたドメイン知識をチーム内で共有
- 得点源が何であるかを認識する (POSTの加点比重が高いなど)
- 各種プロファイリングの準備を整える
- 初期状態の完全なバックアップを作成する
- 減点となる原因を把握する
- 環境を壊して初期化に必要なデータをロストするとどうしようもなくなる
- 途中の状態には戻せない
- 初期状態の完全なバックアップを作成する
- 12時
- 昼飯をちゃんと食べる
- ランチミーティングのつもりで方針と戦略をチーム内で共有して動き方を整理しておく
- 分からないことが出たら分からないことリストにしておく
- やること。やらないことをできる限り明確にする
- 13時
- この頃にはデプロイが1コマンドでできるように
- デプロイ→性能計測→プロファイルまでの一気通貫ででやれる仕組みが出揃っていること
- 大きな単位の計測プロファイルができるようにする
- nginxの。。。。
- 小さな単位の計測プロファイルができるようにする
- 言語ごとのラインプロファイラやSQLクエリプロファイラ
- 14時ー17時
- 1コミット1ベンチくらいの勢いでベンチを回す
- CPU専有率・メモリ使用量・レスポンスタイムなど気にするべき指標を明確に把握してプロファイルする
- 17時
再起動試験を実施して再起動しても問題ないことを確認する
- NewRelic APMを入れてたりする場合はそれらを停止する
- デバッグログの出力を止める
- プロファイル用に差し込んだものを止める
- コードフリーズの気持ちになってると気持ちに余裕が
- 最後の仕事を
- 18時
- 結果を待つ
- 記憶が明確なうちにチームで振り返りを

## おすすめの練習項目
ISUCONの練習するなら
-
### デプロイ方法セットアップ
- 問題環境にログインしたらすぐにデプロイの用意を始める
- Githubにpro repo作成
- git init
- 全てチェックイン
- deploy keyでpushする
- これを真っ先に初手何も考えずできるだけでかなり違う

### IaaC適用セットアップ
- ansible等を最速で回せるようになっておく
- ミドルウェアが入ってるとか入ってないとか関係なしで自分達の理想の環境に出来る様になっておく
- ただし、OSの違いなどでインストール済みのものとのバッティングも起こりやすいので分割適用できると尚いい
-
### ベンチ → 集計を1コマンドに
- ISUCONベンチマークは大体1分実行
- ベンチボタン押す → wait 1.5min → 集計 のような仕組みになっていると
- デプロイ→ベンチ→集計が1コマンドだとかなりいい

### サーバーの役割変更
3台を使い切るための構成変更に慣れておく
- 1台だけnginxがあり、そのupstream 2台はアプリなど
- 必要のないサービスを起動させたままでいられるメモリ的余裕はISUCONのサーバーではあまり期待できない
- 軌道を停められる・接続先を変更できる、はかなり大事
- systemctlならstopするだけだと再起動で上がってくるのでちゃんとdisableする！！！

### 使いたいツールのインストール
当日インストールからしてて出来るわけがない！！
- alp, pt-query-digestなど
- 使いたいツールは一発で入れられるように
- ansibleでやるなど
- 他人が作ったツールはビルド方法がわからないなどトラブルに見舞われがち
- prebuilt binaryが用意できるなら用意しておくのも1つの手
- scpで各archのバイナリを上げるだけ、てしておくと最速！！

### ISUCONを日々に活かす
- もはや炊飯器ですらインターネットと通信する
- 「ご飯が炊けました」の通知でサーバーが死ぬ時代
- 1世帯が持つクライアントの平均台数は年々増加している
- 1リクエスト10msで処理できるサーバー、500万リクエストされたら13時間かかる

### ISUCONは実践的？
- そんなことないんじゃね？
- 今時SSHで入ってデプロイとかせんくね
- sshdを入れてるかすらあやしい
- それでもISUCONは日々の業務に役たつ
- 水平分散できるコードを書く能力
- もはやボトルネックは光の速度が遅いとかの世界

### 単体速度の限界
- とある１行の改善ではシステム全体が速くならない
- DBとアプリが相互にボトルネックを押し付け合っている
- 仕組みや気候が改善されることでしか取り除けないボトルネック
- まず持って即時では "書き込まない"
- キャッシュすることで最新のデータを "読み込まない"
- 計算毛化や集計結果は保持することで "計算しない"
- 単体の速度とシステムの速後が噛み合うようにする！！！

### 効くことをやる
- やってみるとわかるがISUCONは単純に楽しい
- やったら数値が上がるのは単に頭脳ゲーム的に楽しい
- 日々のKPIだって、計算ロジックがわかってればエンジニアはもっと楽しいのでは？
- 「効くことをやる」の逆は「効かないならやらない」
- 選択するには根拠が要る

### コンフォートゾーンから１歩出る
- パフォーマンスチューニングをする機会に恵まれる人生は幸運
- 関わってるサービスが
- まず何も分からない、ということを体感して

### 文化祭症候群にかかろう
- ISUCONの8時間は炎上の状態とほぼ同じ
- 自分でこの状態を作るのは難しい
- 仕事で炎上するのはごめんだが
- 8時間集中するのは1年に3日くらいならやってみるのも楽しい
- 文化祭前日の夜のような時間を友達と過ごすのは悪くない
- やってる間の苦痛が終わった瞬間笑い話になるのは楽しい
- 楽しかったと脳の記憶が改竄される

### 上手くなる自分を楽しんで
- この前描けなかったJOINが一発でかけた　にはすごい価値がある
- 手なりでできることが増えると脳のリソースを別のことに使える
- 人の感想ブログに書いている単語で分からないものが消えていく
- 最終的に優勝してもやりきってないからもう一回でも何度でもチャレンジを続けられる
- 優勝した瞬間は最後の記憶にしたくなるが、もう一度求めてしまう
- 白金動物園(rosilillyさん)も発表されるまでは自分達が優勝するとは思わなかった
- すごい人のすごさが分かる、尊敬できる人が増えていくのは楽しい
- 楽しいことは最高のスパイス

言語による差
- 昔はテンプレートエンジンの影響が大きかった
- Perlは人類の叡智だった
- ぶっちゃけ今はそんな差はない
- Golangはgoroutineで並列処理が実装しやすいのは強みだが、活かせてナンボ

ISUCONでRubyのJITが実装されることも
gRPCはHTTP2の上で動く。HTTP2のライブラリでエラーが起きてしまう。
他のライブラリのPRに作問者がいると問題のネタバレになってしまうのが良くないから細心の注意を払っている

ISUCON運営者は学生を手厚くサポートしている
rosilillyさん昔は高校の非常勤講師だったらしい