12月8日に開催されたISUCON14に参加してきました！
ISUCONはWebアプリケーションのパフォーマンスチューニングをおこない、事前に用意されたシナリオを通して、決められた採点ロジックをいかに高められるかというコンテストです！
自分は昨年の参加が初めてで、今年は2回目の参加でした。今回は、3名で参加する予定だったのですが、1名都合が合わなくなってしまい、2名で参加しました。
メンバー
友人：普段組み込みでC++を書いている
昨年は自分がPHPを書いていたのと友人がPHPを触ったことがあるということでPHPを選び惨敗したのですが、それを反省することなく今年の準備を全くしていなかったので今回もPHPで挑むことになりました。
起床試験
前日、ISUNARABEで素振りをしていたのですが、波に乗ってしまいよふかし。。
無事に起床試験に失敗しました。(10:03起床)
大慌ててDiscordに入ったのですがまさかの友人も寝坊しており、2人で朝からワタワタしました。(次回は早寝を頑張りたい。。)
本編
今回のお題はISURIDEという椅子のシェアリングサービスのチューニングがお題でした。
午前中は疲れが残っていたのとISUNARABEの環境が残っていた為、AWSのEIPクオーター上限に当たってCloudFormationが作成失敗したり、ソースコードをGitHubに上げようとして事故ったりなどを何度か繰り返して振り返ると事前準備が足りてなかったなぁと反省が多くありました。
事前の素振りで事前に練習した通り
などをして、DBのインデックスの設定やN+1の修正などを取り組んで行きました。
いざ、N+1を直して行こうかなとNginxのログをALPで見たりしていたのですが、過去問と比べて極端に遅いところがなかったので、ベンチを回していて気になったRideと椅子のマッチングに手をつけてみることにしました。
初期実装は、１番待たされているRide１つに対して、ランダムな椅子の取り出しを10回行いマッチ可能な椅子があれば割り当てるようなロジックでした。
そこで、１番待たされているRideから順に乗車可能な椅子のなかで一番座標が近い椅子をマッチさせるようなロジックに切り替えるように変更を進めたのですが、「乗車可能な椅子」という判定は椅子テーブルが持っているのではなく椅子に対する過去のride_statusesが全て完了しているかという判定を取る必要があり、複雑なSQLになり適切なロジックを時間内に組み切ることができず、タイムオーバーとなりました。
結果
ISUCON14の結果は457位(FAILを覗いて下から58番目)でした。大きな成長をしたとは言いづらい結果ではありますが、昨年が503位(下から4番目)だったので少しはISUCONを味わうことができたかなと思います。
感想戦
当日は別のチームでしたが、ひがきさんと２週連続でISUCON14の感想戦を行いました。
１週目は、お互いがどんな環境でISUCONを共有しあったのですが、自分は手動で行っていた初期設定やベンチ結果の情報取得などがAnsibleで構築されていてとても便利そうだったので、来年自分のチームに導入してみたいなと思いました。
２周目は、技術的な目玉？の「Server-Send Event」が何者なのかを調べてみることにしました。どのような技術なのかと調べたところ、意外と身近に使われているところがあり、ChatGPTのAIが応答を少しずつ返してくるデータの送信に使われているということでした。これまでWebSocket的なものでクライアントとサーバー間でデータ送信をしているものだと思い込んでいたのですが、クライアントから送信されたHTTP通信のレスポンスをストリーミング的に返しているということでした。HTTP/1.1から利用できる技術であるという点は調べていてとても驚きました。
本番当日に改善しきれなかったRideとChairのマッチング方法の修正にも取り組みました。本番では初期データの改修が必要になるため避けていたのですが、割当可能になったことを示すフラグをChairテーブルに組み込むことにしました。最近はRubyを書いているのでしれっとRubyで書いていますが、こちらのコードと初期データの修正で無事にマッチングのベンチマークを通すことができました。
まとめ
ISUCON用の対策はあまりしていないのですが、昨年よりは順位もスコアも上げることができたので満足はしていますが、来年に向けて2ヶ月に1回素振りをする予定を組んだので事前準備をしっかりして中盤くらいまで上がれる力はつけたいです。
