スコアが動かなくなったら

読了目安 約4分

何を変えてもスコアが同じ帯に収束したときに、何が上限を決めているのかを 2 回のベンチで判別します。

何を入れても同じ点数の帯に戻ってくることがあります。 このとき、直す場所を探し続けるのは無駄です。 何がスコアの上限を決めているのかを、先に確定させます。

数えるのは成功した仕事だけ

サーバーが物理的に処理した件数ではなく、ベンチマーカーが有効と判定した件数を見ます。

エラーを返したリクエストも、検証に失敗した処理も、リソースは消費しています。 それを含めた件数で改善を語ると、「速くなったのに点が下がった」が説明できません。

さらに、規定を満たす範囲での最大を容量とみなします。

• 検証に通っている
• エラー率が規定以下
• 応答時間の上位パーセンタイルが規定以下

頭打ちの見分け方

次の 3 つが揃ったら、上限を決めているのがサーバー側ではない疑いがあります。

• 大きく変えてもスコアが同じ帯（前後 1 割）に収束する
• ベンチマーカーの不満の内訳が変わらない
• エラーがゼロ

ただし、3 つ揃っても打ち止めとは限りません。 実測で、揃ったと判断した帯から、応答時間の削減だけでさらに 2 割以上伸びた例があります。

判別のためのベンチを 2 回

確定させるには、次の 2 つの変更で 1 回ずつベンチを回します。

リソースを増やしてもスコアが動かず、応答時間を削ると伸びたなら、全体はこう振る舞っています。

この形では、リソースを足してもスコアは増えません。 1 リクエストの往復の数と処理時間、つまり 1 リクエストがリソースをどれだけ使うか の $V$ と $S$ を削ることだけが効きます。

リトルの法則を逆に使っても確かめられます。毎秒の件数と平均応答時間を掛けた値が変更しても一定なら、それが固定された同時リクエスト数です。

疑う相手を間違えない

頭打ちに見えて、別のものが犯人であることがあります。

計測の道具そのものを容疑者に入れます。 プロファイラやログ収集の常駐プロセスが CPU の上位に来ることがあり、実測ではログの転送だけで CPU の 7 割を使っていた例があります。 計測ツールが足を引っ張っているなら、止めてから測り直します。

速くしたせいで下がることがあります。 応答が速くなるとベンチマーカーは負荷を増やすので、増えた書き込みを捌けずタイムアウトに変わることがあります。 さらに、それまで遅くて実行機会が少なかった処理が回るようになり、最初から潜んでいたバグが一気に表に出ます。 スコアの内訳を変更前後で差分して、減った項目を特定します。

エラーがどの層で出ているかを確定します。 サーバー側のアクセスログのステータス分布と、アプリケーションのエラー件数が食い違うなら、差分はアプリケーションに届く前に返されています。

仮説は計測で棄却する

原因の見当がついたら直す前に、「これが本当なら、次のベンチでこの数字がこう動くはずだ」を先に書きます。 直したのにその数字が動かなければ、仮説は外れです。 別の原因を探し直します。

直したことで説明のつかない改善が出た場合も、同じくらい疑います。 偶然だったものを効いたと記憶すると、本番で間違った引き出しを開けます。

試してみよう

次の状況を考えてください。

• 3 回続けて別々の改善を入れたが、スコアはいずれも 18,000 前後
• ベンチマーカーの不満の内訳は 3 回とも同じ
• エラーはゼロ

1. この 3 つが揃っただけで「打ち止め」と判断してよいでしょうか
2. 確定させるためにベンチを 2 回回します。それぞれ何を変えて回しますか
3. リソースを増やしたほうはスコアが動かず、応答時間を削ったほうは 22,000 に伸びたとします。次に手を入れるべきなのは何ですか

判断を書き留めてから回してください。 外れたときに、何を勘違いしていたのかが残ります。