はじめに
何をいまさら…という話ですが、クラウドの世界では Infrastructure as Code や Kubernetes による運用の自動化が当たり前になりました。
NW運用領域でも、Ansible などで設定変更や情報収集をしているところは多いでしょう。では、それでNW運用は楽になったでしょうか? もうこれで十分自動化されていると感じていますか? デバイスに対する設定変更は自動化できた…とはいえ変更作業のたびに構成図を広げ、影響範囲を人が洗い出し、機器ごとの手順書を書き、検証環境で検証し、作業後に人が確認している。こうした一連のプロセスの多くは今でも人力で回っていませんか? コンフィグを流し込むのは楽になったけど、そもそものコンフィグをどう用意するのか、どのノードに・どんな順番で設定していくべきか…という設計・検証・作業立案に負担を感じていませんか?
この連載では、NWの自動化がなぜ進まないのかを考えます。よく挙がる理由は、機器ごとのバリエーションの多さ、あるいはそれを使う人のスキルや実現にかかるコストといったものですが、何かひとつを原因だと特定するのは困難です。実際には、NWという対象の性質、機器の多様性、情報の欠如、検証の難しさといった要因が絡み合っていて、ひとつだけを取り出して解決しようとしてもうまくいきません。
あれこれ理由を考えてみると、多くの場合で自動化を「やらない」ことが合理的な選択になりえることが見えてきます。一つひとつの判断を積み上げると、いますぐ自動化しなくてもいいかな…という結論に至りがちです。そのため、NW運用領域全体で自動化が進みにくい状況が続いています。
この連載で扱う要因の関係を、先に1枚の図で示しておきます。
図1: 連載マップ。矢印は「左が右を引き起こす・悪化させる」という意味です。各回の冒頭でこの図を再掲し、その回で扱う部分を示します。
この回の要点
- ノード単位の設定変更は自動化できても、NW全体を対象にした作業の自動化はまだこれから
- それはコスト・効果・リスクのどれを見ても「割に合わない」構造によるもの
- この構造は、規模で押し切れない環境ほど影響が強い
前提整理
自動化?
最初に「自動化」についての認識を合わせましょう。この連載で扱うのは、ノード単体の設定変更の自動化だけではありません。複数のノードをまたいでNW全体を調整し、NWサービスとしての目的を達成するための作業=プロセス全体の自動化です。
たとえば「新しいシステムを収容し、既存のシステムとの間で必要な通信だけを通す」という依頼を考えてみます。この依頼を実現するには、次のような作業が必要になります。
- 計画: どの機器・どの経路が関係するかを洗い出し、影響範囲を見積もる
- 設計: 経路上のどの機器に、どんな設定(VLAN、ルーティング、フィルタなど)を入れるかを決める
- 検証: 変更が意図どおりに動くか、ほかの通信に影響しないかを事前に確かめる
- 実施: 複数の機器に、正しい順序で設定を入れる
- テスト: NW全体として、狙った通信が通り、それ以外が通らないことを確認する
多くの現場で自動化されているのは、このうち「実施」の一部、つまり決まった設定を機器に投入する部分です。どの機器に何を入れるべきかを決める計画・設計や、NW全体として正しく動くかを確かめる検証・テストは、まだまだ人に残っています。
図2: NWの変更プロセスと自動化の到達点。緑は自動化が進んでいる部分、赤は人に残っている部分。点線はその段の自動化を止めている主な理由です。
図2のとおり、自動化は「実施」の手前と後ろで止まっています。止めている理由は段ごとに違って見えますが、この連載を通して見ていくと、それぞれが互いに絡み合っていることがわかってきます。
なお、プロセス全体の自動化はすべての判断を無人化することではありません。承認や例外の判断は人に残しつつ、工程の間のデータの受け渡しや定型的な処理を機械に任せる形も含みます。
対象者?
この連載は、SI(エンタープライズ)、DC、ISP などのNW運用・その運用者をターゲットに考えています。とくに、大きな開発投資を大量の反復作業で回収する…という方法を取りにくいサービスを念頭に置いています。NWに対する要求や複雑さはあるものの規模はそれほど大きくなく、同じ作業を何千回も繰り返すわけではない、そんな環境(サービス)が対象です。
ハイパースケーラや大規模キャリアのように、規模で投資を回収でき、機器や設計を自分たちで統一できる組織は自動化を進めています。なぜ彼らにはできて、ほかの多くの組織には難しいのかは、連載の中で考えます。
要因を並べるだけでは見えないこと
「NWの自動化が進まない理由」を挙げようとすると、いくらでも出てきます。機器ごとにコンフィグの書き方が違う。インタフェース名がバラバラ。検証環境が作れない。トポロジを表すデータがない。製品が高い。スキルのある人がいない……。
ただ、こうした理由を並べてみると、同じトピックが何度も形を変えて出てきます。たとえばクラスタ構成のファイアウォールに対する処理を自動化しようとしたとき「クラスタを1台として見るか2台として見るか」は、NWが多層構造であることの話でもあり、機器の実装に依存する話でもあります。
つまり、要因はバラバラに存在しているのではなく、ある要因が別の要因を引き起こしたり、悪化させたりしています。ただ列挙するだけだと何が問題なのかが見えてきません。この連載では、何が何を引き起こしているのかに注目して整理していきます。
全体のストーリー: 「割に合わない」の分解
自動化するかどうかの天秤
ある作業を自動化するかどうかを決めるとき、私たちは次の3つを比べています。
- コスト: 作るのにどれだけの手間とお金がかかるか
- 効果: 作ったら、どれだけ楽になるか、何が良くなるか
- リスク: 失敗したら何が起きるか、それを事前に潰せるか
NWの場合、この3つどれもが「自動化しない」側に傾いています。図1の中央にある3つの箱がこれにあたります。
コスト: 作るのが高い (第4・5回)
NW機器は、同じことをするのにも、モノによって設定の書き方・処理の順番・名前の付け方が違います。
たとえば OSPF の設定を見ると、Cisco IOS では process id という管理情報を指定しますが、Junos にはありません。
一つひとつは小さな違いですが、ベンダ × 機種 × OS × バージョン のように「コントロールすべき違い」の数が増えていきます。この掛け算を吸収する仕組みを作ろうとすると、仕組みそのものが複雑になり、使いにくくなっていきます。自動化製品を買っても自分たちの環境向けの作り込みは残り、自作すれば基礎的な(「原始的」な)部品から作ることになります。
効果: 割に合わなく見える (第6回)
NW全体を対象にした判断の多くは、人には簡単で機械には難しいものです。
たとえば「このサーバとあのサーバの間の通信はNWのどこを通るか」を考えましょう。経験のあるエンジニアなら、構成図を見ればすぐに答えられます。しかし機械に同じ判断をさせるには、トポロジ、冗長構成の組み方、フィルタのポリシといったデータに加えて、人が暗黙に使っている「通常はこちら、障害時はあちら」という設計上の前提を、データやルールとして与える必要があります。
人がすぐにできることを、大きなコストをかけて自動化しても、効果は小さく見えます。規模がそれほど大きくなく、変更の頻度も高くない環境であれば、直近の作業時間だけで比べると手作業のほうが安いよね…という判断は、多くの場合で合理的です。
リスク: 試せない (第7回)
自動化は、良い結果も悪い結果も増幅します。だからこそ、本番に適用する前に安全に試せる場所が必要です。
ところがNWでは、本番と同じ検証環境を作ることが困難です。本番と同じ機材をそろえればコストが跳ね上がり、仮想環境で代用すればハードウェアに依存する機能のふるまいが再現できません。手順を確認しようにもそもそものNW構成やインタフェース名が本番環境と変わってしまいます。どこまで確かめれば十分なのか、という基準もはっきりしません。(基準を満たしたから本番実施OKというより、いま手持ちのリソース・時間でやれることをやったからOKとなっていませんか?)
NWは多くのシステムが共有するインフラなので、失敗したときの影響範囲がどうしても広くなります。でも事前に検証できることには制約・限界があります。自動化をためらってしまうのもわかります。
3要素を「やらない」側に傾けている前提 (第2〜4回)
コスト・効果・リスクの傾きには、共通の原因があります。図1の左側にある「前提」です。
- NWの性質(➡️第2回): NWは、機器が互いに連携して系全体で状態を持ち、物理(L1)・L2・L3・overlay…と重なっています。機器を1台ずつ見るだけでは全体の動きはとらえられません。これはNWがもつ性質であり、変えられません。
- 足りない情報(➡️第3回): NW全体の構造や、ある設定が誰の何のために入っているのかは、多くの場合、構成図や人の頭の中にしかありません。機械が使える形のデータになっておらず、自動化しようにも判断材料がありません。これは、自分たちで変える余地があります。
- 機器ごとの違い(➡️第4回): ベンダや機種、OS による違いがあります。これはそのままコストを押し上げる要因でもあるので、第4回では前提とコストの両方を扱います。
NWの性質は、人の判断を必要とする場面を増やし(効果)、検証を難しくし(リスク)、世代の混在を通じて違いを増やします(コスト)。足りない情報は、機械に判断させる材料を奪い(効果)、検証環境の再現を難しくします(リスク)。このように、前提のひとつが複数の箱に効いています。そして、それぞれの箱は複数の前提の影響を受けているので、ひとつの対策ですべてが解消するわけではありません。
悪循環: 合理的な判断が積み上がると
ここまでの話は、ひとつの組織の中での判断でした。しかし、この判断が多くの組織で積み重なると、技術領域/業界全体として悪循環が生まれます。
図3: 悪循環。一つひとつの判断は合理的でも、全体としては自動化が進まない状態が続きます。
割に合わないので自動化しない、あるいは自分たちの環境専用に作り込む。どちらも合理的ですが、作ったものも知見も組織の中に閉じるので業界にはたまらず、次の組織にとっても自動化は割に合わないままです。この悪循環と、それをどこで断てるかは最終回(➡️第8回)で考えます。
この先の連載と結論
NWの操作やデータの形を誰かが強力に標準化してくれないかなー……と考えたことがある人は多いと思います。でも OpenConfig の登場から10年以上たちましたがそういった理想的な世界は来ていません。
規模で押し切ることもできず、誰かの標準化も待てない。そういう環境で自動化の判断をどう変えていけるのかを最終回(➡️第8回)で考えます。自分たちの環境に絞ったデータ整備、段階的な検証、知見の共有といった、地味だけど手の届く対策について取り上げます。
この先の連載は次のとおりです。
| 回 | タイトル | 内容 |
|---|---|---|
| 第1回 | 「割に合わない」が積み上がる構造 | 連載全体のストーリー |
| 第2回 | NWの「変えられない前提」 | 系全体が状態を持ち、層が重なるNWの性質 |
| 第3回 | NWは構成図と人の頭の中にしかない | トポロジ・状態・経緯がデータになっていない |
| 第4回 | 同じことをするのに書き方がバラバラ | 機器ごとの違いと、その掛け算 |
| 第5回 | 吸収しようとすると使われない | 抽象化のジレンマと、道具がそろわない理由 |
| 第6回 | 人がぱっとできることが自動化しにくい | 手作業のほうが合理的に見える理由 |
| 第7回 | 安全に試せる砂場がない | NWの検証はなぜ難しいのか |
| 第8回 | 悪循環をどこで断つか | 振り返りと、規模がなくても取りうる対策 |
リーダー・意思決定者の方へ
NW運用のリーダーやサービスの意思決定に関わる方に向けて、第1回から言えることをまとめておきます。
NWの自動化が進まない理由を、「ツールがないから」「人のスキルが足りないから」のように何かひとつに求めてもうまくいかないと思います。ツールを買っても自分たちの環境向けの作り込みは残りますし、作り込みをがんばる気力があっても機械で判断するのに必要なデータや安全に試せる環境がなければ力を発揮できません。
一方で、手作業のまま運用を続けることにもコストがかかります。NWの規模に応じて変更時間は増大し、判断が特定の人に依存していきます。いまは自動化を進めるのが割に合わなく見えていても、NWの規模や重要度が変われば手作業であることがボトルネックになりえます。そのときにあとから自動化するのはもっと困難でしょう。
「いまやるべきか」を判断するときは、まずコスト・効果・リスクを分けて、それぞれがどれだけ「やらない」側に傾いているのかを見てみてください。傾きの理由がわかれば、どこから手を付けるかも考えやすくなります。
次回は、すべての前提になっている「NWの性質」を取り上げます。分散システムといわれるものはいろいろあるのに、なぜNWはそんなに難しいのか? というところから始めます。
付録: 要因の詳細図
連載で扱う要因と、その関係を描いた図です(Mermaidの図なんですがQiitaだとみるのが難しいのでGistにも置いてあります)。各回では、この図から関係する部分だけを切り出して使います。
凡例: 実線の矢印は「原因 → 結果」「前提として依存する」関係、点線は同じ現象を別の角度から見ている関係です。
図4: 要因の詳細図 Gist参照