Part 1: Rethinking Networking with Automation on Designing Network Automation at Scale

01 - 自動化という必然

Mon, 01 Jan 0001 00:00:00 +0000

1. 自動化という必然#

「自動化すべきか、せざるべきか、それが問題だ。」

Software-Defined Networking (SDN)とDevOpsが登場して以来、ネットワーク自動化は必要なのか、贅沢なのか、それとも過剰な設計なのかという議論が絶えない。答えは「場合による」。ハイパースケーラーには必須だ。選択の余地がなかった彼らは2010年代初頭にすでに着手していた。中小企業には完全な自動化はまったく不要かもしれない。ほとんどのネットワークはその中間に位置する。文化、スキル、ツールの成熟度、ビジネスの優先事項、これらすべてが採用のスピードを左右する。今日、これらの要因がそろいつつある。自動化は避けられない流れになっている。

ある地域物流会社のネットワークチームは、自分たちが「自動化プラットフォーム」と呼ぶものを3年かけて構築した。VLANプロビジョニング、BGPネイバー設定、デバイスハードニング用のAnsibleプレイブック。コードはGitで管理され、変更はピアレビューを経て、デプロイは数日ではなく数分で完了した。あらゆる指標において、彼らは自動化を正しく実践していた。

そして会社が競合他社を買収し、一夜にして規模が2倍になった。新しいサイト、2つの新ベンダー、自社の命名規則と衝突する命名規則。新環境に対してプロビジョニングプレイブックを初めて実行したとき、エッジケースで失敗した。修正した。また別の箇所で失敗した。買収から6週間後、1人のエンジニアが手動でネットワークを運用するよりも、自動化のメンテナンスに多くの時間を費やすようになっていた。

振り返りの場は居心地が悪かった。ツールは失敗していなかった。Ansibleは問題なかった。失敗していたのは目に見えないものだった。ネットワークがどうあるべきかという単一の記述が存在しなかったのだ。各プレイブックは命名規則、IPアロケーション戦略、ベンダー挙動に関する独自の前提を抱えていた。環境が変わると、すべての前提が同時に崩れた。チームは既存のネットワークを自動化していたのであって、変化に適応できるプラットフォームを構築していなかった。

これがあらゆる自動化の停滞の根本にあるパターンだ。組織は、今日の問題のために構築した自動化が明日の障害になる地点に必ず差し掛かる。

1.1. 完璧な嵐#

自動化はもはや任意ではない。ハイパースケーラーは爆発的なArtificial Intelligence (AI)成長に対処している。数十万のCentral Processing Unit (CPU)とGraphics Processing Unit (GPU)が高速イーサネットを通じて通信している。エンタープライズやサービスプロバイダーは、レガシーインフラ、新サービス、クラウド/オンプレミス/エッジの拡散、コスト増大に悩まされている。

02 - 設計原則

Mon, 01 Jan 0001 00:00:00 +0000

2. 設計原則#

あるネットワーク自動化チームが6ヶ月かけて、本当に誇りに思えるシステムを構築した。構造化データモデルからインテントを取得し、テンプレートエンジンでデバイス設定を生成し、ポリシーライブラリに照らして変更を検証し、完全なロールバック機能を備えたNETCONF経由でプッシュする。アーキテクチャ的には盤石だった。経営陣へのデモも好評だった。そしてネットワーク運用チームに引き渡した。

導入は一向に進まなかった。オペレーターはCLIを使い続けた。理由を尋ねると、答えは一致していた。「実行する前に何が起きるかわからない」「何か問題が起きたとき、何が起こったのか把握できない」「出力の読み方がわからない」。自動化チームは技術的には印象的なものを作り上げたが、運用面では不透明だった。ドライランモードも、人間が読めるような変更プレビューも、オペレーターが認識できる言葉で書かれた監査証跡も存在しなかった。システムはまだ信頼を得ていないのに信頼を求めるブラックボックスだった。6ヶ月分のエンジニアリングの成果は使われないまま放置された。

この結果はほとんどのチームが認めるよりもはるかによく起きる。自動化はバグや設計の欠陥だけで失敗するわけではない。それに依存しなければならない人々が信頼しないために失敗する。ここでは、ネットワーク自動化を信頼性高く、スケーラブルで、安全なものにする基本的な設計原則を探っていく。これらは抽象的な理論ではない。導入されて真の価値をもたらす自動化と、無視されて最終的に放棄される自動化の違いだ。

これらの原則の多くは他のソフトウェアプロジェクトにも当てはまる。しかしネットワーク自動化は重要なインフラを支えるという独自の特性を持つ。ネットワークエンジニアは慎重さ、精度、手動検証に基づくモデルを使ってこれらのシステムを数十年にわたって構築・保守してきた。今、私たちは彼らに根本的に異なるモデルを採用するよう求めている。それには信頼が必要だ。

2.1 信頼を築く#

具体的な原則に入る前に、信頼について話しておこう。信頼はネットワーク自動化を成功させるための礎だ。それなしには、導入はほぼ不可能になる。

なぜ信頼がこれほど重要なのか？なければ、ネットワークエンジニアはあなたの自動化を採用しないからだ。自動化が置き換える手動プロセスと少なくとも同等の信頼性（さらにその他のメリット）を提供すると信じてもらう必要がある。

さらに難しいのは、自動化システムを構築するエンジニアが深いネットワーク経験を持っていない場合が多いことだ。だから自動化は、ネットワークエンジニアチームにとって安全で、信頼でき、カスタマイズと管理がしやすいという強く明示的な特性を埋め込むことで補完しなければならない。

信頼できる自動化の重要性は、Autocon3でのDamien GarrosのプレゼンテーションBuilding Trustworthy Network Automationに着想を得ている。

シンプルにまとめると、必要な4つの基本特性は以下の通りだ。

Predictable（予測可能）: 一貫した決定論的な結果。エンジニアは「実行」を押す前に何が起きるかを知る必要があり、毎回同じ動作が得られなければならない。
Reliable（信頼性）: エラーを適切に処理する。障害から回復する。予期しない状況下でも、規模が大きくなっても、操作が安全に完了する（またはロールバックする）ことを保証する。
Usable（使いやすさ）: 過度な複雑さなしにエンジニアが動作を検証、理解、制御できるインターフェース。ガードレール付きで。
Understandable（理解可能）: ブラックボックスであってはならない。インテント、ステップ、結果、判断を、人間の信頼を築く形で公開しなければならない。

graph BT
 %% ===== Middle Layer =====
 subgraph L2[**特性**]
 direction LR
 B1[予測可能]:::layer2
 B2[信頼性]:::layer2
 B3[使いやすさ]:::layer2
 B4[理解可能]:::layer2
 end

 %% ===== Top Layer =====
 subgraph L1[" "]
 direction TB
 A[信頼]:::layer1
 end

 %% ===== Connections: Behavior → Outcome =====
 B1 --> A
 B2 --> A
 B3 --> A
 B4 --> A

 %% ===== Styling =====
 classDef layer1 fill:#ffcccc,stroke:#b8860b,stroke-width:2px,color:#000;
 classDef layer2 fill:#ffe6cc,stroke:#4682b4,stroke-width:1.5px,color:#000;

AI/ML技術がネットワーク自動化の領域に参入するにつれて、予測可能性または決定論的な動作はますます重要になっている。これらの技術は一定のランダム性をもたらすからだ。

03 - アーキテクチャ的思考

Mon, 01 Jan 0001 00:00:00 +0000

3. アーキテクチャ的思考#

この章は本書の基盤を紹介する。このマインドセットを採用する必要がある理由を説明し、Network Automation Forum（NAF）が提唱する参照フレームワークを紹介し、自分のプロジェクトでどう活用するかを示す。

第2部ではこれらのトピックを深く掘り下げる。この章では、各構成要素を詳述する前に全体像を把握できるよう、概要を紹介するにとどめる。これが重要な理由は、各構成要素を説明したとき、全体像があると点と点をつなぎやすいからだ。

しかし筆者はWHATを知る前にWHYを理解することを強く信じているので、まずアーキテクチャを活用する理由を理解しよう。

3.1. 参照アーキテクチャが重要な理由#

「教育を受けた者だけが自由だ。」 エピクテトス

ネットワーク自動化ソリューションは複数のピースの組み合わせで、それぞれが役割を担う。ネットワーキングの世界では、あらゆる問題を解決しようとするシンプルなモノリシックなソリューションに慣れ親しんでいる。ある程度はそれが正しいかもしれないが、単独で多様な課題とユースケースすべてを解決できるものはない。だから、ユースケースが最も一般的なものでなければ、カスタマイズや拡張が必要になるかもしれない。

明確な参照アーキテクチャがなければ、チームは予測可能な一連の問題に直面することが多い：

重複した努力: 複数のチームが同様のツール（データソース、重複したスクリプト、冗長なモニタリングシステム）を独立して構築し、リソースを無駄にして一貫性のないインターフェースを生む。
統合のギャップ: ツール同士がきれいに連携せず、高コストなカスタム統合作業を強いられる。
責任の不明確さ: どのツールがオブザーバビリティ、オーケストレーション、状態管理を担当すべきかが不明確で、混乱と責任のなすり合いにつながる。
拡張の難しさ: 新しい機能やツールの追加がシステム全体の再考を必要とする。
知識のサイロ化: 異なるチームが異なるメンタルモデルを使い、新しい人のオンボーディングやソリューションの保守が難しくなる。

参照アーキテクチャはこれらの問題を、自動化システムをどのように整理すべきかという単一の明確なメンタルモデルを提供することで解決する。それが定義するのは：

各コンポーネントが何をすべきか → その責任
コンポーネントがどのように相互作用するか → インターフェースとデータフロー
どこで選択できるか → どのツールを使うか
どこで一貫性が必要か → コンポーネント間の通信方法

参照アーキテクチャはネットワークエンジニアにとって新しいものではない。私たちは皆、親しみ深いOSIモデルとともに育ってきた。OSIモデルを使うことで、各レイヤーが異なる責任と関心事を持つため、ネットワーク問題を診断して理解するための段階的なレイヤードアプローチが得られる。ネットワークの専門家は、この懸念事項の分離が複雑なシステムを管理可能にすることを直感的に理解している。

ネットワーク自動化でも、連携して機能するソリューションの開発と相互接続を導くための同様のものが必要だ。チームが一貫した決定を下し、プロジェクト間でコンポーネントを再利用し、毎回ゼロから考え直すことなく自動化の能力を進化させる助けになる。

3.2. ネットワーク自動化アーキテクチャ#

これを踏まえると、アーキテクチャが必要だ。しかしセクションタイトルの「A（一つの）」に注目してほしい。アーキテクチャは一つだけではなく、多くある。アーキテクチャは単なる参照フレームワークだ。思考を整理し、一貫した決定を導く方法。筆者は3つのイニシアティブに貢献してきた：

Network to Code参照アーキテクチャ：NTCアーキテクチャチーム（筆者が4年間参加）が主導した集合的な取り組みで、幅広いユースケースにわたって効率的で理解しやすいネットワーク自動化をサポートするよう設計されている。
O’Reilly「Network Automation and Programmability」第2版：共著者のMatt Oswalt、Scott S. Lowe、Jason Edelmanとともに本書のすべてのコンテンツの点と点をつなぐ取り組み。
NAFフレームワーク：Wim Henderickx、Dinesh Dutt、Claudia de Luna、Ryan Shaw、Damien Garrosとともに主導した、NAFの傘下のコミュニティプロジェクト。初心者と経験豊富な実践者の両方が構造化された再現可能な方法で自動化ソリューションを構築できるようにすることを目標としている。

これらのイテレーションを通じて、一貫性を維持し各進化から学ぶことに注力してきた。3つのアプローチすべてが有用だ。しかし、NAF Frameworkを現在のベストプラクティスとして使用することを提案する。コミュニティ主導で、ベンダーに依存せず、広く適用可能だ。長年の集合的な学習を統合し、積極的に活動する成長するコミュニティによって維持されている。