ネットワーク機器への操作もおなじみのインターフェースで
シスコシステムズのシステムエンジニア、田川真樹氏は九州工業大学情報工学部出身。大学は学生の自主性を尊重し、パブリックのIPv4アドレスを自由に使える環境だった。後に奈良先端科学技術大学院大学でSDNと無線LANを組み合わせる研究に没頭し、2016年からシスコシステムズへ。SDN応用技術室を経て、現在はアカウントSEとして活動している。
今回のセッションでは、その田川氏がネットワークインフラのプログラマビリティについて、デモを交えながら解説する。前半はプログラムでネットワーク機器を操作する方法について、後半はネットワーク上でプログラムを稼働させる方法について紹介する。
ネットワークの世界はアプリケーション開発の世界と大きく異なる印象がある。ネットワーク機器から情報を取得し設定を行う時に使われるコマンドラインインターフェースは、アプリケーションの世界でおなじみのRESTとは異なるプロコトルだ。機器固有のコマンドにはオプションや省略形があり、達人でなければ使いこなせない。コマンドの戻り値は構造化されていないテキストが長文で並ぶ。構造化されていないデータをプログラムで扱うのは非常に難しい。
しかし今回のセッションで紹介された2種類のプログラマブルなインターフェースには、パーサーを使った抽象化と、ネットワーク機器が備えるネイティブなプログラマブルインターフェースがある。前者はネットワーク機器のコマンドラインインターフェースで扱われるテキストをパーサーが抽象化するもので、後者はアプリケーションの世界におけるREST APIと同様に、ネットワーク機器が情報を構造化して扱う。
パーサーで抽象化するものだとシスコのpyATS／Genieや、GoogleのTextFSMがある。ここでは前者をベースに解説する。pyATSはPython3をベースとしたネットワークテスト自動化フレームワークで、その中にオープンソースライブラリとなるGenieがある。シスコの製品開発時に使われているツールをオープンソース化したもので、実績は豊富。シスコだけではなく、他のネットワークOSにも対応している。
pyATS／Genieでは、Pythonプログラムがネットワーク機器でコマンドを実行、戻り値となるテキストをGenieがパースするという流れになる。単なるスクレイピングにとどまらず、プラットフォームやベンダーに依存しない機能ごとのモデルに抽象化することもできる。例えば特定の機能について情報収集したい時はモデルを指定して「learn」（学習する）を実行すればよい。そうすればプログラムが自動的に関連するコマンドを発行し、戻り値をもとに情報をまとめる。機種依存のコマンドを使いこなさなくてもいいのだ。
こうしたスクレイピングではなく、ネイティブなプログラマブルインターフェースとしてはNETCONF、RESTCONF、gNMIなどがある。例えばRESTCONFは文字通りREST APIに非常に似通ったインターフェースだ。
NETCONF、RESTCONF、gNMI、これらインターフェースごとにプロトコル（SSH、HTTPなど）やエンコーディング（XML、JSONなど）が異なるが、コンテンツ部分はデータモデル言語YANGによって共通して表現できる。従来はベンダーやOSごとに異なるコマンドや表現を学習する必要があったが、YANGデータモデルには業界団体や標準化団体によって定義されたオープンモデルと呼ばれるデータモデルが存在する。これによってマルチベンダー環境にも対応できる。
例えばネットワーク機器の設定を変更するとしよう。コマンドラインなら「no」に続いて古い設定を入力し確定、その後新たな設定を入力し確定する。REST API的に見ると、コマンドライン内にメソッドとペイロードが混在しているようなものだ。しかしRESTCONFであれば、POSTやPUTメソッドを使い、bodyの中に新しい設定を指定するため、「宣言的に設定を投入できる」と田川氏は言う。
ここまではネットワーク機器への操作だったが、逆にネットワーク機器からの出力（テレメトリ）に関するプログラミングについて見ていこう。従来使われているテレメトリにはsyslog、SNMP Trap、NetFlowがある。これに加えてYANGでモデル化されたNETCONF Dial-In、gRPC Dial-Out、gNMI Dial-Inがある。つまりネットワーク機器がYANGデータをプッシュ送信していることになる。プッシュのタイミングは定点観測のように一定時間ごとだけではなく、例えばクライアント数がしきい値を超えたなどの変化をきっかけにすることもできる。
田川氏はコレクタのTelegrafでテレメトリを指定し、Grafanaで可視化する様子を披露した。取得したい情報をコードの中でパス（URI）として指定すると、ネットワーク機器から情報が出力され、このデータを時系列データベースとなるinfluxdbに蓄積し、Grafanaでグラフ化する。データはすべて構造化されているのでプログラムで扱いやすい。
ネットワークスイッチ上でアプリケーションやコンテナを稼働できる
ここからはネットワーク機器でプログラムを稼働させるための方法に話題を移す。セッションのサブタイトルにあるように「LANスイッチでPythonだって動いちゃう」時代なのだ。
一般的には「On-Boxプログラマビリティ」と呼ばれている。これまではプログラムはネットワーク機器（Box）の外にあったが、今ではネットワーク機器の上でプログラムが稼働するためだ。リモート管理システムだけでは得られないロジックを実現できるというメリットもある。シスコ以外のベンダーの機器でも実現可能だ。
シスコで長年使われているOn-Boxプログラマビリティ機能にEEM（Embedded Event Manager）がある。ネットワーク機器単体でイベントをトリガとしてアクションを実行できるため、装置の中で完結する。対応している機種が多いのも特徴だ。
こうしたプログラマビリティの進化と呼応するように、ネットワーク機器も日々進化している。シスコのLANスイッチを例に取ると、2017年に発売されたCatalyst 9300シリーズではx86 CPUと8GB メモリを搭載し、さらにコンテナをホストするためにSSDを追加できるようになっている。ちょっとしたパソコンのようである。
実行可能なアプリケーションだと、まずGuest Shell機能がある。これはCisco IOS XEに標準で組み込まれていて、ユーザーが利用可能なLinux環境だ。加えて、ユーザーがDockerコンテナ、LXC（Linux Containers）、KVM（Kernel-based Virtual Machine）をインストールすることもできる。田川氏はデモとして、Catalyst 9300スイッチで数コマンド実行するだけでLinux環境が立ち上がる様子を披露した。
EEMとGuest Shellを組み合わせると、ネットワーク機器で起きたイベントをトリガにPythonスクリプトを実行することができる。これは外部装置やサーバーを必要とせず、ネットワーク機器のみで何らかの自動化が可能となる。外部との連携もできる。例として田川氏は、ネットワーク機器で特定のエラーを検出すると、スマートスピーカーからBGMを流すアラートの仕組みと実際に稼働させた様子を動画で示した。
ここでネットワーク機器内のアーキテクチャを紹介しよう。シスコのネットワーク機器ではネットワーク機能を提供している部分（Cisco IOSd）は独立しており、サードパーティーのアプリケーションやコンテナなどエッジコンピューティングを支える部分（Cisco IOx）は別にある。
Cisco IOxで稼働しているサービスをコマンドラインから確認すると、libvirtdやdockerdが「Running」となっているのが分かる。田川氏はCisco IOxを使ってnginxのDockerコンテナを稼働させ、そのIPアドレスをブラウザで開いて見せた。ネットワーク機器（スイッチ）でコンテナが走り、そのコンテナでWebサーバーがホストされていることが示された。
このようにネットワーク機器で何らかのアプリケーションやコンテナなどが稼働できるようになると、「ネットワーク管理製品がコンテナをオーケストレーションする時代になる」と田川氏は言う。ここで「Kubernetesでいいのでは？」と思えるかもしれないが、わざわざKubernetesを稼働させるほどでもない……というような時にはいいかもしれない。選択肢として覚えておきたい。
最後に田川氏は参加者に向けて、こう話した。「今ではネットワークエンジニアの仕事はコマンドラインで『sh xxx』を駆使する世界から変わり、アプリケーションのようにAPIやRESTのインターフェースが用意されています。アプリケーション開発者の皆さんにとって、より近い世界になっているのではないでしょうか。ネットワークも意外と遊べます。楽しい世界だと気づいてくれたらネットワークベンダーのエンジニアとして、とてもうれしいです」
