伸びなかった実験も、次の一手にする ​

応用編では、きれいに右肩上がりにはなりませんでした。むしろ、伸びなかった変更から「いま何が上限ではないか」を知る場面が増えます。

応用編のscore履歴 ​

主な節目を、測定条件が同じものと違うものに分けて並べます。

1台・同居ベンチ ​

3台・測定場所も記録 ​

98,004だけを大きく太字にしたくなります。でも、1台ベンチはサーバーのCPUをベンチ自身と分け合い、外部ベンチは家庭回線を通ります。競技環境での順位を予言する数字ではありません。

さらに6時間: 外部の同じ経路で比べる ​

ここからは、WSLのベンチからAWS 3台へ接続する同じ系列です。外部JIAはmainへSSH tunnelでつなぎます。得点の揺れは大きいものの、変更前後を同じ経路で比べられます。

目標に置いた30位は92,604、1位は1,464,232でした。手元の最高はそれぞれ約33.2倍、約2.10倍です。最終コードを3台ともrebootした後の値です。

ただし「当時の1位に勝った」とは書きません。当時とはinstance、ベンチ実行場所、network、実行時刻が違います。ここで言えるのは、今回の同じ外部系列で1位スコア水準を越え、再起動後にもdeduction 0で再現したことです。

60万点でも不採用にした理由 ​

仮登録を入れた最初のrunは609,846点でした。ところが終盤、POST /api/authに403が73件出ました。

公式ベンチのコードを読むと、JWTは作成から30秒で期限切れになります。さらにログには、mainから応答がないまま発生したtimeoutも出ていました。認証の仕様を緩めて期限切れJWTを通せば、見かけの点は守れます。でもそれはボトルネックを隠す変更です。

このrunは「mainの前で30秒以上待つrequestがある」という計測結果として使い、採用スコアにはしませんでした。次のrunで3台同時pprofを取り、認証handlerそのものではなく、測定系を含む長い外れ値だと切り分けました。

286万点を、もう一度疑う ​

最高runではGraphGoodが13,578回まで増えました。あまりに伸びたため、Agentへ「古いtrendを返し続け、ベンチの利用者増加を避けていないか」と疑わせました。

ベンチ中40秒、mainのtrend responseを1秒ごとにhashへ変換しました。hashは中身から作る短い指紋です。40個の指紋は連続して変化し、workerからmainへの最新状態pushとtrend更新が動いていました。

速くなった結果ほど、正しさを疑う。これはAgentの勢いを止める作業ではなく、安心して次のアクセルを踏む作業です。

reboot後の0点も残す ​

最終コードを3台ともrebootし、nginx、MySQL、Goがactiveへ戻った直後に外部ベンチを始めました。このrunはPOST /initializeが20秒でtimeoutし、0点でした。Goのinitialize handlerが出すログへ到達する前に止まっており、外部networkの準備が間に合わなかったと判断しました。

同じreboot後、コードや設定を変えずに再試行すると3,072,854 / deduction 0でpassしました。だから最初の0点を消してよい、とは考えません。

• systemdのactiveは、外部から採点可能という意味ではない
• 再起動後は3つのFQDNへ実際に接続してからベンチを始める
• 競技の再起動試験には、起動待ち時間も含める

速いコードだけでなく、いつ「準備完了」と言えるかも提出手順の一部です。

gzipは効いたのか ​

JavaScript、CSS、SVGを事前にgzipすると、asset転送量は次のように減りました。

転送量は約74%減ったのに、スコアは下がりました。

ここで「gzipは遅いから戻す」と結論づけるのは早すぎます。gzip後のAPIはp99 1〜2msで、WSLのCPUも94%以上idleでした。一方、condition POSTは平均34.87msなのにp99 2ms。1%より外側だけが長く止まり、家庭回線の揺れが得点へ強く影響しています。

gzipは転送量を減らした事実を根拠に採用します。ただし「スコアを14,726点下げた」とも「必ず速くした」とも言いません。

access logを止めても伸びなかった ​

3台proxy構成のaccess logは約47MBになりました。最終runではログ自身のI/Oを減らすためaccess_log offにしました。

結果は70,064点から61,565点。期待とは逆です。

ログ停止がアプリを遅くする理由は考えにくいものの、この1回は「ログ停止で伸びた」という証拠にはなりません。設定は本番候補として残し、効果量は未確定と書きます。

計測には費用がありますが、計測を止めるタイミングも計測して決める。ちょっとややこしいけれど、これが応用編らしいところです。

HTTP/2のGOAWAY ​

外部ログには、次のエラーがありました。

http2: server sent GOAWAY and closed the connection;
LastStreamID=1999, ErrCode=NO_ERROR

http2: server sent GOAWAY and closed the connection;
LastStreamID=1999, ErrCode=NO_ERROR

GOAWAYは、HTTP/2 serverが「この接続では新しいrequestを受けない」と伝える正常な終了通知です。LastStreamID=1999は、約1,000 requestでNginxが接続を閉じた手がかりでした。

大量POSTでは、正常なつなぎ直しもベンチ側のrequest errorとして観測されます。NginxのHTTP/2 request上限を引き上げるとGOAWAYは消えました。再測定70,056点は分散内で、得点向上は断定しません。ここでも、エラーを消せたことと、scoreが伸びたことを分けて記録します。

失格runを最高記録にしない ​

3つの公開IPへ直接分散した外部runは、途中で約8.8万点まで伸びました。しかし、その後WSL側からnetwork is unreachableとなり、最終結果はError count over 100、0点です。

途中の数字だけ切り取れば強そうに見えます。でも競技のscoreは最終判定です。このrunは次の仮説を与えてくれましたが、成功扱いにはしません。

• 入口を3つへ分ける構成は、高い負荷を立ち上げられる可能性がある
• 家庭回線は外部ベンチの再現環境として不安定
• 同じAWS region内の独立したベンチ環境が欲しい
• 一部の404も、安定した回線で再検証が必要

Agentへloopの品質を頼む ​

残り時間は、改善案の数ではなくloopの品質を優先してください。

各loopで次を1行ずつ残してください。
1. 観測: どのログの、どの数字が最大だったか
2. 仮説: 何を減らせば、どの数字が動くはずか
3. 変更: 仮説と直接つながる差分
4. 検証: score、pass、deduction、timeout、status、profileの変化
5. 判断: 採用・保留・revertと、その理由

- scoreが伸びても、測定場所やinstance数が変わったら別系列にする
- 数字が動かなければ「効かなかった」ことを次の絞り込みに使う
- 外部要因が支配したrunは、サーバー性能の比較に使わない
- 途中scoreが高くても最終failなら成功扱いしない
- 失敗runのログも、次の仮説に必要な部分だけ保存する

残り時間は、改善案の数ではなくloopの品質を優先してください。

各loopで次を1行ずつ残してください。
1. 観測: どのログの、どの数字が最大だったか
2. 仮説: 何を減らせば、どの数字が動くはずか
3. 変更: 仮説と直接つながる差分
4. 検証: score、pass、deduction、timeout、status、profileの変化
5. 判断: 採用・保留・revertと、その理由

- scoreが伸びても、測定場所やinstance数が変わったら別系列にする
- 数字が動かなければ「効かなかった」ことを次の絞り込みに使う
- 外部要因が支配したrunは、サーバー性能の比較に使わない
- 途中scoreが高くても最終failなら成功扱いしない
- 失敗runのログも、次の仮説に必要な部分だけ保存する

ISUCONの改善は、正解を一発で当てる競技ではありません。外れた仮説を早く捨て、残った可能性へ時間を使う競技でもあります。