はじめに
『ネットワーク自動化とプログラマビリティ』(Jason Edelman、Scott S. Lowe、Matt Oswalt 著/土屋 太二 監訳/牧野 聡 訳、オライリー・ジャパン)を読みました。
この記事は、本書全体を設計・アーキテクチャの視点から振り返る書評です。
ネットワーク機器の操作に詳しくない方でも、「運用を自動化するとき、設計として何を決めておくべきか」という観点で読めるようにまとめています。
本記事は書評であり、本書の内容を再掲するものではありません。
詳細なコードや図は、ぜひ書籍で確認してください。
本書の概要
本書は、ネットワーク運用を「手で打つコマンド」から「ソフトウェアとして扱う対象」へ変えるための基礎スキルを、一冊にまとめたものです。
| 項目 | 内容 |
|---|---|
| 対象 | ネットワークエンジニア、システム管理者、ソフトウェア開発者 |
| 前提 | プログラミング経験は不要(オープンな姿勢があれば十分) |
| 構成 | 全11章+付録2本(Linux応用、NAPALM) |
| 特徴 | トピックごとに独立しており、1〜3章を読めば拾い読みも可能 |
本書が扱うのは「特定ツールの使い方」だけではありません。
APIとデータ、テンプレート、バージョン管理、CI、そしてチーム文化までを一続きの流れとして描いています。
全体像
本書の各章を、ひとつのパイプラインとして並べるとこうなります。
章の並びは、おおむねこの矢印に沿っています。
個別の技術を学ぶ順序と、運用プロセスとして組み上げる順序がきれいに対応している点が、本書の読みやすさにつながっていると感じました。
各章の要点
1章 ネットワーク業界の動向
SDN(Software Defined Networking)が登場した経緯を整理する章です。
OpenFlowによるコントロールプレーンとデータプレーンの分離から始まり、NFV、仮想スイッチ、ネットワーク仮想化、ベアメタルスイッチ、SD-WANなど、SDNと呼ばれてきた潮流を並べています。
印象的だったのは、SDNを無理に一つの定義へ押し込めていない点です。
代わりに、各潮流に共通する目標を示しています。
それは、ソフトウェアの原則を持ち込み、運用者に制御力と即応性と選択肢を与えることです。
設計の観点では、「機器ごとに閉じたCLI」から「プログラムから触れるインタフェース」へ重心が移る、という見取り図を最初に得られます。
2章 ネットワークの自動化
なぜ自動化するのかを、速度以外の理由から説明する章です。
本書は、次の3つを価値として挙げています。
- シンプルなアーキテクチャーに近づく(一度きりの特殊な設定を減らす)
- 結果が予測可能になる(人為ミスの余地を減らす)
- ビジネスの即応性が上がる
自動化の対象も、設定の投入だけではありません。
プロビジョニング、データ収集、移行、構成管理、コンプライアンス確認、レポート作成、トラブルシューティングまで広く扱います。
特に参考になったのは、小さく始める進め方です。
読み取り専用の作業(データ取得、監視、設定生成)から着手し、リスクの低い領域で経験を積んでから書き込み系へ進む、という順序が提案されています。
3章 Linux
ネットワーク機器のOSにLinuxが使われ、自動化ツールもLinux上で動く以上、Linuxの基礎は必須だという位置づけの章です。
歴史、ディストリビューションの系統(Red Hat系とDebian系)、シェルの基本操作、ファイル権限、プロセスとデーモンの管理、ネットワーク設定の基礎を扱います。
ネットワークエンジニア向けの入門として、範囲が絞られているのがよいところです。
網羅を目指さず、「自動化に必要な最低限」を示す姿勢は、本書全体に共通しています。
4章 ネットワークとPython
Pythonの基礎を、ネットワークエンジニアの目線で解説する章です。
データ型、条件分岐、ループ、関数、ファイル操作、モジュール、クラスまでを扱います。
Pythonを推す理由は、次のように整理されていました。
- 動的型付けで、すぐに書き始められる
- 英語に近い読みやすさがある
- ベンダーやコミュニティ製のライブラリが豊富
「すべてのネットワークエンジニアはソフトウェア開発者になるべきか」という問いには、はっきり「ノー」と答えています。
一方で、スクリプトの基本的な読み書きは身につけるべきだという立場です。
この線引きは現実的で、読者の心理的ハードルを下げてくれます。
5章 データフォーマットとデータモデル
JSON、XML、YAMLといったデータフォーマットと、データの構造や制約を定めるデータモデルを区別して説明する章です。
ここでの整理は、設計の観点でとても重要だと感じました。
| 概念 | 役割 |
|---|---|
| データフォーマット | データをどう文字列にエンコードするか(JSON、XML、YAML) |
| データモデル | データがどんな構造と制約を持つか(XSD、JSON Schema、YANG) |
XSDはXML専用、JSON SchemaはJSON専用です。
一方、YANGはネットワーク向けのモデリング言語で、エンコーディングに依存しません。
同じモデルをXMLでもJSONでも表現できるため、後述のNETCONFやRESTCONFと相性がよい、と説明されています。
6章 ネットワーク設定のテンプレート
Jinjaを中心に、設定をテンプレートと変数に分離する方法を扱う章です。
テンプレートが成立する要素は、テンプレート本体、埋め込むデータ、両者を結ぶ仕組みの3つです。
章末のまとめでは、実践上の注意が挙げられています。
- テンプレートはシンプルに保つ
- 重複は継承で避ける
- 設定の構文と実データを分離する
- テンプレートはバージョン管理する
私なりに、考え方を小さなコードで確認してみました。
以下は本書の例とは別に用意した、動作確認用の最小構成です。
hostname: edge-sw01
domain_name: example.net
vlans:
- id: 110
name: users
- id: 120
name: printers
hostname {{ hostname }}
ip domain-name {{ domain_name }}
{% for vlan in vlans %}
vlan {{ vlan.id }}
name {{ vlan.name }}
{% endfor %}
import yaml
from jinja2 import Environment, FileSystemLoader
with open("vars.yml") as f:
data = yaml.safe_load(f)
env = Environment(loader=FileSystemLoader("."), trim_blocks=True)
print(env.get_template("switch.j2").render(**data))
VLANを増やしたいときは、vars.yml に1件追記するだけです。
テンプレートは触らないので、変更の影響範囲が明確になります。
この「データと構文の分離」が、後続のすべての章の土台になっています。
7章 ネットワークAPI
ネットワーク機器のAPIを実際に触る章です。
大きく、HTTPベースのAPI(RESTfulとそれ以外)と、NETCONFベースのAPIに分けて解説しています。
RESTful APIについては、「Webサイトを見るときのHTTP GETと同じ仕組み」という説明がわかりやすいです。
違いは、返ってくるものがHTMLではなく、JSONやXMLといった構造化データである点です。
あわせて、次のPythonライブラリが紹介されています。
-
requests:HTTPベースのAPI向け -
ncclient:NETCONF向け -
netmiko:SSH経由のCLI操作向け
APIの実装はベンダーごとに異なるため、共通点と独自点の両方を知ることが重要だと述べられています。
マルチベンダー環境を前提にした実用的な姿勢です。
8章 Gitによるソースコード管理
スクリプトやテンプレートが増えると、その管理自体が課題になります。
この章はGitを題材に、バージョン管理の価値を説明します。
本書が挙げるメリットは次の3つです。
- 変更の追跡(何が変わったか)
- 説明責任(誰が変えたか)
- プロセスとワークフローの強制(レビューやテストを経由させる)
対象はソースコードに限りません。
機器のコンフィグレーションファイルやドキュメントも、同じ仕組みで管理できます。
後半ではブランチ、フォーク、プルリクエストといった共同作業の流れを扱います。
ネットワーク運用の変更管理を、開発チームのレビュー文化に接続する橋渡しになっています。
9章 自動化ツール
Ansible、Salt、StackStormの3つを取り上げる章です。
個別の使い方に入る前に、自動化ツールを比較する軸が示されています。
| 比較軸 | 選択肢 |
|---|---|
| 実行主体 | エージェントベース/エージェントレス |
| 構成 | 集中型/分散型 |
| プロトコル | 独自/標準(SSHなど) |
| 記述方法 | 独自DSL/標準フォーマット+汎用言語 |
| 拡張性 | スクリプト言語で拡張できるか |
| 動作モデル | プッシュ型/プル型/イベント駆動型 |
ネットワーク機器ではエージェントを動かせない場合が多いため、エージェントレスでSSHを使うツールが適用しやすい、という指摘は実務的です。
StackStormについては、センサー、ルール、アクション、ワークフロー、パックといった構成要素と、マイクロサービス的なアーキテクチャーが説明されています。
たとえば「特定のイベントを検知したら設定を投入する」といった、イベント駆動の自動化を表現できる点が特徴です。
10章 継続的インテグレーション
ツールの話から、プロセスの話へ視点を切り替える章です。
本書の根幹にある考え方は、ネットワーク操作の工程から「人間の手作業」を取り除くことだと説明されます。
ただしそれは、人間の関与をなくすことではありません。
人は確認、改善、効率化といった上流の仕事に集中する、という整理です。
最初に出てくる「Simple Is Better」は、設計者として強く共感しました。
自動化で最も重要なのは、プログラミングでもツールでもなく、自動化しやすいネットワーク設計だという主張です。
サービスごとの差異を減らし、均質なものをデプロイできるように設計し直す必要があります。
後半では、テレメトリによる継続的な監視や、分散テストツールによる能動的なテストが紹介されます。
フェイルオーバーテストが軽視されがちな点にも触れ、変更の前後で定量的に比較する考え方を示しています。
11章 ネットワーク自動化に取り組むための文化の構築
技術以外の側面を扱う章です。
次の3つのトピックで構成されています。
- 組織的な戦略と柔軟性
- 失敗の許容
- スキルと教育
自動化は「かっこいいから」ではなく、組織にとって定量的で目に見えるメリットを示して進めるべきだ、と述べられています。
また、「自動化はエンジニアの仕事を奪うのか」という不安にも正面から答えています。
自動化は少しずつ進むもので、不要になる業務がある一方、新しい課題と機会も生まれる、という立場です。
まとめでは、DevOpsは技術・プロセス・文化の3つが揃って初めて機能する、と強調されています。
付録A Linuxにおける高度なネットワーク操作
macvlanインタフェース、仮想マシンのネットワーク、ネットワーク名前空間、コンテナのネットワーク、Open vSwitch(OVS)を扱います。
いずれも単独で一冊になる内容のため、位置づけと基本操作に絞った構成です。
コンテナや仮想化基盤の裏側を理解する足がかりになります。
付録B NAPALM
マルチベンダー対応のPythonライブラリ、NAPALMの解説です。
設定管理と情報取得の2つの機能に絞って紹介されています。
設計の観点で面白いのは、宣言的な構成管理の考え方です。
「最終的にどういう設定であってほしいか」だけを渡し、差分の計算は機器側の機能に任せる、というアプローチです。
設定全体を置き換える方法と、部分的に取り込む方法の2通りが示されています。
StackStormとの連携にも触れられており、9章とつながります。
設計者として学んだこと
本書を通読して、設計上の学びを5つに整理しました。
- 自動化は「設計の前提」です。 後から足すと、例外だらけの設定が障害になります。最初から標準化を前提にするのが、結局は最も安くつきます。
- データと構文を分けます。 この考え方は、設定駆動のシステム設計全般に通じます。変更が「データの更新」で済むと、レビューもテストも簡単になります。
- 変更履歴は設計資産です。 誰が、いつ、なぜ変えたかが残る構造は、運用の再現性を支える基盤です。
- 小さく、読み取りから始めます。 読み取り専用の自動化は、失敗しても被害が小さいという利点があります。
- 技術・プロセス・文化を同時に設計します。 ツールを入れるだけでは定着しません。レビューの流れや失敗を許容する姿勢まで含めて、初めてアーキテクチャーと呼べます。
読んでいて気になった点
良い本ですが、読む際に知っておくとよい点もあります。
- ツールやOSのバージョンは執筆時点のものです。たとえばCentOSの扱いは、監訳時点の状況が訳注で補われていますが、現在の環境では確認が必要です。
- Pythonの章は入門レベルです。すでにPythonに慣れている方は、読み飛ばしても問題ありません。
- 付録は広く浅く触れる構成です。深掘りしたい場合は、別の専門書が必要になります。
どんな人におすすめか
次のような方に向いています。
- 手作業のネットワーク運用を、仕組みで改善したい方
- インフラの自動化を、設計の観点から体系的に学びたい方
- ネットワークとソフトウェア開発の両方の言葉を知りたい方
- 自動化を組織に導入する進め方で悩んでいる方
一方で、特定のツールの詳細な手順書を求めている方には、物足りない可能性があります。
本書は、全体像と考え方を掴むための本です。
おわりに
本書の核心は、自動化を「速さのための道具」ではなく、「予測可能で再現できる運用をつくる設計」として捉え直している点にあると思います。
ツールは入れ替わります。
しかし、データと構文の分離、変更履歴の管理、小さく始める姿勢、そして文化づくりという考え方は、長く使えます。
ネットワークに限らず、インフラや運用の設計に関わる方にとって、視野を広げてくれる一冊でした。
参考
-
『ネットワーク自動化とプログラマビリティ ―次世代ネットワークエンジニアのためのスキルセット』Jason Edelman、Scott S. Lowe、Matt Oswalt 著、土屋 太二 監訳、牧野 聡 訳、オライリー・ジャパン、2022年 ↩