📝

ISUCON13にて初参加し敗走した記録

2023/11/30に公開

ISUCON

webパフォーマンス

tech

はじめに

SDD(眠気ドリブン開発)の1人amkkrとして、ISUCONに初挑戦しました。
その時自分たちが、

ここまで出来た
これが出来なかった
こんなものは思いもよらなかった

といったものを時系列でまとめて、次に繋げるために書きます。
あと、「記事まで書くのがISUCON」らしいので！！！（運営の方談）

先に個人的反省点をまとめ

時系列も書いて長くなりそうなので、先に次の自分や来年初参加する人向けにまとめようと思います。

3人で参加する
- 2人じゃ頭も手も足りないです。基本的に通話を繋ぎっぱなしになるのですが、話し中、相談中は実質1人減るようなものなので、2人ペアだともはや手が1人分になります。たりなさすぎます。
過去のレギュレーションも読んでおく
- これは当日に「どこまで触っていいのかが分からん！」となった教訓。
- 例えば、
競技終了時間までに、競技の内容に関するあらゆる事項 (問題内容・計測ツールの計測方法など)を公開・共有すること(内容を推察できる発言も含む)
引用:https://github.com/isucon/isucon11-prior/blob/main/webapp/doc/REGULATION.md
- という１文からGitHub使っていいの？レベルに何もわからなくなったため。
- レギュレーションをちゃんと読むと競技に必要なアクセスとして許可されていることとかもわかるけど、書かれていることにすらその時には気が付けませんでした（自戒）
インデックスは貼り切ろう
- SHOW PROCESSLISTやslow_query_logをみて、明らかに重い上位3件程度まではインデックスを対処したものの、それ以下が同じような数値だったため放置。なお、それ以下で出てきたクエリ、テーブルは、一様にインデックスが貼られていないから同じような速度だったというだけでした。ちゃんと調べよう。

チーム構成

今回は2人チームで挑みました。
2人ともインフラ構築をガッツリやってきたわけではないが、コードやクエリを書いたり調査したりしてきた人種です。
メンバーの大まかな情報は以下

自分
- 職歴
  - 新卒入社した会社でバックエンド1.5年
  - 転職してNext.jsを扱うフロントエンダーになって1年
  - 大体の経歴：https://www.wantedly.com/id/tenshin_yakura_a
もう一人
- （自分から見た）前職の同期
- 2.5年バックエンダー（のはず）
- 「Linuxが一生わからない」とは本人談（あのC言語のコードは難しいよな...）

本番前にしたこと

ISUCONのため、ではないことも含めて自分の時系列を並べると

夏頃にISUCONにもう一人から誘われる
現職で速度改善系も取り組み始める
ISUCON本を読み始める
Dockerで環境構築できるものを触ってコンテナのインフラにおののく + 本番はコンテナではなさそうと気がつく
特に予定が合わないまま、本番2日前になんとか過去問を初める
6. いきなり「インフラ変えようぜ」と言われ再度おののく

当日したこと

以下、当日のチャットの時間を元に覚えている限り書いていきます。

10:00〜

競技内容発表で「こんいす〜〜〜」と💖を送る。
環境構築を開始、事前チェックでは一人だったのでaws-cliを叩いたが、画面共有しながらステータスもみたいよねとブラウザでポチポチ。

10:40

環境構築終了、もう一人もssh接続できるようにしてhtopで見ながら初回ベンチ実行

10:48　〜

定石通りCPU使用率が跳ねる瞬間が見えるDBからテコ入れ開始。
スロークエリのログ設定やテーブル構成のチェックをする

12:00~

インデックスを張ったのに何も変わらない、そんなはずがないと不思議がる。
30分ほどして、ベンチマーク実行のページから3台あるうちのどのサーバにリクエストを投げるか選択できることに気がつく。
どうせ1番に向いていると思いこんでいました、恥ずかしい。

12:30~

向け先を変更し、とりあえず1個貼ったインデックスの効果があることを確認。
ここで全部に貼ればよかったのだが、ログから見た重い順上から3件ほどしか実行しないまま、あとは似たようなスコアと重さだから貼るだけインデックスショットガンになりそう、などと思いやめてしまう。

お昼休憩

13:00〜

午後からは、インフラ系やってみたいよね、という希望通りに進めるが思わぬ事故にあう。

再開し、nginxにログ出力の設定をして様子見。

やることをまとめていたので転記

envを書き換えて、DBを外部に向ける
設定をもう1機のAppサーバーに移す。
nginxでロードバランシングとか
結論から言うと、上位グループのフリ帰りを聞くとアプリサーバー２台にしてロードバランシングはしなくて良さそう。また、Githubを使っていない縛りプレイ状態のため、設定移植がまあしんどい。

13:30~

DBの外部接続許可の設定がわ”か”ら”ん”
ここで覚えている限り、思考の順番を書き連ねると

CREATE USERとかでユーザーを作らないとだったな
このDBにするサーバーのIPを他のサーバーのDBホストのenvに書いて
ベンチ→動かないじゃん！！
GRANT ALLで許可が必要？実行
ん？許可？？セキュリティグループどうなってるんだっけ。
（AWSコンソールを見ながら）グプルないで同じ192.168始まりのローカルIPで全許可になってるし、うーん...パブリックIP関係ないよねえ？ポート周りに変なenvをコード中で入れてきたりしていないよねえ...?
mysqlのサービス再起動もしたはず...怖いからもう1回叩いとくか..
bind-address...?何これしらないconfigがあるらしい(本当に初めて知りました)

ここで気がついたものの、設定を見様見真似で書くが落ち続けてわからないまま格闘を続け、フォーマットエラーを解消できたころには15:00を回っていました..

15:30~

ロードバランシング試してみようとこんなことをnginx.confに書き始めました↓（そのまま書くのも嫌なので、抜粋、一部変更しています）

        upstream isucon13 {
            least_conn;
            server 192.168.0.xx;
            server 192.168.0.xx;
        }

アクセスログの出力設定も揃えてベンチを回すと、ログが2台のアプリケーションに流れるもののスコアが減少。
ここで野の頃3時間ということで、スコアのためにた３０分ほどかけて設定を戻し、コードのチェックに移り始めました。

16:00~終わりまで

設定を戻している間に,取ったアクセスログからもう一人がコール回数をエンドポイントごとに出してくれました。それを見て多いところから手をつけようとしましたが、トランザクションをそのまま剥がすとベンチの初期化タイミングのチェックに失敗して落ちる事がわかり格闘をしながら最後の時間を迎えました。

後半に行くほど切羽詰まってチャットにテキストを残していないのも振り返りしづらいので、ちゃんと書いていきたいですね、反省点です。

最終結果

9,408 　SDD(眠気ドリブン開発)
でした、1万届かなかったか...

感想・謝辞

感想としては、ここはやろうと決めていた

DBチューニング
サーバ構成の変更
にはとりあえず取り掛かれたことは今は良しとします。
ただし、計測が全て、インデックスショットガンを疑う前に貼られているかも確認せよ。
慣れないconfに慣れるほど触る機会はないが、ここは本当にISUCONの練習あるのみ。
とは心得ました。

次はアプリケーションエンジニアらしくコードの修正にもっと注力できるように、会社でも使っているプロダクトのあるGoの勉強はしたりアサイン貰ったりやっていこうと思います。

最後になりますが、ISUCON運営の方々、スポンサーの皆様方、こういった社外でパフォチュー、課題解決という機会をありがとうございました！
入賞者の方々も、本当におめでとうございます。
終了後のコメントやDiscordでは、ただただ（こんなことをしていたのか！）と驚かされるばかりでした。
チームメンバーも、フロントエンダーになり距離も空いた自分を誘ってくれて本当にありがとう。
これからもisuconが続くことを願っています。

また、ここまで読んでくださった方がいましたら本当にありがとうございます。