はじめに

こちらは長野高専 Advent Calendar 2024 19日目の記事です！NNCTアドカレ、これで4回目の参加になります！
この記事では、自分は初めて参加したISUCONであるISUCON14についての参加記を残しておこうと思います。

自己紹介

卒業してしまった身なので書いておきます！
18sで昨年電子情報工学科を卒業したBonyChopsと申します！現在は大学に3年次編入して、業務委託等々をやっています。

ISUCON とは

ISUCONは、Webのサーバーサイドで動く、Webアプリケーション、サービスを高速化することを参加者が競い合うコンテストです。

ISUCONの競技は、参加者にサーバーが何台か与えられて、お題となるWebアプリケーションが動いている状態から始まります。それを制限時間「8時間」でチューニングしていくバトルです。競技中は『ベンチマーカー』というベンチマークをかけるプログラムで採点をして、たくさん処理できたチームのスコアが上がります。分かりやすいスコアリングシステムです。最終的に1番高いスコアを取ったチームが勝者になります。

「なんでもあり」なWebアプリのチューニングバトル『ISUCON』はエンジニアの輪が広がる文化祭？　ISUCON12出題者に大人気の秘密を聞いた - Qiita Zine

です！

もう少し具体的な概要を示すと、

大会では例年AWSのEC2インスタンス(いわゆるVPS) 1-3台ぐらいを渡される
チューニングはEC2インスタンス内でやる、AWSなどのクラウドアーキテクチャは(ほぼ)問われない¹
問われる知識は主に下記
- アプリケーション実装: Go²
- Linux
- データベース
- その他なんでも³
フロントエンドのチューニングはなし
- フロントエンドのチューニングに興味がある人は CyberAgent が開催する Web Speed Hackathon もチェック

と言った感じでしょうか。

結果はどうだった？

多分これが気になって記事を開いてくださった方も多いと思うので先に書いておきます！
我々のチーム: もつ煮 の結果⁴は

スコア: 2,633
順位: 393/514位

でした！！

参加したメンバー

もつ煮はトリオ(3人)チームです。もつ煮では、役割がわかりやすくなるようにあだ名が用いられるようになりました。役割は名前の通りです(ただしアプリ以外のタスクは比較的短時間でできるものが多いため、タスクがない時は基本全員アプリケーションを見てました)。

アプリケーションチンパンジー
- 某インターンで知り合った修士2年
- パワー系のくせにフルスタックできるのなんなんだ
- 元気いっぱい
- Go歴: 1年ぐらい？業務でも使用中
- アプリケーション担当
インデックスモンキー
- 大学で知り合った学士4年
- キャッチアップの速さが最近契約した光回線より速い
- 元気いっぱい
- Go歴: ほぼ0⁵
- DBのスキーマを見て、スロークエリや実行計画をもとにインデックスをばら撒き大臣
インフラゴリラ(俺)
- 俺、学士4年
- 模擬中は歌ってみんなを励ましました⁶
- 元気いっぱい
- Go歴: 1年ぐらい、業務でも使用中
- 別インスタンスにDB分けたりアプリケーション用インスタンス分けたり大臣

使ったツール

使ったツールを紹介します。

pprotein
- ISUCON定番のモニタリングツール。使い方は以下の記事などを参考にしました
- https://zenn.dev/team_soda/articles/20231206000000
Makefile⁷
- 環境のセットアップやツールのインストールを make ... で行うために使用しました
Git/GitHub
- 行った変更は必ずうまく行くとは限りません。問題が発生した際に切り戻すためにもGitは必須だと思います
isucrud
- 各テーブルに対してCRUD操作を行う関数を Diagram で確認できるツール。問題の切り分けやオンメモリ戦略の判断で大変お世話になりました
GoLand
- 普段使っていたので今回も使いました。開発体験がよくなります

模擬

やった対策は以下の通りです。週末にDiscord繋いで8時間ぶっ通しで解く感じに頑張りました。

isucon9-qualify
isucon11-qualify
isucon11-final
isucon12-qualify
isucon12-final
isucon13

ISUCON 14

今年のテーマは「ISURIDE」でした。

「電車での移動は大変…」「自家用車は駐車場代が高い…」そんなあなたにおすすめな全く新しいライドチェアサービスがISURIDEです。

ISURIDEはアプリで呼んだ椅子に座り、自動運転で目的地まで移動できるサービスです。昨今、持続可能な社会を目指すためシェアリングエコノミーへの注目が高まっています。また、自動運転という新たなビジネスモデルは交通事故の削減や、交通渋滞の緩和なども期待されています。

ISURIDEでは、チェアオーナーが提供する椅子をユーザーがアプリから配車リクエスト、目的地を入力して、マッチングが完了するとすぐに椅子が到着します。

利用後のライド評価システムを活用し、ユーザー・チェアオーナーともに満足度の高いライドチェアサービスを実現していきます。

利用エリアも続々拡大中！オトクな招待キャンペーンも実施中！今なら新規登録でますますお得に！

フェーズ

当日の動きは以下のようにやるよう事前に定めていました。

第1フェーズ (初期)

ロール	やること
アプリケーションチンパンジー	リポジトリセットアップ→s1 pproteinセットアップ
インフラゴリラ	s2セットアップ & DB分け → s3セットアップ
インデックスモンキー	DBスキーマ熟読 & インデックス検討

第2フェーズ(20分)

ロール	やること
everyone	レギュレーション熟読会 & ソース読む

第3フェーズ(通常)

ロール	やること
アプリケーションチンパンジー	アプリケーションサイドチューニング
インフラゴリラ	アプリケーションサイドチューニング→ボトルネックAPIの特定 & s3アプリケーション展開→アプリやりつつ必要に応じてs3切り分け
インフラモンキー	DBインデックス大臣

振り返り

良かった点と反省点を振り返ります。

良かった点

ロール/立ち回りを事前に決めていたこと

事前にどのような役割か、当日はいつ何をするかをある程度決めていたため、　

スキルセットが被っていても、「どっちに頼めばいいんだ...」がなくなる
「これに関しては誰に聞けばいいんだ...」がなくなる
各メンバーが把握する「やらなければいけない事項」の数が $n$から $n/メンバー数(3)$ になる

と言ったメリットがありました。

やる気のあるメンバーを集められた

毎週模擬やろ！と言った時に積極的にしてくれる温かいメンバーでした。
ISUCONでは技術力も大事ですが、仲間とのコミュニケーションのしやすさ/チームワークもかなり重要なポイントだと思います。

レギュレーション/アプリケーションマニュアルを最初に読んだこと

最初に頭へ入れた方が戦略を立てやすいです。まあ結局それでも足りてなかったという反省をこの後しているんですが...

反省

足りなかったな〜と思うところです

模擬をただ通すだけになっていた

解いた模擬の数が少なくはない⁸と思いますが、 解いた後の振り返りが蔑ろになっていました。
本番では感想戦⁹なるものをやっていましたが、あれと同じように まずは一つのコンテストで10万点出せるようになるべき だと思います。

アプリケーションマニュアルを読む

この点においてはかなり気を付けていましたが、それでも「まだ足りなかったな」と感じさせられる結果でした。
ISUCON 14を解いた方ならわかると思うのですが、「notificationをstreamingで実装できる」という点をチーム全員が重要であると理解したのはラスト2hぐらいでした ¹⁰

実装力不足

ナチュラルに実装力が不足していると感じましたw これは実務や模擬をたくさんやってつけるしかない

「パフォーマンスがあがるとnotificationの整合性が保たれなくなる」問題が最後まで倒せなかった

これは改善点というよりナチュラルな敗因なのですが、主題に「パフォーマンスがあがると」とあるように、ある一定のスコアを超えるとベンチが通らなくなる問題だったのでスコアが頭打ちになるという地獄のような状態になりました。
ISUCON 14鯖の#general, #randomを見る限り

internal/matching エンドポイントにトランザクションを貼る
別インスタンスに分ける際、matchingを叩くサービスがあるので確実に止める
- 特にサービスが別サービス(たしかMySQL)に依存しているので、解消する

あたりが原因なのかなあ...と思います¹¹が、自分ではまだ確認ができていないので真の原因はまだわかっていません ¹²。

終わりに

このメンバーならもっと高い点が出るな〜〜¹³と思っていたので、このような結果になったのには正直悔しさがあります。ただ、何事も経験ですし、この過程と結果全てにおいて無駄だったとは全く思いません。
今回このISUCONに初めて参加して、大きく成長/学びがあったと感じたのは

DB
Linux
Go

に関するチューニングポイントの知見です。ここで得た知見は今後の実務や開発、はたまた次回のISUCONでもガッツリ活かそうと思います。もちろん来年のISUCONにも出ますよ！！！

この記事を読んでISUCONにちょっとでも興味が湧いた方がいらっしゃったら、ぜひ一緒に参加しましょう！

今年はセキュリティグループの編集が許されていたので、この知識がある場合は「ポートを開ける方法を事前に知っているとスムーズにできる」、ぐらいの利点はあります ↩
Go以外にもPython, Ruby, PHP, Node.jsなど豊富な実装例があり、それらを使用できます(ただし言語間のパフォーマンスには差があるので注意) ↩
「なんでもあり」なWebアプリのチューニングバトルなので、これ以外の知識も普通に問われることがある ↩
https://isucon.net/archives/58837992.html ↩
お得意のキャッチアップの速さでカバーしてくれました...ありがとう ↩
最初は面白いですが後半の疲れている時にやっても辛い空気になるのでやめた方が良いです ↩
ここら辺はAnsibleにしたいですね〜 ↩
多くもないかもしれない ↩
コンテスト終了後、8時間の制約を設けずにとにかく点数を伸ばせる期間(ただし大会のスコア/順位には反映されません) ↩
ただ、実際高得点を出されている方々の話を聞くと、どうもstreamingの実装をされていない方もちらほらいるみたいで、どちらかといえばnotificationが正しく返却されるようになることが優先かもしれないですね ↩
上記に関しては全て対応した自覚があるのですが、当時焦っていたこともあり、ここらへんのオペレーションを雑にやっていた記憶があります。よって正確に反映できていないことも考えられるので、そこも敗因の一つかもしれません。 ↩
卒研etcで忙しいため感想戦に参加できていません... ごめんなさい！！！ ↩
最後の模擬では2万点ぐらいでした ↩