写真:Getty Images

 ネットワーク運用管理の自動化は、ネットワークエンジニアにとって大きな課題の一つになっている。ネットワーク運用管理を自動化すると深夜作業や障害対応の時間を減らせるため、ネットワーク管理者の働き方の質を大きく上げられる可能性がある。

 ネットワーク運用管理の自動化技術は、抽象度別に大きく四つのレイヤーに分類できる図1)。このうち「機器管理」と「ネットワーク管理」は、主に物理ネットワークの管理作業を自動化するレイヤーだ。「機器管理」は、ネットワーク機器の管理を自動化する技術。例えば、初期設定を自動化する技術が該当する。「ネットワーク管理」は、複数機器が接続するネットワークの管理を自動化する技術である。この記事では、ネットワーク技術者にとって身近なこれら二つのレイヤーに絞って、自動化のための技術を解説する。

図1●ネットワーク運用管理の自動化の分類
ネットワーク運用管理の自動化技術を、抽象度別に四つのレイヤーに分類した。「機器管理」と「ネットワーク管理」は、主に物理ネットワークの管理作業を自動化するレイヤー。「SDN/ネットワーク仮想化」では、仮想ネットワークを作成して管理を自動化する。「オーケストレーション」は、仮想ネットワークを用いてITサービス全体を管理するレイヤー。
[画像のクリックで拡大表示]

ライフサイクルを意識する

 ネットワーク運用管理を自動化するうえで重要なのは、「誰が」「いつ」「どのようなことを」「どこまで」自動化するのかを決めることだ。一般的なネットワークのライフサイクルは、ネットワークの「構築」「設定」「運用・保守」の三つのフェーズに大きく分類できる(図2)。

図2●自動化の三つのフェーズと関連するツール
ネットワーク運用管理の自動化のライフサイクルは三つのフェーズで構成される。各フェーズにはそれぞれに適した自動化ツールが存在する。
[画像のクリックで拡大表示]

 各フェーズにはそれぞれ適した自動化ツールがある。

 構築フェーズでは、機器の設定ファイルを生成する必要がある。その際に、「Ansible」などの構成管理ツールを使うことで、設定ファイルをテンプレートから正確に作成できる。また、「ZTP」を併用すれば、機器をネットワークに接続するだけで、設定が自動的に適用される。

 設定フェーズでは、日々のオペレーションやユーザーの要望への対応を行う。機器の更新などに伴うVLANの追加やセグメントの変更などが該当する。こうした設定変更もAnsibleなどの構成管理ツールで効率化できる。また、「特定の機器から取得したデータをグラフに整形する」といった柔軟な処理を実現したい場合は、Pythonなどのスクリプト言語も有用だ。

ZTP:
機器の設定作業を省力化する

 まず構築フェーズでの自動化技術の一つであるZTPを取り上げる。あなたがデータセンターのサービスを提供する会社のネットワークエンジニアで、ある朝、上司から、「明後日までに10台のスイッチを商用環境にセットアップできないか?」と相談を受けたとする。そのようなとき、ZTPは有効な解決策の一つになる。

 ZTPは、特定の機能やプロトコルではなく、「ネットワーク構築を自動化するワークフロー全体」を指す。初期状態のネットワーク機器をネットワークに接続して電源を入れるだけで、機器のOSのアップデートや必要な設定をネットワーク経由で自動的に行う。

 機器の設定や入れ替えの担当者は、機器を設置してケーブルを接続するだけで、一切の設定作業から解放される。

作業工程がシンプルに

 ZTPを利用すると、作業工程の多くが省略され、とてもシンプルになる(図3)。従来の標準的な導入作業では、「作業スペースなどでスイッチを1台1台、箱から取り出す」「コンソールケーブルを接続してセットアップする」「作業用ネットワークに接続する」「OSを実環境のバージョンに合わせる」「初期設定ファイルを入れる」といった一連の作業が必要だった。個々の工程の作業量は少ないが、セットアップする台数が多い場合、全体ではかなりの作業量になる。ZTPの導入で、これらの多くを省略できる。

図3●ZTPと従来のオペレーションとの比較
ZTPを使用する場合としない場合で機器の設置作業がどのように変わるのかを示した。ZTPを用いた場合、作業工程の多くが省略され、とてもシンプルになる。
[画像のクリックで拡大表示]

 ZTPを導入してネットワーク構築を自動化することで得られるメリットは三つ。まず「作業工数の削減」。次が「変更への柔軟な対応」。従来は、機器の設定ファイルの変更が必要な場合、1台ずつ設定変更しなければならなかった。ZTPでは、初回起動時の設定ファイルの読み込み前であれば、ファイルサーバーに置いた設定ファイルを変更するだけで対応できる。三つめが「担当者の負担軽減」。ZTPでは、作業項目の多くが自動化されるため、担当者の負荷が少なくなる。

ゼロ設定をどう実現するか

 ではZTPの仕組みを解説しよう。ここではベンダーに依存しない、DHCPを使うオープンな実装を取り上げる。

 ZTPに必要なコンポーネントは「DHCPサーバー」「ファイルサーバー」「ZTP対応ネットワーク機器」(ここではスイッチ)の三つだ(図4)。

図4●ZTPの動作シーケンス
ZTPに必要なコンポーネントは、DHCPサーバー、ファイルサーバー(対応プロトコルはTFTP/FTP/HTTPなど)、ZTP対応ネットワーク機器(ここではスイッチ)の三つである。ネットワーク機器を起動すると、ZTPプロセスが始まる。スイッチがDHCPで自身のIPアドレス、ファイルサーバーのIPアドレス、設定ファイル名やOSイメージファイル名を要求する。DHCPサーバーはIPアドレスおよびファイルサーバーのIPアドレス、ファイル名を返す。スイッチはファイルサーバーから設定ファイルやOSイメージファイルをダウンロードし、それらを読み込んで再起動する。
[画像のクリックで拡大表示]

 ZTP対応のネットワーク機器の多くは、電源を初めて入れた際、自身のIPアドレスをDHCPサーバーから取得しようとする。DHCPサーバーは、機器にIPアドレスを自動で割り当てる。DHCPサーバーにはMACアドレスを基にIPアドレスを静的に割り当てる機能がある。ファイルサーバーのIPアドレス、設定ファイル名、OSのイメージファイル名なども付与できる。DHCPサーバーには、機器のMACアドレスと、設定ファイル名/イメージファイル名をひも付ける設定を施す(図5)。

図5●機器のMACアドレスを見て設定ファイルやファイルサーバーの情報を返す
DHCPサーバーの設定ファイル(dhcpd.conf)の例。ここではスイッチのMACアドレスに対し、IPアドレス、設定ファイル名、ファイルサーバーのIPアドレスをひも付けている。
[画像のクリックで拡大表示]

 もう一つのコンポーネントがファイルサーバーだ。担当者は必要な設定ファイルやOSのイメージファイルをファイルサーバーにアップロードしておく。ZTP対応機器は、DHCPサーバーからの情報に従い、ファイルサーバーから必要なファイルを自動で取得および適用する。これらの手順はすべて自動で実行されるので、手動設定でよく起こる設定漏れを防止できる。

保守にも役に立つ

 ここまでZTPを構築フェーズの自動化として紹介してきたが、ZTPは保守作業で機器を交換する際にも適用できる。例えば従来のスイッチの故障対応では、構築作業と同様にスイッチOSをインストールし、最新の設定を適用してから機器を交換する必要があった。

 一方、機器の最新の設定ファイルを常にファイルサーバーに保存しておけば、この交換作業にもZTPを適用できる。DHCPサーバーの設定ファイルに記載されたMACアドレスを交換後のスイッチのものに変更する。あとはスイッチを交換して電源を入れるだけでよい。いったんZTPを導入すれば、構築フェーズだけでなく、運用・保守フェーズでもメリットを享受できる。

Ansible:
機器の設定を自動的に管理

 もっとも、「事前にすべてのネットワーク機器の設定ファイルを正しく作成する」のは手間がかかる。この問題を解決するのが「構成管理ツール」だ。

 構築フェーズの次の設定フェーズでは、サービスに必要な設定ファイルを作成し、機器に設定を反映させる。このフェーズでは、ユーザーやサービスの追加といった要望(オーダー)に応じて、機器に設定を追加していく。実際にはユーザーの追加や変更などのサービスオーダーを受けた後、対象機器の設定ファイル作成、設定手順書の作成、手順書のレビュー、本番作業という業務が発生する。このフェーズでは様々な問題が発生する。

 まず「大量の設定ファイルへの対応」だ。手動で設定していると作業ミス、専用スクリプトでは再利用性の低さやコードメンテナンスなどの問題が発生する。

 次が「作業時間」。全体の作業時間を短くするため、1台当たりの作業工程数を削減するだけでなく、工程当たりの作業時間を短縮する工夫も必要になる。

 「作業の正確性」も必要だ。作業を効率化しても、作業品質が低下しては、トラブルが発生する可能性が高まり、逆に全体的な工数の増加につながる。

 こうした問題を解決するのに有効なのが、クラウドのインフラ構築で使われている構成管理ツールである。最近の構成管理ツールには企業のネットワークに適用できるものもある。構成管理ツールを導入することで、大量の設定ファイルを自動的に生成できるようになる。また設定の適用も自動化できるため、短い時間で正確に設定を適用できる。

Ansibleで設定を一元管理

 ここでは構成管理ツールの例としてAnsibleを取り上げよう。管理サーバーにAnsibleをインストールすれば、各種サーバーやネットワーク機器の設定や起動状態などを一元的に管理できる(図6)。ネットワーク運用にAnsibleを利用すると、機器の設定を自動生成して適用したり、機器情報を一括して取得したり、OSを一括インストールしたりして、運用管理を自動化できる。

図6●Ansibleを利用した機器の一括管理
管理サーバーにAnsibleをインストールすることで、担当者は各種サーバーやネットワーク機器の設定や起動状態などを一元的に制御できる。ネットワーク運用にAnsibleを利用すると、機器の設定を自動生成して適用したり、機器情報を一括して取得したり、OSを一括インストールしたりして、業務を自動化できる。
[画像のクリックで拡大表示]

 Ansibleでは、主要な設定ファイルをYAML形式で定義する。XMLよりも構造化されたデータをシンプルに表現できるのが特徴だ(図7)。

図7●設定ファイルはYAML形式で記述
Ansibleの主要な設定ファイルはYAML形式で記述する。構造化されたデータをXMLよりもシンプルに表現できる。
[画像のクリックで拡大表示]

 ユーザーが機器の設定ファイルを生成して適用するには、YAML形式の「Playbookファイル」と「パラメーターファイル」、Jinja2形式の「テンプレートファイル」を用意する。テンプレートファイルは、基本的には基になる設定ファイルでパラメーター化した部分に変数名を割り当てて作成する(図8)。Ansibleではパラメーターとテンプレートを完全に分離して管理するため、ベンダーごとに設定ファイルの形式が異なっていても、テンプレートを変更するだけで様々なベンダーの機器に対応できる。

図8●機器の設定ファイルを基にテンプレートファイルを用意
テンプレートファイルはJinja2という形式で記述する。最もシンプルな例では、基の設定ファイルの中で可変にしたい部分に変数名を割り当てるだけで作成できる。
[画像のクリックで拡大表示]

実際に機器を制御してみる

 では実際にAnsibleを使ってネットワーク機器を設定してみよう。「データセンター内のリーフスイッチとスパインスイッチの設定ファイルを生成し、IPファブリックネットワークを構築する」という例を取り上げる。

 サーバーからスイッチを制御する際にNETCONFプロトコルを使用するため、操作対象のすべてのスイッチであらかじめNETCONFを有効にしておく。

 そして、各スイッチのインベントリ情報(機器リスト)を定義する。ここでは、役割からリーフとスパインの二つのグループに分けている。グループ化することで、リーフのみに必要な設定やスパインのみに必要な設定といったように、それぞれ内容を分けられる(図9)。

図9●制御する機器の一覧を定義するインベントリファイルを用意
Ansibleでは、制御したい機器をインベントリファイルに記述する。ここでは、役割ごとにリーフとスパインの二つのグループに分けている。グループ化することで、例えばリーフのみに必要な設定やスパインのみに必要な設定といったように内容を分けることができる。
[画像のクリックで拡大表示]

 次に二つのテンプレートを作成する(図10)。「Junos-system」は、すべてのスイッチに共通する設定を生成するテンプレート。DNSサーバーやNTPサーバーの設定などが該当する。「Junos-ebgp」はインタフェースの設定など、スイッチごとに固有の設定を生成するテンプレートだ。

図10●二つのテンプレートを作成する
「Junos-system」ではすべてのスイッチに対して同じ共通設定を生成する。「Junos-ebgp」ではスイッチごとに固有の設定を生成する。
[画像のクリックで拡大表示]

 Playbookファイルには、対象ホストやタスクを定義する。「tasks」の後に、「-(ハイフン)」でタスク名や呼び出すモジュール名と必要なパラメーターを記述する(図11)。

図11●Ansibleの動作を定義するPlaybookファイルの例
対象ホストやタスクを定義する。「tasks」の後に、「-(ハイフン)」でタスク名や呼び出すモジュール名と必要なパラメーターを記述する。
[画像のクリックで拡大表示]

 Playbookファイルは「ansible-playbook」というコマンドを使って実行する。図11の例では、スイッチ8台分の約1200行のJunos設定ファイルを/config配下に生成し、その設定ファイルを機器に投入している。

Jupyter:
スクリプトを簡単に実行できる

 ここまではツールを使った自動化を紹介した。さらに、プログラミング言語を使えば、より柔軟に運用を自動化できる。プログラミングといっても複雑なコードを書く必要はない。機能を実現するためのコードを事前に用意しておけば、あとは呼び出すだけでいい。ここでは、Pythonのコードを簡単に実行できる「Jupyter」というツールを紹介しよう。

 現在、ネットワーク機器ベンダーの多くは、自社機器をPythonで簡単に操作するためのライブラリを提供している。これらを使うことで、機器への接続制御などの煩雑な処理をライブラリに任せ、ユーザーは実行したい処理のロジックの組み立てに集中できる。ジュニパーネットワークスのネットワーク機器を操作する「PyEZ」というライブラリを利用する例を紹介しよう。

 Jupyterでは、Webブラウザーから直接、Pythonスクリプトを記述したり実行したりできる。ルーターの情報を取得するスクリプトを埋め込んだサンプルを図12に示した。Pythonスクリプトを実行するには、スクリプトが記述されているセルをクリックして「'Cell' -> 'Run Cell'」を選択する。最初の部分では、4台のルーターからJunosのバージョンとインタフェース(ge-0/0/0)の状態を取得している。

図12●Webブラウザー上でPythonスクリプトの記述や実行が可能なJupyter
ここに示したのは、4台のルーターからJunosのバージョンとインタフェース(ge-0/0/0)の状態を取得し、結果を表として出力するスクリプト。
[画像のクリックで拡大表示]

 その下にある「check_junos_status(junos_ip_s)」というセルを実行すると、ルーターの情報が表形式で出力される(図13)。「check_junos_traffic(junos_ip_s)」というセルを実行すると、ge-0/0/0を通過したパケットの量をグラフで表示する(図14)。

図13●ルーターから情報を取得して表形式で出力
「check_junos_status(junos_ip_s)」というPythonスクリプトが記述されているセルをクリックし、‘Cell’ -> ‘Run Cell’を実行すると、このように結果が表示される。
[画像のクリックで拡大表示]
図14●通過したパケット量を取得してグラフを表示
「check_junos_traffic(junos_ip_s)」というセルを選択して実行した結果。
[画像のクリックで拡大表示]

 このようにスクリプトを埋め込んだ手順書を作成しておくことで、定型的な処理を、人間による結果の判断を挟みつつ、ステップ単位で実施できる。画像を埋め込んだり、REST API経由で取得した値から表やグラフを生成したりすることもできる。必要な情報をすべて自動で取得し、人間は確認と判断だけを行えばよい。

自動化の未来像:
完全自律型ネットワークの実現へ

 ここまで紹介してきた自動化ツールは、それぞれ特定の業務を自動化するのに有効なものだ。これらを運用の一部に取り入れるだけでも、運用負荷をかなり低減できる。そこからもう一歩自動化を進め、業務の自動化の比率を上げるには、複数のツールの連携が重要になる。

 ツール間の連携がない場合を図15上に示した。ネットワーク管理者がすべてのツールの操作方法を習得しなければならず、作業の負荷も高い。

図15●自動化の比率を上げるには複数のツールの連携が重要
ツール間の連携がない場合にはネットワーク管理者が作業の中核になり、各ツールを操作、実行する形になる。管理者がすべてのツールの操作方法を習得しなければならず、オペレーションの負荷が高まる可能性がある。一方、ツール間の連携がある場合は、ある一つの作業をするだけで、業務フローを実行できる。直接操作するツールの数が減り、工数を削減できる。
[画像のクリックで拡大表示]

 一方、ツール間の連携がある場合は図15下のようになる。ある一つの作業をするだけで、業務フローが自動的に進んでいく。管理者は必要に応じて確認を行うだけでいい。これにより、直接操作するツールの数が減り、工数を削減できる。

 より細かい業務分業も可能だ。通信事業者のサービスオーダーの作業を例に考えてみよう(図16)。従来は、設定ファイル作成から機器追加、確認までをオペレーターが担当していた。自動化やツール連携を導入すると、手順が整理されるため、図に示したような「サービスオーダーチーム」と「オペレーションチーム」の分業が可能になる。

図16●通信事業者のサービスオーダー作業を自動化するフローの例
ユーザーからのオーダーをサービスオペレーターが入力するところからフローが始まる。オペレーションチームは、予備試験の結果として生成された設定ファイルを実機に適用できるかどうかを送信されてきたレポートから判断し、承認するだけで済む。ネットワーク機器にログインする必要すらない。
[画像のクリックで拡大表示]

 このフローでは、オペレーションチームは予備試験の結果として生成された設定ファイルを実機に設定できるかどうかを送信されてきたレポートから判断し、承認するだけだ。ネットワーク機器にログインする必要すらない。

完全自動化に向けたステップ

 最後に、未来のネットワーク自動化について考えてみよう。究極的には、人が何も行わなくても最適なインフラを常に利用できる自律型のネットワークが理想だ。それを実現するまでにはいくつかのステップがある(図17)。

図17●完全自律型ネットワークを実現するまでのステップ
完全に自律的に動作するネットワークを実現するには、このようなステップを踏む必要がある。
[画像のクリックで拡大表示]

 ステップ1では作業の一部を自動化する。設定ファイルの自動作成など単一の操作を支援する。ステップ2は継続的なネットワーク自動化。自動化できる範囲を広げ、各フェーズの自動化を行う。ステップ3がプロセスの自動化。自動化をフレームワーク化し、単一の操作だけでなく業務フローも含めてシステム化する。ステップ4は人工知能(AI)や機械学習の活用。ステップ5で完全に自動化されたネットワークになる。

▼四つのレイヤーに分類できる
「オーケストレーション」は、仮想ネットワークを用いてITサービス全体を管理するレイヤー。「SDN/ネットワーク仮想化」のレイヤーには、仮想ネットワークを作成して管理を自動化する技術がある。
▼Ansible
オープンソースの構成管理ツールの一つ。PuppetやChefといった他の構成管理ツールは操作する機器にソフトウエアモジュールを追加する必要があるのに対し、エージェントレスアーキテクチャを採用しているため、機器にソフトウエアモジュールをインストールする必要がない。詳細な使い方は後述。
▼ZTP
Zero Touch Provisioningの略。詳細は後述。
▼設定フェーズ
その後の運用・保守フェーズにも多様な自動化ツールが存在する。従来のネットワーク運用管理でも使われてきた「SYSLOG」や「SNMP」は、自動化処理を開始するきっかけ(トリガー)として利用できる。
▼VLAN
Virtual LANの略。
▼Python
広く使われているプログラミング言語の一つ。記述したプログラム(スクリプト)をコンパイルせずにそのまま実行できる。最近は機械学習などのデータサイエンスの分野でよく使われている。
▼ファイルサーバー
TFTP、FTP、HTTPといったプロトコルに対応したもの。
▼構成管理ツール
複数のサーバーやネットワークといったリソースを統一的に管理することを目的としたソフトウエア。ネットワーク分野で構成管理ツールを利用することで、機器ごとの設定ファイルの生成から機器への設定ファイル適用までを自動化できる。主なものにAnsible、Puppet、Chefなどがある。
▼サービスオーダー
ユーザーが通信事業者などに対して行う新規申し込みや設定変更の依頼のこと。
▼YAML
YAML Ain't a Markup Languageの略。構造化されたデータを表現するためのフォーマットの一つ。インデントを使ってデータの階層構造を表す。
▼XML
eXtensible Markup Languageの略。構造化されたデータを表現するためのフォーマットの一つ。タグを使ってデータの階層構造を表す。
▼Playbookファイル
Ansibleで実行するタスク(作業)を記述するファイル。
▼パラメーターファイル
テンプレートに適用して設定ファイルを生成するための具体的な値を記述するファイル。
▼Jinja2
Pythonでよく使われるテンプレートエンジンおよびそのテンプレートの形式。
▼リーフスイッチ
ネットワークを利用する機器を直接収容するスイッチ。リーフは「葉」を意味する。
▼スパインスイッチ
ネットワークのバックボーンを構成するスイッチ。スパインは「幹」を意味する。
▼IPファブリックネットワーク
ルーティングプロトコルを利用してリーフスパイン構成で冗長化を行うネットワーク構成のこと。データセンターなどでよく使われる。
▼REST API
RESTはREpresentational State Transferの略。APIは Application Programming Interfaceの略。REST APIは、HTTPのメソッドを使って呼び出せるAPIを指す。
▼自動化やツール連携を導入すると
このように、あるきっかけから作業を自動化することを「イベントドリブンの自動化」と呼ぶ。
▼業務フローも含めてシステム化
こうした自動化を「DevOps」や「Infrastructure as Code」と呼ぶこともある。
出典:日経NETWORK 2017年11月号 pp.38-47
記事は執筆時の情報に基づいており、現在では異なる場合があります。