ネットワーク自動化とコントローラベースネットワーキング

ネットワーク自動化とは何か、なぜ必要なのか

従来、ネットワーク機器（スイッチ・ルータ・ファイアウォール等）の設定は、管理者がSSH等でログインし、1台ずつCLI（コマンドラインインターフェイス）でコマンドを打ち込んで行うのが一般的でした。この方法は、ネットワークの規模が小さいうちは問題になりませんが、機器の台数が数十台・数百台と増えるにつれて、次のような課題が顕在化します。

• 作業時間の増大：同じ設定変更（例：VLANの追加、ACLの更新）を機器の台数分だけ繰り返す必要があり、時間がかかります。
• 設定ミスのリスク：手作業でのコピー＆ペーストやタイプミスにより、機器ごとに設定内容がわずかに食い違う「構成ドリフト（configuration drift）」が発生しやすくなります。
• 再現性・監査性の低さ：「いつ・誰が・何を変更したか」を後から正確に追跡することが難しく、変更履歴がテキストファイルやメモに散在しがちです。

ネットワーク自動化（network automation）とは、こうした設定・監視・運用作業を、スクリプトやツールを使って自動的に実行できるようにする取り組み全般を指します^{本記事シリーズの別記事で扱うAnsible・Puppet・Chef（設定管理ツール）や、REST API・JSON（自動化プログラムがネットワーク機器・コントローラとやり取りするための技術）は、いずれもこの「ネットワーク自動化」を実現するための代表的な手段です。[1]}。

自動化がネットワーク管理に与える主な影響

• 一貫性（consistency）の向上：同じ処理をプログラム・テンプレートとして定義しておけば、対象の台数に関わらず全く同じ内容が適用されます。手作業に起因する設定差異を減らせます。
• 作業速度の向上：数百台規模の一括設定変更も、スクリプトを1回実行するだけで完了させられます。
• 人的ミスの削減：定型的な操作を自動化することで、タイプミスや操作手順の抜け漏れといったヒューマンエラーの発生機会そのものを減らせます。
• 構成ドリフトの検知：現在の機器の設定状態と、あるべき設定（定義済みの状態）を自動的に比較し、差分（ドリフト）を検出できます。
• 再現性・監査性の向上：設定変更の内容をコード（テキスト）として管理する^{この考え方は一般に「Infrastructure as Code（IaC）」と呼ばれます。設定変更の内容がテキストファイルとして残るため、バージョン管理システム（Gitなど）と組み合わせることで、変更履歴の追跡や差分の確認が容易になります。[2]}ことで、変更履歴の追跡やレビューがしやすくなります。

一方で、自動化はあくまで「手段」であり、自動化スクリプト自体に誤りがあれば、その誤りも一貫して・高速に・大量の機器へ適用されてしまうという裏返しのリスクもあります。自動化を導入すれば運用上の課題がすべて自動的に解消される、というものではない点には注意が必要です。

従来型ネットワークとコントローラベースネットワークの比較

従来型（デバイス中心）のネットワーク管理

従来型のネットワークでは、スイッチやルータなど機器の1台1台が、それぞれ独立して自分自身の設定・状態を保持し、動作を決定します。管理者は、変更したい機器へ個別にログイン（CLI・コンソール等）して設定を行います。ルーティングプロトコル（OSPF等）による経路計算も、各ルータがそれぞれ自分の持つ情報をもとに個別に行います。

この方式は、機器単体としてはシンプルで実績のある方式ですが、ネットワーク全体を横断した一貫性のある変更や、ネットワーク全体を俯瞰した状況把握を行うには、管理者自身が各機器の情報を個別に集めて突き合わせる必要があります。

コントローラベースのネットワーク管理

コントローラベースネットワーキング（controller-based networking）では、複数のネットワーク機器を集中的に管理するコントローラ（controller）と呼ばれるソフトウェア（多くの場合サーバー上で動作する専用アプリケーション）を導入します。管理者はコントローラに対して「ネットワーク全体としてどうあってほしいか」という意図（ポリシー）を伝え、コントローラがその意図を実現するために必要な設定を、配下の各機器へ自動的に配布します。

管理者から見ると、機器を1台ずつ意識して設定するのではなく、コントローラという単一の窓口（しばしば「シングルペインオブグラス」とも呼ばれます）を通じてネットワーク全体を管理できるようになる点が、従来型との最も大きな違いです。

なお、コントローラベースのアーキテクチャを採用しても、実際にパケットを転送する処理（データプレーン、後述）自体は、従来型と同じく各ネットワーク機器上で行われる点は変わりません。「コントローラベース＝すべての処理がコントローラに移る」という理解は誤りです。あくまで管理・制御に関する部分が集中化されるという違いです。

コントローラベースのソフトウェア定義型アーキテクチャ

コントローラベースネットワーキングを実現する代表的な考え方がソフトウェア定義ネットワーキング（SDN：Software-Defined Networking）です。SDNのアーキテクチャは、一般に次の3つの機能（プレーン）に分けて説明されます。

3つのプレーン

• データプレーン（data plane、転送プレーンとも呼ばれます）：実際にパケットを受信し、宛先へ転送する処理を行う層です。スイッチ・ルータのハードウェア（ASIC等）がこの役割を担い、コントローラベースのアーキテクチャでも各機器上に分散したまま残ります。
• コントロールプレーン（control plane）：どの宛先へどう転送すべきか（経路情報等）を決定する層です。従来型ネットワークでは各機器がそれぞれ自分自身のコントロールプレーンを持ちますが、SDNではこの機能の全部または一部を、機器から切り離してコントローラへ集中させます。
• マネジメントプレーン（management plane）：機器の設定・監視・管理を行うための層です。SSHでのCLIアクセスやSNMPによる監視などが該当し、コントローラベースのアーキテクチャでは、この層の機能の一部または多くをコントローラで集約できます。ただし、各機器への直接的な管理アクセスが残る場合もあります。

サウスバウンドAPIとノースバウンドAPI

コントローラは、上位のアプリケーションと下位のネットワーク機器の両方とやり取りする「仲介役」であり、それぞれとのインターフェイス（API）には別々の名前が付いています。

• サウスバウンドAPI（southbound API、南向きAPI）：コントローラと、配下のネットワーク機器との間のインターフェイスです。コントローラはこのAPIを通じて、各機器へ設定を配布したり、状態を収集したりします^{サウスバウンドの具体的なプロトコルは実装により異なり、OpenFlow、NETCONF、RESTCONFなどが用いられます。CCNA 200-301の出題範囲ではプロトコルの詳細な比較までは求められていません。本記事でも詳細な個別プロトコルの比較には立ち入りません。[3]}。
• ノースバウンドAPI（northbound API、北向きAPI）：コントローラと、その上で動く業務アプリケーション（自動化スクリプト、監視ツール、オーケストレーションツール等）との間のインターフェイスです。一般にREST APIの形で提供され、アプリケーション側はコントローラが集約したネットワーク全体の情報を、必要な部分だけ取り出して利用できます（REST APIそのものの詳しい特徴は別記事で解説します）。

「サウス（南）」「ノース（北）」という呼び方は、ネットワーク構成図を描く際に、下（南）に機器、上（北）にアプリケーションを配置する慣習に由来しており、地理的な意味は持ちません。コントローラを中心に、下向き（機器方向）のAPIか、上向き（アプリケーション方向）のAPIかを区別するための名称です。

Ciscoの代表的なコントローラ製品の例

CCNAの出題範囲は特定製品の細かい操作方法を問うものではありませんが、「コントローラベースアーキテクチャが実際にどのような製品で提供されているか」のイメージを持つ助けとして、代表的な例を挙げます。

• Cisco Catalyst Center（旧Cisco DNA Center）：企業のキャンパスネットワーク（オフィスや拠点内のスイッチ・ワイヤレスLAN等）を対象としたコントローラ製品です。
• Cisco APIC（Application Policy Infrastructure Controller）：データセンターネットワーク向けのSDNソリューションであるCisco ACI（Application Centric Infrastructure）のコントローラです。
• Cisco Meraki ダッシュボード：クラウド上でホストされたコントローラ（ダッシュボード）を通じて、スイッチ・アクセスポイント・セキュリティ機器等を一元管理する、クラウド管理型の製品です。

これらの製品ごとの詳細な機能・設定方法はCCNA 200-301の出題範囲外のため、本記事では製品名の紹介にとどめます。