AIおよびエッジワークロードのためのネットワークのレジリエンス

障害発生時にエンジニアが復旧できるAIインフラの設計

AIインフラは、企業ネットワーク全体で急速に拡大しています。GPUクラスターがモデルのトレーニングを支え、エッジ推論システムが金融、製造、小売、通信などの業界でデータをリアルタイムに処理しています。ほとんどのAI環境は、コンピューティングインフラの観点からは順調に稼働しています。

しかし、多くの導入事例が集中型データセンターの枠を超え、分散型のエッジ環境へと拡大するにつれ、ネットワークエンジニアは常々直面してきた問題に再び直面しています。それは、「障害が発生した際、どのように制御を維持するか」ということです。

AI環境では障害による運用への影響が拡大するため、これは対処すべき重要な課題です。大規模なGPUクラスター、分散したエッジ拠点、そしてレイテンシに敏感なワークロードは、いずれも信頼性の高いネットワーク接続に依存しています。何かが故障した際、復旧は冗長性と同じくらい重要になります。

お問い合わせはこちらから

デモ希望はこちら

AIインフラはネットワークに異なる要件を課す

従来のエンタープライズアプリケーションは、一般的に短時間の中断には耐性があります。ユーザーは、大きな影響を受けることなく、アプリケーションに再接続したり、トランザクションを再試行したりすることができます。しかし、AIワークロードはそれほど寛容ではありません。

大規模言語モデル（LLM）のトレーニング、分散推論パイプライン、およびリアルタイム分析は、コンピューティング、ストレージ、ネットワークリソース間の継続的な通信に依存しています。現代のAI環境は以下に依存しているため、中断は連鎖的な影響をもたらします。

高帯域幅のイーサネットまたはInfiniBandファブリックで接続されたGPUクラスター
従来の「ノース–サウス」方向のアプリケーションフローを上回る「イースト–ウエスト」トラフィック
トレーニングデータを供給する分散ストレージシステム
GPUワークロードをスケジューリングするKubernetesオーケストレーションプラットフォーム
集中管理システムと継続的にテレメトリを交換するエッジ推論ノード

たとえば、ラック上部のスイッチの故障、誤ったルーティングポリシー、または設定ミスのあるスパインスイッチにより、GPUプール全体がストレージやオーケストレーションサービスから切り離されてしまう可能性があります。たとえコンピューティングノードが稼働し続けていても、エンジニアが接続の復旧に取り組んでいる間は、ワークロードが停滞してしまいます。

ネットワークエンジニアにとって、レジリエンスとは、特に障害が発生した際に、インフラストラクチャが監視可能、アクセス可能、かつ復旧可能な状態を維持することを保証する業務となっています。

さまざまなネットワークプレーンの理解

話を進める前に、ネットワークを構成する3つの別個でありながら密接に関連する部分を区別しておくと、障害が発生する場所やその影響を理解するのに役立ちます。

プロダクション（またはデータ）プレーン：AIのトレーニングデータ、推論リクエスト、ストレージトラフィック、ユーザー間の通信など、アプリケーションのトラフィックを伝送します。たとえば、AIアプリケーションにプロンプトを送信する場合、そのプロンプト、モデルの応答、および関連データを伝送するのがプロダクションプレーンです。

制御プレーン：BGP、OSPF、EVPN、VXLAN、スパニングツリー、その他のルーティングおよびスイッチング機能など、トラフィックがネットワーク内をどのように移動するかを決定するプロトコルを実行します。これは、ネットワークのナビゲーションシステムのようなものと考えてください。制御プレーンはトラフィックが通る最適な経路を決定しますが、トラフィック自体を伝送することはありません。

マネジメントプレーン：エンジニアがインフラストラクチャの監視、設定、復旧を行うために使用するインターフェースを提供します。これには、SSH、HTTPS、API、SNMP、シリアルコンソールアクセス、インテリジェントPDU、およびアウト・オブ・バンド管理が含まれます。これは、エンジニアがデバイスにログインし、設定変更を適用し、障害発生時にシステムを復旧するために使用する経路です。

画像：3つのネットワークプレーン。ワークロードを処理する「データプレーン」、ワークロードの行き先を決定する「コントロールプレーン」、そしてエンジニアが機器の管理や復旧を行うためのアクセス権限を提供する「マネジメントプレーン」です。

AIインフラストラクチャの障害が実際に発生する場所

マネジメントプレーンを混乱させるコントロールプレーンの障害

すべてのサービス停止がハードウェア障害から始まるわけではありません。実際、多くのインシデントは、以下のようなコントロールプレーンに起因しています。

BGPポリシーの誤り
OSPFの隣接関係障害
EVPN/VXLANの設定ミス
VLANまたはVRFの設定ミス
意図せず管理トラフィックをブロックしてしまうACLの変更

これらの問題が発生すると、ルーター、スイッチ、サーバーは正常に動作しているにもかかわらず、本番ネットワークからはアクセスできなくなる可能性があります。管理トラフィックがアプリケーショントラフィックと同じインフラを共有している場合、エンジニアは最も必要としているまさにその瞬間に、SSH、API、および監視へのアクセスを失ってしまいます。

だからこそ、管理ネットワークと本番ネットワークを完全に分離することが重要なのです（これについては後述します）。

影響範囲を拡大させる自動化の失敗

Infrastructure-as-Code（IaC）やネットワークの自動化は、一貫性を高める上で非常に有効ですが、その一方で、設定ミスが引き起こす影響範囲も拡大させてしまいます。たった1つのAnsibleプレイブック、Terraformによるデプロイ、あるいは自動化ワークフローが、意図せずして数百台のデバイスに同時に影響を及ぼす可能性があります。

そのような事態が発生した場合、エンジニアは本番ネットワークが稼働し続けていることに依存しない復旧手段を必要とします。これが、ハイパースケール環境やサービスプロバイダー環境において、アウト・オブ・バンド管理が依然として標準的な手法として定着している理由の一つです。

遊休状態にあるGPUクラスター

AIインフラは、データセンター内で最も高価な演算リソースを中核として構築されています。専門家は、2026年には世界のAI投資額が1兆ドルを超えると予測していますが、その理由は容易に想像がつきます。1台のGPUサーバーの価格は数十万ドルにもなり、本番環境のAIクラスターは、こうしたシステムが数十台から数百台連携して構成されることが一般的です。

モデルのトレーニングには、GPUが連携したクラスターとして動作することが必要です。ネットワークの問題によってクラスターの一部が孤立したり、ノードがストレージやオーケストレーションプラットフォームと通信できなくなったりすると、トレーニングジョブは停滞するか、完全に失敗してしまいます。GPUの電源は入っているものの、もはや生産的な作業を行っていない状態です。

推論環境においても、その影響は異なるものの、同様に重大です。カメラの映像、センサーデータ、またはリアルタイムのトランザクションの処理を停止した到達不能なエッジAIノードは、アプリケーションのパフォーマンスを低下させたり、ワークロードを他の場所にフェイルオーバーさせたりすることになります。

ハードウェアのアイドル状態は、コストのほんの一部に過ぎません。エンジニアが接続の復旧に取り組んでいる間、組織は生産的な演算時間を失い、モデル開発が遅れ、サービスレベル目標（SLO）を達成できず、運用上のオーバーヘッドが増大します。

どのインフラも障害から免れることはできないため、すべての停止を排除することは現実的ではありません。その代わりに、エンジニアがシステムの診断と復旧に即座に取り組めるようにすることで、平均復旧時間（MTTR）を最小限に抑えることが目標となります。そうすることで、高価なGPUリソースは、ネットワークの復旧を待つ時間を減らし、ワークロードの実行により多くの時間を割くことができるようになります。

AIに関するよくある疑問への回答

AIのレジリエンスに関する議論でよく聞かれる反応の一つに、「当社のAIインフラはすでに問題なく稼働している。なぜ何かを変える必要があるのか？」というものがあります。

これはもっともな疑問です。何しろ、「壊れていないなら直さなくていい」というものですから……。

しかし、この疑問は、私たちが長年にわたり指摘してきたことを浮き彫りにしています。重要なのは、すでに問題なく機能しているネットワークを再設計することではありません。重要なのは、インフラの拡張に伴う増大する運用リスクからあなたを守る、究極のセーフティネットを構築することです。

データセンター内のGPUクラスターを管理することと、数百もの遠隔地に分散したAIシステムの群を管理することは、まったく別物です。エンジニアは、避けられないルーティングミス、WANの障害、設定ミスが発生した際にも、可視性と制御を維持する必要があります。レジリエンスはアーキテクチャに組み込まれていなければなりません。

AIアーキテクチャにはレジリエンスを組み込むべき

ネットワーク業界は、冗長化されたリンク、耐障害性の高いルーティングプロトコル、およびフォールトトレラントなハードウェアを通じて、高可用性の実稼働ネットワークを設計するために数十年の歳月を費やしてきました。AIインフラストラクチャにも同レベルの配慮が必要ですが、冗長化だけでは不十分です。

従来の高可用性設計は、プロダクションプレーンとコントロールプレーンの強化に重点を置いてきました。同様に重要なのは、マネジメントプレーンを強化し、「午前2時にエンジニアがリモートGPUクラスターへの接続を失った場合、それを復旧するためにどのような手順を踏めばよいか」という問いに自信を持って答えられるようにすることです。

その答えが「プロダクションネットワークが先に復旧すること」に依存している場合、そのアーキテクチャには依然として単一障害点が存在します。だからこそ、マネジメントとプロダクションを完全に分離することが重要なのです。この分離により、エンジニアは最も重要な局面で、AIインフラの診断、制御、復旧を確実に行うことができます。

では、「なぜ変更が必要なのか？」という疑問があります。実際には、アーキテクチャそのものを変更するということではありません。むしろ、本番ネットワークがダウンしていてもシステムを復旧できる、代替の管理パスを追加することです。

そこで、アウト・オブ・バンドとIMIの出番となります。

IMI：アウト・オブ・バンドの進化

アウト・オブ・バンド管理といえば、通常、数台のルーターに接続されたコンソールサーバーを指し、メインネットワークがダウンした場合にエンジニアがバックアップアクセスを行えるようにするためのものと捉えられています。しかし、現代のアウト・オブ・バンド――いわゆる「Isolated Management Infrastructure（IMI）」――は、システムを完全に再構築する機能を含め、はるかに幅広い運用機能を備えています。

IMIには以下の機能が含まれます。

ルーター、スイッチ、ファイアウォール、ストレージアレイ、GPUサーバーへのシリアルコンソールアクセス
独立したイーサネット管理インターフェース
WANに依存しない5G/LTEまたは衛星接続
インテリジェントPDUによるリモート電源管理
一元化された認証を備えたセキュアなジャンプホスト機能
監視プラットフォームによってトリガーされる自動リカバリワークフロー

画像：Isolated Management Infrastructure（IMI）は、ネットワークがオフラインの状態であっても、ネットワークシステムを完全に再構築・復旧するための運用機能を提供します。

ルーター、スイッチ、ファイアウォール、ストレージアレイ、GPUサーバーへのシリアルコンソールアクセス
独立したイーサネット管理インターフェース
WANに依存しない5G/LTEまたは衛星接続
インテリジェントPDUによるリモート電源管理
一元化された認証を備えたセキュアなジャンプホスト機能
監視プラットフォームによってトリガーされる自動リカバリワークフロー

これにより、本番ネットワークが利用可能かどうかに関係なく、常に稼働し続けるマネジメントプレーンが構築されます。そのため、トラブルシューティングを開始する前に接続を再構築する必要がなく、エンジニアは5G/LTEや衛星経由で接続し、直ちにログの調査、デバイスの状態確認、設定の復元、あるいは障害が発生したシステムの電源再投入を行うことができます。

ZPEはレジリエントなアーキテクチャに不可欠

ZPEのソリューションは、レジリエントなネットワークアーキテクチャに不可欠な構成要素です。多くの組織で、本番ネットワークと並行して独立した運用層として採用されています。各AIサイトやエッジサイトにおいて、1台のZPE Nodegridデバイスで、ルーター、スパインおよびリーフスイッチ、ファイアウォール、GPUサーバー、ストレージ、PDU、ハイパーバイザー／コンピュートプラットフォームへの管理アクセスを集約できます。

画像：ZPEのソリューションは、複数の機能を単一のデバイスに統合し、RS-232、イーサネット、USB、OCPインターフェースを介して接続する機能により、さまざまなAI本番インフラへの管理アクセスを集約します。