春告げ鳥

興味のあることをごちゃ混ぜで書いているので、.カテゴリー別に閲覧することをオススメします

ISUCON 10 予選参加記

ISUCON とは Iikanji ni Speed Up CONtest です。
≒ウェブアプリの高速化を競うコンテストです。
大学時代の友人 (ugwis, altescy, kob) で参加しました。

競技前

コンテストが始まる前までに準備したことは主に以下三点です。

  • APM選定(opentelemetry + jaegerになりました)
  • 役割分担決め（マニュアル読み、opentelemetry 入れる係、メトリクスツール導入係)
  • opentelemetry + jaeger, prometheus + grafana の環境用意(kob)

opentelemetry 何もわからなかったので、前日に使い方などを確認しました。

競技中 (12:20 ~ 21:00)

13:18 初期ベンチ

=> スコア:496

  • kataribe 導入
  • OpenTelemetry 導入
  • スロクエリログ有効化
  • node_exporter 導入

15:01 インデックス追加 (altescy)

=> スコア:604

  • node_exporter 用ポートフォワーディング

17:58 searchEstateNazotte の改善 (ugwis)

ISUUMO の「なぞって検索」は N+1 で実装されており、判定もポリゴンで判定していたため、1 クエリ化。

geometry 型のカラムを追加しようと考えていたのですが、カラム追加せずとも BoundingBox の条件を追加すれば早くなるのではと言うお告げを受け、試してみると本当に早くなって kataribe の top に出なくなったため geometry のカラムは入れませんでした。 => スコア: 775

19:09 DB を別サーバに移行(altescy)

mysqld の CPU 負荷が大きかったため、どうせ DB も分けるということで、App と DB を別々のサーバで起動するように変更。 => スコア: 819

20:14 /api/estate/[id] のキャッシュを返す(kob)

/api/estate/[id] に対する GET リクエストがかなり多く、kataribe 上でも遅いことがわかったため、estate に対する変更 (UPDATE) がないことを確認し、キャッシュを追加。 => スコア: 1345

22:05 searchEstate の range 検索の高速化(altescy)

DB 上では物件のドアの高さ、幅、賃料が数値で格納されていますが、検索時はレンジ ID (100~200 or 200~300) のように指定するだけなので、SQL で都度検索時に rent < 100 & rent > 200 というように条件してするのではなく、rangeID = 1 のように検索できればインデックスを生かせて早く検索ができそうというアイデア。

alt 君が頑張って変更してくれて、終了間際変更完了はしたものの、ベンチマークが完了せず結果がわからなかったため、最終追試でこの改善結果が反映され、最終スコアが上昇しました。 => スコア: 1715 (47位)

ベンチマーク側のバグかどうかに関しては不明なため、最終追試がスコアとして判定されたかは不明ですが効果のある改善だったことが分かってよかったです。

感想

今回は次にやるべきことがある程度明確であったので、虚無の時間を過ごすことが少ない印象でした。 ちなみに、運営側の最大スコアは 8000 点だったようで、頑張ればそこまで上がるらしいです。 http://isucon.net/archives/55025156.html

DB 分割や、降順ソートの問題は気付いておらず（ソートが効いてなさそうだよねという話はあった）、もう一つ改善し 2000 点台であれば本選へ進めた可能性もあるのかなといった水準でした。

（各々の感想は各々書いてくれると信じますが！）個人的にはコードを書くことやパフォーマンスチューニングを行う機会がほとんどないので、仕事であまり触れない以上事前練習や自分のプロダクトを増やしていくのが今後の自分の課題になりそうです。