Roblox Cloudにおけるネットワークパケットロスおよび遅延の監視

Robloxのネットワークエンジニアリングチームは、世界中にデータセンターや接続拠点（POP）を配置し、大規模かつ急速に成長するネットワークを運用しています。Robloxプラットフォーム上で優れたユーザー体験を提供するには、このネットワークのパフォーマンスと信頼性が不可欠です。ネットワーク運用担当者にとって、ネットワークの問題を特定・解決し、ネットワークのパフォーマンスを可視化できることは極めて重要です。 ネットワーク監視は一般的に、デバイスの統計情報、エラーメトリクス、およびシスログを定期的に収集し、時系列データベースやログデータベースに保存することで実現されます。データの収集には、SNMP、Netconf、REST API、またはStreaming Telemetryなどの標準プロトコルを使用したプッシュ型またはプル型のモデルが採用されます。

デバイスのテレメトリのみに基づくネットワーク障害検出には、受動的な監視手法であるため、いくつかの欠点があります。これは、異常な状況が発生した直後に、ネットワークノードがそれを識別して報告する能力に依存しています。デバイスが常にデータを報告するとは限らず、場合によっては、通常のテレメトリ収集方法ではすべてのヘルスステータスが把握できないこともあります。さらに、ネットワークデバイスが誤ったデータを提供したり、トラフィックを黙ってブラックホール化したりすることもあります。 デバイステレメトリの主な制限は、ネットワークのエンドツーエンドの到達可能性、パケットドロップ、および遅延統計に関する可視性が極めて低い点にあります。

ネットワークを能動的に監視する優れた方法は、以下の図に示すように、メッシュ全体に合成プローブを定期的に送信することです。

本番環境の障害対応中、ネットワーク運用担当者は「ネットワークでパケットロスが発生しているか？」や「サービス接続に影響を与えるネットワーク障害が発生しているか？」といった質問を頻繁に受けます。過去のパケットロスや遅延データにアクセスできない状態で、こうした質問に答えるためには、ネットワーク内の多数のリンクやノードを調査する必要があります。

信頼性が高くスケーラブルなネットワークメッシュ監視システムの設計

ブラックボックス型のネットワーク監視システムがパケットロスや遅延の急上昇を効果的に検出するためには、ネットワークのさまざまな部分に対して継続的なプロービングを行う必要があります。データセンターネットワークでは、ユーザートラフィックのためにノード間のすべてのリンクが利用されます。本番ネットワーク機器はBGPを実行し、複数の等コストパスにトラフィックを負荷分散します。通常、ネットワークトポロジーの変更は、ルーティングテーブルの更新によって数秒以内に反映されます。 ネットワークのパケット損失を正確に測定するには、テストプローブがすべてのネットワークノードとリンクを網羅するように、可能な限り多くの経路を通過する必要があります。当社のように世界中の複数のサイトにまたがる大規模なネットワークでは、すべてのノードやラックのペア間でプローブを行うことはスケーラブルではありません。可視性のレベルを損なうことなく、より持続可能な解決策として私たちが選択したのは、各サイト内のラック間でN²メッシュをプローブするとともに、すべてのサイト間で別のN²メッシュをプローブすることです。

ネットワークのプロービングには何を使用するか？

テストプローブは、本番ネットワークを通過する実際のトラフィックをエミュレートする必要があります。当社のネットワーク上のトラフィックの大部分はTCP、UDP、またはHTTPであり、これらはいずれもプローブとして使用可能です。TCPプロービングの問題点の一つは、大規模ネットワークを監視するために必要な接続数に対応できるほど軽量ではないことです。 TCPのもう一つの課題は、組み込みのフロー制御とスライディングウィンドウ方式の送信により、プローブの送信レートが変動してしまうことです。これは、瞬間的なパケット損失の定量化や検出には適していません。pingやtracerouteで使用されるICMPは、通常、サーバーやネットワークノードでレート制限がかけられています。これにより、使用可能なICMPプローブの総量が制限されてしまいます。 HTTPリクエストはアプリケーション層の上位に位置し、サーバーやアプリケーションのパフォーマンスなど、ネットワーク外の要因に依存します。HTTPは結果に追加の変動要因をもたらし、これを分離することは困難です。本システムの目的は、主にOSIレイヤー4以下で動作する基盤となるネットワークインフラのパフォーマンスを監視することです。これらの理由に加え、UDPが当ネットワークにおける主要なトランスポート層プロトコルであることから、UDPプローブを採用しました。

どこからプローブを送信するか？

プローブ送信レートを集計して高め、かつ多数のネットワーク経路をカバーする一つの方法は、可能な限り多くのコンピュートノードを利用してプローブを送信することです。これには2つの利点があります。プローブを生成するシステムへの負荷を分散できること、そしてプローブを伝送するネットワークポートの数を増やせることです。しかし、これには非常に安定しており、ホストシステムのリソースを極力消費しないエージェントが必要です。 同時に、エージェントは、ホストシステムのCPU、メモリ、またはI/O使用率の変動に影響されることなく、複数の経路におけるパケットロスと遅延を正確に測定できる必要があります。エージェントは、軽量であることと高いパフォーマンスを発揮することの間のこの微妙なバランスを常に維持しなければなりません。

ネットワークのパケットロスと遅延はどのように測定するのでしょうか？

単一のプローブストリームに対する計算としては単純に見えるかもしれませんが、大規模化に伴い、一見して明らかではないいくつかの課題が生じます。このような大規模なメッシュに対応するためには、エージェントは多数のストリームに対して、タイムスタンプ付きの送信（Tx）および受信（Rx）パケット数を高速かつ正確に計算する必要があります。 ネットワーク損失のメトリクスには、エージェントを実行しているホストのCPUがビジー状態にある場合やネットワークバッファがオーバーフローした際に失われたパケットを含めないことが重要です。ネットワーク遅延は、プローブが回線上または中間ネットワークノードに存在していた合計時間で計算する必要がありますが、I/Oバッファでの待機時間や、OSのスケジューリング待ち状態にあるエージェントプロセスの時間は除外する必要があります。

RobloxのPing Meshシステム

パブリックおよびプライベートクラウドインフラの成長に伴い、ネットワークのパケットロスや遅延をブラックボックスとして監視する必要性は以前から存在していました。しかし、当社の大規模なネットワークに対応できるスケーラブルな既製ソリューションを見つけることは困難でした。いくつかの大手クラウド事業者やネットワークツールプロバイダーは、ネットワークのパケットロスや遅延を監視するために独自のソリューションを設計しています。 我々は公開されているツールをいくつか試しましたが、安定性やスケーラビリティに問題が生じ、ネットワークパフォーマンスの可視化も限定的でした。このため、低オーバーヘッドで低頻度のエラーをより的確に検出できる独自のメッシュ監視システムを構築することになりました。当システムの主な特徴は以下の通りです：

• システム全体のコンポーネント実装にはGo言語を採用し、これにより最小限のシステムリソースで高いパフォーマンスを実現できました。
• 当社のエージェントは極めて安定しており、トラフィック、キャッシュ、アプリケーションサーバーなど、Robloxプラットフォーム上で重要なサービスを実行しているホストを含む、幅広い本番環境ホスト上で動作可能です。
• エージェントは、Linuxのsendmmsg()およびrecvmmsg()システムコールをGoのラッパー関数で処理し、パケットI/O操作をバッチ処理するように最適化されています。これにより、低オーバーヘッドで高頻度のプローブ送信が可能になります。デプロイメント内の各エージェントは、最大100台の他のホストに対して、毎秒100パケット（PPS）のレートで同時にプローブを送信します。エージェントは、各宛先に対して毎秒パケットバーストを送信します。
• プローブは、各宛先に対してIPヘッダー内の異なるサービス種別（TOS）フィールド値を保持しており、ネットワーク上のパケット損失や遅延について個別に計測されます。各パケットバーストには、他のすべての宛先に対して複数のTOS値が混在しています。これにより、異なるサービス品質（QoS）クラスにおけるネットワークパフォーマンスの監視が可能になります。
• エージェントは、各プローブ経路において、1分あたり6000パケットに1パケットという低レベルのネットワークドロップを検出可能です。BGPフラップ時など、ネットワークのコアまたはエッジ内で1秒未満続くパケット損失も検出できます。
• プローブパケットのドロップチャートは、エラーがドロップの原因である場合、ネットワークデバイスのインターフェースエラー率のチャートを再現します。これにより、検出が困難なネットワーク内のトラフィックブラックホール化バグを発見することが可能になりました。
• エージェントは、NICカーネルの読み取りタイムスタンプを使用して、ネットワーク遅延測定の高い精度を実現します。ホストOSのスケジューリング遅延やネットワーククロックのドリフトを除外しつつ、サイト内での一貫した往復遅延（50～100マイクロ秒）を測定可能です。
• CPU使用率とメモリ使用量は低水準です。エージェントは、送信および受信のピークレート（各5 kpps）時でも、シングルコアの25%未満しか使用しません。導入されたエージェントのほとんどは、コアの約5%しか使用していません。エージェントの送信および受信パケットバッファとカウンタを管理するために必要なヒープメモリはわずか10MBです。ネットワークが拡大した場合は、制限値を調整するか、エージェントを追加することで、垂直または水平方向にスケールアップできます。
• ホストシステムに負荷がかかっている場合でも、エージェントへの影響はほとんどありません。ホストのCPU使用率が99%に近づいた状況でも、数回にわたり正確な結果を得ることができました。
• 各エージェントからテレメトリデータを収集し、その健全性を監視しています。エージェントは、ホストシステムの再起動、エージェントプロセスの再起動、ソケットバッファのオーバーフローによるパケットドロップなど、問題のある状況を特定できます。

エージェントはChefを用いて広範なサーバークラスタに展開され、ネットワークプロービングに参加するノード数を高水準に維持しています。エージェントのバイナリはLinux上でsystemdによって実行・管理されるため、ホストの再起動やエージェントのアップグレード後も自動的に再起動されます。メッシュスケジューラは、エージェントのいずれかがダウンしたり、新しいエージェントが起動したりした際に、必要に応じてストリームを動的に検出して調整します。 当社のスケジューラアプリケーションは、Intra-Pod、Intra-Site、およびInter-Siteプロービングのターゲットを割り当てる前に、デバイスインベントリとサービスディスカバリシステムを定期的にポーリングし、新しいエージェントやサーバーのヘルスステータスを検出します。 メッセージバスを使用して、テストプローブを送信する各エージェントにターゲットホストリストを通達します。特定のラックを起点または終点とする個々のストリームは、そのラック内の利用可能なすべてのエージェントに分散されます。これにより、以下の図に示すように、ネットワークファブリック内の多数の等コストパスを効果的にテストすることが可能になります。

最初の導入時には150台のエージェントから開始しましたが、現在は10倍に拡大することに成功しました。このメッシュは、世界中に点在する25のサイトを相互接続する当社のバックボーンをカバーしています。 主要データセンターサイトの1つでは、200台以上のラックをカバーするサイト内メッシュを展開しており、約33,000のストリームが1.65 Mppsのプローブレートに集約されています。各ラックは、他のラックから5～10 kppsのプローブを受信します。スケジューラアプリケーションは、35,000を超えるターゲットを計算し、異なるサイトにあるすべてのエージェントに均等に分散させます。

データ収集と可視化

別途、コレクターアプリケーションを実行し、すべてのPing Meshエージェントに対してパケットロスおよびレイテンシの結果を定期的にポーリングしています。このデータは、コレクターにローカルでキャッシュされたヘルスステータスに基づいて、無効な結果を除外するよう自動的にフィルタリングされます。例えば、ヘルスチェックに応答しなかったサーバーや、再起動直後のサーバー上で実行されているエージェントからの結果は除外されます。 当社のコレクターは、1,500台以上のノードから結果を同期的にポーリングしてフィルタリングし、2秒以内に時系列データベースへデータを取り込むことができます。

集計結果とストリームごとの結果は、Grafanaダッシュボードを用いて可視化されます。ヒートマップグリッドは、特に当社の大規模データセンターサイトのような大量のデータセットでは使いにくい場合があります。そこで、Prometheusのtopk()クエリを活用し、数千件の結果の中から個々のパケットドロップ率が最も高いパスを表示しています。通常、該当する結果はごくわずかです。 結果は、コレクターによって頻繁にポーリングされるエージェントおよびホストシステムのヘルスステータスと照合され、徹底的に検証されます。これにより、パケット損失の変動幅がどれほど大きかろうと、個々の結果に対して高い信頼性を得ることができます。個々の結果を総合的に見ることで、ネットワーク障害が発生した場所の手がかりを得ることができます。当社のメッシュ監視システムによって検出されたパケット損失の例を以下に示します。

概要と今後の予定

当社のPing Meshシステムは、ネットワークエンジニアリングチームがエンドツーエンドのパケットロスや遅延を監視するための強力なツールとなっています。このデータを活用することで、「ネットワークでパケットがドロップしているか」という疑問に即座に答えることが可能です。これまでの経験上、顧客に重大な影響を与えるネットワークインシデントは、通常、デバイスのテレメトリ監視システムによって検出され、アラートが通知されます。 一方、影響は小さいものの潜在的な問題となるネットワークのバッファリングや、孤立したトラフィックのブラックホール化といった問題は、本システムによって明らかになります。

また、当社のシステムはRoblox Cloud Networkの全体的な信頼性に関する洞察も提供します。主要なデータセンターサイトの1つでは、1分間に1億回以上のプローブを実行してネットワークの状態を監視していますが、1分あたりのパケット損失数が50を超えることはほとんどありません。これは、データセンターネットワークの信頼性が約6つの9（99.9999%）であることを示しています。 1億パケットのうち、パケットロスが全く発生しないことも頻繁にあります。大量のパケットが損失した場合、本システムはパケットロスが発生した場所と継続時間を特定します。自動修復エンジンがネットワークを自己修復し、トラフィックをネットワーク内の別の経路に迂回させることで、ユーザーのトラフィックがさらなる損失に見舞われるのを防ぎます。Robloxのネットワークチームは、極めて信頼性の高いクラウドネットワークを構築しました。

将来的には、アナリティクスエンジンを活用し、デバイスのテレメトリ、syslog、その他のデータセットを相関分析する予定です。その後、その分析結果をPing Meshのデータと比較することで、ネットワーク障害の発生箇所を特定しやすくする計画です。Robloxのクラウドネットワークが拡大・進化し続ける中、プロービングメカニズムを強化してIPv6やジャンボフレームに対応させるとともに、エージェントを追加してサイト間のカバレッジを拡大していく予定です。