インフラエンジニアが挑むISUCON14アプリケーションパフォーマンスチューニング奮闘記

みなさんこんにちは。マネージドサービス部MSS課の塩野（正）です。

社会人になってからずっとインフラ回りしかやってこなかった私はアプリ周りのことは正直よくわかりませんが、New Relicを使った改善活動の中でアプリケーション周りの話もできるようになりたいという思いからISUCON14に初チャレンジしてみました。ISUCONの詳細については下記公式ブログをご参照ください。

isucon.net

想定読者

ISUCONってどんな雰囲気なのか知りたい方
前日まで、当日にどんなことをやったのか知りたい方

ISUCONについて

ISUCONってなに？

公式サイトには下記のような記載があり、早い話がアプリケーションをチューニングしてパフォーマンスを競うコンテストです。

お題となるWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトル

isucon.net

今回のISUCONのスケジュールは下記の通りでした。

競技日程: 2024年12月8日（日）
競技時間: 10:00 - 18:00（JST）の8時間

また、参加条件として参加者はチーム登録制でメンバーは1～3名まで、参加可能チームの最大は1000チームまでという条件になっていました。利用するサーバはチームメンバーのAWSアカウントを利用し、参加資格として運営が用意したCloudFormationを実行し、CloudFormationの展開が問題なく完了し、運営側にその状況が伝えられることとなっています。そのため、今回は指定期間までの間にCloudFormationを展開し運営側でその状況が確認できなければ失格となるような流れになっていました。

ISUCON14の問題

ISUCON14ではライドシェアサービスならぬライドチェアサービスを展開しているアプリに不具合があり、すでに障害発生の状態でユーザーがサービスにつながりにくく、パフォーマンスを改善するというお題でした。

前日までのお話

ISUCON参加するにあたり前日までの間にパフォーマンスチューニングなどの本やWebサイトの情報で事前に学習するのですが、それ以外にチームとして当日どのように過ごすか、当日までにどんなことをやるのかといったざっくりとした作戦を練りました。

私たちのチームでざっくりと決めたのはこんな感じのことでした。

Go言語を使用すること
それぞれの役割分担
- アプリ周りの担当
- インフラ回りの設定担当
- New Relicを使用した監視設定
コード管理用レポジトリなどツールの準備
当日のコンテスト開始後の動き
- ドキュメントの理解
- コード変更後にバックデートする方法

私個人として前日までにやったこととしては、Go言語を使用したNew RelicのAPM設定の手順について確認しました。私はGo言語自体の経験がなく初めてだったという事もあってISUCONの過去問を使用してNew RelicのAPM設定についての手順の確認を行いました。

実際のところ手順確認の際にとりあえずAPM入れてみたけど・・なんかデータ飛んでこないな・・という所でつまづいてしまいかなりの時間を消費してしまったため、最悪New Relicが使えないことを想定してコマンドラインなどで対応できるようにそちらの方を中心に当日チャレンジしてみてダメだったら他の方法でやるというような進め方をしていました。

この点については最終的に複数の凡ミスが重なったため発生したということが判明しましたが、その結果ISUCON当日にNew RelicのAPMを使用できなかったという悲しい現実に直面しました。このあたりの話の詳細は失敗談のセクションでお話します。

当日のお話

競技開始が10時ちょうどからになるため、私は少し早い9時30分くらいにはパソコンの前でスタンバイしながら運営が配信するYoutubeを眺めていました。事前配信の中で今回の競技に使われるアプリケーションがどのようなものなのか簡単な説明がありましたので、個人的にはライブ配信は視聴していて正解だったかなと思いました。

そして10時ちょうどになってアプリケーションの公開が始まったのですが、、、ISUCONのポータルにログインしていなかったことや、ポータルのURLがすぐすぐわからずにURLを探すところからスタートするということになり、最初から大きく出遅れることに・・・（汗

その後チームメンバーとWeb会議の画面を通じてコミュニケーションを取りながらリソース展開、事前に作成しておいた設定をAnsibleでばらまく作業、New Relicのインフラエージェントなどの個別設定などそれぞれ役割毎に作業を行いながら、平行してISUCON14 当日マニュアルからアプリケーション仕様やアプリケーション改修の中でやってはいけないことなどの確認を行いました。

ISUCON14 レギュレーション : ISUCON公式Blog

実際のアプリケーションのパフォーマンスチューニングは、ISUCON過去問では下記のような対応が求められる認識でした。

DBのインデックス設定が漏れている
N+1の構成になっており大量のクエリが発行されるコードになっている
リソース貼りつきの問題に対応するために3つあるインスタンスの中で役割を決めて負荷分散の構成に変更する

今回も漏れなくこのあたりのチューニングはふくまれていたようですが、ふたを開けてみると「このインデックス貼った方がいいんだっけ？」とか「これインデックスだけで解決できないじゃないんじゃない？」など、アプリケーションコードとそのチューニング設定の妥当性に自信が持てないまま「やってみたけどベンチマークが上がらねぇ・・」というのを繰り返しているうちに時間だけがどんどん進んでいきました。

おそらくNew Relicなどのツールを使ったアプリケーションのチューニングを行う場合でも、何かがおかしいことはわかるがどう対処したらいいかわからないという全員の手札のなさはISUCON開催中に非常にもどかしく感じました。

たとえ手札が少なかったとしても、最近では生成AIにこういう場合はどうしたらいいかという質問を投げるとそれっぽい回答をしてくれることもあり、途中からは多少やっつけ感はあるもののとりあえず出てきた回答の中から妥当そうなものを判断しながらベンチマークを動かして、妥当性とベンチマーク結果をひたすら確認するような感じで進めていたことが功を奏して、大規模なアプリケーション側のコード修正を殆どおこなわなくてもインフラ周りの設定変更だけである程度のパフォーマンスが出せたのは結構大きな収穫でした。

次回参加する際は、アプリケーション周りのところをもう少し理解してパフォーマンスチューニングに少しでも絡められるようにしたいですね。

失敗談

事前準備として短い期間であれもこれも対応するのは難しく、とりあえずNew Relicで監視できるようにすること、New Relicが使えなかった場合でもパフォーマンスチューニングで対応できるように準備することの２点を目標として準備しておりました。

New Relicが使えなかった場合でもの部分は悪い想定が当たってしまったため個人的にはこれはこれで仕方がないか・・という感じではありましたが、事前準備の段階でNew RelicのAPMエージェントがいくら設定してもデータ送信できなかったひとつの理由として、チームメンバーから「Go設定おわったらビルドしないとね～」という話があって、「えっ？Goってビルドいるの？もしかして事前検証でうまく設定できなかった理由って・・・」というのが１点目の失敗でした。

そしてもう一つの失敗がNew Relicのマルチテナント構成が悪影響して、今回のISUCONで使用するアカウントとは別の検証用アカウントにデータを送信していることにISUCONの時間中まったく気が付かずに、ISUCON終了後のお片付けしている際に「あっ・・・・（泣　」となってしまったというお話でした。

この失敗を通じて、言語仕様はちゃんと理解しておこう、当日慌てないようにちゃんと準備しておこうという点は次の参加の際には注意したいと思います。

まとめ

私自身は初参加ということやアプリケーション周りに対応できる人がチームに１人だけ、パフォーマンス分析の際に使用する予定だったAPM周りの知識もそこまであるわけでもなかったため、個人的にはチームとして全体の半分より上か15,000点くらい取れたらそこそこ頑張った方にはいるだろうと考えていましたが、結果は130位 / 787チームで9,966点と不出来な対策の割にそこそこ得点につながったので、全体としては上出来だったと思います。私個人としてのスキルセットは現状ガッツリインフラ屋ですが、今後はアプリケーション周りの理解も深めていければと思います。

isucon.net