ISUCON10本戦に参加してきた話

ISUCON10 本戦に参加してきた話

ISUCON10予選に参加してきた話の続き。 予選敗退、、、悔しい。って気持ちだったのですが、ISUCON本戦2週間前になんだかんだあって本戦出場できることになりました。歓喜。

メンバー

予選と一緒

• reud
  • 学生枠ギリギリでISUCON10本戦に参戦した話
• やぱった
  • ISUCON10本戦参加記RTAのはず...

本戦まで

事前練習

reudがVultrでインスタンスを4台用意してくれました。
予選ではhtopとnew relicでほぼ雰囲気で計測していたため、計測ツールの導入等練習しました。
具体的には

• alp
• netdata
• pt-query-digest

の導入の練習をしました。

また、予選の環境をインスタンス上に構築する際に運営側がAnsibleで用意してくれていた為、Ansibleを初めて触りました。触った所感として、「Ansibleめっちゃ便利だな」とチームメンバー全員でAnsibleに感動し、計測ツールの導入もAnsibleで行おうという話になり、reudがAnsible周りの用意をしてくれました。神。

後、この記事を読んで

主にはベンチ実行後、alp + pt-query-digestの結果をNginxのドキュメントルート配下にhtml出力し、そのURLをSlack通知するという方法で確認できるようにしていました。 この形式だと結果を中途半端にSlack通知するより視認性も高く、後から見返す時もわかりやすいのでオススメです

とあり、便利そう！ということでalp + pt-query-digestの出力結果をNginxで配信できるように準備しておきました。
その内容としては 定期実行処理としてcrontabに

crontab -e

こんな感じでnginxのアクセスログをalpに通し、sedでmdのいー感じの形式にし、md形式にて出力しました。

*/1 * * * *  cat /var/log/nginx/access.log | alp ltsv -r | sed -e 's/\+/|/g' -e '1d' | head -n -1 > /home/isucon/logs/nginx.md

また、pt-query-digestの方も

*/1 * * * *  sudo pt-query-digest /var/log/mysql/mysql-slow.log > /home/isucon/logs/slow.txt

のように出力しました。

本戦始まってから気づいたのですが、cronでこんなに解析かけるとサーバーになかなか負荷がかかります。その為本戦ではcron外しました、、、良い子はめんどくさがらずにちゃんとベンチマークの実行に合わせて解析をかけるようにしましょう。

景品

当日前に本戦出場記念の景品が届きました！ 物が届くと嬉しいですね！

当日

やぱったの家にメンバー3人で集まり、オフラインで本戦に挑みました！

本戦開始

10:00の開始と共に問題とレギュレーションを読み始めました。文章量かなりあった、、、

概ね読み終えた所でインスタンスに接続し、まずはミドルウェア周りの確認を行いました。

mysqlは8系が入っていることはすぐに分かったのですが、Webサーバーにnginxが用いられていると思いきや入っていない、、、

sudo lsof -i:443

で確認してみるとenvoyが動いている、、、存在は知ってたけど触ったことは無かったのでconfigのymlを雰囲気で読みました。

確認後はmysqlの設定でslow-queryのログをオンにし、pt-query-digestで解析できるようにしたり、別インスタンスからのアクセスを許可したり、軽くindexを貼ったりしました。

メンバーの方もUbuntuのバージョンによる違いによりansibleが上手く動かない等、かなり手こずっていました。

また、alpでアクセスログの解析を行おうとしたものの、envoyのログをalpで欲しい形式で出力するのに時間がかかってしまい、結局やめました。(ltsvで食わせて上げる必要があると思っていたのですがalpのREADMEをちゃんと読んでみると解析に必要な情報が書いてありますね、、、本番中にも読んだのですが、焦っていて読み飛ばしていました)

サーバー構成

reudがneofetchを用いてサーバー3台のスペックを確認してくれて、3台ともスペックが違う事が判明しました。(3台のスペックが違うなんて思ってもいなかった)

• サーバー1
  • CPU 2コア
  • メモリ 1GB
• サーバー2
  • CPU 2コア
  • メモリ 2GB
• サーバー3
  • CPU 4コア
  • メモリ 1GB

その為、初期状態でベンチを回した場合もスコアはバラけてました

• サーバー1
  • 4973
• サーバー2
  • 5617
• サーバー3
  • 6887

netdataで負荷を確認しながらベンチを何度か回して、サーバーの構成を入れ替え、DBのCPU負荷が高いため最終的に

• サーバー1
  • envoy
• サーバー2
  • web, api
• サーバー3
  • DB

の構成にしました。 多分この辺でスコアが多分7152点。

TeamCapacity

サーバーを分散し、CPU負荷に余裕があることが確認できた為、何かしらのパラメータでアクセス数のlimitにあたっているのでは無いかと考えました。メンバーに話すとTeamCapacityなるパラメータがある事が判明。 10→50へ上げてもらう。これでスコアが多分10010点。 良さげなTeamCapacityを探すために一旦120にあげて、ベンチを回したりしてみるも通らず60にてfix(負荷がかかりすぎるとenvoyが死んでしまっていたっぽい。open files limitに引っかかってしまっていた？？)

WebPush

やぱったとreudが実装してくれました。 途中で実装手伝おうと思いドキュメント読んだものの、しっかり読まないと何も分からなかった為何も手伝えず。実装感謝です。これで多分14314点

Goのコードをい〜かんじに

Goのコードをい〜かんじにしようとしたものの時間が足らずにほぼできませんでした。

ラスト1時間

諸々あって、ベンチが通らなくなってしまいかなり焦りました。

終了時間ぎりぎりでベンチが通ったためそこでfinish

結果

failしてました

最後のベンチが通ったのでいけると思ったのですが、ランダムでベンチが落ちる状態だったようです。 出ていたエラーとしては下記

• あるべき通知を受信していないことが検知されました
• 最終検証にて Clarification の検証に失敗しました

悔しいです。

振り返り

競技中はやらなきゃいけないことが多すぎて終了時間まであっという間でした。その振り返りとして、やることとやらないことをしっかりと判断するべきだったと感じています。

具体的には、計測ツールの導入で手間取る箇所やenvoyの理解など競技のスコアアップには本質的には繋がらない箇所はある程度割り切って自分たちのできる所で更にスコアアップを狙うべきだったと思います。

できることをやるの大切。

後、マニュアルにキャッシュ可と書いてあったものの最小工数での良い方法が思いつかなかったです。他チームではVarnishというものをenvoyとwebの間でキャッシュしていたそう。知らなかった為、勉強する。

来年は社会人枠で本戦出場目指して頑張ります。

P.S.

メンバーでオフラインで集まって参加するのはとても楽しかったです。 来年はオフラインで開催できてると良いな。