要約

  • RFC 10054の例では、計算が最速の拠点でもエンドツーエンドで22.4ミリ秒、ネットワークが最速の拠点は23.4ミリ秒となり、どちらも例示された20ミリ秒の目標を超える。
  • 第3の拠点は計算5ミリ秒とネットワーク5ミリ秒で、記載上の合計は19.4ミリ秒。これらはシナリオの仮定であり、実測値ではない。

プロセッサが最速の拠点が負ける。RFC 10054のクラウドVR例では、拠点1の計算遅延は4ミリ秒で、3拠点の中で最短だ。しかし、混雑したネットワーク経路に9ミリ秒かかり、RFCが示す動きから表示までの合計は22.4ミリ秒。例示上のサービス予算は20ミリ秒だ。計算の数字だけなら勝者に見えても、利用者が受け取る結果は要件を外れる。

ネットワークだけを見ても選択を誤る。拠点2はネットワーク遅延が4ミリ秒で最短だが、高負荷のため計算に10ミリ秒を要する。記載された合計は23.4ミリ秒。拠点3はどちらも特別ではない。計算5ミリ秒、ネットワーク5ミリ秒で、合計19.4ミリ秒となる。20ミリ秒を下回るのはこの選択だけだ。RFCの仮定では、わずか3〜4ミリ秒の差が需要を満たすかどうかを分ける。

これが「Computing-Aware Traffic Steering」が扱う問題だ。サービスインスタンスは、近いだけでも、計算資源が空いているだけでも適切とは限らない。利用者が体験するのは、端末処理、転送、サーバー描画、戻り経路をつないだ全体である。RFCは20ミリ秒を、センサーサンプリング（1.5ミリ秒未満）、画面更新（7.9ミリ秒）、サーバー描画（5.5ミリ秒）、往復ネットワーク（5.1ミリ秒）に分ける。計算とネットワークの双方が予算を大きく使う。一方だけを改善して他方を無視すれば、選ぶ拠点を間違える。

RFC 10054は課題と要件を記述したInformational文書で、扱うシナリオは単一ドメインに限られる。特定の導入環境でこの選択方式が実装済みだと示すものではない。実務上の要点は明快だ。選択ロジックが最適化すべきなのは、ダッシュボードの一列ではなく、アプリケーションのエンドツーエンド目標である。

Source: IETF RFC 10054.