要約

  • RFC 3334は会計を設定可能な観測連鎖として描いた。ポリシーは記録生成前に対象通信、属性、精度、標本化、集約、報告間隔、送付先、保存期間、閲覧権限を決められた。
  • 記録がないことは利用ゼロの証明ではない。対象外、収集器の除外、輸出損失、集約、保存期限切れの可能性がある。この文書はExperimentalであり、会計設定を料金計算や請求書と同一視していない。

カウンターの前に契約があった

素朴な図では、資源利用が先に起こり、中立的なカウンターが測り、後から料金が決まる。RFC 3334の順序は違った。サービスと商取引の条件が会計ポリシーになり、それが計測、収集、会計を設定する。その後にchargingが非貨幣コストを計算し、billingが金額と請求形式を決める。

同じ会計データに複数の料金方式を適用でき、請求書も明細か集約かを選べる。会計ポリシーは価格そのものではない。後段が価格を説明するために利用できる証拠を先に限定する。

RFC 3334は2002年のExperimental文書で、特定のポリシー言語を標準化せず、導入実績も証明しない。重要なのは、利用証拠が自然発生するのではなく観測契約から作られると明示した点である。

同じ空白でも失われた場所が違う

静的meterは固定粒度で広く測り、後のcollectorが不要なデータを濾過・集約する。設定可能meterは、ポリシーで指定されたflowだけを最初から測る。最終記録が同じ空白を持っていても、証拠の意味は異なる。

前者なら生の入力が残っていれば後から復元できる可能性がある。後者で選択外だった通信は一度も数えられておらず、下流の検索では戻らない。変換時の欠落と観測時の盲点を区別する必要がある。

ポリシーは五つ組microflowからネットワーク全体のaggregateまで粒度を変え、属性、測定周期、時刻精度、samplingも設定できた。収集ではpush/pull、集約、報告周期を、保存では送付先、期間、access listを決められた。

数字だけを残して範囲、時計、sampling、変換、保存条件を捨てると、後の利用者は元の計測より高い精度を読み込んでしまう。

サービス区分が「見える量」を変えた

conditionには利用者ID、IPアドレス、時間帯、service class、accounting typeを使えた。actionにはrecord構造、送付先、間隔、保存、権限、flow粒度、meter精度が並んだ。上位サービスだけ詳細かつ短周期で記録し、標準サービスは粗く記録する設計が可能だった。

物理通信は同じでも、ラベルによって注意の向け方が変わる。「comprehensive accounting」は自然界の性質ではなく、事業者が束ねた設定である。その定義を失えば、記録だけから観測範囲を再現できない。

異なる事業者が同じ「bytes used」を報告しても、観測点、sampling率、集約、保持属性が異なり得る。roamingや外部委託では、用語、パラメータ、紛争解決を事前に合わせなければ比較できない。

集約は未来の質問を先に捨てる

microflowを顧客別に合計すれば総量は残るが、宛先やアプリは消える。長い時間窓は容量を残してburstを消す。samplingは費用を下げて推定誤差を増やす。短い保存はストレージを節約して異議申立て期間を閉じる。

目的が明示されていれば合理的な交換である。危険なのは、生き残った総量を完全な履歴として再利用することだ。請求に十分な値でも、セキュリティ帰属、性能調査、事業者間精算には不足する。

RFC 3334はNeTraMetやNetFlowの例が正確な会計を保証せず、exact dataが必要な場面には推奨しないと明記した。製品名や方式名は精度証明ではない。誤差、損失、用途適合性が別に必要である。

meterが正しくてもcollectorまでのdatagramが失われることがある。template解釈や時計のずれも期間帰属を変える。観測、輸出、受信、変換の各境界にreceiptが要る。

ポリシー交換は信頼境界を越えた

ポリシーはlocalでも、別AAA serverやcustomerからpush/pullしてもよかった。roamingとoutsourcingには便利だが、「何を見るか」という実行可能な意図を組織間で受け渡す。

RFC 3334はactionだけでなくconditionの評価も危険になり得ると警告した。悪意や事故による条件が資源を消費し、DoSを起こすことさえある。送信者認証だけでは足りず、評価前に条件と動作の権限・安全性を検査する必要がある。

作者、発行者、承認、版、生効時刻、scopeと、Application Specific Moduleが実機設定へ変換した結果を残すべきである。変換成功は、異なるmeterが同じ意味の観測をした証明ではない。

観測点が違えば正しい数字も食い違う

integrated accountingはサービス固有の信号を利用できる。discrete accountingは独立サービスとして複数アプリをまとめて測れる。前者は文脈が豊富だがサービス依存、後者は統一しやすいが観測できる属性が異なる。

入口、アプリサーバ、下流exporterのbyte数は交換不能である。再送、encapsulation、cache、失敗sessionにより各数字は自分の位置では正しくても一致しない。観測点は記録のprovenanceである。

RFC 3954のNetFlow v9、RFC 7011/7012のIPFIX、RFC 2903/2904のAAA、RFC 2975/2924の会計、RFC 2123のNeTraMetは周辺機構を説明する。しかしRFC 3334の配備や過去記録の意味を遡って証明しない。

総量と一緒に視野を保存する

五つのreceiptを保つ。第一はpolicyの条件、action、版、権限。第二は実際に適用した装置設定。第三はmeter型、観測点、scope、時計、精度。第四はsampling、filter、aggregate、export loss。第五は送付、閲覧、保存、削除である。料金と請求はその後に別のpolicyを加える。

欠落は利用ゼロかもしれないが、対象外、見落とし、sampling、輸出失敗、集約、アクセス拒否、期限切れかもしれない。記録単体では選べない。RFC 3334の教訓は、測定は数値になる前に選択であるということだ。

出典