UTE-1に参加しました
こんにちは、monica です。
この度、ウルシステムズ株式会社さん主催のUTE-1というイベントに参加してきました。
UTE-1 とは、学生を対象にした Go アプリケーション開発のビジネスタスク力・パフォーマンスチューニング力を競うコンテストです。
ISUCON の学生向け、Go に特化したバージョンといった感じです。
私たちについて
なぜUTE-1に参加したのか
私のいる某大学で昨年度の夏に新しく「Web 研究会」を立ち上げました。
(正式には競プロサークル Maximum の子サークルという立ち位置です。)
未経験の学生が Web アプリケーション開発の基礎を学べる基盤を作りたいという目的で実務経験のある私(monica)と競プロサークルの代表(Asa)の２人で立ち上げました。
ISUCON に参加することを目標にして人材育成に励んでいたところ、ウルシステムズさんから UTE-1 の招待をいただき、せっかくの機会なので参加してみようということになりました。
メンバー構成
- 私（monica）: フルスタックエンジニア、Go 初心者、実務経験者
- Asa: フルスタックエンジニア、Go 初心者、Atcoder がつよいひと
- Through: Web 未経験、一年前に競プロでプログラミングデビューをしたひと
- Kasa: Web 未経験、一年前に競プロでプログラミングデビューをしたひと
事前準備
学期末が終わった 2/9 から毎晩 3 時間ほどあつまり、ISUCON の過去問をといて主に「パフォーマンスチューニング」について勉強しました[1]。
本番が 2/25 日なので 15 日間と約二週間という短い期間で基礎をがん詰めするということになりました。
本番
UTE-1 運営の意向により、問題内容やコードは公開しないとのことなので、ここでは私たちの取り組みについてのみ記載します。
流れ
| 時間 | 内容 |
|---|---|
| 10:00 | 開会式 |
| 10:30 | リポジトリの配布、本番環境の公開、開発スタート |
| 17:00 | 本番環境の停止、開発終了、最終採点スタート |
| 17:40 | 最終採点終了、結果発表、閉会式 |
| 18:00 | 終了 |
| ... | (優勝者だけが参加できる領域) |
開発環境
- リポジトリ: 事前に UTE-1 の Github Organization へ招待され、各チームに 1 つ配布されます
- 環境:
- ローカル: docker, docker-compose, devcontainer
- 本番: k8s, GKE(GCP)
- CI/CD: Github Actions
- DB: MongoDB, MySQL
チームの役割分担
| メンバー | 役割 |
|---|---|
| Through, Kasa | バグ洗い出し、Issue立て（仕様書を熟読してドメインリーダーになってもらう目的） |
| 自分, Asa | Issue解決、バグ修正 |
なるべく初心者の 2 人の開発負担を軽くしたいということで、このような役割分担をしました。
バグの発見と修正
私たちは Issue Template を事前に用意して、初心者でも GitFlow がうまく運用できるようにしておいたため、バグの発見から共有、タスクマネジメントはとてもスムーズでした。
まずは、仕様書を読み、バグを洗い出しました。想定外[2]のバグ Fix タスクなのでとても苦戦しました。
特に IO(Req,Res)のバリデーションやクエリ修正等のシンプルなものが多かったですが、トランザクション系のアプリ故になかなか読み慣れない書き方が多く、発見と修正に時間がかかりました。
パフォーマンスチューニング
[1:1]のとおり、パフォーマンススコアを上げるためには、先にある程度のバグを修正する必要がありました。
自分たちのチームはバグで想定以上につまづいてしまったのでほとんどパフォーマンスチューニングに取り組めませんでした。
MongoDB や Mysql へのスキーマは SQL で定義せず、Go 上で定義していました、しかし ISUCON 対策で未経験二人に SQL を教えていたため本番では詰んでいました...
（先見の明があれば...もっと実務的なことをやっておけばよかった...と反省しています）
結果
初動はかなり順調で、開始二時間半の時点で 5/30 位にランクインしました。
しかし、バグ修正と仕様書の解釈ミスが重なりに重なった結果、中盤以降のスコアが停滞してしまい（同じバグで 3 時間ほど悩んでしまいました...）、最終的には 22/30 位にとどまる結果となりました。
反省
結果を踏まえて当日中に感想会という形で振り返りを行いました。
- 仕様書の解釈ミスが目立った
- 仕様書を読む担当とバグ修正担当で疎通がうまく取れず、解釈ミスがバグ改善の時間にも影響してしまったので、ビジネスタスク力や読解力がより重要になると感じました。
- バグ修正の時間がかかった
- 適宜テストを書くべきだった（時間的な焦りからテストを書くという選択肢に踏み出せなかった）
- ローカル開発環境の立ち上げで詰まってしまった（docker の立ち上げで 30 分ほどかかり、さらにローカルでの改修後反映の方法がわからず、結局本番でログを見ながら修正した）
- ベンチマークをより積極的に使うべきだった（点数からできる問題推測やログを見ることも重要だと感じた）
- 人的リソースのマネジメント
- 30 分ごとにチーム全員へ進捗を聞くという形で被っているタスクをしていないか、同じ問題に詰まりすぎていないかを確認していたつもりだったが、結局口頭での毎回の確認が目立ち、時間がかかってしまった
- 例えば Issue Flow を強固にしたり、リアルタイムタスク共有ツールを使ったりするなど、チーム全体のコミュニケーションをよりスムーズにする方法があると感じた
- 十分な事前学習ができていなかった
- これは参加が決まって学期末が終わってからの対策で、効果があまり出なかった
- 次回(ISUCON に参加する予定)はより長めの対策と過去問分析をしたい
まとめ
ISUCON に参加して、自分とサークルとしての課題を見つけることができました。
今回見つけた課題を今後のサークルの講義で活かし、より実践的な講義をしていきたいと思います。
さいごに運営の方々、チームの皆さん、応援してくれた皆さん、ありがとうございました！
Discussion