今年も例年通り @matsuu、 @ishikawa84g と参加しました。
最終スコアは43249。 スコアだけ見ると上位にイケなくはないけど、failしちゃったので0点です。 途中まで絶好調だったこともあり、宇宙海賊賞をいただけるとのこと。 ありがとうございます！
役割分担はこれまたいつも通りこんな感じ。
- @matsuu バリバリ実装する前衛
- @ishikawa84g サイトやレギュレーションやコードやログやDiscordを見る情報官
- @netmarkjp 司令塔
予選同様、同じ場所に集まらずリモート参加。 Discordで音声をつなぎ、各自のデスクトップを配信して自由に覗ける・すぐに共有できるようにしました。 隣にいるのにかなり近い感覚でできてよかった。
最終構成
サーバ3台体制でした。 メモリ1GBだと何をするにも足りなかったのでMySQLを2に移したけど、最後はMySQLのCPUネックだったので3をMySQLにしてもよかったかもしれない。 でもやっぱりメモリ1GBだと苦しいんだよね...というのがお悩みでいまのところ解なし。
| サーバ | スペック | |
|---|---|---|
| 1 | 2cpu, 1GB mem | envoy, varnish |
| 2 | 2cpu, 2GB mem | MySQL |
| 3 | 4cpu, 1GB mem | app（Golang） |
最終状態がかなり不安定で3回に1回くらいfailしない感じだったのですが、もう安定化を探る時間もなく、時間配分に失敗してしまいました。 ここは司令塔として改善点。
予選じゃなくて本選だしワンチャン賭けようみたいな不慣れなことをしたのがアレだったのかな。。。 無力感ではなく力不足感が強いので、また来年強くなってリベンジしたいです。
いまのところISUCON開始から10年経っても高頻度で上位をウロチョロできているので、引き続き上位を賑やかしていきたい。 そしてワンチャン狙いたい。
ここ2年で「基本的な方法論は引き続き通用するな」というのを確認できたのは収穫です。 今回はfailだったけど、コード読み書きやプロダクト習熟、体調管理みたいな基礎力を上げればスコア的には2～3位が狙える位置にいけそうです。
envoy初めて、WebPush初めて、gRPC初めて、にしてはうまく回せたと思います。
途中まで絶好調、のなぜ？
具体的な実装の話は@matsuuが書いてくれると思うので書いてくれました→ISUCON10本選に出場し17:00時点ではベストスコア1位だったもののfailフィニッシュになりました - Gマイナー志向、
司令塔ポジションで今回ポイントだったところを。
きちんとスコアを積み重ねていけたのは、われわれが「コツコツ改善」に振り切ってるからだろうなと思っています。 正直なところ時間内にアプリを理解してベンチマーカーの挙動を理解して、、、ベスト（に近い）アプリを最後にドン！というのはやれないので、先を見越さずに計測→改善を繰り返しています。
コツコツ改善を実現するためにはまず第一に正確な情報。レギュレーション・マニュアル・仕様の把握と、測定データの獲得。あとは情報の読解と、誘惑より情報を重視する理性が必要。これらは積み重ねがあり自信があります。
また高速な計測→改善サイクルを実現するためには素早い的確な実現力が必要なんですが、これはもう@matsuuがスゴいのでスゴい。 我々がアーキテクチャやミドルウェア～ネットワークとかのインフラに強くやりたいことがスッとできる、というのが高速な改善サイクルを支えています。
使った計測ツールは相変わらずkataribe、pt-query-digest、top、dstatです。 kataribe作者だしね。 とはいえツールがどうじゃなくて、データをきちんと読んでやるべきことをやるのが大事だなと思う次第。
- まずは計測ツールを仕込む
- システムリソースがボトルネックなら原因箇所を特定して対処する
- MySQLのCPU（USR）が高ければクエリ削減・改善、インデックス調整
- DiskIOが多ければ原因のプロセスを特定してIO削減
- ネットワークトラフィックが妙に多ければ圧縮して削減
- ...
- システムリソースが空き始めたらベンチマーカーの挙動を再確認して、ベンチマーカーを高速で回すアプローチ
TeamCapacityのような設定値を調整- 最初の10秒で250チーム程度まで登録できることを確認したので、チーム登録関連はひとまずスルー
- 質問→操作停止→質問回答→操作再開 の流れを重点的に短縮
- ...
継ぎ足し継ぎ足ししてきた秘伝のタレ集（設定例集）もあるし。
VarnishでTTLを0.7秒にしたり、gzip圧縮したり、/initalizeがきたらキャッシュをBanしたりがスッとできる（レスポンスをgzip圧縮したところ、レスポンス送信にかかる時間が減ったのか、ダッシュボードの内容が古い的なエラーが減ったりした）。
ログを見てsystemdの設定を変えてLimitを変更したりがスッとできる。
予選の反省を踏まえて、ALTER INSTANCE DISABLE INNODB REDO_LOG でMySQL8.0のredoログを無効化してIOを削減することもできる。
こういうのは積み重ねててよかったなと思う次第。
あとは、それを支えるドキュメントとかアプリの仕様把握。
ベンチマーカーの挙動が丁寧に書いてあるので、システムリソースが空いてきたらベンチマーカー（ユーザ）の挙動に沿って改善ポイントを変えるとかやってます
（今回だとWebPush実装後にListNotificationsが空レスポンスを返すようにするとか）。
【宣伝】
わたしが実践している基礎知識や方法論などをまとめたのがWebエンジニアが知っておきたいインフラの基本です。 発売時のエントリに 「この本に書いてあることをきちんと実践できれば決勝進出はできます。間違いない。」 なんて書いちゃったんですが、いまだに本選進出できているのであながち間違ってないなぁなんて自画自賛しています。
今後のさくせん（？）
最近トップのみなさんがどうやって（どこを見て・何をどう考えて）最終的にスコアを出しているのか、（わたしが）ぜんぜんわかっていないのですよね。 スコアの変化の仕方を見ていると、どうも我々とは違う着眼点・考え方・アプローチをしている感じがしています。
トップを狙うためには、我々も路線変更すべきだろうか・・・・・・でも改善を積み重ねてスコアを伸ばしていくの、楽しいんですよねぇ。
最後に。毎年楽しいコンテストを開いていただき、運営のみなさんには大変感謝しております。 来年もぜひ開催していただきたいです。 tagomorisさんも、答えにくい質問に答えていただきありがとうございました。 楽しみました。
来年も楽しみにしております！