· 531 words · 3 min read

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を現在のベストプラクティスとして使用することを提案する。コミュニティ主導で、ベンダーに依存せず、広く適用可能だ。長年の集合的な学習を統合し、積極的に活動する成長するコミュニティによって維持されている。

3つは競合するものではなく補完的だ。各アーキテクチャが最も関連する場面を明確にするための簡単な比較：

アーキテクチャ主な焦点ガバナンス最も役立つ場面
NTC参照アーキテクチャ意見のあるツール選択と統合パターンNTC内部、継続的に進化NTCツールを使用し、規範的な実装ガイダンスを求めるチーム
O’Reilly 第14章プログラマビリティトピックをつなぐ概念的フレームワーク発行済み、静的自動化のコンセプトがどのように接続するかを理解したい読者
NAFフレームワークモジュールごとのMUST/SHOULD/MAYを持つ相互運用性標準コミュニティ維持、ベンダーニュートラルマルチツール、マルチベンダー環境の共有参照を求めるすべてのチーム

NAFフレームワークはブロック間のコントラクトを定義し、実装の選択を自由にする。NTCアーキテクチャは特定のツール推奨でそれらの選択を埋める。チームがNTCツールを使用する場合、両方が同時に競合なく適用される。

NAF Frameworkは以下のアーキテクチャを提案している：

block-beta
    columns 7
    
	space:1	
    block:layer1:5
        Presentation["プレゼンテーション"]
    end
	space:1

    space:7

    
    block:Observability:2
        columns 2
        ObservedState[("観測状態")]:1
        ObservedLogic["観測ロジック"]:1
    end

	space
    
	block:Orchestration:1
		columns 1
		OrchLabel["オーケストレーション"]:1
	end

	space
    
    block:Intent:2
        columns 2
        IntendedState[("意図された状態")]:1
        IntendedLogic["意図ロジック"]:1
    end
    
    space:7

	space

    
    Collector["コレクター"]:2
	space
    Executor["エグゼキューター"]:2
	space
    
	space:7
	space:1
    
    block:layer4:5
        NetworkInfra["ネットワークインフラ"]
    end
    
    Presentation <--> Observability
    Presentation <--> Orchestration
    Presentation <--> Intent
    
    Observability <--> Orchestration
    Orchestration <--> Intent
    
    Collector --> Observability
    Collector <--> Orchestration
	NetworkInfra --> Collector
    
    Orchestration --> Executor
    Intent --> Executor
    Executor --> NetworkInfra
    
    classDef darkStyle fill:#5a4149,stroke:#4a9eff,stroke-width:2px,color:#e8e8e8,font-size:20px,font-weight:bold
    
    class Presentation,NetworkInfra,ObsLabel,IntLabel,Collector,Executor,ObservedState,ObservedLogic,IntendedState,IntendedLogic,OrchLabel darkStyle

このアーキテクチャはドキュメントの定義に基づく以下のブロックを含む：

  • Intent (Architectural Block)（インテント）: ネットワークのDesired Stateを処理するロジックと、設定と運用上の期待の両方を含むその保存レイヤーを定義する。
  • Executor（エグゼキューター）: 意図された状態に従ってネットワークに変更（設定の更新）を適用するための実際のタスクを担う。
  • Collector（コレクター）: Executorとは対照的に、このコンポーネントはネットワークのActual Stateの取得（読み取り）に焦点を当てる。
  • Observability（オブザーバビリティ）: ネットワークのActual Stateを永続化し、それを処理するロジックを定義する。
  • Orchestrator（オーケストレーター）: 自動化タスクがイベントに応じてどのように調整され実行されるかを定義する。
  • Presentation (Layer)（プレゼンテーション）: ユーザーがシステムと対話するインターフェースを提供する。ダッシュボード、グラフィカルユーザーインターフェース（ITSM）、Command Line Interface (CLI)ツールを含む。

このアーキテクチャは恣意的なものではない。ソフトウェアエンジニアリングの原則をネットワーク運用に適用した自然な結果だ。

NAFフレームワークは、ネットワーク自動化アーキテクトが各モジュールの機能を参照し、MUST、SHOULD、MAYを定義する（RFCスタイルを使用して）ことでソリューションを整理できるよう支援することを目指している。そして、自分のユースケースを解決するためにそれらをどのように実装するかを決定できる。

複数のコンポーネントがあるからといって、1つのコンポーネントに1つのツールを選ばなければならないわけではない。多くの場合、異なる機能を実装するツールを使用することもできるが、理解（と承認）しなければならないトレードオフが伴う。

ここで各ブロックを紹介していく。

3.2.1. インテントまたは信頼できる情報源（Source of Truth）#

インテントとは、ネットワークをゼロから完全に稼働状態にするために必要なすべての情報を定義するすべてのデータだ。プレプロビジョニングからブートストラップ、完全稼働、そしてすべての種類のネットワークサービスの最終的な廃止まで、異なるライフサイクル状態をすべて含む。

アーキテクチャではインテントと呼ぶが、もう一つのよく知られた用語である信頼できる情報源（Source of Truth、SoT）と照合させている。SoTという用語は誤解されることがあり、SoTまたはインテントとは何かを明確にすることから始めたい（本書では両方を同義で使用する）。

ご想像の通り、これはデバイス、IPアドレス、データセンターインフラ（ラック、ケーブル）、ルーティングプロトコル、仮想化サービス、シークレット、運用上の制限、設定テンプレート、サービスまたはポリシーの抽象化など、非常に多様なデータを表す可能性がある。重要な側面の一つは、このデータが機械が理解できる形式で構造化されていなければならないことだ。そして、作成、読み取り、更新、削除の操作をサポートし、Representational State Transfer (REST)やGraphQLなどの標準化された、よく文書化されたApplication Programming Interface (API)を通じてアクセス可能でなければならない。

手動ネットワーク管理との類比では、これは主にネットワーク設計を定義するネットワークアーキテクト、ネットワークスキーマ、または新しいネットワーク展開のBOMを定義するネットワークプランナーの役割に相当する。

理想的には、このコンポーネントはデータが複数のデータソースに分散していても、望ましい状態の一貫した統合されたビューを提供すべきだ。これらのデータソースは、システムオブレコード（SoR）と呼ぶが、データの実際の所有者だ。これが最初に明確にすべきことの一つだ。データソースが一つだけというのは極めてまれだが、統合されたとき一貫性がなければならない。データ管理は複雑なトピックで、タイムスタンプ、データの出所、データの所有権、有効期間などのメタデータを含むデータガバナンス機能が、このデータの理解と管理を助けるために必要だ。

さらに、信頼できるネットワーク自動化を可能にする機能に関連して、このブロックは予測可能で信頼性の高いネットワーク自動化プロセスを可能にするデータへのトランザクション的かつバージョン管理されたアクセスを提供すべきだ。

このカテゴリに当てはまる実際のツールを理解しようとするなら、いくつかの例を挙げる：CSV/YAML/JavaScript Object Notation (JSON)ファイル、Git、NetBox、Nautobot、Infrahub、Infoblox、または汎用データベース。

信頼できる情報源の構築と管理については第4章で深く掘り下げる。

3.2.2. エグゼキューター（Executor）#

エグゼキューターは、SSH、NETCONF、gNMI/gNOI、REST APIなどのさまざまなインターフェースを介してネットワークと対話し、インテントから来る望ましい状態を実際のネットワーク状態に実装（書き込み）する役割を担う。

手動ネットワーク管理との類比では、エグゼキューターは最終的なネットワーク設定を準備し、CLIを通じてネットワークデバイスに接続して設定コマンドを入力するネットワークエンジニアに相当する。

しかし、これはインテントというある場所からネットワークという別の場所へデータをコピーアンドペーストするほど単純ではない。ネットワーク変更からシステムの再起動やアップグレードまで、考慮すべき操作は多い。また、参照データがほとんどの場合インテントブロックから来るが、観測されたデータがオブザーバビリティからこのコンポーネントに影響を与える場合もあるため、両方を組み合わせる必要がある。

例えば、エグゼキューターは変更を試みる前にデバイスの到達可能性を検証したり、現在のネットワーク状態に基づいてフェイルオーバーロジックを適応させたり、オブザーバビリティが重要な依存サービスがダウンしていることを示している場合に実行をスキップしたりするかもしれない。オブザーバビリティからのこのフィードバックにより、自動化の決定がインテントだけでなく、リアルタイムのネットワーク状態に基づいて行われることが保証される。

インテントと同様に、このコンポーネントはドライラン、トランザクション的な変更、冪等性（宣言的または命令的アプローチを通じて）などの機能を提供すべきで、ネットワークエンジニアが依存できる自動化システムの構築を支援する。これは通常、ネットワークエンジニアが（最初は）最も関心を持つコンポーネントで、実際にネットワークを「変更する」ものだからだ。

このカテゴリに主に当てはまるツールはAnsible、Terraform/OpenTofu、またはNetmiko、Scrapli、Napalmなどのライブラリを活用するあらゆる種類のスクリプト、またはKubernetes CRD（カスタムリソース）だ。

実行フレームワーク、冪等性パターン、実装戦略については第5章を参照してほしい。

3.2.3. コレクター（Collector）#

エグゼキューターと類比して、コレクターはさまざまなインターフェースとプロトコル（エグゼキューターと同じインターフェースに加えて、SNMP、Syslog、またはその他のフローベースのテレメトリ）を介してネットワークから実際の運用データを取得する役割を担う。

このすべてのデータの目的地は、データが自動化の意思決定を支援するために使用されるオブザーバビリティブロックだ。

ここで通常考慮されない重要なトピックは、比較可能であるために正規化されたデータの必要性だ。すべてのベンダーで一貫したメトリック名（プラットフォームに関係なくOSバージョンを定義するsystem_version）と高度なデータ処理を可能にする一貫したメタデータが重要だ。

このカテゴリに当てはまるツールの例はTelegraf、Vector、gNMIc、PMACCT、goFlow、Akvorado、またはネットワークからデータを取得するためにライブラリを活用するあらゆる種類のスクリプトだ。

親和性から、コレクターは次の構成要素であるオブザーバビリティと一緒に第6章で扱う。コレクターとオブザーバビリティはアーキテクチャ的には別物だが、運用上は切り離せない。データをどのように収集するかについての設計上のすべての決定は、オブザーバビリティレイヤーが処理する必要があるものによって決まる。一緒に扱うことで、その依存関係が保たれる。

3.2.4. オブザーバビリティ（Observability）#

コレクターと密接に関連し（多くの場合一緒に見られる）、オブザーバビリティは収集されたデータを受け取り、その永続化をサポートし、高度な分析、レポーティング、トラブルシューティングワークフローをサポートするためのプログラマティックアクセスを提供する。理想的には有能なクエリ言語（PromQLなど）を使用して。

このブロックからのデータは、ネットワークのDesired StateとActual Stateの間の関連する不一致を公開し、緩和システムをトリガーするイベント（またはアラート）を生成しなければならない。

手動ネットワーク管理の類比では、これはネットワークの実際の状態を確認し適切に対応するネットワーク運用センターの役割に当てはまる。

さらに、観測されたデータは意図された状態からの文脈情報で補完でき、他のサードパーティソース（EoL情報、CVE、メンテナンス通知など）も含め、分析を強化してより正確なデータ相関を可能にする。

従来のネットワーク監視では、オブザーバビリティ（と収集）のすべての機能は一つの大きな箱に統合されていた（Nagios、LibreNMS、Spectrumなどのツール）。

現在は、PrometheusやInfluxDBなどのTime Series Database (TSDB)、アラートを管理するAlertmanager、可視化するGrafanaやKibanaなどの関連システムを統合するより多様なシステムが普及している。これにより、ELK、TIG、TPGなどの人気のあるスタックが生まれた。

監視アーキテクチャ、アラート戦略、オブザーバビリティのベストプラクティスについては第6章で詳しく学べる。

3.2.5. オーケストレーター（Orchestrator）#

ここまでで多くの異なるコンポーネントを見てきたが、それらを調整する必要がある。異なる構成要素のプロセスを統合し、洗練されたエンドツーエンドの自動化ワークフローを作成する。このため、オーケストレーターは手動トリガーから完全なイベント駆動ワークフローまで、同期と非同期の両方で、複数の方法での対話をサポートしなければならない。

オーケストレーターが実装するワークフローは、複数のステップを定義する方法を提供し、他のコンポーネントに依存して（例えばインテントブロックからバージョン管理されたスナップショットを使用して）ロールバックとドライラン機能をサポートしなければならない。

手動の運用では、これは通常、従うべきプロセスのチェックリストとして大まかに定義される。

このコンポーネントは、異なるプロセスがどのように組み合わさるかを明確なログと追跡可能性を通じて示し、ネットワーク自動化全体で何が起きているかの包括的な可視化をユーザーに提供する。

ここでの例はAAPやAWX（Ansible Automation Platform）、Windmill、Prefectだ。

AIとエージェントがアーキテクチャのどこに位置するか： AIを活用した意思決定は主にオーケストレーターとオブザーバビリティブロックの交点に位置する。AIエージェントはセンス・ロジック・アクトのループに従う。オブザーバビリティブロックを通じてネットワーク状態を観測し、何のアクションが必要かを決定するための推論を適用し、オーケストレーター経由でエグゼキューターをトリガーする。これはオーケストレーターの従来の役割（事前定義されたワークフローに従う）とは異なるが、同じインフラを使用する。第7章（オーケストレーション、7.2.7節）では、エージェントアプローチを調整パターンとして扱う。第15〜17章では、それを自律ネットワークの基盤として探る。今は、エージェント型自動化を静的なワークフロー定義を動的なモデル駆動の意思決定に置き換える調整アプローチと考えてほしい。

ワークフロー設計、イベント駆動自動化、オーケストレーションプラットフォームについては第7章を参照してほしい。

3.2.6. プレゼンテーション（Presentation）#

ネットワーク自動化のユーザーに適切なインターフェースを公開することがいかに重要かを、ときに忘れてしまう。これは通常、境界線が曖昧な領域だ。紹介してきたすべてのツールには何らかのインターフェースがあるからだ。CLI、API、またはウェブベース。場合によっては、それで十分だと判断することもある。また、すべてのいいとこ取りをしてユーザー体験をシンプルにするために独自のユーザーインターフェースを作成することもある。場合による。

従来、外部ユーザーに対しては電話またはメールに、ネットワークチームに対してはCLIに限定されていた。

どちらにしても、このレイヤーは柔軟な認証と認可を許可し（システムのエントリーポイントだ）、実際のニーズに応じて調整しなければならない。場合によってはネットワーク固有のプラットフォームになることもあり、場合によっては会社全体のシステム（ServiceNow、Slackなど）と統合することもある。

ロールに応じて書き込みまたは読み取り操作をカバーするかもしれないが、最良の結果を得るために常に異なるタイプのユーザーのニーズを考慮する。

ユーザー体験、インターフェース設計、統合パターンについては第8章を参照してほしい。

3.2.7. ネットワーク（The Network）#

最後に、しかし重要なこととして、自動化をサポートするためのネットワークの能力を理解しなければならない。そしてネットワークはもはやデバイスとケーブルが接続されたものだけではない。2020年代では、仮想化とクラウドベースのネットワークソリューションにより、エンドツーエンドの到達可能性（ネットワーク）はハイブリッドで多様な環境になっている。

ネットワーク自体は自動化アーキテクチャ全体の制約であり、同時に実現者でもある。前の6つのブロックとは異なり、制御できるものだが、ネットワークインフラ（デバイス、プラットフォーム、サービス、接続性）には可能なことに影響する制限がある可能性がある。

ネットワーク能力はいくつかのカテゴリに分類される：

  • インターフェースとプロトコル：ネットワークはどの管理インターフェースをサポートしているか？SSH CLI？NETCONF？gNMI？REST API？SNMP？プラットフォームによって多くをサポートするものもあれば、少ししかサポートしないものもある。これらの選択がコレクターとエグゼキューターが何をできるかを直接制限する。
  • データモデル：デバイスがgNMIをサポートしていても、公開するYANGモデルが不完全かもしれない。例えば、デバイスはgNMIサポートを主張しているが、管理する必要がある特定の設定を公開していない場合がある。これらのギャップを理解することは計画中に重要だ。
  • 運用上の成熟度：新しいプラットフォームは最新のAPIを持っているが、文書化されていない動作がある場合がある。古いプラットフォームは安定しているかもしれないが、APIが全くない場合がある。宣伝されている機能だけでなく、実際の成熟度を評価する必要がある。

自動化を効果的にサポートするために、ネットワークインフラは理想的に以下を提供すべきだ：

  • 開発とテスト環境：ソフトウェア開発と同様に、自動化はテストするための安全な場所が必要だ。これはラボネットワーク（多くの場合、高価で限定的）、仮想ネットワーク環境（Containerlab、GNS3）、またはベンダー提供のシミュレーター（Cisco DevNet、Arista EOS-lite）を意味するかもしれない。
  • 一貫したインターフェース：デバイスの90%がNETCONFをサポートしているが、10%がSSHのみをサポートしている場合、標準化するか複数のエグゼキューターを構築するかのどちらかが必要だ。すべての不一貫は複雑さを増やす。
  • 適切なテレメトリ：デバイスから必要なデータが得られなければ、オブザーバビリティは意味をなさない。デバイスが必要な粒度と情報でテレメトリをストリーム（ストリーミングテレメトリ、SNMP、Syslog）できることを確認する。

ネットワークはアーキテクチャの中で最も変更が難しい部分だ。ルーターを簡単に交換することはできない。だから制約を早期に理解し、その中で自動化を設計する。これがネットワークブロックがアーキテクチャ計画中に慎重な注意を払うに値する理由だ。

ネットワーク能力、デバイスAPI、テスト環境については第9章を参照してほしい。

次に、このセクションをまとめるために、非常にシンプルなユースケースとアーキテクチャがそれにどのようにマッピングされるかを見ていこう。

3.2.8. 実践的な例#

各ブロックに深く入る前に、アーキテクチャがどのように連携するかを示す具体的なシナリオを見ていこう。

問題: アプリケーションチームが新しいアプリケーションセグメントのリクエストを提出した。新しいVLAN、IPサブネット、ルーティングポリシー、アクセスコントロールゾーンを、Cisco、Arista、HPEから約800台のアクセスおよびディストリビューションスイッチが稼働する異種混在のキャンパスネットワーク全体に展開する。運用チームは何百ものデバイスへの手動CLIなしにエンドツーエンドで対応する必要がある。

アーキテクチャによる解決方法：

  1. インテント（信頼できる情報源）: ネットワークエンジニアがNautobotに新しいサービス定義を入力する。VLAN ID、サブネット、ルーティングポリシー、ベンダーごとの設定テンプレート、適用するスイッチグループ。これは800台のデバイスの単一の真実の場所としてDesired Stateとして保存される。
  2. Orchestrator（オーケストレーター）: AWXがNautobotから変更に関するWebhookを受け取り、実行ワークフローをトリガーし、正しい順序でステップを調整してデバイスごとの失敗を処理する。
  3. Executor（エグゼキューター）: AnsibleプレイブックがNautobot Application Programming Interface (API)から読み取り、ベンダーごとにデバイス固有の設定をレンダリングし（Cisco、Arista、HPEはそれぞれ異なる構文が必要）、NETCONF経由で変更をプッシュする。各実行は冪等性を持つ。すでに設定済みのスイッチで再実行しても変更は生じない。
  4. Collector（コレクター）: デプロイ後、gNMIcコレクターが各スイッチに接続し、実際のVLANメンバーシップ、インターフェース状態、ルーティングエントリーを取得する。
  5. Observability（オブザーバビリティ）: 収集されたデータがPrometheus Time Series Database (TSDB)に流れる。クエリがインテントからのDesired StateとコレクターからのActual Stateを比較する。VLANが欠落しているスイッチがメトリクスとして公開され、アラートをトリガーする。
  6. Orchestrator（オーケストレーター）: アラートが発火すると（「access-switch-b3-07でVLAN 210が見つからない」）、AWXワークフローが自動的にそのスイッチでエグゼキューターを再実行し、データを再収集し、修正を検証する。
  7. Presentation (Layer)（プレゼンテーション）: ダッシュボードが建物とベンダーでグループ化された800台のスイッチすべてを表示し、準拠しているもの（✅）とドリフトしているもの（❌）を強調表示する。アプリケーションチームはCLIアクセスなしにロールアウトを追跡できる。IT運用チームはコードを書かずに手動修復をトリガーできる。
  8. ネットワーク: このフローの成功はデバイスが実際にサポートするものに依存する。CiscoとAristaではNETCONFがきれいに機能する。一部のHPEスイッチはSSH CLIのみをサポートするため、別のエグゼキューターパスが処理する。洗練度は低いが必要だ。どんなアーキテクチャもベンダーの制約を取り除かない。ただし制約を明示的にする。

重要な洞察: 単一のツールがこれを実現したわけではない。Nautobot（インテント）、Ansible（エグゼキューター）、gNMIc（コレクター）、Prometheus（オブザーバビリティ）、AWX（オーケストレーター）、Grafanaダッシュボード（プレゼンテーション）が連携した。アーキテクチャがそれらを統合するためのメンタルモデルを提供した。

これがアーキテクチャ的思考が可能にするもの：体系的で組み合わせ可能な自動化。

第2部（第4〜9章）を通じて、同じキャンパスネットワークに戻り、各構成要素を深く探る。SoTがVLANサービス定義を保存し（第4章）、エグゼキューターがそれをデプロイし（第5章）、オブザーバビリティが監視し（第6章）、オーケストレーターが完全なライフサイクルを調整し（第7章）、プレゼンテーションレイヤーが異なる聴衆に公開し（第8章）、ネットワーク章がシミュレーションベースの本番前ゲートで締めくくる（第9章）。信頼できる情報源ツールを参照する例では、NautobotとNetBoxは同義で使用される。アーキテクチャパターンはどちらを選択しても同じだ。

3.3. アーキテクチャの使い方#

NAFネットワーク自動化アーキテクチャのさまざまな構成要素を理解したところで、「実際にどのようにプロジェクトで始めればよいのか？」と思っているかもしれない。

3.3.1. 採用のための段階的アプローチ#

参照アーキテクチャは処方箋ではない。自動化ソリューションを考え整理するためのフレームワークだ。以下は適用するための実践的で段階的なアプローチだ：

flowchart LR
    A[現在の状態を理解する]:::phase1 --> B[自動化の道筋を計画する]:::phase2
    B --> C[より良いツールと設計の決定をする]:::phase3
    C --> D[統合を考慮して設計する]:::phase4
    D --> E[ステークホルダーとコミュニケーションする]:::phase5
    E --> F[段階的に進化する]:::phase6

    classDef phase1 fill:#e0f7fa,stroke:#333,stroke-width:2px;
    classDef phase2 fill:#b2ebf2,stroke:#333,stroke-width:2px;
    classDef phase3 fill:#80deea,stroke:#333,stroke-width:2px;
    classDef phase4 fill:#4dd0e1,stroke:#333,stroke-width:2px;
    classDef phase5 fill:#26c6da,stroke:#333,stroke-width:2px;
    classDef phase6 fill:#00bcd4,stroke:#333,stroke-width:2px;

フェーズ1：現在の状態を理解する

まず既存のツールとプロセスをアーキテクチャブロックにマッピングする。このアセスメント演習はギャップ、重複、改善の可能性がある領域を特定する助けになる：

  • データが複数のシステムに散らばっているか？
  • ネットワーク状態を効果的に収集しているか、それとも手探りで進んでいるか？
  • 現在どのように変更を実行しているか？手動で？場当たり的なスクリプト？整理されたフレームワーク？

優れた実行能力を持ちながらオブザーバビリティが貧弱だと発見したなら、次に解決すべき影響の大きな問題を特定したことになる。

フェーズ2：自動化の道筋を計画する

アーキテクチャを使って自動化のロードマップを導く。すべてのブロックを一度に実装する必要はない。最も重要な課題に対処するコンポーネントから始める：

  • 設定ドリフトに悩んでいるなら、インテント/信頼できる情報源と実行に焦点を当てる。
  • 問題を素早く検出できないなら、コレクターとオブザーバビリティを優先する。
  • 自動化が断片的で信頼性が低いなら、オーケストレーションに投資する。
  • ユーザーが変更のリクエスト方法に困惑しているなら、プレゼンテーションを改善する。

アーキテクチャの完全性ではなく、ビジネスへの影響で優先順位をつける。

フェーズ3：より良いツールと設計の決定をする

新しいツールを評価したり、カスタムソリューションを構築する際は、自問してほしい：

  • これはどのアーキテクチャブロックに役立つか？
  • 他のコンポーネントとうまく統合できるか？
  • ブロック間にどんなデータフローが必要か？

これによりツールの乱立を防ぎ、自動化エコシステムが一貫性を保てる。また、構築すべきか購入すべきかも明確になる。ツールが1つのブロックにきれいに収まり、明確に定義されたインターフェースを持っていれば、通常は構築よりも購入の方が良い。

フェーズ4：統合を考慮して設計する

コンポーネント間の境界を理解することで、より良いインターフェースを設計できる。重要な原則：コンポーネントはお互いの内部を知る必要がない。

  • エグゼキューターはインテントがデータをどのように保存するかを知る必要がない。望ましい状態を照会するための明確に定義されたAPIだけが必要だ。
  • オーケストレーターはAnsibleを使っているかTerraformを使っているかを気にすべきではない。ただ実行をトリガーして結果を監視する。
  • オブザーバビリティシステムはコレクターの内部を知る必要がない。明確なメトリクスとイベントだけが必要だ。

この疎結合が各コンポーネントを独立して進化させることを可能にする。

フェーズ5：ステークホルダーとコミュニケーションする

アーキテクチャは異なる聴衆と自動化について話し合うための共通言語を提供する：

  • 経営陣へ：「MTTRを下げるためにオブザーバビリティの体制を強化している。」
  • チームへ：「コレクターがオブザーバビリティにデータを送る方法を標準化しよう。」
  • 他部門へ：「プレゼンテーションレイヤーがあなたのITSMインスタンスと統合する。」

明確なアーキテクチャの言語は混乱を減らし、賛同を得る助けになる。

フェーズ6：段階的に進化する

アーキテクチャはニーズの変化に応じてコンポーネントを交換できる：

  • 今日はGitを信頼できる情報源として使用しているかもしれないが、明日は明確なインターフェースを維持する限り、自動化ワークフローを完全に再設計することなくNetBoxやInfrahubに移行できる。
  • シンプルなスクリプトをオーケストレーターとして始め、後でAAPやWindmillに置き換えることもできる。
  • オブザーバビリティで1つのTSDBから別のTSDBに移行しても、コレクターがデータを取得する方法は変えなくていい。

この段階的なアプローチはリスクを最小化し、進みながら学ぶことを可能にする。

過剰エンジニアリングの罠に陥らないよう注意してほしい。目標はアーキテクチャの純粋さではなく、現実の問題を解決する実践的な自動化だ。時に最良のソリューションは複数のアーキテクチャブロックにまたがるシンプルなスクリプトだ。アーキテクチャはガイドであり、拘束衣ではない。

重要な教訓：アーキテクチャを思考を整理し、ギャップを特定し、意図的な設計上の決定を下すためのメンタルモデルとして使う。すべての実装の詳細を指定する厳格なテンプレートとしてではなく。

3.3.2. 避けるべき一般的な落とし穴#

率直に言おう。失敗はする。しかし他の人から学ぶことで多くの苦労を節約できる。一般的な落とし穴を挙げる：

  1. すべてを一度に実装しようとすること

    「このアーキテクチャが良いなら、7つのブロックすべてを完璧に構築すべきだ」と考えたくなるものだ。それは完成前に時代遅れになる大規模な複数年プロジェクトにつながる。

    より良いアプローチ: 最も緊急の問題を解決する1つか2つのブロックから始める。段階的に構築する。初期の成功がモメンタムと賛同を生む。

  2. 「すべてを解決する唯一のツール」を信じること

    一部のベンダーはプラットフォームがすべてをこなすと主張する。それが本当だとしても、多くの場合：

    • 彼らのやり方に縛られる
    • 後でコンポーネントを交換できない
    • 必要のない機能にお金を払っている

    より良いアプローチ: 各ブロックに最適なツールを選ぶが、明確なAPIと統合ポイントがあることを確認する。3〜5つのツールを統合する必要があるかもしれないが、柔軟性が得られる。

  3. ネットワークの制約を無視すること

    gNMIを使った美しいエグゼキューターを設計したが、デバイスの30%がSSH CLIのみをサポートしている。またはストリーミングテレメトリを望んでいるが、古いプラットフォームはSNMPのみをサポートしている。

    より良いアプローチ: まずネットワークインフラの能力を理解する。これらの制約がアーキテクチャを形作る。物理の法則は無視できないし、デバイスが実際に何をできるかも無視できない。

  4. インターフェースが単純だと思い込むこと

    「エグゼキューターはインテントのAPIを呼び出して望ましい状態を取得するだけだ」と言う。しかしインテントはカスタム拡張を持つNetBoxを使い、エグゼキューターはフラットなYAMLを期待する。突然、変換レイヤーを書いている。

    より良いアプローチ: 明確でよく文書化されたインターフェースに早い段階で投資する。可能な場合は標準を使用する（REST API、gRPC、明確なスキーマ定義）。良いインターフェースは今のコストが後の変換レイヤーのコストより低い。

  5. 良いツールが存在するのにカスタムツールを構築すること

    チームが「どのツールも私たちのニーズを正確に満たさない」という理由でカスタムコレクターを構築することを決定する。6ヶ月後、独自のテレメトリパイプラインを維持する3000行のコードがある。

    より良いアプローチ: まず既存のツールを評価する（Telegraf、Vector、gNMIc）。それらはユースケースの80%を処理し、実績がある。必要に応じてカスタマイズするかアダプターを構築するが、ゼロから構築しない。

  6. オブザーバビリティを後回しにすること

    多くのチームがインテントとエグゼキューターに集中し、ネットワークで実際に何が起きているかが見えないことに手遅れになってから気づく。オブザーバビリティは最後に後付けされる。

    より良いアプローチ: 初日からオブザーバビリティを計画する。どんなメトリクスを収集するか？ドリフトをどのように検出するか？どんなアラートが重要か？エグゼキューターを構築する前にこれらに答える。

  7. ユーザーを忘れること

    エンジニアが強力なオーケストレーターを構築するが、ユーザーがそれと対話できる唯一の方法がCLIコマンド経由。非技術系ユーザーは混乱し、採用が悪くなる。

    より良いアプローチ: ユーザーのことを早い段階で考える。彼らはどんなインターフェースが必要か？API？Web UI？ServiceNow統合？プレゼンテーションレイヤーが採用の成否を決めることがある。

これらの落とし穴は理論的なものではない。実際の自動化プロジェクトからのパターンだ。今それらから学ぶことでアーキテクチャが強化される。

3.3.3. どこから始めるか#

アーキテクチャは7つのブロックを定義している。誰も7つすべてを一度に実装しない。実際には、2つの開始パターンが実際のデプロイメントの大部分を占める。

パターンA：設定駆動の始め方（最も一般的）

すでに手動で設定を管理していて、そのプロセスを一貫性があり自動化されたものにしたいチーム。インテントとエグゼキューターから始める。信頼できる情報源を構築し、そこからデプロイするプレイブックを作成する。実行が安定して実際にデプロイされたものへのフィードバックが必要になったらオブザーバビリティを追加する。

flowchart LR
    A[インテント / SoT] --> B[エグゼキューター] --> C[オブザーバビリティ] --> D[オーケストレーター] --> E[プレゼンテーション]
    style A fill:#4a9eff,color:#fff
    style B fill:#4a9eff,color:#fff
    style C fill:#7db8f7,color:#fff
    style D fill:#b8d4f5,color:#333
    style E fill:#ddeeff,color:#333

パターンB：可視性駆動の始め方

主な課題がネットワークの現在の状態を把握できないことであるチーム。コレクターとオブザーバビリティから始める。まずデータパイプラインを構築し、実際に何がデプロイされているかを理解し、それに対してデプロイするための信頼できる状況が得られたらインテントとエグゼキューターを追加する。

flowchart LR
    A[コレクター] --> B[オブザーバビリティ] --> C[インテント / SoT] --> D[エグゼキューター] --> E[オーケストレーター]
    style A fill:#4a9eff,color:#fff
    style B fill:#4a9eff,color:#fff
    style C fill:#7db8f7,color:#fff
    style D fill:#b8d4f5,color:#333
    style E fill:#ddeeff,color:#333

両方のパターンで、オーケストレーターとプレゼンテーションはコアのデータフローが安定した後に来る。信頼性の高いインテントまたは実行の前にオーケストレーターから始めるのは時期尚早だ。調整する意味のあるものがまだない。プレゼンテーションは内部チームが自動化を使用していて、直接のAPIまたはCLIアクセスではなく適切なインターフェースが必要になったときに重要になる。

これらは出発点であり、設計図ではない。制約（既存のツール、チームのスキル、最も緊急の課題）が順序を決定すべきだ。重要なのは、すべてを並行して構築して何も完成させないのではなく、意図的に出発点を選ぶことだ。

3.3.4. チーム間でブロックを所有する#

7つのブロックはアーキテクチャ上の問いと同様に組織上の問いを生む。誰が何を所有し、複数のチームがどのようにお互いの邪魔をせずに同じプラットフォームを共有するか？

中規模から大規模な組織で最も一般的なモデルは2つのグループに分かれる。プラットフォームチームは自動化インフラ自体を所有する。SoTスキーマとAPI、オーケストレーターランタイム、オブザーバビリティパイプライン、プレゼンテーションレイヤー、共有のコレクターインフラ。これらは組織の残りが依存するコンポーネントだ。プラットフォームチームの仕事はそれらを信頼性が高く、バージョン管理され、利用可能に保つことだ。ネットワーク運用チーム（または技術領域ごとに1つの複数のドメインチーム）は自動化のコンテンツを所有する。プラットフォームの上で動くプレイブック、ワークフロー定義、意図されたデータ、ビジネスロジック。彼らはプラットフォームを使用する。維持はしない。

この分割はブロックの境界がチームの境界にどのように変換されるかに影響する。SoTは共有プラットフォームリソースだが、異なるチームは異なる書き込み権限を持つ。IPアドレスチームはIPAMデータを所有するかもしれない。キャンパスチームはスイッチのインベントリを所有するかもしれない。セキュリティチームはファイアウォールポリシーデータを所有するかもしれない。SoTのTerm "rbac" not foundモデルはこれらの所有権の境界にマッピングされなければならない。間違ったドメインへの書き込みは起きかけている運用インシデントだ。

オーケストレーターも同様だ。プラットフォームチームはランタイムとワークフロー実行フレームワークを所有し、運用チームはワークフロー定義を所有する。ワークフロー定義はオーケストレーターのUIで直接編集されるのではなく、デプロイ時にオーケストレーターによってプルされる運用チームの所有権の下でバージョン管理に置かれるべきだ。これによりプラットフォームチームと運用チームがお互いの作業を妨げないようにする。

プレゼンテーションはさらに所有権の問いを分ける。他の自動化ツールが使用する内部APIはプラットフォームの関心事だ。アプリケーションチーム向けのセルフサービスポータルは専用のツールチームや共有サービスグループに属するかもしれない製品の関心事だ。これらの境界を早い段階で定義することで、すべてのチームが同じ基盤となるプラットフォームへの独自の場当たり的なインターフェースを構築する状況を防ぐ。

自動化プラットフォームの運用の組織的な次元（チームがどのように組織化されるか、製品思考が内部ツールにどのように適用されるか、プラットフォームチームが内部コンシューマーとのコントラクトをどのように管理するか）については、第10章（プラットフォームエンジニアリング）と第13章（文化とコラボレーション）で深く掘り下げる。ここで行うアーキテクチャ上の選択、特にSoT RBACスコープとオーケストレーターワークフローの所有権は、それらの章が説明する組織モデルを直接制約する。

3.4. まとめ#

アーキテクチャ的思考は実際に機能するネットワーク自動化を構築するために不可欠だ。OSIモデルがネットワークを理解するための階層的フレームワークを与えてくれるように、参照アーキテクチャは保守可能で、スケーラブルで、信頼性の高い自動化システムを整理し設計する助けになる。

この章ではNAFフレームワークを紹介した。7つの重要な構成要素を定義している。アーキテクチャは厳格な処方箋ではなく、柔軟なフレームワークだ。それを使って現在の状態を評価し、自動化の道筋を計画し、情報に基づいたツールの決定を下し、ステークホルダーとコミュニケーションし、統合を考慮して設計し、段階的に進化する。覚えておいてほしいのは、目標はアーキテクチャの純粋さではなく、現実の問題を解決する実践的な自動化だということだ。

本書の第2部では、これらの各構成要素を深く掘り下げ、自分の自動化プロジェクトに適用できる実装パターン、ベストプラクティス、実世界の例を探る。

💬 Found something to improve? Send feedback for this chapter