水底

ScalaとかC#とかk8sとか

ISUCON7本戦は惨敗でした

最後の学生枠チャンスが…

問題解説は公式に譲るとして次回に向けて覚えていることをメモ. 特に有益な情報はないです.

競技中

役割分担は予選と同じくミドルを担当し, アプリは@spring_rainingと@susisuに任せる…予定でした.

序盤は構成把握・ツール類の導入・プロファイラの導入といったいつも通りの流れ. WebSocketベースだったため準備していた単純なアクセス解析ができず, とりあえずDBログにちらついていた m_item をオンメモリ化とroom別負荷分散対応してからスコア計算部分に取り掛かろうという方針ではじめました. しかし m_item をオンメモリ化するとベンチがfailしだして早速雲行きが怪しく. 3人がかりでもすぐには解決できず負荷分散とスコア計算をやることに. 負荷分散の方はすぐに終わったもののスコア計算で無限にfail. 私はアプリを離れて裏で static_gzip 等のミドル側でよくやる最適化をちまちまやっていました. その後ミドル側は一段落したものの相変わらずスコア計算部分が解決できず, ここ (15時くらい?) から競技終了までほとんど進捗がなくなります. それからミドル側は出来ることがなくなってしまったので私もアプリ側に参戦することに. この段階で@spring_rainingと@susisuが最終的にどちらかの実装が通れば良いだろうということで別々の実装を進めていたので, 現状を聞きつつコードを読みつつ2人を後ろから突いていました. この状態が続き, 終盤はスコアではなくbugfixが目的化しほとんど何もmergeに至ることなく競技終了となりました.

結果と反省

結果としてはfailしなかったものの点数があるチームの中では最下位. ほとんど何も出来ずに終わりました.

反省点はいくらでもありますが, 特に大きいのは出だしの m_item オンメモリ化で躓いてしまいテンパったこと・ミドル側の仕事が相対的にかなり少なく, 途中からアプリ側にまわるもほとんど力になれなかったこと 辺りでしょうか. 最初の構成把握段階でより詳しくアプリ側も把握していつでもアプリ側を手伝える状態にしておくべきでした. 加えてアプリ側の2人が別々の実装で進める判断も結果的に失敗でした. アプリ側は基本的に2人に任せていたのですが, 全員でより細かく丁寧に方針設計して少しずつでもそれを実現していくべきでした, バラバラに進めちゃうとお互いにサポートできなくなりますからね.

まとめ

問題の難しさも去ることながら, チーム開発の難しさも再確認させられるコンテストでした.

次回は一般枠で予選突破を目標に頑張りたいです. ISUCON5からずっとミドル側を担当してミドルを素早く捌くための資産が十分に溜まりほぼ作業ゲーのようになってしまっているので次はアプリ側にも手を出したいな〜

予選時のエントリ

amaya382.hatenablog.jp

公式問題解説

isucon.net