こんにちは、ES課研修中の深瀬です。
先日開催されたISUCON14に参加し、スコアは9,812で132位でした。 参加した経緯や結果、反省点等を記載します。
本記事はサーバーワークスAdvent Calendar 2024の19日目の記事です。 qiita.com
想定読者
- ISUCONに興味がある方
- ISUCONに参加しており、他チームがどのような対応をしたか気になる方
ISUCONとは
「ISUCONとは」や「ISUCON14で出題されたWebサービス」については、すでに社内で参加した方が記事にしていますのでご参照ください。
ISUCON14 に出場したので個人としての振り返りを書く (InfraNinja / 9,966点) - サーバーワークスエンジニアブログ
インフラエンジニアが挑むISUCON14アプリケーションパフォーマンスチューニング奮闘記 - サーバーワークスエンジニアブログ
メンバー
私はISUCON10から友人と参加しており、今回も同じメンバーで参加しました。
- 友人A（全部担当 体調不良で当日欠席）
- 友人B（アプリ担当）
- 私（性能測定係）
簡単な経歴
- ISUCON10から参加
- ISUCON10では事前に勉強したものの、ここ数年は当日オンラインで集まってなんとなく始めている
- Go言語、MySQL、nginxは業務で使用した経験なし
なぜ参加するのか
もはや友人と参加する恒例行事になっていますが、参加する理由は一言でいうと「楽しい」です。
毎年新しいWebサービスがお題となり、8時間という短い時間でパフォーマンスチューニングを行います。ボトルネックを見つけ、ユーザーにとって良い改善をする必要があります。アプリケーションを改善するもよし、インフラを改善するもよし、ユーザーから見るふるまいが変わってなければOKです。ベンチマーカー（負荷をかけるツール）が用意されているので、何度でも変更がスコアに影響するか確認できます。実践的で何をしてもいい環境というのは普段なかなかありません。
ISUCONはパフォーマンスチューニングのコンテストではありますが、あくまでユーザーの体験をよくするための改善をした結果としてスコアが伸びていきます。そのため、計測して重いクエリを上から順に直してもスコアが伸びないことがある、というのも面白いところです。 （実際その改修で後半伸びる可能性もありますが、8時間でそこまでたどり着けない）
また、ISUCONのための勉強はせずとも、業務で対象言語やミドルウェアを触っていなくても、何かしら自分の成長を感じる点もあるため、恒例行事として参加を続けています。
当日の内容
簡単ではありますが、チームで実施した内容を記載します。
| 時刻 | 作業内容 |
|---|---|
| 競技前 | discordで集まる。 youtubeライブでWebサービスが発表されるので確認しながらメンバー内で雑談。 |
| 競技開始 | CloudFormationを流してWebサービスの環境をAWSに構築。マニュアルを読みアプリケーションを触ってどんなものか確認。 |
| 10:30～11:30 | とりあえずベンチマーカーを流す。 OS情報やスペック、動いているサービスを確認。いつものUbuntu, MySQL, nginxというところを確認。 nginxのログを出力して、alpでアクセス状況を解析できるように準備。MySQLのスロークエリーログを出力できるように準備。 ベンチマーカー実行前、実行後に流すシェルスクリプトを準備。githubの準備。 |
| 11:30～12:30 | ベンチマーカーを回しつつ、topコマンドでCPU、メモリ等の負荷を確認。明らかにMySQLのCPU使用率が高いことを確認。 MySQLの分割も考えるが、分割してスコアが伸びるか判断ができなかったので保留に。インデックスや不要な処理の削除などを行う。(2261点) |
| 12:30～13:30 | スロークエリーログやalp、マニュアルを見つつどこを直すか悩む。重そうな処理を修正するもスコアはあまり伸びず。 |
| 13:30～14:00 | 休憩 |
| 14:00～15:30 | notificationについて、ユーザー、椅子ともに状態が変更されてから3秒以内に通知されればよいのに0.03秒ごとに返していたため、2秒に変更（6千点）。 これによりMySQLの負荷が減り、OSのCPUはカツカツではなくなったため、MySQL分割はやらない方向に。 SSE（サーバーからクライアントにライドの状態をリアルタイム通知する）は挑戦するも時間内に対応は難しいと判断し断念。 |
| 15:30～16:30 | chair_locationの処理修正(7千点)。notification修正でCPUが空いたので、ライドのマッチングを500msから100msに変更（9千点弱)。 |
| 16:30～17:30 | スコアに影響しそうな椅子のマッチング処理の修正をメンバーで試みるが、アプリケーションの動作やSQLの意図が分からず断念。 |
| 17:30～18:00 | 仕込んだログ系を削除(9812点) |
| 競技終了 | youtubeライブで作問担当者の方の講評を確認。 |
| 20時ごろ | 順位発表。とりあえず追試で失格になっていないことに安堵。 |
反省点
反省点は以下の通りですが、当日の内容よりぶっつけ本番になったことを反省しています。
- 事前に計測する方法をまとめていなかった。
- 当日になって、何をインストールするんだったかな・・と考えて過去にまとめていたドキュメント、スクリプトを探しはじめた。
- alp、スロークエリーログを仕込んだものの、その後の深堀を考えていなかった。
- nginxやMySQLの改善設定を事前に確認していなかった。
- MySQLの分離ができなかった。
- 毎年、アプリ側もできるようにGo言語をやりたいと思って何もしてない。
まとめ
毎年反省はするものの、翌年の当日まで何もしてませんでした。次は事前準備をするぞ！とここに宣言。
AWSを利用するとサービスのスペックを上げやすいため、内部のチューニングにまで目が向かないことがあるかと思います。 その結果、スペックを上げた分使ってしまう可能性もありますし、コストもかかりますので、根本原因の解決が必要な場合もあると思います。 ISUCONは、こうした内部の問題に目を向けるための良い機会だと考えています。
