前回までのおさらい
➡️第2〜7回で、NWの自動化の判断が「自動化しない」側に傾く理由を、前提(NWの性質・足りない情報・機器ごとの違い)と、コスト・効果・リスクに分けて見てきました。最終回ではこれらを全体として振り返り、どこに手を付けられるのかを考えます。
図1: 連載マップ
この回の要点
- NWの自動化が進まないのは、個々の組織の合理的な判断が積み上がった結果で、広く見たときに知見がたまっていかない構造があります。
- 規模と標準化で要因を取り除けるハイパースケーラと同じ方法は、そこまでの規模がない多くの環境では取れません。
- 自分たちの運用に必要な範囲に絞った標準化とデータ化、段階的な検証、知見の共有によって、判断の天秤を自分たちで動かしていくことが現実的な道でしょう。
ふりかえり: 天秤はなぜ傾いているのか
➡️第1回で、自動化するかどうかはコスト・効果・リスクの3つを比べて判断されると述べました。そして、NWではこの3つがすべて「自動化しない」側に傾いていることを見てきました。
- 前提 (➡️第2〜4回): NWは機器同士が連携して系全体で状態を持ち、いくつもの層が重なっています。これは変えられない性質です。そして、NW全体の構造・状態・設定の経緯は、必要な範囲を横断して機械が使える形にはそろっておらず、多くを構成図と人の頭の中に頼っています。さらに、機器ごとに設定の書き方や処理の順番など様々な組み合わせ・バリエーションがあります。
- コスト (➡️第4〜5回): 機器ごとの違いは、ベンダ・機種・OS・世代の数だけ掛け算で増えます。それを吸収しようとすると、導入・保守や、変更結果の確認に追加の負担が生じます。製品を買っても自分たちで作っても、自分たちの環境向けの作り込みは残ります。
- 効果 (➡️第6回): NW全体を対象にした判断は、人には簡単で、機械には難しいものです。いまの規模と作業時間で比べれば手作業のほうが安く、見送る判断には理由があります。
- リスク (➡️第7回): 自動化は増幅器なので、影響範囲の広いNWでは事前に試す場所が必要です。しかし、本番と同じ環境は作れず、何をもって十分とするかの基準を決めるのも困難です。
ひとつの前提が複数の箱に影響しています。たとえば、トポロジのデータがないことは機械に判断させる材料を奪い(効果)、製品が対象を限定せざるを得ない理由になり(コスト)、検証環境の再現も難しくしています(リスク)。一方で、それぞれの箱は複数の前提の影響を受けているので、ひとつの対策ですべてが解消するわけではありません。
悪循環: 合理的な判断が積み上がると
ここまでは、ひとつの組織の中での判断について考えていました。最後に、この判断が多くの組織で積み重なったときに何が起きるかを考えてみます。
図2: 悪循環。一つひとつの判断は合理的でも、全体としては自動化が進まない状態が続きます。
割に合わないので自動化しない。あるいは、どうしても必要な部分だけを自分たちの環境専用に作り込む。どちらもその組織にとっては合理的な判断です。
しかしその結果、作ったツールも得た知見も組織の中に閉じます。機材も構造も設計も運用のポリシもバラバラの独自プラットフォームを各社(各組織)が運用するので、共有しようにも共通の土台がありません。同じ会社の中でさえその時々の機器や技術で作られた世代の違うNWが混在しています。検証も都度の個別対応になる(➡️第7回)のでそのノウハウも狭い範囲にとどまります。パーサのテンプレート集のように、共有されている部品もあります。ただ、対象の機器や設計が違えば、自分たちの環境に適用するための追加作業が残ります。
知見が組織をまたいでたまらなければ、製品も OSS も育ちにくくなります。製品は大規模な顧客向けに作られ続け、OSS は対応する機器が限られたままです。すると、次の組織も自動化はやはり割に合わないと考えます。こうして悪循環が続いていきます。
パブリッククラウドでは、多くの組織が同じ土台の上で運用することで知見やツールが共有され、使う人が増えるほど便利になる「ネットワーク効果」が働いています。オンプレミスのNW運用でも共有された部品は増えていますが、環境ごとの統合作業が残るため、この効果は限定的にしか働いていません。
ハイパースケーラはなぜできたのか
「それでもハイパースケーラは NW を自動化できている」という反論があるでしょう。確かにそうです。彼らがなぜできたのかを考えると、この連載で見てきた要因がよく見えてきます。
- 機器と設計を統一できる: 自分たちで機器を選び、場合によっては自分たちで作り、設計のパターンをそろえられます。機器ごとの違いの掛け算(➡️第4回)を狙って小さくできます。
- 自動化を前提に設計できる: NWを作る段階から自動化しやすい構成を選べます。トポロジが決まっていれば役割も決まり、データにもしやすくなります(➡️第3回)。
- 規模がある: 同じ作業が膨大な回数行われるので、大きなコストをかけて自動化しても回収できます(➡️第6回)。
つまりハイパースケーラは、この連載で挙げた要因の多くを自分たちで取り除ける立場にあります。この連載が対象としている、規模で押し切れず、既存の多様な機器やサービスを抱えた環境にはその条件がありません。同じ方法をそのまま真似することはできません。
前提として受け入れること
対策を考える前に…ここは個人的な所感ですが、NWの操作やデータの形を誰かが強力に標準化してくれる世界は、多分来ません。SDN や OpenConfig が登場してから10年以上が経ちましたが、既存のマルチベンダ環境全体が統一されたデータとインタフェースで運用される世界は実現されていません。誰かがそれを達成してくれるのを待つのは現実的ではないと思います。
その前提に立つと、選択肢は「それなりのお金を払って既製の製品を買う」か「腹をくくって自分たちで作る」になります。➡️第5回で見たように、どちらを選んでも作り込みは残ります。また、新しくNWを作る機会があるなら、最初から自動化を前提にした設計を取ることが最も効果の大きい選択になります。
そのうえで、規模で押し切れない環境が取りうる対策として、3つの方向を考えます。
対策1: 自分たちの環境で運用が回るレベルの標準化(コストを下げる)
業界的な標準化ができあがる・普及するのは待てません。しかし、自分たちの環境の中での標準化なら自分たちで進められます。
NWのあらゆる側面を表現できる汎用のモデルを目指す必要はありません。自分たちのNWの構造、設計、運用に必要なデータを選び、その範囲に絞ってそろえれば十分です。抽象化のジレンマ(➡️第5回)は、あらゆる違いを吸収しようとするから起きます。自分たちが実際に使っている機器と構成に範囲を絞れば、抽象的になりすぎないようにできるはずです。
とくに効果が大きいのは「足りない情報」(➡️第3回)を埋めることです。
- トポロジのデータ化: 自分たちのNWの構造を、機械が読める形で持つ。まずは一部の層、一部の範囲からでも構いません。
- 設定の経緯の記録: フィルタのルールや経路のポリシに、誰が何のために必要としているかを残す。新しく追加するものから始められます。
データは作るだけでなく、変更作業と一緒に更新する手順を決めておきます。実機から取れる情報は設計データと突き合わせ、食い違いがあれば自動処理を止めて確認する、といった仕組みがあれば、古いデータのまま変更を進めずに済みます。
データは作るだけでなく、変更作業と一緒に更新する手順を決めておきます。実機から取れる情報は設計データと突き合わせ、食い違いがあれば自動処理を止めて確認する…といった仕組み(➡️第5回)があれば、古いデータのまま変更を進めずに済みます。
足りない情報は、連載で扱った多くの要因の上流にあります。ここが埋まれば、機械に判断させる材料ができ(効果)、検証の前提も整い(リスク)、製品や OSS を使うときの足場にもなります(コスト)。そして、大きな予算や組織の合意を待たずに、小さく始められる取り組みでもあります。
調達の段階で、扱う機器の組み合わせを増やさないことを評価軸に入れる(➡️第4回)のもこの方向の対策です。
対策2: All-or-nothing でない検証(リスクを下げる)
➡️第7回で見たように、本番環境の完全な再現はできません。問題は「どこまで近づけられるか」です。
そこで、単一の検証環境・1回の試行での完全な検証を目指すのではなく、試す条件や失敗のパターンを増やしながら、用途ごとにどこまで再現できれば十分かを設計することを考えます。
- 設定の論理的な正しさを確かめたいなら、コンフィグの解析や仮想ノードで十分なことが多いでしょう。
- 障害時の切り替わりを確かめたいなら、規模を絞ってでも本番に近い物理機材が必要かもしれません。
- 転送性能やハードウェア固有のふるまいを確かめたいなら、本番と同じか同等のハードウェアが必要です。
- 作業手順を確かめたいなら、コマンドやインタフェース名が本番と同じになる機材を使うか、読み替えの対応表を検証項目と一緒に管理する必要があります。
検証を段階に分けることで、すべてを本番同等の環境で確かめなくても、段階的に確度を上げられるのではないでしょうか。検証サイクル……検証頻度・時間・並列度、もっと手軽で使い捨てられる環境の利用などを含めて検証を含む作業プロセスを変えることが考えられるでしょう。
もうひとつのポイントは、判断の基準を変えることです。仮想化やシミュレーションを使う限り「同じものを使っているから大丈夫」という根拠は成り立ちません。代わりに、NW全体が狙ったふるまいをしているかが判断基準になります。この通信は通るか通らないか、障害時にはこちらに切り替わるか…など。ふるまいを基準にすることで、道具(NWの構成要素)が本番と違ったとしても目的を達成できているかどうかを評価できます。1
そのためには、検証項目ごとに、使う環境が何を再現でき何を再現できないかを対応づけておく必要があります。確認できたことだけでなく確認できなかった条件も記録し、本番ではその部分を範囲を区切って確かめます。そして、ふるまいを定義するためにも、対策1のデータが必要になります。
対策3: 知見を組織の外に出す(悪循環を断つ)
対策1と対策2は、自分たちの組織の中で天秤を動かす方法です。しかし、それだけでは悪循環は断てません。悪循環の中心は、知見が組織の中に閉じ、組織をまたいで(業界に)たまらないことにあるからです。
各組織のNWがバラバラである以上、ツールをそのまま共有するのは難しいでしょう。しかし、共有できるものはあります。
- 考え方と設計のパターン: 自分たちの環境で、どんなデータを選び、どう標準化したか。どんな検証の段階を設計したか。
- 部品・道具: コンフィグやコマンド出力のパーサのように、どの組織でも必要になる基礎的な部品や道具。OSS に還元すれば、次の組織の車輪の再発明を減らせます。共有するときは、成果物だけでなく、対応している機器・バージョン、未対応の範囲、サンプルデータとテストも一緒に示すと、次の組織が使いやすくなります。
- 失敗の経験: 何がうまくいかなかったか。これは、製品のカタログには載らない、最も価値のある知見かもしれません。
汎用ツールとして完成させて公開するところまで、最初から目指す必要はありません。何に困り、どこまで試し、何が残ったかを記事にすることも共有です。
パブリッククラウドのようなネットワーク効果を、オンプレミスのNW運用の世界で生み出すのはとても難しいことです。それでも、知見を外に出す組織が増えるほど、次の組織にとってのコストは下がり、悪循環は少しずつ弱まるはずです。この連載も、そのささやかな試みのひとつです。2
どこから始めるか
3つの対策はどれも一度に全部をやる必要はありません。むしろ、小さく始めて効果が見えるところから広げていくほうが進めやすいでしょう。たとえば、次のような順番が考えられます。
- 手作業がボトルネックになりつつある作業を1つ選ぶ: 効果が見えやすいのは、数が増えて人の作業が詰まり始めている作業です。(➡️第6回)
- その作業に必要なデータだけをそろえる: NW全体のトポロジを一度にデータ化するのではなく、選んだ作業の判断に必要な範囲に絞ります。
- その作業に必要な検証の度合いを決める: 本番同等でなくてよい部分、本番に近い環境が必要な部分を分けます。
- やってみてわかったことを記録し、外に出す: うまくいったこともいかなかったことも記録をとる。
1つの作業でうまくいけば、そろえたデータは次の作業にも使えます。データが増えると次の作業の自動化はより安くできるようになっていきます。規模で押し切れない環境でも組織の中で小さな「ネットワーク効果」を作っていくことはできるはずです。
立場ごとの打ち手
3つの対策を、立場ごとにまとめます。
| 対策 | 現場で始められること | 意思決定者が判断すべきこと |
|---|---|---|
| 1. 自分たちの環境での標準化 | トポロジの一部をデータにする。新しいルールに経緯を記録する | データ整備を、ツール導入より先の投資として位置づける。調達時に機器の組み合わせを増やさないことを評価軸に入れる。新規構築では自動化前提の設計を選ぶ |
| 2. 段階的な検証 | 作業の種類ごとに、必要な再現の度合いを整理する。ふるまいで確かめるテストを作る | 検証への投資を、「どこまで再現できれば十分か」を決めてから判断する |
| 3. 知見の共有 | 部品や設計のパターンを社外に出す。OSS に還元する | 知見共有に人と時間を割り当てる |
| 共通 | 手作業がボトルネックになりつつある作業を見つける | いまの作業量だけでなく、将来の規模で手作業がボトルネックになる時点を基準に投資を判断する |
図3: 3つの対策の当てどころ。
結び
NWの自動化が進まないのは、誰かの努力が足りないからではありません。NWの性質、足りない情報、機器ごとの違いという前提のうえで、コスト・効果・リスクが「やらない」側に傾いていて、一つひとつの組織が合理的に判断した結果です。そして、その合理的な判断の積み重ねが全体の悪循環を生んでいます。
だからこそ魔法のような解決策はありません。規模で押し切れない環境では、自分たちの手の届く範囲から天秤を少しずつ動かしていくしかありません。
この連載が、自分たちのNWの自動化が「なぜ進まないのか」を説明し、「どこから手を付けるか」を考えるための見取り図になれば幸いです。
付録: 要因の詳細図(全体)
第1回の付録と同じ図です。連載で扱った要因と、その関係をすべて描いています。(Mermaid図ですがQiitaだとみにくいのでGistの方を参照してください)
図4: 要因の詳細図。実線の矢印は「原因 → 結果」「前提として依存する」関係、点線は同じ現象を別の角度から見ている関係です。 (Gist参照)
-
作業手順の確認はふるまいだけでは評価できません。手順は使う道具そのものに依存するので、本番と違う部分は読み替えの対応表として残し、本番作業の中でその部分を確かめることになります。 ↩
-
ここ数年の筆者の活動については GitHub - ool-mddo/playground を参照してください。この連載はこうした活動を通して検討したことを筆者なりにまとめたものです。 ↩