# インバンドネットワークテレメトリ ## 定義 インバンドネットワークテレメトリ(In-band Network Telemetry, INT)は、プログラマブルデータプレーン(P4 等)を活用して、テレメトリ情報をネットワーク内を通過するパケットに直接埋め込む方式のネットワーク監視技術である(P4 Applications Working Group, 2025)。INT ソースが選択されたパケットに命令ヘッダを挿入し、トランジットノードが命令に従い自身のメタデータ(キュー占有率・ホップごとの遅延・ノード ID など)を付加し、INT シンクがテレメトリヘッダを除去して収集情報をコレクタにエクスポートする三者構造をとる。 INT はコントロールプレーン介入なしにデータプレーン内で直接動作し、SNMP ポーリング・NetFlow/IPFIX・sFlow サンプリングといった従来の粗粒度・高レイテンシな手法の限界を克服する。IETF の IOAM(In Situ Operations, Administration, and Maintenance)フレームワークが同等機能を標準化している。主要なヘッダ種別は MD-type(ホップごとの詳細計測で最もよく使われる)・Destination-type・MX-type の 3 種。 INTFusion([[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]])は INT のソース/シンク機能を smartNIC にオフロードし、スイッチ側に INT トランジット機能のみを要求する「エッジ終端 INT」アーキテクチャとして発展させた。 ## INT の課題 1. **帯域オーバーヘッド**: トランジットノードがパケットにメタデータを付加するため、ペイロードが膨らむ。MTU 超過が問題になる場合がある 2. **シンク処理オーバーヘッド**: 高リンクレート(100G/400G/800Gbps)では per-packet のテレメトリレポートが分析・ストレージシステムを圧倒する 3. **コンテキスト欠如**: ネットワーク内計測はホスト・アプリケーションの文脈(どのアプリ、どのプロセスが生成したフローか)を持たない ## INT の主要アーキテクチャパターン | パターン | 説明 | 代表システム | |---|---|---| | スイッチ内蔵シンク | スイッチが INT ヘッダを除去してコレクタに送信 | 標準 INT | | smartNIC オフロード | エンドホストの smartNIC が INT ソース/シンクを担当 | INTFusion | | eBPF + INT ハイブリッド | eBPF でホスト層トレースを取得し INT ネットワーク計測と統合 | INTFusion, TCP-INT | ## 横断的知見 - **「ネットワーク計測」と「ホスト/アプリコンテキスト」の断片化が INT 普及後も残存する**: INT がスイッチ内部の per-hop 計測を可能にしても、そのテレメトリをどのアプリ・プロセス・フローレットが生成したかという文脈は失われる。INTFusion はこの断片化を、smartNIC への INT シンクオフロードと eBPF によるホスト層トレースの per-flow 融合で解消した。同様の問題は [[テレメトリ]] の横断的知見における「フルスタック計装の階層相関」(Astral の 4 層計装)とも共鳴する——単一層の観測だけでは根本原因に届かないという共通の制約。(Source: [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]]) - **「全パケットミラー vs 積極的サンプリング」の二択が二層エクスポートモデルで解消される**: 従来の INT 展開は全パケットのテレメトリをストリームするか(帯域・処理オーバーヘッド大)、積極的サンプリングに頼るか(輻輳ダイナミクス揺らぎ時に精度低下)のジレンマを抱えていた。INTFusion の二層モデルは、閾値超過イベントのリアルタイム配信と非クリティカル集計のレート制御遅延配信を分離することで、両者の中間点を実現する。これは [[テレメトリ]] の横断的知見「遡及的サンプリング(Hindsight)」が「全数生成 + 症状駆動的収集」で計装コストと有用性を両立するのと同型の設計判断。(Source: [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]]) ## 未解決の問い - INTFusion は 10 GbE sNIC でのプロトタイプで、100G/400G/800G Gbps のデータセンターファブリックへの適用性は未検証。ラインレートで INT を処理する sNIC/DPU のスケーラビリティはどうなるか。 - フローレット抽象化のパケット間隔閾値をどう自動チューニングするか。異なるワークロード(ストレージ・ML 訓練・Web サービス)で最適値はどう変わるか。 - クロスホストのタイムスタンプ対応が NTP 精度に依存しており、マイクロ秒級の遅延計測ではずれが問題になりうるか。PTP(精密時刻同期)への移行で改善されるか。 - Centralizer(Elasticsearch ベース)のスケーラビリティは大規模クラスタ(数千ホスト)でどうなるか。 - INT の命令ビットマップによる収集メタデータの選択と、ホスト CPU オーバーヘッド(特に Spooler のポーリング)の間の最適なトレードオフはどこにあるか。 ## 関連 - 概念: [[テレメトリ]] / [[ネットワーク監視]] / [[データセンター輻輳制御]] / [[eBPF]] / [[限定観測可能性]] - ソース: [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]] - エンティティ: [[Leonardo Alberro]] / [[Matias Richart]] / [[Eduardo Grampin]] / [[Universidad de la República]] - 関連 MOC: [[AIOps - Fault Localization - MOC]] / [[Systems for ML - MOC]] ## 出典 - [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]](§I-III)