2006年に入るころから，「IT」（information technology）という言葉に代わって「ICT」（information and communication technology）という言葉が多く使われるようになったと感じています。「IT」が「ICT」に置き換わったことの意味を深読みすると，今のITには「C」つまり「Communication」が必要なキーワードとして捉えられたことだという気がします。
ICT時代のネットワークに求められる要件とは？
しかし，ルーター開発者の立場から感じるのは，これまで「C」が「IT」に欠けていたことの表れでないかと感じています。ネットワーク機器がITシステムと連携するためのしくみを提供できていなかったのではないか，という反省もあります。
ネットワークはもともと，自律的に運用できるシステムとして提供されてきたものです。回線や機器の障害回避，適度な負荷がかかったときの負荷バランス制御，アクセス制御，等さまざまな自律運転の機能をネットワークだけで実現しています。おもに2000年ころまでに構築されたITシステムは，ネットワークが備えるこれらの機能を利用することで，日々の運用における障害の回避等は自立的に行えてしまう為，システム全体として安定的に稼働することが可能でした。従来のITシステムでは，あえてネットワークを意識する必要がなかったといえるでしょう。
ところが，2000年問題を乗り越えたITシステムは，企業活動のグローバル化やインターネット技術の普及によるボーダーレス化（ユビキタス化）により，大きく様変わりしました。例えば，企業間の電子商取引の市場規模は，2000年の21兆円が2004年では102兆円へと大幅に増加しています。その他の統計資料でも同様にネットワークを使った各種の数値は指数級数的に増加しています。
このようにネットワークを介したビジネス形態が拡大した結果，ITシステムには，24時間365日の安定的稼働はもとより，企業活動の拡大に伴うシステム増設，企業統合や業種統合などによるシステムの統廃合，データセンターへのアウトソーシング，日々深刻化するセキュリティなどの問題に迅速に対応，等動的な変更や切替を柔軟に支援できるしくみが求められるようになったのです。
これは，ITシステムだけを対応させれば済む話ではありません。ネットワークもシステムの変更や開発に合わせて変更していく必要が出てきます。つまり，ネットワークにもITシステムに合わせて日々更新できる機能や能力が必要となっているのです。これが，「IT」が「C」を加えて「ICT」となった事情なのだと勘ぐったりしています。ネットワークはすでに，「自律的に稼動するしくみだけ用意して，しばらくそのまま放置しておく」ということはできなくなっているのです。
二つのポイント「自動化」と「ITとの親和性」
では，ITシステムに合わせて日々更新できる機能や能力をネットワークに持たせるにはどうすればいいのしょうか。私たちがルーター開発者の立場からこの問題に取り組み，出した結論は，「自動化」と「ITとの親和性」の実現です。
まず「自動化」について書いていきたいと思います。
これまでのネットワーク機器は，おもにコマンド・ベースのCLIで制御する機能を備えています。CLIは，ネットワーク機器が出来た当初の1980年代から存在している手法です。基本的には，ネットワークを運用管理するオペレータが利用するために開発されました。ただし，CLIは機器や機種，提供ベンダーに依存します。統一された仕様はありません。
CLIはオペレータ，つまり人間が使うことを前提とした手法です。ネットワーク機器を制御するためにコマンドを打ち込みますし，その結果を確認するのにもコマンドを入れます。処理するのが人間なので，応答メッセージに多少おかしなところがあったり，機種によって応答の返し方が若干違っても吸収して運用できます。
しかし，これをコンピュータに代行させて「自動化」しようとするとどうでしょうか。応答メッセージのフォーマットやメッセージの出現順序など，機器ごとに異なるCLIを処理するために複雑なしくみが必要となりますし，機器のファームウエアの更新によって変更となるメッセージにもその都度対応しなければならなくなります。このため，CLIを使って自動化を実現する製品やソリューションもあることはあるのですが，特定の範囲のシステムとか機器を限定してシステムなどの運用の場面で使われている程度なのが現状です。とても普及しているとはいえません。
CLIは，自動化に限らずオペレータの運用にとってもあまり望ましいものではありません。複数の機器をCLIで運用しようとすると，オペレータはそれぞれ異なるCLIを覚えなければならず，大きな負荷がかかることになるからです。さらに，自動化が困難なCLIを使い続けることでオペレータの作業効率が低下し，新機能を使いこなすノウハウの習得が困難になるなどの恐れもあります。つまり，現在のネットワークの運用は，業務用サーバーや業務アプリケーションをいまだにコマンド・ラインを使ってオペレーションしているようなものであり，まったく自動化されていないといっても過言ではありません。
こうした状況の改善案の一つとして，1980年後半に登場した技術にSNMPがあります。SNMPを使うことで，マルチベンダーで構築されたネットワークでも標準的な設定情報やトラフィック情報を自動的に収集することが可能になりました。
しかし，SNMPでも設定（構成定義の設定等）機能もあったのですが，主には情報収集に力点がおかれた為，自動化を支援するとい面では力不足です。セキュリティ面への配慮や機器の機能拡張に合わせた対応は進められていますが，ITシステムの進化に比べればその進みは遅いといえるでしょう。
もう一つの観点である，ITシステムとの親和性について少し考えてみます。
ITシステムで最もコストがかかるのはプログラム開発です。プログラムの生産性を向上させ，開発期間を短縮するために，さまざまなプログラミング言語が開発されました。Cobol，PL/I，C，Javaなどなど，システムに合わせたものが登場してきました。その一方で，ネットワーク機器に対する制御は「コマンド」の域をでていません。いまだにCLIをtelnetで流し込むという運用を続けているところも多くあるようです。
今のITシステムが求めるネットワークは，機器の種類やベンダーに依存することなく，分や秒の単位で構成や機能が変更できる「自動化」と，ITシステムのアプリケーション開発者が意識しないで制御プログラムを開発できるネットワークです。例えば，省力化の観点で「誰も使わない無線LANアクセス・ポイントの給電を止めておこう」とか「会議室の予約と合わせてLANのポートを空けておこう」，「災害対策用に用意した遠隔センターへデータをバックアップするときに回線帯域を確保し，終了したら解放する」など，業務の中からネットワークを制御する事で，より効果的な利用が図れるからです。
現状のネットワークの状況と求められる姿を比べて考えていくと，さまざまな課題が浮かび上がってきます。
機種やメーカーごとに違いがあるCLIやSNMPの拡張MIBでは，どんなネットワークでも管理できるアプリケーションを開発することはできません。さらに，ネットワーク管理システム（NMS）が高度な処理を実現するようになると，複数の管理システムからネットワークを制御する枠組みも必要になります。ただし，勝手に管理システムからの制御を受け入れてしまうと，悪意のあるユーザーによってネットワークを好きなようにいじられてしまうという危険性も出てきます。さらに，柔軟な管理アプリケーションを開発するとなると，標準的なプログラム環境からネットワーク機器を制御できるしくみも必要でしょう。
これから先では，こうした課題とその具体的な対策について紹介します。
|
|
|
