前回のおさらい
NW機器には様々な「違い」があり、その違いが組み合わさって自動化のコストを押し上げています。今回は、この違いを吸収しようとする試みがなぜ思うようにいかないのかを見ていきます。
図1: 連載マップ
この回の要点
- 機器ごとの違いを吸収する製品や仕組みはありますが、違いを吸収するほど複雑になり、現場で使いこなすのが難しくなります。間に道具を挟むことで、急ぎの作業や実機とデータの整合にも手間がかかるようになります。
- 製品を買うとしても自分たちの環境向けの作り込みは残り、自作するならかなり基礎的な部品から作ることになります。
- どちらを選んでも、規模のない環境では割に合いにくい構造があります。
困る場面
マルチベンダで構成されるNWを統一的に管理するために、共通の管理システムを導入したとします。この管理システムは機器ごとの違いを吸収した共通のデータモデルを持ち、NWの設定を表現します。これでベンダごとの違いを気にせず、統一されたオペレーションでNWを制御できるようになるはずです。
ところが、しばらくたっても現場の担当者はこのシステムを使わず、これまでどおり機器に直接ログインして作業しています。管理システムのデータモデルは複雑で自分が普段見ているコンフィグとの対応がわかりにくい。ちょっとした変更をするにもモデルの仕様を調べる必要があって手間がかかる。障害対応のような急ぎの作業で管理システムを経由している余裕はない、といった声も出ます。結果として、管理システムを使いこなせる一部の人に作業が集中し、その人たちがいなくなると管理システムがブラックボックス化してしまいます。
抽象化のジレンマ
違いを吸収するには抽象度を上げる必要がある
機器ごとの違いを吸収するには、個々の機器の設定よりも一段上の抽象的な表現を用意し、そこから各機器の設定を生成する必要があります。
抽象度を上げればより多くの違いを吸収できます。しかし、前回見たように、違いは書き方だけでなく処理の順番にまで及んでいます。そこまで吸収しようとすると「この機器ではこう扱い、あの機器ではこう扱う」という変換のロジックが機器ごとに必要になります。モデルそのものは簡潔でも、モデルと変換ロジックを合わせた全体は複雑になっていきます。
入力は簡単になっても、何が変わるかわからない
同じ接続を、機器設定・共通モデル・サービス要求という粒度の違う3つの形で表してみます。なお、③から①を生成するにはアドレスやポートの割当情報などを別途参照する必要があります。
① 機器コンフィグ (Junos)
set interfaces ge-0/0/1 description "to-core"
set interfaces ge-0/0/1 unit 0 family inet address 192.0.2.1/24
② ベンダ中立のデータモデル (OpenConfig 形式の例、一部省略)
{
"openconfig-interfaces:interfaces": {
"interface": [{
"name": "ge-0/0/1",
"config": { "name": "ge-0/0/1", "description": "to-core" },
"subinterfaces": {
"subinterface": [{
"index": 0,
"config": { "index": 0 },
"openconfig-if-ip:ipv4": {
"addresses": {
"address": [{
"ip": "192.0.2.1",
"config": { "ip": "192.0.2.1", "prefix-length": 24 }
}]
}
}
}]
}
}]
}
}
③ サービスモデル (架空の例)
service: core-uplink
site: tokyo-01
peer: core-01
bandwidth: 10G
①機器コンフィグはNWエンジニアなら一目で意味がわかります。これは機器ごとに異なります。②ベンダ中立モデルは機器の違いを吸収できますが、同じ内容を表すのに階層が深くなり、機械処理のためのキーや構造が増えているため、人には読みにくいと感じるでしょう。③サービスモデルは「何をしたいか」だけを書くので短くなりますが、そこから各機器の設定がどう生成されるかはモデルの外にあるロジックを見ないとわかりません。
現場の担当者が知りたいのは、この入力で、どの機器の何が変わるかです。②は階層が深くて追いにくく、③は短いぶん中で何が起きるかが見えません。どちらも、入力から実機の変更までの対応を追えなければ、変更してよいかを判断できません。そのデータによる操作に責任を負わなければいけないのに、見てもわからないデータを扱いたいと思う人はいません。結局、内部の仕組みを理解している一部の人に作業が集まり、冒頭の場面のようになります。
抽象化を現場で使える形にするには、共通モデルだけでなく、機器設定との対応関係、差分の表示、うまくいかないときの調べ方まで用意する必要があります。違いを吸収する仕組みを作るコストに加えて、それを現場で使える形にするコストもかかるわけです。
急ぐときは直接触りたくなる
抽象化した仕組みを使うと、運用者は機器を直接操作するのではなく、管理システムや自動化ツール、コントローラといった道具を通して、間接的に機器を操作することになります。計画的な変更ならそれでも構いません。しかし、障害対応のように急いでいて、しかも「いまどうなっているか」を見てからアクションを決める作業(➡️第2回)では、この間接的な操作が回り道に見えます。目の前の機器にログインすれば1行で済む変更のために、モデルを調べ、入力を作り、生成された設定を確かめる余裕はありません。さらに、間に入った道具そのものが止まったら、機器に手が出せなくなるのではないか、という心配も出てきます。運用者から見ると、障害が起きうる場所が機器に加えて道具の分だけ増えたように見えてしまいます。
そのため、いざというときに機器を直接操作する逃げ道を残すことが多いと思います。ただ、道具を通さずに機器の設定を変えると、道具が持っているデータ(設計情報やインベントリ)と実機の設定がずれます。データを正とするなら、次に道具から設定を生成したときに直接入れた変更を上書きして消してしまうかもしれません。実機を正とするなら、道具のデータは実機を後から写したものになり、抽象化した意味が薄れます。どちらを正とするかを決めたうえで、実機の状態を集めてデータとの差分を確かめ、ずれを直す仕組みが必要になります。データは放っておけば現実からずれていきますが(➡️第3回)、道具と直接操作が併存するとそのずれは日々の運用の中で生まれ続けます。
図2: 道具と直接操作が併存すると、データと実機のずれが広がっていきます。
ずれたデータは信用されず、信用できないデータをもとにした道具は使われなくなります。使われなければデータの更新も止まり、ずれはさらに大きくなります1。冒頭の場面で管理システムがブラックボックスになっていったのは、読みにくさだけでなくこの循環のためでもあります。抽象化を現場で使える形にするコストには、急ぎの作業や道具の障害に備えた逃げ道と、その逃げ道が生むずれを埋める仕組みも含まれます。
ちょうどよい抽象度はあるか
だったら、読みやすさと吸収できる違いのバランスが取れた、ちょうどよい抽象度を選べばよいのでは、と考えたくなります。
問題は、その「ちょうどよい」が環境ごとに違うことです。どの抽象度がちょうどよいかは、どれだけの種類の機器を扱うか、どんな作業を自動化したいか、運用するエンジニアがどんな知識を持っているか…によって決まります。ある組織にとってちょうどよいモデルは、機器の構成が違う別の組織にとっては、吸収しきれない違いが残るモデルか、必要以上に複雑なモデルになります。
製品や OSS は、多くの組織に使ってもらうために作られるので、想定する機器や作業の範囲を広く取らざるを得ません。範囲を広く取れば抽象度は上がります。その結果、どの組織にとっても「自分たちには複雑すぎる」モデルになるリスクがあります。逆に、自分たちの環境に合わせてモデルを作ればちょうどよい抽象度を選べますが、そのモデルは自分たちにしか使えません。この点は➡️第8回で扱う悪循環につながっていきます。
Cisco NSO のような汎用の自動化基盤が強力である一方で「敷居が高い」と言われることがあるのは2、このジレンマの表れだと考えています。マルチベンダの違いを吸収できる柔軟さを持つ分、使いこなすためにはモデルとその仕組みを深く理解する必要があります。
買う場合: 共通管理製品の限界
では、違いを吸収する製品を買えばよいのでしょうか。製品を検討すると次のような限界に突き当たります。
- メーカー製品は自社機器中心: NW機器メーカーの管理製品は、基本的に自社の機器を対象にしています。他社の機器のサポートはないか、あっても限られます。
- サードパーティ製品は大規模顧客優先: 複数ベンダの機器を扱うサードパーティ製品もありますが、開発は世界規模で影響の大きい大口顧客の要望に沿って進みます。ワールドワイドで見たときにボリュームの小さい機器への対応(国内ベンダの機器など)は後回しになりがちです。
- 割高に見える: 製品は多くの機種と機能に対応していますが、自分たちが使うのはその一部です。使わない機能にもお金を払うことになり、オーバースペックに見えます。製品の価格からすると、ある程度大きな規模のNWでないと、費用対効果を見込みにくいのが実情です。
そして何より、製品が提供するのは、多くの場合「基礎的な自動化の土台」と「基本的な運用管理の機能」までです。その土台の上で、自分たちのNWの構造や使っている機器に合わせた具体的な自動化は、結局自分たちで作り込む必要があります。
図3: 買う場合も作る場合も、自分たちの環境向けの作り込みは残ります。
作る場合: 部品から積み上げる
それなら自分たちで作ろうとすると、今度は別の壁があります。
NW全体を対象にした自動化を作るには、コンフィグを解析するパーサ、コマンド出力を構造化するパーサ、トポロジを表すデータ構造といった基礎的な部品が必要です。ところが、こうした部品で多くの機器に対応し、広く使われているものは多くありません。結局、原始的な部品から地道に積み上げることになり、車輪の再発明と開発コストの高騰を招きます。
OSS の中には強力なものもあります。たとえば Batfish は、コンフィグを解析してNW全体の経路やフィルタのふるまいを計算できます。扱いたいことが Batfish の対応範囲に収まれば、自動化はとても楽になります。ただし、どの機器のどの設定をどこまで解析できるかは、機器によってまちまちです。そのため、使うたびに「この情報は Batfish で扱えるんだっけ?」という事前の確認が必要になります。3
部品が育たないのはなぜか
NWの自動化に使える基礎的な部品がなかなか育たないのには理由があります。
部品を作る側から見ると、➡️第4回で見た掛け算がそのまま立ちはだかります。多くの機器に対応するパーサを作るには、多くの機器の多くのバージョンの出力を集め、それぞれに対応し、機器が更新されるたびに追随しなければなりません。その作業を通常のNW運用業務の合間に続けるのは困難です。
一方、使う側から見ると、自分たちの機器に対応していない部品は使えません。対応していなければ自分たちで対応を追加するか別の方法を探すことになります。対応を追加してもその成果が部品の本体に還元されなければ、次に同じ機器を使うほかの組織はまた同じ作業を繰り返すことになります。
こうして、部品は「多くの組織で広く使われている一部の機器」には対応しても、それ以外の機器への対応はなかなか進みません。自分たちの環境にそうした機器が1つでも含まれていれば、その部分は自分たちで作ることになります。
買うか作るかの前に
「製品を買うか、自分たちで作るか」は自動化の投資でよく議論になるテーマです。しかし、ここまで見てきたように、どちらを選んでも自分たちのNWに合わせた作り込みは残ります。製品を買えばその上に作り込みが必要になり、自分たちで作れば基礎的な部品から作ることになります。
そこで、「買うか作るか」を決める前に、どの部分を自分たちの資産として持つかを決めておくことをおすすめします。たとえば、機器との接続や設定投入のような共通の部分は製品や OSS に任せ、自分たちのNWのトポロジや設計ルールのデータは自分たちで持つ。そうした切り分けを意識すると、製品を入れ替えても資産を残しやすくなるはずです。
コストの話はここまでです。次回は、たとえ作れたとしてもその効果が見えにくい、という側から考えます。