きっちんゴリラ*1*2というチーム名で、id:tyage, id:nonyleneと出場しました。
結果は、max 113,846、score 95,352でした。
詳しい内容は
の通りです。
準備
去年の反省を活かしてデプロイスクリプトやベンチマーカーが混んだときのための負荷クライアントの雛形を準備していきました。
結果、提供されたベンチマーカーのスケーラビリティが素晴らしく後者は無用となりました。*3*4
作戦
結果的に、以下の作戦になりました。
- app1サーバのnginxでロードバランサになる
- app1サーバだけで
/iconsに関わるすべての処理を受ける - app1, app2サーバで残りの処理をする
- pumaのthreadsを増やしまくってCPUを使い切れる範囲でいい感じの値を二分探索する
- ベンチマークガチャを引き続ける
役割分担
- 全員
- 初期の足場硬め
- ログやメトリクスの収集環境構築
- デプロイの仕組み
- tyage
- アプリのチューニング
/iconsの処理をDBから剥がす- N+1の解消
- nonylene
- インフラの設定とチューニング
- HTTP Cache問題の解決
- nginxやsystemdの設定
私はmackerelの設定といった細かい雑用やベンチマーク結果のエラーを眺めてボトルネックの指摘をしていたくらいで、特に実装上の貢献はありませんでした。
が、チームの皆様が優秀で/iconsのHTTP Cache設定およびimageテーブルの破棄（と、パラメータチューニング）がうまくいって10万点付近まで浮上することができました。
知見
戦略をちゃんと考える
戦略はありませんでした。しかし、今回のisuconは戦略を立てられたかどうかでHTTP Cacheの問題をクリアした後の点に大きく差がついたであろうことにあとで気づきました。
ISUCON7予選 当日マニュアル.md · GitHubb.hatena.ne.jpfetchにもN+1があり、POSTは3倍の点なのでfetchを遅くしてfetchで食うリソースを減らす。fetchでworkerが取られるのでthread数は思い切って増やすという戦略が有効だった。（もう遅い
2017/10/23 19:25
ということです。
にも書いてあるとおりです。
元の当日マニュアルにはちゃんとヒントが散りばめられています。太字になってすらいますね。
ドキュメントは落ち着いて隅から隅まで読まないければならないことがわかります。
実作業をして手を動かしてるとどんどん視野が狭くなっていくので、最初のうちに戦略を死ぬほど考えるとよいかもしれません。*5
CPUを早いうちに使い切る
Mackerelを導入してグラフが見えているのにも関わらず、CPUを使いきれてないことの問題をはっきりとは意識できてませんでした。
CPUが使い切れていないということは、ネットワークやディスク、メモリのいずれかがボトルネックになっているということであり、まず最初の目標はCPU使用率を100%になるよう設定を弄ることだったのかもしれません。
意識していても設定を弄ったりコードを読んでると忘れてしまいがちなので、ここを最初にクリアするのが重要です。*6
ベンチマーカーの気持ちになって考える
ユーザやjsのクライアント実装の気持ちになるとも言えます。
解説にもあるように、jsクライアントの実装は/fetchを起点としたmessageの取得になっています。
ブラウザでしっかりとアプリケーションの動作を確認して図にしておくと、当日マニュアルの読み込みが効いてきそうです。
感想
いいチームでおもしろい問題を解き、10万点の大台に乗れた点で概ね満足できました。
特にsleep(1)が一見不要に見えて本質的なパラメータになってるのは、とても面白かったです。インフラとアプリのバランスも良かったように思います。
運営および作問、インフラ設営、チームのみなさまありがとうございました。とても楽しく有意義な8時間でした。
