id:masawadaと
id:side_tanaと一緒にはやいTシャツ屋さんで参加しました。初期スコアが最高スコアでした。察してください。
チームでやった主なこと:
- New Relicの導入
- Web Transactions
- SQL
- Logs
- デプロイ自動化
- デプロイするたびにNew Relicのdeploymentsを打つ *1
- MySQL 8化n
- estateのlongitude/latitudeをgeometry型にする
- ☆searchEstates/searchChairsをやっつける
- もろもろインデックス貼る
- アプリ複数台構成へ
コミュニケーション
Slackで事務連絡、Scrapboxにメモ、Hangoutで会話という体制にした。Hangoutは繋ぎっぱ。
Scrapboxに予選ページを作ってそこで30分ごとのイテレーションで進捗確認と次のタスクを確認した。
1時間だとおよそ8回しか回せないけれど30分だと16回あるので「これ前回も共有してからハマっているな」って自覚できるタイミングが理論値では30分はやくなる。 実際、「これ前も共有しているからヘルプしますか? まきとりますか?」みたいな会話は何度かできた。
New Relic
ISUCON 9の問題を事前に解く練習をしてその時にNew Relicを試して良かったので今回も使った。
なので我々はalpを使わなかった。pt-query-digestは詳細な分析に使うくらい。複数台構成も睨まれていたので、ログもNew RelicのLogsに集約させた。
alpとかを使うのに比べてレイテンシはまああるし、X-RayやGoogle Cloud Traceと比べても遅い。これは集計にかかっているらしい。
それでもタイムアタック競技のISUCONでなぜ選んだかというと、パーマリンクを共有できることと差分の比較が楽という点が魅力だったから。
今回はリモート参加で3人全員別の拠点におり、ぱっと画面を見せたりということが難しいのでパーマリンクができてSlackやScrapboxにスッと貼れるのは便利。
あと時系列で変化を見られると、この変更が効いて速くなったねとか一目でわかる。
特に便利だったのはLogsで、これは仕事でもよくあることだけれど「こういうログが出ていました」「タイムスタンプが見たいな (削らないで!)」「スタックトレース出ていない? (削らないで!)」「どのホスト? (書いて!)」みたいなやりとりはけっこうしたことがあって、複数台で動かすとなるとこれが面倒そうだなと思っていた。 LogsはWebのコンソールに集約されるのでリンクを貼ればメンバーに過不足なく共有できるのが良い。
別途デーモンを立てないといけなくはあるけれど、まあさして大変ではなかったし最後に止めてしまえばパフォーマンス影響はないしでよかろうと思った。
ちなみにファイルに書き出すようにしたのでlogrotateどうしようか一瞬悩んだけれどデプロイごとに : > /var/log/app/isuumo.log して空にすればいいかと思った。妥当な判断だったと思う。
MySQL 8
geometry型にできるとか最新は正義でしょっていうことで選んだ。ただ、最初にコード読んだ時はGISか?!ってびっくりしたけれど、声に出して自分たちはMySQLでいくよねって確認をした。
MySQL 8へのアップグレードやgeometry型への書き換えはid:masawadaがやってくれてめちゃくちゃ頼もしかった。
感想部屋ではbind-addressとかユーザーの接続元情報とかでハマって外から繋げられなかった人もいたっぽいけれど、裏番組で本人に聞いていたら「ハマると思ったので初手でやりましたね」って言っていてかっこよかった。
反省点としては事前の練習時にはMySQLが使われたなら8に上げようって話をしていたので変更点についてちゃんと勉強しておくべきだった。 descending indexとかパラメータとかについて調べておくべきだった。
DB2台構成に至らなかった
のがこのスコアの根本的な原因だねーって話をチームメイトとした。
searchとか改善しても焼け石に水のようなスコア上昇しか見られなかったけれど、後から振り返ると順番が逆だったんだろう。しかし間違えてしまった結果「ここは意味がないのか?」「きっと複数台構成にすれば早くなるはず」と間違った推論をしてしまい深みにはまってしまった。 間違った前提からは間違った帰結しか得られないとはこのこと。
なんというかサービスを改善するっていう意識が低くてISUCONをやるっていう意識に支配されていたなあ。
各ホストのメトリック中止がおろそかになった
New Relic傾倒の余波なのかもしれないけれど、アプリケーションメトリクスはつぶさに見れたと思うが、各ホストのメトリクスはきちんと見れていなかった。
象徴的なのがinnodb_buffer_poolを贅沢にしすぎて終盤にDBがOOMで死んだこと。あとからインフラメトリクスを見ると枯渇気味だったことは一目でわかった。
これは普段ではできていることなので、良くも悪くも道具に使わされたということなんだろう。New Relic, 便利ではあったのでちゃんと手にしたい。
感想
コードを見た時に「短い! 把握できる!」「テーブルが2つしかない!」「外部へのHTTP通信ない! ほんとに?」「なぞって検索、スコアリングに影響しないのにちゃんと作られていてすごい」と今まで見てきた問題のどれよりもコンパクトでありながら歯応えがあって取り組んでいて楽しかった。 それだけにこの結果はすごく悔しい。
特にDB2台構成に舵を切る判断ができなかったのは決断力の甘さと場数の少なさを痛感させられる。
問い合わせの仕組みとかリアルタイムにスコアが増えるベンチマーカーとか予選ポータルのもてなしが充実していたりと、最大級の規模でありながらすばらしい競技体験が得られたのは一重に運営のみなさまの尽力あってのことだと思います。ありがとうございます。
次は予選突破するぞ。
*1:実際にはアプリIDを間違えていて今回は使えていなかった
