こんにちは。
今回は Automation and Programmability 基礎（第1回） として、まずはこの分野の全体概要を学習しました。
正直なところ、今回は初見のワードがかなり多く、少し混乱気味です。
いつものように GenSpark に3枚ほどのスライドへ整理してもらい、それを見ながらブログ記事として自分の中に落とし込もうとしているのですが、まだすぐに頭へ入ってくる感じではありません。
この分野については、一度で理解しきろうとするよりも、何度も繰り返し見直しながら少しずつ慣れていく必要がありそうです。今回もまずは「全体をざっくりつかむこと」を目標に整理してみました。
Automation and Programmability とは何か
Automation and Programmability は、ネットワーク機器を人が1台ずつ手で設定・確認していくのではなく、より自動的に、より一貫した形で管理していく考え方です。
Cisco でも、ネットワークオートメーションを「設定、管理、テスト、展開、運用を自動化すること」と説明しており、日々の繰り返し作業を減らしながら、ネットワーク全体の運用品質を上げていく方向性が示されています。
今回の学習では、Automation は単に「作業を楽にする」という意味だけではなく、同じ品質でそろえるための考え方でもあると理解しました。
人が手で触る回数が増えるほど、設定ミスやばらつきが起きやすくなります。だからこそ、自動化は効率化だけでなく、安定した運用のためにも重要です。
Traditional networks と controller-based networking の違い
従来型のネットワーク、つまり Traditional networks では、各機器を個別に設定し、必要な変更も機器ごとに順番に入れていくのが基本でした。
それに対して controller-based networking では、中央にあるコントローラーを通してまとめて管理する考え方が出てきます。
これにより変更をより速く、より一貫した形で反映しやすくなり、運用のばらつきを抑えやすくなります。
今回のスライドでも、Traditional は「各機器を個別管理」、controller-based は「中央からまとめて管理」と整理されていて、まずはこの違いをつかむことが大切だと感じました。
Software-defined architecture の考え方
この分野で最初に少しややこしく感じたのが、Underlay / Overlay / Fabric という言葉です。
ただ、意味をシンプルにすると、Underlay は物理ネットワークや IP 到達性を支える土台、Overlay はその土台の上に作る論理的なネットワーク、Fabric はそれら全体を一体として扱う仕組みや構成、という理解でよさそうです。
Control plane と Data plane の分離
次に出てきたのが、Control plane と Data plane という考え方です。
これは難しく見えますが、今回の学習ではかなり分かりやすく、Control plane は頭脳、Data plane は手足 と捉える整理がされていました。
Control plane は「どこへどう転送するかを決める側」、Data plane は「実際にパケットを転送する側」です。
つまり、考える役割と動かす役割を分けて見ることで、ネットワークの動き方を整理しやすくしているのだと理解しました。
Northbound API と Southbound API
ここも最初はかなり分かりにくかった部分ですが、まずはAPI はやり取りの窓口と考えると少し入りやすくなります。
今回の学習では、Northbound API はコントローラーを“使う側”の窓口、Southbound API はコントローラーが“機器と話す側”の窓口 と整理しました。
厳密な実装は製品によって違っても、まずは「上から使う入口」と「下の機器へ指示する入口」というイメージを持てば、かなり分かりやすくなると思います。
REST-based API はどこまで覚えるか
REST API も、最初は難しそうに見える言葉のひとつでした。
ただ、今回の段階では 「ネットワーク機器やコントローラーを、プログラムから扱うための入口」 と理解しておけば十分だと感じています。
あわせて覚えておきたいのが CRUD です。
これは Create（作成） / Read（読み取り） / Update（更新） / Delete（削除） の頭文字で、API でよく出てくる基本操作のまとまりです。
今回の学習では、「まずはこの4つの意味が分かれば十分」という感覚で整理するのがよさそうでした。
JSON とは何か
JSON も、この分野では頻繁に見かける言葉です。
今回の理解としては、JSON は設定や情報を、プログラムが読みやすい形で表したデータ形式と考えればよさそうです。
人が文章を読むためのものというより、機械が読み書きしやすい形でデータを持たせるための形式、というイメージで覚えておきたいと思います。
Ansible と Terraform は何者か
今回の中でも特に「名前だけ聞いたことはあるけれど、違いが曖昧だった」のが Ansible と Terraform でした。
Ansible はリモートシステムの管理を自動化し、望ましい状態を保つための仕組み となります。
今回の学習の文脈では、構成や設定をまとめて適用しやすくする代表的な自動化手段 と理解すると入りやすいです。
一方で Terraform は、Infrastructure as Code のツール であり、クラウドやオンプレミスのリソースをコードで定義し、作成・変更・管理していくための仕組みです。
つまり、Terraform は「インフラそのものを定義して管理する」考え方が強く、Ansible は「設定をまとめて適用する」方向で理解すると、今の段階では区別しやすいと感じました。
今回の学習で感じたこと
今回の分野は、VLAN や ACL のように「その場で設定して結果を見る」タイプの内容と比べると、かなり概念が先に来る印象でした。
そのため、単語を読んだだけではすぐにイメージしづらく、最初は混乱して当然だと思います。
ただ、今回の3枚のスライドに整理してみたことで、
「個別管理から中央管理へ」
「土台と論理を分けて考える」
「機器をプログラムから扱う入口が API」
「JSON はデータ形式、Ansible と Terraform は自動化の道具」
というように、少しずつ位置関係が見えてきました。
まだ完全に理解できたとは言えませんが、まずは全体像をつかむ第一歩にはなったと感じています。
コメント