要約

  • RFC 10053では、CATSはネットワークと計算資源の情報を使って、クライアントから見えるサービス接点を選ぶ。その接点は一つ以上の内部サービスインスタンスを扱えるため、選ばれた接点だけから実際の処理先を特定することはできない。
  • 接点のメトリクスは複数インスタンスを集約しうる。さらにサービスメトリクスエージェントが複数の接点を集約する場合もある。選ばれた経路や安定して見える集計値は、ステアリングの状態を示す証拠であって、個々のリクエストの実行先や結果を示す受領記録ではない。

入口が見えても、その先の処理までは見えない

オンライン対戦ゲームの参加リクエストを考えよう。クライアントはサービス識別子を指定する。ステアリング側は、経路が短い拠点と計算資源に余裕のある拠点を比べ、サービス接点を選ぶ。システムは到達可能なサービス接点を選び、そこへリクエストを送る。クライアントに見えるのはサービスの入口だ。接点自身が処理することもあれば、内部のどのインスタンスに任せるか決めることもある。

RFC 10053が両者を区別しているのはそのためだ。サービスインスタンスは事業者のサービスロジックに沿って稼働するリソースの集合である。サービス接点はリクエストを受け取るクライアント向けの機能で、一つ以上のサービスインスタンスを扱う。ロードバランサーのように、リクエストを内部へ振り分けることもできる。RFCは、接点より先のステアリングはクライアントにもCATSの構成要素にも見えないと明記している。

したがって「CATSがサービスを選んだ」という表現には範囲がある。CATS Path Selector（C-PS）はサービスとネットワークのメトリクスエージェントから情報を受け取り、出口CATSフォワーダーを選び、場合によってはサービス接点と経路も選ぶ。これは事業者のサービス構造へ入る地点を決める処理だ。実際に仕事をした内部インスタンスをそれだけで示すものではない。

メトリクスの集計範囲を確かめる

RFC 10053は、階層型や再帰型の構成では、選択からクライアントが実際に呼び出すインスタンスを特定できない場合があると述べる。そのため、サービス接点のメトリクスが複数のサービスインスタンスを集約した値になることもある。第4.2節では、CATS Service Metric Agentが複数のサービス接点のメトリクスを集約する、個別に保つ、または両方を行うことも認めている。前者は接点の背後にある実行先をまとめる場合、後者は接点単位の状態を選択器へ配る前にまとめる場合だ。集計の階層を混同してはいけない。

集約値だから誤りだという話ではない。何を測った値なのかを知らずに読むと、主張を広げすぎるということだ。接点の平均値は入口を選ぶ材料になっても、遅いリクエストの裾野、あるリクエストに割り当てられた実行先、その応答結果までは語らない。拠点単位の集計は大規模化に役立つ一方、各接点の個別測定とは異なる。RFCは展開上の選択を事業者に委ね、唯一の選択アルゴリズムも定めていない。

CATS Traffic Classifierは、同じサービスリクエストに属するパケットを選択済み接点へ送り続けられる。第4.4節の接点インスタンスアフィニティは、フローのパケットを同じ接点と経路に留め、並べ替えや予測しにくい遅延変動を抑える考え方だ。これは転送上の性質であり、接点内部の振り分けを見えるようにするものではない。CATSの判断とバックエンドの実行先・結果をリクエストごとに結ぶ記録は、この枠組みには定義されていない。

たとえば、一つの接点がゲーム参加リクエストを複数のマッチング用インスタンスへ振り分けているとする。一つの処理系だけが混み合っても、集約された接点メトリクスは問題がないように見える可能性がある。そのままCATSが接点を選び続けても、偏りや影響を受けたリクエストは分からない。これはRFCの可視性境界から考えられるシナリオであり、特定の事業者で起きた事故や測定済みの結果ではない。

この分担は意図的だ。RFC 10053は、内部リソースとサービスロジックの制御権をサービス事業者に残し、サービスの内部構造をCATSの対象外としている。CATSはネットワークと計算資源の状態を使ってトラフィックを導く枠組みであって、事業者のバックエンドスケジューラーを監査する仕様ではない。ネットワーク側は信号が示す範囲を超えて推測せず、事業者側も接点が選ばれた事実を個別リクエストの成功証明として扱うべきではない。

RFC 10054はCATSの問題提起と要件を補うが、ここで問うのはもっと狭い。選択された接点にトラフィックが届いた後、何が分かるのか。答えは事業者が別途提供するテレメトリーや記録次第だ。RFCはいずれも、共通のバックエンド振り分けAPI、リクエスト単位のトレース、結果の受領票を要求していない。展開側が追加することはできるが、存在を別途確かめる必要がある。

証拠は、補完しない限り接点で途切れる

ステアリング変更後に遅延が改善したように見える一方、アプリケーション側で結果のばらつきが目立つ場合、この違いは運用判断に直結する。経路と選択された接点は、パケットの到達先を説明する。しかし事業者側の証拠がなければ、どの内部インスタンスが処理したか、依存先が劣化していたか、応答がサービス目標を満たしたかは分からない。

報告で言えるのは「CATSはこの範囲のメトリクスを使ってこの接点を選んだ」ということだ。「このバックエンドが依頼を正しく処理した」にはサービス側の証拠が要る。「サービスが改善した」には、対象のリクエストやコホートにひもづいた結果指標が要る。後で一つの可観測性システムに統合しても、それぞれ別の主張である。

RFC 10053は単一のサービス事業者を対象とするアーキテクチャフレームワークで、選択アルゴリズムも内部サービス設計も固定していない。ステアリングの境界を示す文書であって、選択した接点がその先の判断すべてを公開するという約束ではない。

出典と適用範囲