クラウド環境でのルータ設定(前編)

ネットワーク機器の設定

「SEIL(ザイル)シリーズ」や「SA-W1」を設置するネットワーク環境は多岐にわたります。あらゆる環境に対応できる汎用的な機器を作ろうと思うと、様々な要件を満たすために設定項目が加速度的に増えていきます。ともすれば設定項目が多くなりすぎて、簡単なことを実現するにも手間がかかり、そもそも設定項目を見つけ出すのが困難な機器を作ってしまいがちです。逆に、項目を絞りすぎると「かゆいところに手の届かない」使い勝手の悪い機器になってしまいます。

ネットワーク機器の開発では、新しい通信プロトコルへの対応という本質的な機能追加はそれほど多くはないのですが、既存機能の動作を微調整・自動調整するといった「ちょっとした便利機能」の追加が、このような状況を生んでいます。ネットワーク機器のユースケース(=案件)が増えると、今まで見逃されていた不便な部分が表面化します。そういった不便さを解消するために便利動作を追加するわけですが、新機能を追加すると今度は更に「もうちょっと変更を加えるとカバーできそうな新しい使い方」にチャレンジしたくなる、という循環が日々生じています。こうして少しずつ設定項目は増えていき、いつしかちょっとしたネットワークの構成変更が、莫大な設定調整の手間を生み出すことになります。

このとき裏側では開発作業も複雑化し、「苦労が多いから機能追加したくないなぁ」というダメな雰囲気が開発にブレーキをかけてしまう事態も生じます。追加と同時に減らす機能を確保できれば問題にはなりませんが、旧来のネットワークがなくなるわけではないので、新規ではほとんど使わない機能の設定項目でも、なかったことにはできません。またセキュリティ対策を考えると、たとえ設計の古いネットワークであっても、常に最新のファームウェアを適用する必要があるのです。

このような問題があるので、開発者としては管理にも開発にも手間のかからない、シンプルかつ使いやすい機器を作りたいと考えています。
その一方で、運用部隊からのフィードバックは可能な限り製品に反映したいですし、かゆいところに手が届く便利機能の実現は、ときとして新規プロトコル対応と同等、もしくはそれ以上に楽しいものです。これは開発者自身が多かれ少なかれ抱えている矛盾で、何とか解消しないと楽しく仕事ができません。

また、できあがった製品について考えてみても、細かな工夫の積み重ねが「この製品ならでは」という特色をなすことになるので、新しいアイデアが出てこないと製品存続が危ぶまれます。そんな中、何とか折り合いを付けて機能追加をするわけですが、前述のように、機能追加することで機器全体が複雑化するたびに、新しいアイデアを実現するのが億劫になっていき、事態は一層困難さを増します。
この矛盾を解決し、運用部隊の豊富な経験と個々の開発者のアイデアを素直に製品に反映することが、「SEIL + SMF」から最新の「SA-W1 + SACM」まで、常にテーマとして存在しています。

設定項目削減を試みる

便利機能を追加していくと、どうしても設定項目数が増えて複雑になりがちです。設定項目が少なければ機器内部のプログラムの動作条件をある程度絞れるので、機能を追加しても開発の複雑さは抑えられるかもしれません。
また運用面から考えると、機器の動作環境ごとに動的に変えなければならない設定項目(自分のIPアドレス、トンネルを張る対向のIPアドレス、各種サーバ類のURL、メールの通知先など)が沢山あると、設定作業も増えてしまい大変ですが、一箇所の設定で多くの機能をまとめて扱うことができれば、いくらか管理も楽になります。

5年前の機器であれば設定値を「自動」にすることで「機器内部の設定値を適宜融通させる」という方針のもと、手動設定の箇所をある程度削減できていました。しかし、今日のネットワーク機器のように設定が豊富にできる場合、「自動」処理の内容にもバリエーションを持たせることができなければ、機器本来の性能・機能を生かし切ることはできません。そこで、ユーザが「自動」の内容をある程度記述できるようにする製品が増えてきました。大まかに分類してみると、以下のような戦略がありそうです。

1.汎用的な設定項目を追加する

1-1. イベント駆動型設定戦略

イベントを検知した際に設定行を有効/無効化したり、特定のアクションを起動したりする動作を「設定」として記述できる製品は比較的古くからあります。SEILシリーズでもmonitorコマンドとして(簡易的なものですが)サポートしています。検知できるイベントの種類とアクションの多彩さが決め手となります。

1-2. 簡易スクリプティング戦略

アプリケーションというほど高度なものではありませんが、設定管理に閉じたプログラミング環境を内蔵した製品もあります。設定組み込み用の簡易スクリプトとしては、Tcl、LUA、JavaScriptなどが有名です。

何かの条件でプログラムが起動すると、プログラムは動作状況を確認するなどして、最終的に設定行を出力したり、アクションを起動したりします。1-1では、単純なイベントと設定/アクションとのペアを記述できるだけでしたが、こちらではより複雑な「ロジック」を記述することが可能です。SEILでは組み込みスクリプト環境としてmrubyに注目しています。

詳しくは『軽量Rubyへの取り組み』をご覧ください。

1-3. 追加アプリケーション/プラグイン戦略

すぐに思いつく例はスマートフォンですが、ルータなどの企業向け製品にもSDKを利用して追加アプリケーションを開発できる製品があります。製品によりますが、設定管理という域を超えて独自プロトコルまで実現できるようなSDKもあります。ただし、本職のプログラマでないと扱いは難しくなります。
SEILとSMFでもAdd-on SDKとして追加アプリケーションの開発環境を開発していますが、まだ一般には公開していません。

2. 設定項目を追加せずになんとかする方法

2-1. 外部アプリケーション/コントローラ戦略

外部にサーバを置いて機器の設定をコントロールする方法もあります。SNMPを利用した製品が古くからあります。SMFも機器の設定を外部からダイナミックにコントロールできますので、この戦略と言えます。

また、前述の1-3「追加アプリケーション/プラグイン戦略」を「クラウド的な発想で実現したもの」と考えることもできます。最近では、Openflowをはじめとする標準プロトコルによるパケット転送の緻密なコントロール(SDN)が、注目されています。これまでSEILシリーズとSA-W1も試行錯誤してきましたが、現在はクラウドの進歩と開発の利便性を重視して、1-2の「mruby」と2-1の「クラウド」に注力しています。

戦略	設定作業	機能開発
イベント駆動	あらかじめ用意されたイベントとアクションを関連づける設定。条件分岐は限定的。	イベントと、アクションを追加する。
簡易スクリプティング	設定値の一部にスクリプトの実行を含める。ほぼ完全なプログラムが書けるが、ハードウェアやファームウェアへのアクセスは限定的。	スクリプトに対する各種APIの追加。
追加アプリケーション / プラグイン	ほぼ完全なプログラムが書ける。設定するというより、設定値を新しく作成してしまう。	開発環境の提供。
外部アプリケーション / コントローラ	機器側には粒度の細かい設定が沢山あるのみ。外部アプリケーションが機械的に設定を作成する。	Web(クラウド)環境の構築や、機器制御プロトコルの作成。

SMF + mruby

mrubyの文法のもととなるrubyは、TclやLUAと比較して開発者人口が多く、情報量も豊富です。そのため、ちょっとした作業を自動化する程度であれば、比較的使いやすいと思います。ただし、mrubyスクリプトを設定項目として直接見せるのかどうかは議論が分かれるところです。簡易的とはいえ、設定とプログラミングが混在する環境が使いやすいかどうは疑問ですし、「スクリプトを記述すれば、ご要望の機能は実現できますよ。」と言われても困惑するユーザも多いのではないでしょうか？

特定のケースであれば「とても便利でかゆいところに手が届くネットワーク機器用スクリプト」はきっと存在します。
しかし、それを設定値の一環としてしまうと、最悪のケースでは「せっかくのイカしたスクリプトが設定のコピペという形で相伝されていく」という悲しい事態になりかねません。せっかくSMFやクラウドの技術を持っているのですから、なおさらコピペからは脱却したいものです。

そこでSA-W1とSACMでは、SA-W1にmrubyの実行環境を備えつつ、設定とスクリプトは明確に分離する設計をとっています。また単純な文字列の置き換えで済むような処理は、汎用スクリプトよりもシンプルなマクロ処理を利用できるようにしています。
これらのスクリプトやマクロのセットは「レシピ」を軸にサーバ上で共有し、スクリプトを作る人と使う人を分離し、便利スクリプトを共有していく環境を実現しようと考えています。

項目	作る人
レシピ設定	エンドユーザ
レシビ設定マクロ	サービス提供事業者
スクリプト(mruby)	IIJ アプリケーション開発者
スクリプト支援機能	IIJ アプリケーション/OS 開発者
ファームウェア	IIJ アプリケーション/OS 開発者

このような環境で「スクリプトからこんな機能が使えればいいのに」という要望が見えてくれば、ファームウェアに対する機能追加として拾い上げたり、プラグインとしてAdd-onしたりすることも可能だと思います。