ロキ・ジョーゲンソンのネットワーク論
ネットワークをインテリジェント化する――対症療法は効果なし
オートノミックと言っても、高度な分析をしてくれるわけではない。現状では、ネットの問題解決は結局技術者の肩に掛かっている。
考える機械という意味での「AI」(Artificial intelligence)という言葉は、すっかり面目を失ってしまった。コンピュータサイエンスが過去数十年にわたり、ありとあらゆる分野にAIを適用しようとした直接的帰結である。これでわれわれは少しは謙虚になるかと思いきや、どうやらそうでもないらしく、「インテリジェンス」という言葉がまたぞろ大げさにもてはやされるようになってきた。今回は、ネットワークとその管理に適用するというものだが、これはまやかしにすぎない。
確かに、非常に有用な技術も業界リーダー各社によって開発され、先見の明のある企業や先進的なユーザーによって導入されているが、せっかくのこういった成果を狂気じみた宣伝マシンが「ネットワークにおけるインテリジェンス」という言葉で汚そうとしている。
現実を直視する
まず、自己修復・セルフプロビジョニング型ネットワークは将来的に有望かつ有益であるように見える。しかし現実的に考えてみよう。「オートノミック」(自律型)という言葉は、各システム要素の間の既存の関係を表すルールセットを自動的に処理することを外延的に意味している。とはいえ、これは、アインシュタインが箱の中に入っているというよりも、中でサルがクランクを回しているというのに近い。卑近な例で言えば、呼吸や血圧をつかさどる人間の自律神経系の場合、意識レベルよりも下層で行われる処理に重点が置かれており、われわれの好みや尊厳などは無視されることが多い(例えば失神など)。
確かに、ネットワーク内での自律的挙動は、どのようなレベルであれ、今日われわれが行っていることから比べると、ほとんど魔法のように見えるだろう。そして「賢い」、「自動的」さらには「意識した」といったような形容詞が当てはまるかもしれない。しかしそれは「インテリジェンス」に匹敵するものではない。
誇大宣伝は無視するとしても、ほかにも検討すべき現実がある。
自己修復やセルフプロビジョニングを実現するには、ネットワーク状態の生成と記述に関する技術が大幅に進歩する必要がある。例えば、自動修復メカニズムには、パフォーマンス低下の原因とその場所、そして必要な対策を明確に特定する機能が要求される。そういった機能を提供できる技術は、(まだ)十分に成熟していない。
二重通信における恐怖のミスマッチを例に取ろう。その典型的なケースが、スイッチのポートに接続されたワークステーションのNICインタフェースがそれぞれ異なる二重通信モードを使用するというものだ。下の図では、ステーションAは交互に送信する半二重通信モード(HD)を使用し、ステーションBは送受信を同時に行う全二重通信モード(FD)を使用している。
これは、オートネゴシエーションを信用せずに手作業でインタフェースを設定したり、あるいはオートネゴシエーションと手作業による設定を意図的に(しかし間違って)組み合わせた、ほとんどのIPネットワークでよく起きることである。この問題は、修正するのは簡単だが、見つけ出すのは非常に難しい。しかも、あらゆるタイプのアプリケーションに甚大な障害をもたらす。
自動ネットワーク管理システム(NMS)は、ネットワークパス(経路)における二重通信のコンフリクトの存在を検知し、それが起きている2つのインタフェースを特定し、一方もしくは両方の設定を変更し、さらにその効果を検証する必要がある。普通に考えれば、デバイスの観点からこの障害を管理するのが適切であるように思える――すなわち、すべてのデバイスのインタフェースを検査して、必要に応じて変更するということである。しかしながら、アプリケーションから見えるネットワークパスと、デバイス管理システムに関連付けられた論理ダイアグラムが異なるというのは、よくあることだ。このため、NMSの運用管理はフルタイムの仕事になるのだ(実際、数名のフルタイムスタッフが必要となる)。また、任意のエンド・ツー・エンドパス上のデバイスの多くは、誰かほかの人が管理するネットワークに属しているかもしれない。しかも、アプリケーションの視点から見た効果の確認は、デバイスレベルで行うことができないのだ。
しかしここで、デバイス管理を通じて二重通信のコンフリクトに対処することができるという、ありそうにもない仮定を立ててみよう。
次に、二重通信のコンフリクトは、対策が必要な多数のネットワークパフォーマンス低下要因の1つにすぎないと考えていただきたい。これらの要因としては次のようなものがある。
- 半二重/全二重通信のコンフリクト
- NICやドライバのパフォーマンス不足
- MTUのコンフリクト
- 意図せぬ帯域幅のボトルネック
- 速度を制限する待ち行列
- メディアのエラー
- 長すぎる半二重通信
- 人工的な渋滞
- 大きな遅延
- QoSメカニズムの障害
- ルートフラッピング
- 検知されないフェイルオーバー
- クロストラフィック
これらの中には、構成に関連したもの(二重通信のコンフリクトやMTUのコンフリクトなど)もあれば、レイヤー1に含まれるもの(ワイヤレス通信での損失など)もある。あるいは、レイヤー2/3に属する要因(NICの問題など)や、QoSの障害などのエンド・ツー・エンドの挙動に関連した要因もあれば、不適切に適用されたメカニズム(CAR方式の速度制限をリアルタイムアプリケーションに適用するなど)によるものもある。
こういった多様なネットワークパフォーマンス低下要因の重要性は、その影響(見かけ上の過渡性、損失/ジッタが付随する度合い)を数量化する作業が絶えず進められており、最近では、VoIPなどの特定のアプリケーションに対する影響などもMOSなど指標によって数量化されている。しかしこれは、個々の影響を区別しない対症療法的なトラブルシューティング手法である。問題の原因を最終的に診断する作業は、結局は技術者に任されるわけである――これは、何日間あるいは何週間にもわたる、非常に手間と時間のかかる作業になることが多い。
確かに、問題を知ることは半分勝ったようなものだ。しかしあくまで半分にすぎない。
損失やジッタ、あるいはMOSといった症状は、あまりにもあいまいであり、賢い人間でも、あるいはそこそこ利口な機械でも、効果的な診断をするのは無理だ。つまり、これらは自動修正メカニズムを実現するには不十分である。もっと詳細な情報が必要なのである。
もちろん、問題は未然に防止するのが理想であろう。しかしここでもう一度、二重通信のコンフリクトの例で考えれば、オートネゴシエーションはこれまで、二重通信コンフリクト問題の一部であり、解決策にはなっていない(とはいえ、業界は着実に進歩しており、現在ではオートネゴシエーションは――少なくとも個別事例的には――以前よりも信頼性が高くなっている)。
では、どんな選択肢があるのだろうか。
アインシュタインはかつてこう言った。
「われわれが抱えている重要な問題は、われわれがそれを生み出したのと同じレベルの思考で解決することはできない」
デバイスレベルのアプローチは、状況を改善する可能性を提供するものの、根本的な解決策にはならない。それに代わる選択肢の1つは、ネットワークパスのエンド・ツー・エンド特性をアプリケーションおよびそのパフォーマンスと関連付けて把握することである。
パスの特性を把握すれば、粒度の粗いパケットレベルの症状(損失など)だけに頼らなくとも、パフォーマンス低下の原因個所を特定することが可能なアプリケーションパフォーマンスのビューが得られる。把握すべき特性としては、パスの性質、個々のエレメントの寄与、アプリケーションの要求、現在の条件の詳細などがある。
こういった特性を把握するのに役立つ新技術も開発されている。最適な実装を実現するには、パッシブパケットモニタリング、アクティブテスティング、アプリケーションパフォーマンスモデリング、デバイス管理、NMS、修正/プロビジョニングのための効果的メカニズムなどの機能を組み合わせる必要があるだろう(SNMPは退場すべきだ――即刻!)。
要するに、オートノミクスおよび自己修復では、症状に基づく一般論ではなく、ネットワークの具体的な詳細を把握しなければ、確実な対策やプロビジョニングを実施することができないということだ。その条件が整うまでの間、高度な教育を受けた賢い技術者やオペレータ(こういった人材は徐々に少なくなりつつあるが)にネットワークインフラの運用を任せることだ。そして、技術の荒野にダイヤモンドが埋もれているかのような広大宣伝の中身を注意深く検証することが大切だ。
「損失とジッタ」と報告するだけでは、あまり役に立たないということを忘れないように。
本稿筆者のロキ・ジョーゲンソン博士はアパレントネットワークスのチーフサイエンティストで、18年以上にわたりコンピュータ、物理学、数学、科学の視覚化、シミュレーションなどの分野で活躍してきた。クイーンズ大学とマギル大学で計算物理学を専攻。哲学、グラフィックス、教育技術、統計力学、論理学、数論など広範な分野で著作がある。また同氏は、サイモンフレーザー大学で数学の非常勤教授を務めるとともに、同大学でCenter for Experimental and Constructive Mathematics(CECM)を共同設立した。民間部門のパートナーおよび政府機関との緊密な連携の下、ハイパフォーマンスコンピューティングやデジタルパブリッシングなどに関する多数の学術プロジェクトで研究を指導した経験もある。アパレントネットワークスでは、ジョーゲンソン氏はハイパフォーマンス、ワイヤレス、VoIP、アプリケーションパフォーマンスなどに関連したネットワーク研究の責任者を務める。これらの研究の多くは、学術機関やBCネット、テキサスA&M、CANARIE、Internet2などの最先端研究組織との共同で進められている。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
新着ホワイトペーパー PR
-
製品資料
[株式会社kickflow] 2社の事例に学ぶワークフロー改革:属人化解消や年数万件の申請書類削減のコツ -
製品資料
[NTTPCコミュニケーションズ株式会社] 「回線速度不足」だけが原因ではない? Web会議の遅延を解決する方法とは -
製品資料
[東京エレクトロン デバイス株式会社] 工場の可用性向上に重要な「7つの領域」と対策 OTセキュリティ強化の基礎知識 -
製品資料
[リコージャパン株式会社] 問い合わせ対応で本来の業務が進まない、総務や情シスの負担をどう減らす? -
製品資料
[リコージャパン株式会社] 自社データから高精度な回答を生成、簡単に生成AIチャットボットを構築する方法
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
全社標準Copilotに絶望? MS Copilotで問い合わせ6割減できた企業は何が違った
-
2
ITエンジニア1265人調査 生成AIを使い込むほど「人の確認」が重い理由
-
3
Microsoft製品でここまで自動化できる 情シスがやめられる手作業10選
-
4
脱VMwareの前提が崩れる BroadcomのVDDK公開停止で確認すべき点
-
5
「Microsoft一択」で本当にいいのか 知らぬ間にライセンス費用が膨らむ真相
-
6
「Copilot」はなぜ放置される? “議事録要約止まり”を脱する処方箋
-
7
【お知らせ】 医療機関のIT化に関する読者調査
-
8
IT予算が10%増えたら何に使う? 著名企業のCIOが明かす「最優先の投資先」
-
9
Web会議では「見た目」よりも「声」を気にすべき理由と、その改善策
-
10
音声もFAXもメールで確認――ユニファイドメッセージの業務効果
ホワイトペーパーランキング PR
-
1
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは?
-
2
生成AIで文書活用を進めるには? 効率化と安全性をどう両立する
-
3
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
4
Windows PCとMacの選択制で生産性向上 LINEヤフーが実践する運用管理方法とは
-
5
少額減価償却資産が40万円未満へ拡大、令和8年度税制改正で押さえるべき変更点
-
6
「Google Workspace」活用事例34選、先進の生成AIによる組織変革の全貌
-
7
国税庁の次世代基幹システム「KSK2」稼働開始に向けて、対応すべき変更点とは?
-
8
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
9
Linuxのスキルを証明する“激推し”の認定資格はこれだ
-
10
AI時代に成功するための「ナレッジマネジメント」ベストプラクティス
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー