要約

  • RFC 8084のサーキットブレーカーは、定義されたingress/egress区間のフローまたは集約を測り、閾値超過が複数の計測間隔で続いた後に反応する。
  • その作動は、当該区間からトラフィックを除去する反応を示す。原因の特定、障害箇所の特定、全経路の状態、利用者影響や復旧を示すものではない。

夜間の当番にとって、警報の「trip」は魅力的な言葉である。何かが止まり、二次被害を抑える行為が行われたことを一語で表せるからだ。しかし、その一語に「誰が悪いのか」「どこで詰まったのか」「もう直ったのか」まで載せれば、記録は便利になったようで、実は検証不能になる。

RFC 8084は2017年3月のIETF Best Current Practice、BCP 208であり、G. Fairhurstを唯一の著者としている。そこではネットワーク輸送サーキットブレーカーを最後の保護と位置づける。通常の輻輳制御を日常的に置き換えるための装置ではない。まず、計測する区間がある。トラフィックは一つ以上のingressから入り、一つ以上のegressから出る。その中で対象になるのは指定されたtransport flowまたはaggregateである。

次に、閾値と時間がある。単発のピークではなく、過剰な状態が複数のmeasurement intervalにわたって持続しなければならない。条件が満たされたとき、定義済みの反応がトラフィックをその計測区間から取り除く。終了させる場合も、レートを大きく下げる場合もある。

ここまでなら、作動記録は精密な証拠である。「この範囲、この対象、この閾値、この連続した観測に対し、この保護を実行した」と言える。範囲の定義、閾値の設定、間隔の並び、反応の実装を後から監査できる。しかし、それ以上を語る欄はない。

RFC自身が因果の余白を残している。持続する過大な輻輳には、異常なトラフィック、別用途に使われた容量、経路変更、設定を誤ったサービスやネットワーク機器、admission controller、policerなどが関わり得る。多くの場合、原因は送信元から明らかではない。アプリケーションは、ブレーカーが作動したことも、ネットワーク内のどこで作動したかも知り得ない場合がある。

したがって、tripを特定リンクの飽和、特定利用者の責任、あるいはサービス品質の測定と読み替えることはできない。通常のコントローラが失敗したとの証明にもならない。作動後に量が減ったとしても、根の条件が消えたとは限らない。保護が見えるトラフィックを減らし、問題が別の場所に残ることはあり得る。復旧には、別に選んだ時刻付きの観測が必要である。

Heng Luのいう最小初期仕様と動作中コードの優位は、ここで実務的な問いになる。仕組みがローカルに決定的に検証できることだけを、その仕組みの記録に帰属させる。メーターはメーターについて語り、経路観測は経路について、設定履歴は変更について、利用者側の観測は利用者への効果について語る。その分担を守ることで、tripは調査を閉じる印ではなく、再現可能な調査を始める印になる。

出典