なんかかきたい

プログラミングなどの個人的なメモやサークル「ゆきいろパラソル」の情報を載せてます

ISUCON10 本戦に鍋部2人前のインフラ枠で参加しました

ISUCON 技術系

諸事情でISUCON10の本戦に並行チーム枠として参加させていただきました。本当に疲れたのでざっくりとまとめだけ。

サーバスペック

  • 2コア / 1G
  • 2コア / 2G
  • 4コア / 1G

OSはすべてubuntu

メモリが1GでMySQLとアプリケーションが同居しているので、油断するとすぐにメモリが足りなくなってしまい操作不能になってしまいます。 とりあえずそれだけは避けたかったので、SSH後すぐにswapfileだけ作っておきました。

アプリケーション

  • benchmark_server
  • xsuportal

とにかくアプリケーションが難しかったため、動作仕様の確認はチームメンバーの @catatsuy さんにお任せして、 自分はサーバ構成の把握、ミドルウェアの確認、設定ファイルの確認、バックアップなどを進めていました。

Envoy

どうせnginxで来るだろうと思って油断していたらenvoyが上がっていて初動で手間取りました。 envoyでそのまま行くか、nginxでいくのか短時間検討して、静的ファイル配信がenvoyでは難しいと判断、nginxを使うことにしましたが、 gRPC を使っていて設定ミス、しばらくベンチが通せなくなってしまいました。

alpでログの調査をしたいので、まずは安全をとってenvoyのログを調整する方向で時間を使うことにして、その後envoyからnginxに切り替えることにしました。 (やや手間取りつつJSON形式でログを出すように変更)

Nginx

Golangが返していた静的ファイルやpackなどはそのままnginxで返すようにし、 expire を設定することにしました。 gRPC / http2 などがあり、もともと用意していた設定をあまりそのまま使えなかったので、その場で設定を作っていくことに。

MySQL

MySQLはubuntuのデフォルトの設定だったので、基本的な設定を入れてMySQLを再起動 再起動前まで COMMIT や INSERT で詰まっていたのでやや不安がありましたが、SELECT 系クエリが上に上がってきたのでそちらを調べていくことにしました。

この辺りはごく普通に pt-query-digest で調べていく感じでしたが、SlowQueryはindex関連で出ているものがあまりなく、 そもそもクエリが発生しないようにするか order by による filesort を避けるか、くらいの戦略しか取れませんでした。

(結果的にMySQLは初期ではクエリレベルの問題はほぼなく、クエリの改善で修正できる箇所は少なかったです)

TeamCapacity

アプリケーション側の改修が終わってきたところで、 TeamCapacity を上げていく作戦を進めていったのですが、 期待より古い内容のリーダーボードが返却されています(GET /api/audience/dashboard) が出るようになったのが大変辛かった。

nginxで /api/audience/dashboard をキャッシュする戦略に切り替え、1s分をキャッシュすることにしました。

しかし、実際には1sキャッシュだと、タイミングによってキャッシュの制限に引っかかることがあり、並列数を上げていくと前述のエラーにかかるようになるようでした。

結局ここを最後まで上げきれずに TeamCapacity は安全をとって 60 まで下げることになってしまいました。 結果、MySQLでもアプリケーションでもCPUやメモリを使い切れなくなり、「これ複数台構成にする意味なくない？」とか言い始める始末。せっかく3台あるのに。

一応最終的には、2号機でnginxとapp、3号機でMySQLを動かす構成にしましたが、残り30分でやったやっつけで、まだCPUを使いきれていなかったのでやっぱりやる意味はなかったかなという状態です。

Generated Column

MySQLのクエリが支配的になっていませんでしたが、JOINに使っていたscore判定の部分を Generated Column にしてIndexを貼りました。

まあこれをやるよりはキャッシュの問題に時間をかけた方がよかったですね...

反省

gRPC や envoy に関しては油断しており、事前準備がなく手間取ったところは否定できません。 (PHP実装がなくなった時点で予想できたかも、という話が出て、まあ確かにとは思ったのですが、逆にPHPを作ろうとしていた = gRPCは来ないだろうと思い込んでしまっていました)

また、アプリケーションの要件がしっかりと定められており、 特にキャッシュ周りがスコアに大きく影響を与えるとわかる内容でありながら、 サーバでの安易なキャッシュを許さないというインフラ担当に非常に刺さる内容がGREATでした。

特に最後まで複数台構成にせず2号機だけでスコアが伸ばせなくなってしまったのは大変心残りです。キャッシュ周りを頑張れば良かった。

内容は非常にボリュームのある問題で対応する時間が足りない非常によい問題と思います。

正直疲れましたが、これは出題側はとんでもない労力をかけたのがわかります、本当にありがとうございました。

最後に一言だけ書かせてください。

これで勝ったと思うなよぉ!!!