ネットワークオブザーバビリティの「水源」を探る第2回

【標準化の功罪】SNMPという「共通言語」とその限界

第2回の今回は、「SNMP」が共通言語として普及した背景と功績を整理し、広帯域環境で顕在化する技術的な限界について解説します。

伊藤覚宏

6:30

導入：なぜ我々は、30年前のプロトコルを今、語り直すのか

前回の序論では、現代ネットワークの複雑化に伴い、私たちがこれまで慣れ親しんできた「監視」という手法そのものを見直す必要性を投げかけました。ネットワークの状態を真に理解するためには、多様な"水源"からデータを集めなければならない、と。

この探求の第1歩として、私たちはまず、ネットワーク管理の世界で長らく「共通言語」として使われてきたプロトコル、「SNMP(Simple Network Management Protocol)」に焦点を当てます。

「なぜ、今さらSNMPなのか?」
「もっと新しい技術の話をするべきではないか?」

そう思われるかもしれません。しかし、私たちが日々、当たり前に使っているこのプロトコルの成り立ちと、その技術的な限界を正確に理解することこそが、現代のネットワークオブザーバビリティが目指す地点を正確に指し示す、何よりの道標となるのです。

本稿では、SNMPがなぜ「共通言語」として普及し得たのか、その偉大な「功績」を改めて評価します。そして同時に、なぜ今日の広帯域な環境において、その「限界」が顕在化しているのかを、技術的な側面から深く、具体的に掘り下げていきます。この30年の歴史を持つプロトコルの光と影を解き明かすことは、私たちが次にどの"水源"を目指すべきかを教えてくれるはずです。

SNMPの功績：マルチベンダー環境を繋いだ「共通言語」

SNMPが登場する以前、ネットワーク管理は混沌としていました。それぞれの機器ベンダーが独自の方法で自社製品の管理・監視機能を提供していたため、管理者はベンダーごとに異なるツールやコマンドを習得する必要があったのです。これは、複数の言語が飛び交う市場で、通訳なしに取引を試みるようなものでした。

この状況に革命をもたらしたのがSNMPです。SNMP最大の功績は、特定のベンダーに依存しない、オープンな標準プロトコルとして設計された点にあります。これにより、管理者は単一の「作法」を学ぶだけで、シスコシステムズのルーターも、ジュニパーネットワークスのスイッチも、ヤマハのファイアウォールも、理論上は同じように監視できるようになったのです。

この仕組みを、もう少し詳しく見ていきましょう。SNMPによる監視は、非常にシンプルな2つの役割分担に基づいています。

SNMP Manager(管理者): ネットワーク全体を監視する司令塔です。各機器に対して「CPU使用率を教えてほしい」「インターフェースの通信量は?」といった命令(リクエスト)を送ります。
SNMP Agent(代理人): ネットワーク機器の内部で動作し、Managerからの命令を待つ「代理人」です。リクエストを受け取ると、機器内部の状態を調べ、その結果をManagerに報告(レスポンス)します。

SNMPの基本構成

そして、この両者が円滑にコミュニケーションをとるための「仕様書」の役割を果たすのが「MIB (Management Information Base)」です。

MIBとは、直訳すれば「管理情報の基地」です。このMIBの構造を理解する上で、IT技術者の皆様にとって最も身近な類似システムは、おそらく「DNS (Domain Name System)」でしょう。

ここで1つ、考えてみましょう。私たちが「www.example.co.jp.」というドメイン名(FQDN)を目にするとき、私たちは無意識に「jp」国の「co(企業)」ドメインに属する「example」社の「www」サーバー、という階層構造を読み取っています。これは「.」(ルート)ドメインから始まる厳密なツリー構造として管理されています。

実は、MIBの設計思想もこれと全く同じです。

MIBは、機器が持つ膨大な情報を管理するために、DNSと同様の厳密な「ツリー構造」を採用しています。そして、そのツリー上の特定の情報(例えば「機器の起動時間」)がどこにあるのかを示す「住所」こそが「OID (Object Identifier)」と呼ばれるものです。

私たちが目にする .1.3.6.1.2.1.1.1.0 のような数字の羅列は、一見すると無機質な暗号に見えるかもしれません。しかし、これは「www.example.co.jp」という名前が「. -> jp -> co -> example -> www」というパスを示すのと同様に、MIBツリーの頂点(ルート)から「.1(iso)」→「.3(org)」→「.6(dod)」…と順番に枝をたどっていった、単なる「階層的なパス」に過ぎないのです。

DNSドメインツリーとSNMP MIBツリーの比較

つまり、MIBとは「どのようなパス(OID)が存在し、そのパスをたどれば、どのような情報が得られるか」を公式に定義した、巨大な仕様書そのものなのです。

SNMPによる監視とは、Managerが「OIDという階層パスを頼りに、Agentという代理人に対して、MIBという仕様書に載っている情報を取得しに行く」という、極めて整然としたプロセスなのです。この標準化された仕組みこそが、ベンダー間の壁を取り払い、ネットワーク管理の世界に秩序をもたらした、SNMPの偉大な功績と言えるでしょう。

「共通言語」の文法：SNMPはどのように機能するのか

SNMPの概念的な役割を理解したところで、次はその具体的な「文法」、つまり技術的な仕組みを探求してみましょう。

ManagerとAgentの対話は、OIDを使って行われます。例えば、Managerがあるネットワーク機器の2番目のインターフェースが受信した総バイト数(Octets)を知りたい場合、次のようなリクエストを送信します。

リクエスト
SNMP-GET request for OID: .1.3.6.1.2.1.2.2.1.10.2
この数字の羅列がOIDです。これは、MIBという巨大なツリー構造データベースにおける、特定の情報までのパスを示しています。

.1.3.6.1.2.1 : 標準MIB(iso.org.dod.internet.mgmt.mib-2)
.2.2.1.10 : インターフェースの受信バイト数(interfaces.ifTable.ifEntry.ifInOctets)
.2 : 2番目のインターフェース

リクエストを受け取ったAgentは、このOIDを解釈し、自身の持つカウンターから具体的な値をManagerに返します。

レスポンス
Value: 15000000
この単純明快なリクエスト＆レスポンス(ポーリング)の仕組みこそが、SNMPが「Simple」と呼ばれる所以であり、長きにわたりネットワークの状態を定点観測する上での基盤となってきました。

【コラム】SNMPv3：Simpleなプロトコルを“Secure”に運用するための追加仕様

SNMPはその名の通りシンプルなプロトコルですが、初期のv1やv2cにはセキュリティ上の大きな課題がありました。通信の認証に使われる「コミュニティ名」が、ネットワーク上を平文で流れてしまうため、容易に盗聴されるリスクがあったのです。

この根本的な問題を解決するために登場したのが「SNMPv3」です。SNMPv3は、プロトコルそのものを複雑化するのではなく、Simpleな枠組みは維持しつつ、現代のネットワークで安全に運用するためのセキュリティ機能を追加したバージョンと位置づけられます。具体的には、以下の2つの重要な機能が実装されました。

認証(Authentication): 正当な管理者からのリクエストであることを、パスワード(認証キー)を用いて検証します。
暗号化(Privacy): やり取りされるデータを暗号化し、万が一盗聴されても内容を読み取れないように保護します。

このように、SNMPv3は、元々セキュリティを考慮していなかったプロトコルに堅牢な鎧を着せるような実装であり、これによって私たちは、今日のセキュリティ基準が厳しいネットワーク環境においても、SNMPを安心して活用できるのです。

現代が突きつける、SNMPの技術的限界

その偉大な功績にもかかわらず、なぜ今、SNMPの限界が指摘されるのでしょうか。それは、ネットワークを取り巻く環境が、SNMPが生まれた30年以上前とは比較にならないほど劇的に変化したからです。

課題1：ポーリング方式の限界ー“聞きに行く”ことの非効率性

SNMPは、Managerが能動的に情報を“聞きに行く”(ポーリングする)モデルです。これは、監視対象が数台から数十台であれば問題ありません。しかし、数百、数千の機器を管理する現代のネットワークでは、Managerがすべての機器に定期的に問い合わせを行う負荷は膨大になります。

結果として、ポーリング間隔は5分や10分といった長いものにならざるを得ず、突発的なトラフィックのスパイクや瞬間的な障害を捉えることは極めて困難です。つまり、リアルタイム性に欠けるという根源的な問題を抱えているのです。

課題2：帯域の爆発的増加とカウンターの限界

前回でも触れた通り、SNMPが直面する最も深刻な問題の1つが「言葉の不足」、すなわちカウンターの限界です。

標準的に使われてきた32ビットのカウンターは、最大で約42.9億($2^{32}$)までの値を数えることができます。数字だけ見れば大きいように思えますが、今日の広帯域ネットワークでは、この上限は瞬く間に使い果たされてしまいます。

ここで1つ、考えてみましょう。10Gbpsのネットワーク回線では、この32ビットカウンターは何秒で1周してしまうでしょうか。

$10 \text{ Gbps} = 1,250,000,000 \text{ Bytes/sec}$
$2^{32} \text{ Bytes} \div 1,250,000,000 \text{ Bytes/sec} \approx 3.4 \text{ 秒}$

わずか3.4秒です。400Gbpsや800Gbpsといった環境では、もはや瞬きする間にカウンターが一周(ラップアラウンド)してしまい、正確な通信量を把握することは不可能です。もちろん、この問題を解決するために64ビットカウンター(ifHCInOctetsなど)も標準化されていますが、すべての機器や項目で利用できるわけではないのが実情です。

課題3：ベンダー独自の拡張と標準化の形骸化

標準MIBで定義された項目だけでは、各ベンダーが独自に実装した機能(例えば、特定のハードウェアの温度やファン回転数)を監視することはできません。そこで、各ベンダーは「拡張MIB(独自MIB)」を用意し、自社製品の詳細な情報を取得できるようにしてきました。

しかし、前回でも指摘したように、この拡張MIBの維持・管理に対するベンダーの姿勢は、近年消極的になりつつあります。「Interop Tokyo 2025」での調査によれば、主要なネットワークベンダーはもはやSNMPを中心とした監視体系からの脱却を志向しており、拡張MIBの積極的なメンテナンスにはリソースを割かない傾向が明らかになりました。

これは、SNMPが「標準」という名の衣をまといながらも、本当に知りたい詳細な情報を得るための手段としては、その実効性を失いつつあるという厳しい現実を示しています。