ISUCON13にチーム「なんかいい感じではやいやつ」で参加しました → スコア91400点で総合20位
概要
2023年11月25日に実施したISUCON13にチーム「なんかいい感じではやいやつ」として出場しました。結果は全体20位と目標としていたネームカード・認定証ラインを達成することができました。この記事ではチームして取り組んだこと、感じたことをまとめます。
チーム「なんかいい感じではやいやつ」
アバター | 名前 | 役割 |
---|---|---|
hirosuzuki | 私 インフラ担当兼アプリ担当 ISUCON7から毎年参加しているチーム最古参 |
|
ekusiadadus | アプリ担当 前回(ISUCON12)からのチームメイト 26位で本選出場をギリギリ逃し一緒に涙を流す |
|
myuon | アプリ担当 ISUCON初出場 業務でバリバリGo言語を書いている |
前回ISUCON12は私の会社の同僚3名でチームを組みました。今年はそのチームメンバーが転職したことも新しくチームを組んでいます。全員Go言語でアプリ改修ができることが強味のチームです。チーム名は今年2023年前半のトレンドランキング1位のゆるかわアニメ「ちいかわ ~ なんか小さくてかわいいやつ」とISUCONの「いい感じにスピードアップコンテスト」をもじりました。
参考: ISUCON12予選に参加しました → 最終スコア 20943 (mnsys)
事前準備
本番1か月前からチーム練習3回を行いました。
- 10.21(土) isucon10本選 オフライン
- 11.04(土) isucon11予選 オンライン
- 11.18(土) isucon12本選 オフライン
このチーム練習を通して、開発環境や計測フロー、GitHub運用方式、8時間の使い方などチームとしてどう動くかの意識合わせを行うことができ、非常に有意義なものであったように思います。
その他、個人でも private-isu, isucon11-prior, gasshuku-isucon を復習しています。
方針
チームで以下の方針を立てて当日に臨みました。
- 開発サーバーを別途構築し、VS Code Rememote Development SSH を利用して開発サーバー上で作業する
- ビルド&デプロイ、ログ収集&分析をこの開発サーバーで実施
- 直接サーバー上でソースファイルや設定ファイルを修正しない
- 3人のソースファイル同期はGitHubのプルリクエスト駆動
- 序盤なるべく早く改善サイクルを回す環境を整える
- マニュアルを全員で読み合わせし、チューニング方針の意識合わせを行う
- 前半(15時めど)はサーバー3台をメンバーそれぞれが占有して開発する(1人1台体制)
- 後半戦は複数台体制を構築し、3人ペアプロで作業を進める
- 最終盤(17時めど)ではスコアをまとめていく。(再起動試験、スコアガチャ、ロギング停止など)
当日
当日は myuonの会社の会議室をお借りして、オフラインで3人集まり競技に参加しました。
私自身が行った作業/改修は以下のとおりです。
- 各種プロファイリング設定
- Nginxログ、kataribe設定
- SQLログ出力設定
- インフラチューニング
- Nginx
- MySQL
- Kernelパラメータ
- アプリ改修
- moderateHandler(NGワード登録) → SQLではなくアプリ側で処理
- getUserStatisticsHandler → N+1クエリ解消
- 複数台構成化
- 1号機 → Ngix, PowerDNS, App
- 2号機 → PowerDNS用MySQL
- 3号機 → App用MySQL
後半戦複数台構成にしたところで67000点までスコアが出ていましたが、突然30000点前後までスコアあ下がる現象が発生しました。理由はNgnixのKeepAlive有効化にあり、それを無効化することでスコアが戻せましたが、原因の発見に結構な時間がかかってしまいました。
チームメンバーは以下のブログが詳しいです。
結果
最終スコアは91400点となり、全体20位で当初から目標としていたネームカード・認定証ラインを達成することができました。また、FAIL数の多さからTVer賞もいただくことができました。
3人オフラインで参加したことでベンチ実施の声掛けがスムーズにできたこと、前半1人サーバー1台作戦をとったことでデプロイの手数が稼げたことが、FAIL数の多さにつながったと分析しています。
振り返り
以下が今大会(ISUCON13)の振り返りとなります
Keep
- 3度のチーム練習の成果が出て、本番ではチームとしてスムーズ動くことができたと思います。
- サーバー分割の面ではCPU使用率が3台に満遍なく分散できており、プログラムの改修レベルとマッチした分割構成だったようです。
Problem
- PowerDNSのTTL設定を忘れるなど、細かいインフラチューニングができませんでした。KeepAlive対応に時間を取られたこととが主な原因です。
- DNS水責め攻撃への対応がほとんど出来ませんでした。DNSDBを分割したくらいが行った施策となります。PowerDNSよりも比較的身近なアプリ領域にチューニングを優先したことが原因です。
- プロファイリングでボトルネックの解消を中心とした改修となっていました。 スコアは売上金額のため、本来であればユーザーの挙動を分析して改善を行うべきところでした。
- 再起動試験を実施できませんでした。これも心に余裕が無かったことが原因です。
Try
- 今回は3年前から利用している自家製の分析ツールを利用しました。次回は pprotein などより便利なツールを導入を検討したいと思います。
- 今後の大会は今回のように予選がく本選のみとなることが予想されます。本選ボリュームの問題を効率的解くためには生成AIの活用が不可欠になるように感じました。解析自動化やプログラム改善の方法論を考えてきたいと思います。
Discussion