AIデータセンターの光通信モジュール（Optical Module）を支えるINT設計：マイクロバースト監視と自律型QoS

AIデータセンターやクラウドネットワークでは、800Gおよび1.6T世代の光通信モジュール（Optical Module）の導入が急速に進んでいます。

これらのOptical Moduleを接続する大規模イーサネットファブリックでは、RoCEv2を利用したAI学習クラスタや分散ストレージ環境において、瞬間的なトラフィック集中（マイクロバースト）が性能ボトルネックとなることがあります。

こうした課題への対応策として、INT（In-band Network Telemetry）やStreaming Telemetryによるネットワーク可視化、自律型QoS制御への関心が高まっています。

本稿では、マイクロバーストの発生要因からINTによる可視化、自律型QoSの実現方法、さらにそれらを支えるFeRAMの活用について解説します。

マイクロバーストが招くネットワーク性能劣化とその検出

マイクロバーストは、平均帯域使用率を追うだけの監視では見逃されやすい、瞬間的なトラフィック集中です。スイッチのバッファを一時的に溢れさせてパケットロスを引き起こし、アプリケーション性能を静かに劣化させます。データセンター内部の高速リンクで特に顕著であり、その発生要因と、従来の監視手法で捕捉が難しかった理由を整理します。

マイクロバーストの発生メカニズム

マイクロバーストとは、数マイクロ秒から数ミリ秒という極めて短い時間の中で、複数の入力ポートから到着したトラフィックが特定の出力ポートに集中することで発生する現象です。分散ストレージの同期書き込みや、AI学習基盤におけるオールリデュース通信などで頻発しやすく、リンクの平均使用率が低くても、瞬間的にはバッファ容量を大きく超過することがあります。秒単位や分単位の平均値を前提とした統計的な監視だけでは、こうした瞬間的な現象の実態を正しく把握することはできません。
近年は、GPUクラスタにおけるAll-Reduce通信やRoCEv2ベースのAIファブリックに加え、800G Optical Moduleや1.6T Optical Moduleを利用した大規模データセンターネットワークにおいても、瞬間的なトラフィック集中が問題となっています。リンクの平均使用率が低くても、特定のタイミングでバッファ容量を超えるトラフィックが集中することで、通信性能が大きく低下する場合があります。

バッファオーバーフローとパケットロスのリスク

スイッチのバッファ容量を瞬間的なトラフィックが超過すると、収容しきれなかったパケットは即座に破棄されます。破棄されたパケットはTCPの再送処理を誘発し、往復遅延の増大やスループットの低下を招きます。特に分散ストレージや分散学習で発生しやすいTCPインキャスト問題では、多数のフローが同時に一点へ集中するため、単発のパケットドロップであっても、全体の処理完了までの時間を大きく遅延させる原因となり得ます。バッファの深さや設計そのものを見直す動機にもなります。

SNMP/NetFlowなど従来監視手法の限界

SNMPによるポーリングは秒から分単位の間隔でしか統計を取得できないため、マイクロ秒単位で発生するバーストは平均化された数値の中に埋もれてしまいます。NetFlowやsFlowもフローのサンプリングに基づく手法であるため、瞬間的に発生する集中トラフィックを取りこぼす可能性が高く、発生箇所や原因の特定が困難です。根本原因を突き止めるには、ナノ秒からマイクロ秒単位の時間分解能を持ち、かつネットワーク全体を俯瞰できる新しい監視の仕組みが必要とされています。

INT（インバンドネットワークテレメトリ）による可視化設計

INT（インバンドネットワークテレメトリ）は、パケット自体が経路上の情報を運ぶことで、ナノ秒単位の粒度でマイクロバーストを可視化する仕組みです。専用のプローブを追加することなく、実トラフィックそのものから精度の高い状態情報を取得できる点が特長です。ここでは、その設計上の要点を具体的に説明します。

INTの基本アーキテクチャとヘッダ埋め込み方式

INTでは、パケットが送信元から宛先へ向かう過程で、経路上の各スイッチが自身の状態を示すメタデータを、パケットヘッダの専用領域に順次書き込んでいきます。宛先ノードに到達する頃には、パケットは通過した全てのホップにおける遅延やキューの状況を記録した、詳細な経路履歴を保持していることになります。この仕組みにより、コレクター側から個別に問い合わせを発行しなくても、経路全体の状態をリアルタイムに再構成することが可能になります。
AIデータセンターでは、ネットワークスイッチだけでなく、Optical ModuleやSmartNICを含めたシステム全体の可視化が重要になっています。INTやStreaming Telemetryを活用することで、通信経路上の輻輳状況や遅延要因を高精度に把握することが可能になります。

ASIC/FPGAによる低遅延データプレーン処理

INTの情報付与処理をCPUで行うと処理遅延が発生し、通常のトラフィックの転送性能そのものに影響を与えかねません。そのため実装では、ASICやFPGAを用いてデータプレーン内でメタデータの書き込みを完結させ、シリコンレベルの速度でタイムスタンプやキュー長を記録する設計が一般的です。INTパケットは通常のトラフィックと同一の経路、同一のキューを通過するため、取得される情報が実際の輻輳状況を忠実に反映できる点も、設計上の重要な利点といえます。
特に800Gおよび1.6T世代のOptical Moduleが接続されるAIクラスタでは、数百Gbps級の通信をリアルタイムに分析する必要があるため、ASICやFPGAによるラインレート処理が重要になります。CPUベースの監視だけでは十分な粒度と処理性能を確保することが難しくなっています。

ホップ単位の遅延・キュー滞留情報の収集

INTによって収集される情報には、ホップごとの通過遅延、入出力ポート番号、パケット受信タイムスタンプ、キューの識別子、輻輳の有無を示すフラグ、出力ポートの速度などが含まれます。これらの情報をホップ単位で突き合わせることで、ネットワーク全体のどの区間でキュー滞留やバッファの逼迫が発生しているかをピンポイントで特定でき、経験や勘に頼らず、対処すべき箇所を迅速かつ客観的に絞り込むことが可能になります。設計段階でどの情報を収集対象とするかが、後段の分析精度を左右します。

テレメトリ駆動の自律制御とセルフドライビングQoS

収集したテレメトリ情報を制御ループへ組み込むことで、人手による判断を待たずに輻輳へ対応する自律型QoSが実現します。あらかじめ固定された設定に頼るのではなく、実測データそのものを起点に判断を下す点が従来の運用との大きな違いです。ここでは、その基本的な仕組みと、運用の自動化が現場にもたらす具体的な変化について解説します。

IBN（インテントベースネットワーキング）の自律制御

インテントベースネットワーキング（IBN）は、管理者が「業務システムの通信を最優先する」といったビジネス上の意図を宣言的に定義すると、AIや自動化エンジンがその意図を実際のQoS設定やアクセス制御ポリシーへと自動的に変換し、適用後もテレメトリに基づいて継続的にネットワークの状態を検証する仕組みです。意図からの逸脱が検知された際には、人手を介さず自動的に是正処理が実行され、意図した状態が常に維持され続けるよう設計されています。

輻輳傾向の分析に基づく優先制御の動的調整

INTから得られるホップ単位の遅延やキュー滞留情報を継続的に蓄積し、輻輳が繰り返し発生する傾向を分析したうえで、優先制御のクラス分けや帯域配分のしきい値を段階的に調整していく仕組みです。あらかじめ固定的に設定されたポリシーだけでは対応しきれない、時間帯や業務負荷の変化によって刻々と変動するトラフィックパターンに対しても、実測データの傾向に基づいた柔軟な制御を継続的に行うことが可能になり、運用担当者の経験則に頼った閾値調整からの脱却にもつながります。

セルフヒーリングによる帯域再配分とルート再構成

特定のキューやリンクで輻輳の閾値超過が検知されると、システムは人手を介することなく帯域の再配分や迂回経路への切り替えを自動的に実行します。障害としてサービスに影響が及ぶ前の予兆段階で対処できるため、ユーザー体験への影響を最小限に抑えられるだけでなく、運用担当者が深夜や休日を含めて個別の事象に逐一対応する負荷も大幅に軽減されます。こうした自己修復の仕組みは、テナントが混在する大規模なマルチテナント環境ほど、その効果を大きく発揮します。

高速不揮発メモリが支えるテレメトリ基盤

テレメトリの集約統計やQoSポリシーの状態を保持する制御プレーン側のメモリには、高頻度な書き換えと電源断への耐性が同時に求められます。選定を誤ると自律制御ループ全体の信頼性を損ないかねません。ここでは、自律型QoSを支える基盤として、メモリ選定における具体的な設計指針を整理していきます。

テレメトリ統計・QoSポリシー状態のメモリ選定要件

自律型QoSの制御ループでは、INTから集約されたトラフィック統計やカウンタが秒単位よりもさらに高い頻度で継続的に更新され、適用中のQoSポリシーの状態もそれに追随して随時書き換えられます。これらの情報を保持するメモリには、高頻度な書き換えに耐える耐久性と、書き込みごとの低レイテンシの両立が求められます。DRAMは高速に動作するものの電源断とともにデータを失い、フラッシュメモリはブロック単位の消去処理が必要な上に書き換え回数にも制約があるため、双方の課題を補う選択肢が必要になります。
同様の要件は近年の800G Optical Moduleや1.6T Optical Moduleにも見られます。AIデータセンターでは、モジュール内部で収集される診断情報やテレメトリ情報の重要性が高まっており、それらを継続的に記録できる高耐久な不揮発性メモリが求められています

FeRAMの高頻度書き換えと低消費電力

FeRAM（強誘電体メモリ、FRAM）は、強誘電体材料の分極反転を利用してデータを保持する不揮発性メモリであり、フラッシュメモリのような時間のかかる消去処理を必要とせず、消去を待たずにそのまま高速な書き込みが可能です。書き換え耐久性は10の12乗回以上に達するとされ、書き込み時の消費電力も低く抑えられるため、頻繁に更新されるテレメトリの集約統計やQoSポリシー状態の保存先として、制御プレーン側のメモリに適した特性を備えています。

Optical Module内部では、

・DDM（Digital Diagnostic Monitoring）
・DOM（Digital Optical Monitoring）
・CMIS管理情報
・FECエラーカウンタ
・リンク品質統計情報
・DSP設定情報
・イベントログ
・温度履歴データ

などが高頻度で更新されます。

これらの情報は故障解析や予兆保全に利用されるため、高速書込み、低消費電力、高耐久性を兼ね備えたFeRAMとの親和性が高い用途といえます。

電源断時の即時復旧を支える状態保持設計

FeRAMは書き込み動作の途中で電源が遮断された場合でも、フラッシュメモリのようなデータ破損のリスクが低く、データ保持のためのバックアップ用バッテリーやキャパシタも基本的に不要です。再起動後は電源断直前の統計情報やポリシー状態からそのまま処理を継続できるため、自律制御ループを長時間中断させることなく、テレメトリ基盤全体の可用性と、自動化された運用に対する信頼性を高める設計を無理なく実現できます。ハードウェア構成をシンプルに保てる点も、設計上のメリットといえます。
また、光通信モジュール（Optical Module）においても、診断情報やイベントログを電源断後に保持できることは重要です。再起動後も直前の状態情報を参照できるため、障害解析や予兆保全の精度向上につながります。

まとめ

AIデータセンターの大規模化が進む中、INTやStreaming Telemetryによるネットワーク可視化はますます重要になっています。

また、800G Optical Moduleや1.6T Optical Moduleでは、CMIS管理情報、DDM/DOMデータ、DSP設定情報、イベントログなどの継続的な保存が求められています。

高耐久・高速書込み・低消費電力という特長を持つFeRAMは、ネットワーク機器の制御プレーンだけでなく、次世代Optical Moduleの診断情報保持やテレメトリ基盤を支える有力な不揮発性メモリとして期待されています。

RAMXEEDが提供するFeRAM製品一覧
https://www.ramxeed.com/jp/products/feram-products