皆さんこんにちは
@tereka114です。
9/12（土）にISUCON10が開催され、当社から3チーム参加しました。
ISUCONはLINE株式会社さんが主催でお題となるWebサービスをレギュレーションの中で高速化を図るチューニングバトルです。
残念ながら全チーム予選落ちでしたが、今年、最も戦果を残せたのではないかと思っています。
その中でチーム「４回目の正直」が終了時点で1801点（全体48位）を獲得し、最も成績が良かったので、その取り組みについて紹介します。
チーム「４回目の正直」構成
名前からお察しですが、実はこれまで3回ISUCONに参加しています。メンバーは次の通りです。
佐々木 峻（Twitter:@Ssk1029Takashi）：インフラ担当
野村 勇仁：アプリ、デプロイ担当
山本 大輝（Twitter:@tereka114）：アプリ担当
当日はMS Teamsで電話会議をつなぎ、全員リモートで繋ぎながら参加しました。
自分の開発環境がそのまま利用でき、会話もできるので特に問題なかったと思います。
ただ、サーバ構成の検討のときにホワイトボード使えないのは苦労しました。
これまでと異なり、パフォーマンスを計測するのにElastic APMを利用しました。
Elastic APM
当社はElastic Stackのリセラーで、性能解析には積極的に活用しています。
JavaやPython、Goなど各種言語にも対応しています。
ISUCONはまずパフォーマンスのボトルネックを素早く把握することが重要です。
そのため、Elastic Stackをベースに簡単にアプリケーションのパフォーマンスやボトルネックを計測できるElastic APMを使いました。
このElastic APMは今回の問題と特に相性がよかったです。Elastic Cloudを使うことで、環境構築も素早く行え、かつ、強力な効果を発揮していました。
Elastic CloudでのAPM構築方法はこちらを参考にしてください。
今回高速化するアプリ
今回のアプリはISUUMOと呼ばれるアプリで「イスに似合う不動産を検索できる」総合情報サイトです。
公式によれば、次の要望に基づいて高速化する必要が出てきたようです。
リモートワークの普及によって、自宅のイスが生産性に直結することがわかった。 その調査結果を受けて、よりよい座環境を求め郊外に住むことを考えるユーザーが増加。 また、注目度が増したことで bot からもアクセスが急増し、機会損失が発生している。 結果として ISUUMO にアクセスが集中し、負荷に耐えられないことが目立ってきた。
時系列での取り組み紹介
12:20
README.mdを読む＆サーバ接続の設定を行いました。
このあたりでBot対策が将来的に必要そうであること、特定の加点形式を確認しました。
私達が選んだ言語は普段使い慣れているPythonです。
13:30
このあたりでデプロイツール一式、実装の確認、パフォーマンス確認の準備を行いました。
今回は実装を見るだけではボトルネックの部分の判断が難しく、明確にここの精度が低いといったことはわかりませんでした。
適用したElastic APMでベンチマークの結果を見ると次のことがわかります。
- estates/chairsに対する検索が遅い。
- nazotteのリクエスト頻度は遅いが、回数が少ないので全体のパフォーマンスに影響度はこの時点では低い。
- low_pricedのリクエストも負荷がかかっている。
例えば、/api/estates/searchのリクエスト個別で見てみるとアプリよりもSQLによる負荷が高いことが判断できます。
そのため、このリクエストを改善するためにはSQLの修正が必要です。
14:00
ベンチマークが502例外を吐いているため、復旧を運営が進めていました。
その間Elastic APMを確認しながらの机上での検討やリクエストを投げて、修正の動作確認を行ってました。
このあたりでnginxにBOT対策用の正規表現を入れていました。あまりスコアは変わらなかったので効果のほどは不明です。
15:00
テーブルのINDEXを張りをしていました。
正直あまり効果は少なかったと思っています。
リクエストの平均速度は若干伸びましたがまだまだ不十分です。
16:00
nazotteリクエストを若干高速化しました。
nazotteの取得件数は最大50ですが、点が領域に含まれているかの実行が50件を超えても動いていました。
そのため、プログラムで打ち切ることで若干高速化しました。
16:30
Redisを利用した高速化を進めました。
テーブルへのレコード登録のAPIの発行回数が少なく、テーブルそのものへのレコード更新頻度が少ないことがわかりました。
また、検索は一見、連続値での条件取得に見えますが、よく見ると殆どがただの離散値です。
そのため、限られたパタンになるため、結果のキャッシュを行うのが案外容易であることがわかりました。
更新タイミングで手動ロックを実装し、この方式を実現しました。実装完了した時点でのAPMは次の通りです。
最初と比較するとかなり性能が向上しました。
18:20
複数台構成を検討し始めました。
複数台を構成するにあたり、DBの負荷が高いことがわかっていました。
また、chair/estatesで干渉する場所はほぼないので、完全に分断する方式を取りました。
最終的には次の構成になりました。
101:Web, Nginx, Redis, DB(chairs)
102:Web
103:DB(estates)
21:00以降
競技終了＋参加した3チーム揃っての感想戦です。
生放送の結果報告を楽しみに待ってましたが、本選出場には届きませんでした。
まとめ
Elastic APMを利用してボトルネックは的確に当てることができました。
詳細画面でSQLが問題であり、全体的にMySQLに負荷がかかっていることがすぐに判断できました。
しかし、ボトルネックを当ててもメンバの地力が足りず、修正しきれなかった箇所があったのは反省です。
特にnazotteのN+1外しに失敗するところやMySQL8にはある降順INDEXの利用は勝敗にかなり影響したと思っています。
最後に
運営の皆さん大変な中、ありがとうございました。
今年のISUCON、これまでの参加の中で最もがんばれたと思っています。
惜しいところまで競ったからこそ悔しいと感じていますが、来年も懲りずにリベンジしたいと思います。
Acroquest Technologyでは、キャリア採用を行っています。
- ディープラーニング等を使った自然言語／画像／音声／動画解析の研究開発
- Elasticsearch等を使ったデータ収集／分析／可視化
- マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
- 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。モノリシックなアプリケーションをマイクロサービス化したいエンジニア募集！ - Acroquest Technology株式会社のWebエンジニアの求人 - Wantedlywww.wantedly.com
