見出し画像

ISUCON12予選に参加して敗退しました

tagty

2022年7月23日(土)に開催された、ISUCON12予選に参加して敗退しました。

ISUCON11に引き続き、チームオガヨシで出場しました。
前回に引き続き、インフラを主に担当しました。

結果は、失格でした。
理由は、3回の再現スコア計測で85%以下のスコアしかでなかったためでした。
スコアは2,761点でした。

実装はGoを選択しました。

サーバーの構成は最終的に以下のようになりました。

  • Web + App (テナントの半分)

  • DB

  • App (テナントの半分)

計測は以下のサービスを利用しました。

  • alp

  • pprof

  • pt-query-digest

以下、個人的なふりかえりを書いていきます。


前回の反省

前回の反省は以下のとおりでした。

  • セキュリティグループを変更して失格になってしまった

  • マニュアルやコードをよく読まずにアプリケーションの改善に手を出そうとして、貢献ができなかった

上記を踏まえて、準備や当日の心構えに改善を加えました。

準備

本番と近い環境に慣れるために、練習はすべてAWSのEC2上で行いました。
デプロイはシェルスクリプトではなく、Makefileを使うようにしました。

当日

当日の心構えとしては、以下のことを意識しました。

  • 個人の仕事としては、アプリケーションの改善よりもインフラの改善を優先する

  • インフラの準備が終わったら、マニュアルとコードを読み、システムを理解する

10:00

競技環境構築をしました。
はじめから全員がisuconユーザーでsshできたので楽でした。
サーバーの基本的な設定をしました。
/home/isucon配下をレポジトリにpushしました。

pt-query-digestを実行できるようにしました。

Makefileでデプロイをできるようにしました。
今回は、サービスの起動にdockerが利用されていました。
設定ファイルを読むと、サーバー上でbuildするには、serviceをrestartすればよいとわかりました。

11:00

alpを実行できるようにしました。
正規表現を書くのに少なからず時間を使ってしまいました。

その他運用面でやり残したことを対処しました。

落ち着いてきたので、マニュアルを読み返して動作確認をしました。

12:00

2台目をDBサーバーにしました。

13:00

pt-query-digestを見ると、プリペアドステートメントを実行していたので、実行しないようにしました。

14:00

pt-query-digestを見ると、id_generatorに対するUPDATEが上位に来ていました。
コードを読むとsqliteのテーブルのIDを生成していることがわかりました。
UPDATEが無駄であることはわかったのですが、解決方法はわかりませんでした。
解説を読むと、アプリケーションでUUIDを発行すればよかったみたいです。

15:00

アプリケーションがCPUを多く使っていたので、3台目をアプリケーションサーバーとして使うことにしました。
今回の構成は、データベースにMySQLだけでなく、SQLiteも使っていたので、分割が難しい状況でした。

チームでは、テナントごとに処理するサーバーを分ければ、矛盾なく処理できるのではという仮説がありました。
テナントごとのリクエストはサブドメインによって判断することができます。
nginxのserver_nameを使って、特定のテナントのリクエストは3台目に振り分けることにしました。

パフォーマンスは良くなりましたが、テナントごとの請求額がずれていて、減点されていました。
増えたテナントのリクエストを振り分けられない問題も残っていました。
このとき3,860点でした。

17:00

3台目を再起動すると起動できなくなりました。
スタックを削除してゼロから作り直すことにしました。
時間が足りず、環境を再現することはできませんでした。

18:00

終了

ふりかえり

前回はセキュリティグループを変更して失格になりました。
それを踏まえて、今回はセキュリティチェックを実行しながら作業し、セキュリティの要件は守ることができました。
本番に近い環境に慣れるという意味で、AWSのEC2で練習したこともよかったと思います。

また、前回は環境構築関連の作業が終わったあとに焦ってアプリケーションの改善に参加しようとして、貢献ができませんでした。
今回は環境構築関連の作業が終わったあとは落ち着いてマニュアルとコードと計測結果を読みました。
あまり貢献はできませんでしたが、全体が把握できたので、方向性としてはよかったと思います。

デプロイにMakefileを使ったところ、運用しやすくなりました。
ただし、1台目以外にデプロイすることや環境を作り直すことに対応できていなかったので、見直そうと思っています。

テナントごとにサーバーのリクエストを分けることを実現できたのはよかったと思います。


この記事が気に入ったらサポートをしてみませんか？