要約

  • RFC 9971 の MLRsearch は、明示された損失率目標を一つ以上用い、明示されたシステムとトラフィックに対する試験境界を報告する実験室向け方法である。
  • その条件付きスループットは、構成、試行、負荷、時間、目標の証拠であって、将来の本番容量、アプリケーション体験、契約上の義務を示すものではない。
  • 数値を運用や商取引に使うなら、試験記録とは別に本番観測と、承認・例外・撤回を担う責任者の記録を置かなければならない。

数字には来歴が必要だ

RFC 9971 は Multiple Loss Ratio Search、すなわち MLRsearch を記述する。汎用ハードウェア上のソフトウェア型データプレーンを含め、ベンチマークの探索時間を短くし、反復可能性と比較可能性を高めることが狙いである。ここで探しているのは、製品に貼り付けられる永続的な「性能値」ではない。異なる損失目標に対し、試行から得た境界を、条件とともに報告できるようにすることである。

そのため、結果は単なる rate ではない。どの System Under Test に刺激を与えたか、フレームサイズとトラフィックプロファイルは何か、各 Trial はどれほど続いたか、ゼロ損失か非ゼロ損失か、目標の幅は何か、どの観測が上下の境界を作ったかを伴う。これらを外してしまえば、二つの値を比較することも、値が答えた問いを再現することもできない。

RFC 9971 は Informational RFC である。BCP 14 の語を使うのは、MLRsearch 準拠を名乗る手順が曖昧にならないためであって、採用の義務や製品の認定を意味しない。また RFC 2544 を改訂も廃止もせず、独立した方法として位置付ける。単一目標を慎重に設定すれば RFC 2544 の条件に合う場合はあるが、その事実は具体的な手順とレポートに属する。

試験されたのは関数だけではない

RFC 9971 は DUT と SUT を区別する。DUT は評価したい転送機能、SUT はトラフィックを受け取り応答を観測される集合全体である。ソフトウェア機能の場合、SUT にはホスト、ファームウェア、OS、ハイパーバイザ、NIC、I/O、そして同じ資源を使う他の負荷が入り得る。同じバイナリでも、周囲の SUT が変われば試験値が変わる。

同 RFC は環境からの干渉と機能内の切り分けにくい揺らぎをまとめて noise と呼ぶ。CPU スケジューリング、メモリ圧力、共有 I/O、別ワークロード、あるいは内部処理の変動が、結果に現れ得る。有限回の試験は各フレーム損失の原因を最終的に判定しない。代わりに、揺らぎを含む試験を明示した語彙と境界で報告する。

ここに証拠の限界がある。結果は、宣言された SUT の状態について語れる。環境から独立したソフトウェアの本質的性能を語ることはできない。本番サービス全体――経路変動、再送、クライアント挙動、ストレージ依存、障害、異なるキューが絡む系――の容量を語るには、別の観測が必要である。

損失目標は価値判断を可視化する

RFC 1242 は throughput を、提供されたフレームが一つも捨てられない最大レートとして定義する。この明快さは有用である。一方で限界付近のソフトウェアでは、短い揺らぎによる稀な損失があり、より高い負荷の試行が以前より低い損失率を示すことさえある。一個の数字だけでは、試行時間、精度、不整合の扱いを誰が選んだかが見えない。

MLRsearch はその選択を分離して表す。Manager は構成を準備し Test Report を作る。Controller は Trial の負荷と時間を選ぶ。Measurer は試行を実施する。これは三つの製品を要求する図ではなく、入力と出力を追えるようにする概念上の役割である。Search Goal はそれぞれ条件を持ち、regular result では relevant lower bound と relevant upper bound が宣言済みの goal width に近づく。

複数の損失目標を一度に扱えるからといって、少量の非ゼロ損失が常に許容されるわけではない。RFC は普遍的な最良の損失目標に合意がないこと、試験の損失と上位層の性能の関係が単純でないことを述べる。同じ比率でも TCP、リアルタイム通信、複製、決済、制御系で意味は異なる。閾値を選ぶのは、結果の損失を引き受ける組織の局所的な判断である。

再現性は世界の代表性ではない

再現できる実験は、固定構成における小さな回帰を見つけるのに役立つ。しかし、実運用と異なるトラフィックを非常に正確に再現することもある。RFC 9971 は Controller の負荷選択ヒューリスティックを実装依存とし、普遍的な目標構成を定めない。そこを営業資料で埋めるべきではない。選択とリスクを持つ当事者が記録すべき領域である。

Heng Lu の Running-Code Primacy はここで実務的だ。重要なのは、実行されたコード、構成、送信されたトラフィック、記録された結果であり、ベンチマークという名称の威光ではない。最小初期仕様と局所的な将来判断という考え方も同じ線を引く。共有された測定言語は比較を可能にするが、他者の容量約束や許容損失を決める権限までは運ばない。

測定から決定への橋を別に記録する

まず benchmark record を残す。ビルド、ハードウェアと仮想化の境界、プロファイル、目標、時間、ツール、raw result を含める。次に interpretation record を作り、「この構成はこの実験室基線に対して回帰を示さなかった」といった狭い命題だけを置く。第三に、実際の範囲の queue、CPU、I/O、retry、transaction、service canary を含む production evidence を置く。第四に decision record を置き、リリース、購入、容量予約、ロールバックを誰が決め、どの条件で期限切れになるかを示す。

ベンチマークは調達の入力にはなるが、受入れ負荷や契約条件を代替しない。容量計画の入力にはなるが、ピーク分布、障害余裕、競合負荷を代替しない。リリース審査の入力にはなるが、互換性、安全性、段階展開、撤回の証拠を代替しない。SLA は定義されたサービスと期間への約束であり、一度のフレーム試験から生まれない。

慎重な下限も将来容量の予約ではない。悪い結果も、ただちに供給者違反や本番障害の原因を証明しない。どちらも検証可能な仮説を作る材料であって、判決ではない。

情報源