s平面の左側

左側なので安定してます(制御工学の話は出てきません)

ISUCON 10 予選に参加しました

isucon.net

記憶が正しければ ISUCON 6 から参加しており今年で 5 回目の参加でした。 チーム「牡蠣を食べろ」として参加し、結果は予選敗退でした。

チームの活動記録の GitHub リポジトリは競技後に Public にしました。

github.com

自分のやったこと

ISUCON はいつも若手ものづくり集団 Oystersのメンバーで出ているのですが、今回は新たに参加を希望するメンバーが増えて Oysters 内から 4 チームが作られました*1

出場経験の多い私は必然的にチームの代表者として、全体指揮的な役割を担いました。

私がやったことは次の通りです。

戦うための土台づくり

ISUCON を戦い抜くための土台を作りを、事前の打ち合わせ・練習のとおり進めました。

私は

  • Kataribe のインストール・設定
  • slow query log の設定
  • デプロイスクリプトの作成

あたりを担当していました。

アプリケーションの仕様把握

土台が整い次第、ブラウザから実際にアプリケーションを操作したり、ソースコードを見ながらアプリケーションの仕様を把握していきました。

f:id:okashoi:20200913222418p:plain
ISUCON 10 予選問題アプリケーション「isuumo」

今回のアプリケーションは近年の ISUCON の中では比較的小さいものだったので、仕様把握にはさほど苦労しませんでした。

「なぞって検索」の改善

その後 slow query の情報をもとに雑に index を貼ったりもしましたが、Kataribe の結果から「不動産検索」「なぞって検索」の 2 機能を改善に集中することに決めました。

「不動産検索」は検索条件のクエリを動的に生成している部分、「なぞって検索」は MySQL の Geometry 型を使った検索がそれぞれ難しそうだったので、チームを 2 分して独立して進めることにしました。 私は 1 人で後者に当たりました。

Geometry 型の事前知識はほぼ 0 だったので、まずは MySQL のドキュメントを読み込むことに集中。

N+1 の解消と spacial index を貼るという方針を打ち出し、まずは estate テーブルに Point 型のカラムを追加しました。 それにより N+1 は解消できましたが、spacial index については

  • InnoDB の spacial index 対応は MySQL 5.7 以降(本番に初期で入っている MySQL は 5.6)
    • → MySQL 8 に上げると(単に上げただけでは)スコアが下がってしまう
  • 初期化処理中に SPATIAL INDEX を貼ろうとするとタイムアウトで fail になってしまう

という諸問題を乗り越えられずに時間切れを迎えてしまいました。

github.com

全員の施策を統合して、最終的に確認できたチームのスコアは 828。 結果は冒頭で述べたとおり本戦進出ならずでした。

所感など

ざっと箇条書きにしていきます。

  • 初の全員がリモートでの参加
  • まさかの Geometry 型
  • 今回 Oysters 内で ISUCON に興味を持つメンバーが多くなって良かった
  • 毎度、終わった後の Discord の学びがすごい
  • 戦うための土台づくりに時間をかけすぎたかも
  • 早い段階で「不動産検索」と「なぞって検索」できっちり役割分担できたのが良かった

うち「初の全員がリモートでの参加」「戦うための土台づくりに時間をかけすぎたかも」の 2 点を取り上げます。

初の全員がリモートでの参加

競技中は常時 Discord によるボイスチャットをつなぎ、30 分に一度各自何をやっているか、何かに詰まっていないか、次に何をやるのか、という報告を行う時間を設けるようにしていました。

テキストでのやり取りはフローの情報(依頼とか、現状の共有とか)は Slack、ストックの情報(ベンチマークやプロファイリング結果)は GitHub と使い分けていました。

チームで何度か事前練習をしていたので、本番での連携はある程度スムーズにできたと思います。

戦うための土台づくりに時間をかけすぎたかも

各種プロファイリングツールのインストールをして、ローカルで動作確認するための環境を作って、ということを分担してやっていましたが、事前に決めていたところまで完了したのが 3 時間経過した頃になってしまいました。

一方で、そこまでプロファイリングツールやローカルの開発環境を多く使ったかというと微妙で、費用対効果に見合わなかった気がします。

本番サーバは 3 台あって、それらをフルに使うのは難しい*2ので 1 台は開発機にしても良かったし、Go 言語だから「ビルド通ってればベンチ回してみてもええやろ」くらいのノリで進めても良かったかもしれません。

プロファイリングも今回は Kataribe と sloq query log だけで十分でした(これは結果論かもしれませんが)。

おわりに

今回は Oysters のうち 1 チームが本戦への出場を決めました!めでたい 🎉

sinnderu.hatenablog.com

ISUCON に参加することで毎年多くの学びを得られています。 本当に参加したてのころはパフォーマンスチューニングの知識が皆無でしたが、今はある程度は戦えるようになったかな、という気がしています。

毎年、運営に携わる方は問題作成や環境準備、当日運営等に多大な労力をかけていることでしょう。 こういった場を提供してくださることに、毎年感謝しています。 本当にありがとうございます。

余談

今回個人スポンサーにならせていただいたのも、そういった感謝の気持ちを少しでも形にできればと思ってのことです。 少しでも運営に役に立てていればと思います。

isucon.net

中身はマグカップとステッカー、アウトドアで使える椅子(かなり質の良いものっぽい)でした!

*1:それぞれチーム名に「牡蠣」あるいは「oyster」が入っています

*2:やるにしても後半