今年もISUCON 予選に参加し、527チーム中31位で惜しくも本戦出場なりませんでした、くやしい〜〜〜〜〜〜〜。
ISUCONとは
Iikanjini Speed Up CONtest。LINE社主催、お題となるWebアプリケーションをガツガツゴリゴリいじくり回して超たくさんの人が同時に使っても死なないチョッパヤ仕様にするソフトウェアエンジニア向けのエクストリームイベント。
今回のオンライン予選は598チーム、1421名の方にご参加いただきました。
チームメンバー紹介
今回はチーム 「牡蠣に当たるときの効果音→カキーン」 として、下記メンバーで参加しました。
cureseven
- アプリの改修頑張った
- 練習熱心
- すぐ歌い出す
shiningcureseven.hatenablog.com
nekodaisuki
- 猫がだいすき
- インフラがちゃがちゃマン
- SQLの魔術師
pinkumohikan
- 色々指図するマン
- やったこととスコアをIssueに書かないとキレる担当
主な施策
やったことの全容↓ github.com
1. index追加
Slow query logを見ながらindexが必要そうなところへペタペタ。
降順インデックスの罠は 進研ゼミ ISUUMOでやったやつ。
2. インフラ構成の変更
最初は1台のインスタンスに全盛りで、CPUをnginx, app, dbで食い合っていたのでDBサーバを別インスタンスへお引越し。 MariaDBには慣れてないからMySQL 5.7に変更、後に降順インデックス使いたかったのでMySQL 8へ。
最終的にはappサーバのCPUがフィーバーしていたのでappだけのサーバも用意して下記のような構成に。
| サーバ | 役割 |
|---|---|
| 1 | nginx, varnish, app |
| 2 | app |
| 3 | DB |
3. dropProbabilityの調整
チューニングが進み、リソースに余裕が出てきたタイミングでいじいじ。
5%刻みで設定変えてベンチ回して、最もスコアが良かった 0.95 に設定。
ただこれは13:30に設定して以降ずっとそのままだったのである程度チューニングが進んだ段階で見直したほうが良かったと反省。
4. lastなIsuConditionをメモリに持たせる改修
最新のIsuConditionを取得しているところやN+1があり、クエリで一括取得するようにしても良いけどDB負荷高めだったのと最新レコードだけならデータ量的にも行けそうだったのでアプリのメモリに持たせる方向で解決。
結構重要な仕事を無事成し遂げられたcureseven氏に拍手。ベースとなるデータを作る部分ではnekodaisuki氏のSQL力がいかんなく発揮された。
5. リバースプロキシでのコンテンツキャッシュ
最初はnginxのproxy cacheでキャッシュしてたけど最小キャッシュ時間が1sなのでタイミングによって鮮度古いよエラーが出ちゃう問題があり、途中からvarnishを挟んだ。
が、varnishは全然練習してなかったので手こずってた模様。自分も最後にvarnish触ったのは7年前とかなのでnekodaisuki氏に血を吐いてもらった。
振り返り
一言で表すと、去年と比べてチームとしても個人としても良い感じに進められ、チームビルディングや練習の甲斐あって成長が感じられる良い回でした。
競技中は終始良い雰囲気で進められたし、みんながしっかりログを見ながら「この辺が遅そう」みたいな当たりを付けながら進められていたので来年は誰がリーダーになってもやっていけそう。スコアも頻繁にリーダーボードに乗るぐらいには健闘していた。
去年本戦に出場できたのはまぐれじゃないぞと証明するため今年もチームで10回ぐらい練習会をしたものの、最終スコアは92336点 31位でわずかに25位に届かず予選敗退。 5万点ぐらい足りなかったら実力不足だと割り切れるけど予選通過ラインが106094点ぽく、競技終盤のスコアは10.7万ぐらいだったのでワンチャン届いていたなーと思えてしまって大変悔しい。
とは言え運も実力の内、むしろ運に左右されない強靭なスコアが必要。また来年がんばるぞ。
今回の問題も大変良い問題でした。 大きなボトルネックがドーンと構えている感じではなく、改善すべきポイントが各所にあって改善のたびに着実にスコアが伸びてコツコツとスコアを積み上げていけるタイプの問題。ベテランはもちろん、ISUCON初心者でも楽しめる課題だったと思います。ISUCON入門イベントとかに使えそう。
来年も対戦宜しくお願いします！
