Hitori-Gotten Log
表題の通りですが、「ブログを書くまでがISUCON予選です！」ということなので大分遅くなりましたけどエントリ上げてみます（毎度）
結果
ISUCON に参加したのは自分は今回が初めてで、@matsumana さんと @sgykfjsm さんとのメンバーで 「博多三双 明太子ラーメン」というチーム名で予選1日目 (2017/10/21) に参加しました。
- 言語: Go
- 最終スコア: 95,883 (ベストスコア: 97,679)
- 順位: 34 位 (407組中)
順位は以下の参考値のものです。予選通過が上位18位まで(←簡単にいえば)、通過ラインが20万点ほどだったので見事予選敗退でした。
ISUCON7 オンライン予選 全ての順位とスコア（参考値） : ISUCON公式Blog
スコア推移や作業内容はリーダーでインフラ担当の matsumana さんのブログにまとまってるのでこちらを見てもらうと早いです… 😇
ISUCON7の予選に参加しました #isucon | @matsumana の技術メモ
準備
まず使用言語が他の二人の得意な golang でいくということで、Go の勉強をせねば、というところ。
その少し前から入門書を読み始めたくらいだったので大丈夫かなと思ってたんですが、結果から言うと全然足りてなかったので 次回までには鼻歌交じりに書けるようになりたい…
当日
13:13 開始（約3時間遅れて開始）
参照実装の初期スコアは 6604。Go 実装に変えたら 3613 でした。
matsumana さんがインフラ系、 sgykfjsm さんがアプリ系の環境構築をして頂いてる中で自分の作業を進める:
- ソースを GitHub private リポジトリにアップ
- テーブル定義確認、インデックス追加
- percona-toolkit での slow query 確認
- alp での nginx アクセスログ 確認
- pprof でボトルネックを確認
- ソース改修
最初 pprof がビルド時の環境と実行時の環境でソースの位置が違っていて pprof list でのソース行ごとの プロファイルが取れてなかったりして途中まで pprof top と percona-toolkit と alp のみでボトルネック潰す方向で作業。 (percona-toolkit と alp での取得は matsumana さん作業分)
pprof もっと慣れてればよかったと反省（直前に methane さんのブログで予習した程度だったので）
しかし思ったように最初手を付けた所の SQL の改修が行ったり来たりで進まず、 いったん中断して /icons の処理に着手。
19:00頃
- 画像を DB から引き剥がして静的ファイルに変更
このあたりでようやく戦える数字に。作業内容自体は難しいものではなかったけど、方針決めるのに大分時間が過ぎてしまっていた…
20:00頃
終了約1時間前のスコア。
このあたりからベンチマーカーが fail して 0 点になる、という自体が頻発していてその原因を探る羽目に。
常にベンチの二回目で成功して一回目でこけている、ということが分かり、何が悪いんだ…と バタバタしてたけど、アプリ起動直後にベンチを走らせるとこける、というよくわからない理由であることがわかった(?)ので 起動後30秒待ってからベンチ走らせることで解決した。この時間のバタバタは完全に無駄だった…
matsumana さんは直前まで作業進められてましたけど、アプリ側は作業してベンチ取って revert して、の繰り返しで スコアを上げられずに終了。
ふりかえり
良かった所
- 直前に pixiv さんの社内 ISUCON を同じメンバー・同じ時間帯でやってみたこと。初参加ながら当日のイメージがつかむことができた。
反省点
- 圧倒的に手数が足りなかった所。
Go は読みやすいので理解は早いけど、いざ自分が書く時に「Javaだとこう書くところを Go だとどう書いたらいいんだっけ…」 みたいな手間取りが多くて全然手が進まなかった。予選通過チームを見たら全然作業量が違ってた。
- ベンチマーカーの挙動をもっと意識するべきだった。
当日マニュアルに色々と書いてあったのに、読んだつもりでいて頭に入ってなかった。 直接的にはスコアにかかわらない部分（とはいえ最終的には速くする必要はあったっぽい）所について、 プロファイラ見てボトルネックだからと思いこんで時間をかけすぎてしまった。 遅い部分を直すコンテストではなく、高得点を取るコンテストであることをもっと意識する必要があった。
- 慌てないこと、思い込みを無くすこと。
例えば必要なインデックスをすぐに張ったけど、実は最初から張られているものがあって途中で不要なものを消したりした所があった。 どうも「インデックスは ISUCON では一切張られていないはず」みたいな思い込みがあった模様… 落ち着いてやるべきことを丁寧にやっていくべき。他にも「実際の運用ではこんなリクエストは来ない」と見送った所、 実はベンチマーカーがバグっててそんな対応で実は良かった、みたいなこともあり…（ベンチ取ってみれば良かった）
- インフラをもっと見れるようになること。
結局のところ ISUCON はインフラチューニングが本来の趣旨だと思うので、インフラ担当者に任せるだけでなくて 自分も問題の調査・解決策の提案等ができるようになっていないといけないと痛感。 アプリ改修にあたっても、方向性を決めるのには全体を見渡せるインフラ力が必要とされる（はず）
とりあえずISUCONで学んだことを実務でも意識的に触ってみることと、会社の蔵書にある ハイパフォーマンスWebサイトや 続・ハイパフォーマンスWebサイトとかを読んでみる。
まとめ
こんな大規模な構成での予選を実施して頂いた運営の方々、サーバ提供のさくらインターネットさんありがとうございました。
毎年開催側の負荷が上がっている中、今年も開催されたこと自体有り難く、またぜひ来年も開催されることを願ってます。
おまけ
参考値スコアとはいえ、同僚が参加するチームに敗退してました… orz
(ベストスコアでどうだったかは不明)
来年までには Go もインフラ力も鍛えなおしてきます！！！１