4. フォーカス・リサーチ（3）

目次

SEIL/SMFの変遷

4.1 はじめに

近年、モバイル回線の普及やIoT技術の発展に伴い、以前より多くの機器がインターネットにつながるようになりました。しかしインターネットにつないで終わりとはいきません。脆弱性に対応するためのファームウェアのバージョンアップや、利用環境の変化に伴う設定変更といった運用管理が必要です。IIJは、多数の機器を誰でもかんたんに運用管理できるようにすることを目的として、集中管理システム"SMF" （SEIL Management Framework）を開発してきました。ここでは歴史を振り返りつつSMFの特徴を紹介します。

4.2 SEILの開発

今からおよそ20年前、1998年にIIJは独自開発のルータ製品"SEIL" （ザイル）を発表しました。ISPであるIIJがSEILを開発した動機は「インターネットを誰にでも使えるものにしたい」という思いでした。当時広く使われていたISDN回線では、ルータに接続先電話番号を設定する必要があります。ユーザが常に最適な接続先を利用できるようにするため、SEILにはこの接続先電話番号を自動的に取得する機能が搭載されていました。

この接続先自動更新プロトコルはユーザの運用管理の手間を減らす一助となりました。しかしISPから一方的に情報を渡すだけではできることは限られています。ユーザが自由にネットワークを構成した上でそのネットワークの運用管理を手助けできるシステムを目指し、SMFの開発が始まりました。

4.3 SMFの誕生

SMFの開発を進めていた2000年代初頭は、高価な専用回線の代わりに安価なインターネットを使って安全な通信路を構築するインターネットVPN技術が徐々に使われ始めていました。インターネットVPNの運用面での課題に、1.機器設置時の初期設定にコストがかかる、2.トラブル対応が難しい、という2点がありました。SMFは「自動接続」と「集中管理」の2つの機能によってこれらの問題を解決しました。

図-1 複数の接続アカウントを利用した自動接続

「自動接続」は、工場出荷状態の機器にケーブルをつなぐだけで自動的にインターネットに接続できる機能です。インターネットVPNに使われる安価なインターネット接続回線の多くは、機器を回線につなぐ前に初期設定として「接続アカウント」を設定する必要があります。そのため、機材を管理者のもとにいったん集めて設定を投入してから改めて設置先に送付するといった作業が必要となり、インターネットVPNの導入コストを引き上げていました。SMFでは機器の起動プロセスを二段階に分けることでこの問題を解決しました（※1）。SMF対応機器は、起動するとまずSMFサーバに接続するためのコンフィグで動作を開始します。このとき接続アカウントには機器に埋め込まれたSMF専用アカウントを用います（図-1 ①）。SMFサーバは接続してきた機器に対し、ネットワーク管理者によって設定されたコンフィグを返します。コンフィグを得た機器は設定変更動作を行い、通常のISP接続アカウントで接続しなおして本来の動作を開始します（図-1 ②）。これにより、機器の設置作業はケーブルを挿すだけに簡略化しつつ、ユーザが自由にコンフィグを設定できる「自動接続」を実現しています。

「集中管理」は、多数の機器を一括して管理できる機能です。ネットワークの構成変更に伴うコンフィグの変更や運用管理コマンドのPush配信、機器が正常に動作していることを確認する監視を一括して実行できます。SMFでは多数の機器を管理するために様々な工夫をしています。例えば、SMFは開発当初IIJ社内で実績のあった能動（アクティブ）監視システムを採用していました。この監視システムは機器に対して定期的にPing（ICMP Echoパケット）を送信し、応答を受信することで機器と回線の正常動作を確認します。しかしSMFに接続される機器の台数が増えるにしたがって、監視システムの性能上の限界が見えてきました。そこで監視システムを見直し、SMF Heartbeatプロトコルと呼ぶ受動（パッシブ）監視方式の監視システムを新しく開発しました。SMF Heartbeatプロトコルでは機器から定期的にUDPパケットを送信し、一定時間Heartbeatパケットを送って来なかった機器があれば異常と判断します。このSMF Heartbeatプロトコルは監視のスケーラビリティの問題を解決しつつ、機器から情報を定期送信する手段としても活用されています。

4.4 SMFv2への発展

SMF技術は自社開発ルータSEILに搭載され、ルータ製品における初期設定と運用管理の課題を解決しました。しかし初期設定や運用管理の課題は何もルータに限られたものではありません。ネットワークに接続された機器はほぼすべて何らかの設定や管理を必要とします。そこでSMF技術をルータ以外のデバイスにも適用すべく、SMFv2（バージョン2）の開発が始まりました。

SMFv2の主要な開発目標は「汎用化」です。IIJの製品であるSEILでしか使えなかったSMF技術を、ルータ以外の機器でも、他社製品でも使えるものに改良しました。そのためにSMF技術を"libarms"というC言語のソフトウェアライブラリとして切り出し、様々なデバイスに組み込めるようにしました（※2）。libarmsを組み込んだデバイスは、SMFの自動接続技術を利用して自動的に集中管理サーバに接続されます。また、集中管理サーバをデバイスに応じて自由にカスタマイズできるように、ソフトウェア開発キット"SMF SDK"も用意しました。このようにして、SEIL以外の様々なデバイスでSMFの自動接続と集中管理が利用できる仕組みを提供しました。

ところで、ルータ以外の機器でSMFv2を利用する場合にはSMFv2サーバへの接続性が問題となってきます。現在、IPv4インターネットに接続する場合は、NATでIPアドレスを節約することが一般的です。NAT配下のホストではインターネットからの通信が阻害されるため、SMFサーバから運用管理コマンドをPush配信することができません。そこでSMFのプロトコルを改良し、NAT越えのコントロールを実現しました。従来のPushプロトコルでは、デバイス上のlibarmsがHTTPSサーバとして機能してSMFサーバからのメッセージを受け付けていました。しかしNAT環境ではサーバからのHTTPSリクエストがデバイスに届きません。そこでNAT環境ではデバイスの方からサーバに対してHTTPSコネクションを確立維持し、そのコネクションの上でSMFv2のメッセージを双方向に交換することで、NAT越えのPush通信を実現しました。

4.5 クラウド型集中管理システムSACM

2011年、これまでのSMFの開発過程で培ってきた技術を元に1つの新しいシステムが生まれました。それが"SACM" （Service Adaptor Control Manager）です。SMFv2をベースとし、多数のデバイスの集中管理に必要となる機能を更に強化しました。

SACMは設計当初よりクラウド型のシステムとして開発されました。SMF SDKを利用して構築したオンプレミス型システムでは、libarmsを組み込んだデバイスを実装してもその後のサービス機能開発や集中管理サーバの運用が課題となるケースがありましたが、SACMではこれらはすべてIIJが行います。加えて、ユーザのブランドに合わせてOEM提供するためのカスタマイズ性も重視しました。SACMの開発によってSMF技術を利用するハードルを下げることに成功し、現在では数十に上るOEMパートナーがSMFを利用しています（※3）。

また、既存のシステムはそのまま利用しつつ、SACMの機能を部分的に組み込みたいというケースがあります。SACMはREST APIによるシステム間の連携に対応しています。単なるサーバ上のデータの読み書きだけに留まらず、あたかもHTTPによるリクエストを介してデバイスを直接コントロールするかのような振る舞いをさせることを可能としました。libarmsを組み込んだデバイスとSACMの持つ機能を組み合わせ、更にこれを外部のシステムとAPIでつなぎ合わせることによって、これまでになかった形態のサービスが作られるようになりました。

IIJが提供する「スマートメーターBルート活用サービス（※4）」はその一例です。スマートメーター（※5）から電力データを取得してクラウドに送信するゲートウェイ機器として"SA-M0"、"SA-M1"を開発し、これにlibarmsを組み込みました。機器の操作や監視は実績のあるSACMシステムにまかせることで、電力データの取得や送信に関わる開発に注力し、安定したサービスをタイムリーに提供することができました。デバイスの自動接続はもちろん、スマートメーターに対するデータ取得コマンドの実行や、デバイスのコンフィグ管理といった機能もREST APIを介したシステム間の連携により実現されています（図-2）。

図-2 SACMとスマートメーターBルート活用サービスとの連携

4.6 SMFの更なる進化

SACMのサービス化によって導入が容易になり、SMF技術は開発当初想定もしていなかったような分野でも使われるようになりました。そしてモバイル技術の普及やIoT技術の発展によってデバイスの運用管理に求められるものも変化しつつあります。ここでは新しい集中管理のニーズに対応するために現在開発を進めている2つの機能を紹介します。

1つは"Legs" （レッグス）です。これはSMFv2で開発されたNAT越え双方向通信プロトコルを更に進化させ、デバイス上で動作するアプリケーションに依存した任意の形式のデータを取り扱えるようにしたものです。多数のデバイスにコマンドを一斉配信したり、反対にデバイスからサーバにイベントを通知する機能を提供します。

もう1つは"Machinist" （マシニスト）です。SMF Heartbeatプロトコルにはデバイスから既定の監視情報を収集するための仕組みがありました。Machinistはこの情報の収集機能を汎用化し、欲しい情報を好きなタイミングで収集できるように改良したものです。収集したデータは可視化され（図-3）、またデータの値の変化に応じて自動的にユーザへの通知や外部APIの実行といった特定のアクションを実行する機能を備えています。

図-3 Machinistユーザインタフェース

また、これらはそれぞれ独立したコンポーネントとなっていて、各機能を単独で動作させることが可能となるように設計しています。そのため、SMFの持つ機能のうち必要なものだけをピックアップして利用する、といった使い方を選択することもできるようになりました。

4.7 おわりに

ここまでSMFの辿ってきた歴史を振り返りつつその特徴を紹介してきました。自動接続と集中管理という根幹は変わらないものの、インターネットの利用環境の変化に応じてSMF技術も少しづつ変わってきています。現在はSMF技術をIoT分野において活用するための開発に注力しています。日々新しく誕生するニーズに対応すべく、SMFの開発は止まることなく続いてゆきます。

（※1）特許第3774433号。
（※2）libarmsはSMFポータルサイトからダウンロード可能です（https://www.smf.jp/product-service/libarms.html）。
（※3）libarmsの動作検証用としてSACMのトライアル環境を提供しています（https://dev.smf.jp/）。libarmsと共に無償で利用することが可能です。
（※4）IIJスマートメーターBルート活用サービス（https://www.iij.ad.jp/biz/smart-meter/）。
（※5）通信機能を備え、電気使用状況を遠隔から取得可能な電力量計。