· 2881 words · 14 min read

4. Source of Truth#

新しいサービスを週末までに本番稼働させる必要があった。変更内容は単純だった。新しいVLAN、新しいサブネット、ファイアウォールルールの更新、エッジルーターへのBGPコミュニティの追加。担当のネットワークエンジニアは何をすべきかを正確に把握していた。ところが実際には、5つのシステムにまたがる4日間の調整作業が待っていた。サブネットを予約するIPAMツール、サービスを登録するCMDB、新しいポリシーを適用するファイアウォール管理プラットフォーム、BGPコミュニティを設定するルーター構成システム、そして新しいしきい値を追加する監視プラットフォーム。各システムはそれぞれ独自のインターフェース、独自のデータモデル、独自の承認ワークフローを持っていた。共通の参照点がなかったため、エンジニアは手動でコンテキストを持ち回るしかなかった。あるシステムから値をコピーして次のシステムに貼り付け、途中でデータが変わっていないことを祈りながら。

6カ月後、そのサービスは廃止された。VLANは削除され、サブネットも解放された。しかしファイアウォールルールはそのまま残った。そのルールがそのサービスに紐付いていたことを誰も覚えていなかった。BGPコミュニティは2台のエッジルーターに残り続けた。監視のしきい値は低優先度のアラートを出し続けたが、NOCはいつしかそれを無視することを学んでいた。時間とともに、ネットワークには孤立した設定が積み重なっていった。完全に追跡されず、完全に削除されず、共通の意図の記録に紐付けられることもなかった変更の残骸が。

これが、Source of Truth なしにネットワークを運用するということの実態だ。一度の劇的な障害ではなく、じわじわと積み重なる不整合。すべての変更が複数の分断されたシステムの更新を必要とし、何が関連しているかを追い続けるものが何もない状態。

すべての自動化システムは一つの問いから始まる。実際に何をしようとしているのか? ファイアウォールルールを展開するとき、IPアドレスを追加するとき、VLANを設定するとき、あなたは何らかのインテントの表現に基づいて行動している。その表現こそが Source of Truth だ。つまり、何が展開されるべきかを示す、唯一の信頼できるバージョン。

「Source of Truth」と「Intent」は本書では同じ意味で使用している。概念としてまったく同一だ。

信頼できる Source of Truth なしでは、ネットワーク運用は属人的な知識の塊になってしまう。エンジニアは何が展開されているかで意見が食い違う。スプレッドシートは実際に動いているものと矛盾する。2つの異なる自動化システムが同じデバイスに対して競合する変更を加える。何かが壊れると、考古学者のような作業が始まる。「なぜこう設定されているのか? 誰が承認したのか? いつ変わったのか?」

本章では、デバイスが数十台であれ数十万台であれ機能し、データを必要とするすべての人(人間、自動化、他のシステム)に提供し、データの正確性と信頼性を維持し、複数のソースからのデータ収集の複雑さを処理できる Source of Truth の構築方法を解説する。6つの構成要素を取り上げる。Modeling、Consumption、Enforcement、Versioning、Aggregation、Design-Driven だ。これらが組み合わさることで、ネットワーク自動化の堅固な基盤が生まれる。既存のネットワークをこのシステムに取り込む際の実践的な課題にも触れ、実際に利用可能なソリューションも紹介する。

4.1. 基本原則#

Source of Truth は3つのことを行う。インテントをどう表現するかの方法を定義し、そのインテントがどこに存在するかを定め、それを長期にわたって信頼できる状態に保つ方法を確立する。これがなければ、他の構成要素は共通の参照点を持たない単独ツールの集まりになってしまう。これがあれば、それらは連携して機能する。

4.1.1. ゴール#

Source of Truth が果たすべき6つの役割がある。

必要なすべてを把握する。ネットワークの全体像を保存する。設定、資産、トポロジー、サービス、IPアドレス、回線、デバイス仕様、認証情報、メンテナンスウィンドウ、コンプライアンス要件、所有者情報。現在稼働しているものだけでなく、計画中のものと廃止予定のものも含める。このデータがスプレッドシートや担当者の頭の中ではなく一か所に集まって初めて、自動化システムは賢い判断を下すために必要なコンテキストを手にできる。
オペレーターがビジネスの言葉で考えられるようにする。スタッフはビジネスレベルで作業すべきだ(「新しいブランチを追加する」や「MPLSサービスをセットアップする」など)。Command Line Interface (CLI) レベルで作業するのではなく。裏側で、システムが実際のデバイス固有の設定を導き出す。こうすることで、人は低レベルの詳細ではなく、達成しようとしていることに集中できる。
人とシステムが簡単にデータにアクセスできるようにする。自動化がデータを取得・更新できるよう Application Programming Interface (API)(Representational State Transfer (REST), GraphQL)が必要だ。人間が閲覧・編集できるよう Web UI と Command Line Interface (CLI) も必要だ。すべての人に対して、見るべきものだけが見えるアクセス制御が必要だ。数百の自動化ワークフローが同時に動き、数十のスタッフがデータを編集し、外部システムが同期していても、一貫性とパフォーマンスが保たれる必要がある。
データをクリーンで信頼できる状態に保つ。すべてを検証する。データ型の確認、関係の整合性確認、VLANの有効範囲確認、IPアドレスの重複チェック。誰が何をいつ変更したかを追跡する。重要な変更は反映前に承認を得られるようにする。何か問題が起きたらロールバックできるようにする。自動化はデータが正確であることを信頼しなければならない。なぜなら、不正確なデータはネットワークの不正な状態と障害につながるからだ。
複数のチームが互いの邪魔をせずに並行して作業できるようにする。複数のチームが同時に変更を提案できるべきだ。変更はアトミックなまとまりにグループ化される。すべて反映されるか、すべて失敗するかのどちらかで、中途半端な状態はない。変更は本番適用前にステージング環境でテストできる。大規模な移行では、ブランチを切って作業し、マージして戻すことができる。現在適用されているインテントと提案中のインテントが常に区別できる。
他のシステムからデータを取り込む。おそらくすでに、ハードウェア管理のための資産管理システム、アドレス管理のためのIPシステム、接続管理のための回線プロバイダー、サービス管理のためのCMDBなどがある。それらを重複させる必要はない。代わりに同期させる。どのシステムがどのデータを所有するかを明確なルールで定める。双方向で同期し続ける。これにより、一から作り直すことなく、すべての統合ビューが得られる。

4.1.2. 柱#

この6つの柱は独立した機能ではなく、階層的なアーキテクチャを形成する。Modeling は何を表現できるかを定義する。Design-Driven はその表現を技術的な成果物に変換する。Consumption はそれらの成果物を必要とするすべてのシステムに提供する。Enforcement はデータが入力時に信頼できる状態を保つ。Versioning はインテントの記録を時系列で保存し、ロールバックと監査を可能にする。Aggregation は、すでにデータを所有している既存システムから権威あるデータを取り込むことで、SoT がまた別の孤立したサイロになることを防ぐ。

どれか一つを取り除けば、他の機能が劣化する。Enforcement がなければ、Consumption は不正なデータを提供する。Versioning がなければ、何かが壊れたときに何が変わったかを把握する手段がない。Aggregation がなければ、オペレーターはシステム間でデータを重複管理することになり、SoT への信頼が失われる。セクション 4.2 では各機能を詳しく解説する。

6つの機能の詳細に入る前に、Source of Truth のスコープを明確にしておこう。

4.1.3. スコープ#

実装の詳細に入る前に、Source of Truth が責任を持つ範囲とそうでない範囲を理解しておくことが重要だ。

スコープ内:

Source of Truth はすべてのインテントデータを管理する。つまり、ネットワークがどうあるべきかの完全な定義だ。本番設定、ステージング環境、開発ブランチ、テストシナリオが含まれる。「何を望むか」を表すすべてのものがここに存在する。

スコープ外:

Source of Truth がカバーしないことがいくつかある。一見関連しているように見えるものもある。

オブザーバビリティデータ: Source of Truth はメトリクス、ログ、ランタイムの状態を保存しない。ただし、アラートのしきい値やベースラインのパフォーマンス数値など、比較対象となる期待値は定義する。実際のオブザーバビリティデータは別の場所に存在する(第6章で説明)。
ネットワークとのやり取り: Source of Truth はデバイスと通信したり設定をプッシュしたりしない。必要な成果物(デバイス設定、検証ルール、デプロイメントマニフェスト)を提供するが、それを実行するのは Executor の仕事だ(第5章)。
オーケストレーションロジック: Source of Truth は変更を展開するためのステップの順序やワークフローを定義しない。意図された最終状態を定義する。そこへの到達方法(どのデバイスを先に、どの検証ステップを、ロールバック手順は)は Orchestrator が担う(第7章)。

Source of Truth はネットワーク自動化戦略の北極星だと考えてほしい。「ネットワークはどうあるべきか?」という問いに対する唯一の権威ある答えだ。自動化システムのその他すべて(実行、監視、オーケストレーション)は、自分の仕事をするためにこの Truth を参照する。現実がインテントから乖離したとき、Source of Truth が現実がどうなるべきかを教えてくれる。

4.2. 機能#

では、これらすべてを実際に実装する6つの機能について話そう。

それぞれがゴールと柱に対応している。

Modeling: 何のデータを保存し、それらがどう関連するかを定義する。デバイスモデル、インターフェース、VLAN、回線、サービス。ニーズの変化に合わせて進化させられるようにする。
Design-Driven: テンプレートとロジックを通じて、高レベルのインテントを実際のデバイス設定に変換する。
Consumption: 人とシステムが実際にデータを取得・利用する方法。Application Programming Interface (API)、Web UI、Command Line Interface (CLI)。全員が役割に応じたアクセス制御を持つ。
Enforcement: 不正なデータが紛れ込まないようにする。検証、一意性チェック、参照整合性。明確なエラーメッセージ。
Versioning: 完全な履歴を保持する。誰が何をいつなぜ変更したか。必要に応じてロールバック。
Aggregation: 他のシステム(CMDB、IPAMなど)からデータを取り込み、同期を維持する。

graph LR

    %% --- Subgraphs ---
    subgraph ゴール
        direction TB
        A1[必要なすべてを把握する]
        A2[オペレーターがビジネスの言葉で考えられるようにする]
        A3[人とシステムが簡単にデータにアクセスできるようにする]
        A4[データをクリーンで信頼できる状態に保つ]
        A5[複数のチームが並行して作業できるようにする]
        A6[他のシステムからデータを取り込む]
    end

    subgraph 柱
        direction TB
        B1[柔軟なデータモデリングフレームワーク]
        B2[設計とテンプレート]
        B3[APIとインターフェース]
        B4[データ検証]
        B5[変更履歴]
        B6[データ集約]
    end

    subgraph 機能
        direction TB
        C1[Modeling]
        C2[Design-Driven]
        C3[Consumption]
        C4[Enforcement]
        C5[Versioning]
        C6[Aggregation]
    end


    %% --- Row connections ---
    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3
    A4 --> B4 --> C4
    A5 --> B5 --> C5
    A6 --> B6 --> C6

    %% --- Row gradient classes ---
    classDef row1 fill:#eef7ff,stroke:#4a90e2,stroke-width:1px;
    classDef row2 fill:#ddeeff,stroke:#4a90e2,stroke-width:1px;
    classDef row3 fill:#cce5ff,stroke:#4a90e2,stroke-width:1px;
    classDef row4 fill:#b3d8ff,stroke:#4a90e2,stroke-width:1px;
    classDef row5 fill:#99ccff,stroke:#4a90e2,stroke-width:1px;
    classDef row6 fill:#80bfff,stroke:#4a90e2,stroke-width:1px;

    %% --- Apply classes per row ---
    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;
    class A4,B4,C4 row4;
    class A5,B5,C5 row5;
    class A6,B6,C6 row6;

以下は Intent ブロックのアーキテクチャ概要図だ。

graph TB

    %% Tier 1
    subgraph T1[外部]
        A[Consumption]
    end

    %% Tier 2
    subgraph T2[データ]
        B[Design-Driven]
        D[Modeling]
    end

    %% Tier 3
    subgraph T3[エンジン]
        C[Aggregation]
        E[Enforcement]
        F[Versioning]
    end

    %% Tier connections
    A <--> B
    A <--> D

    B <--> D

    D <--> C
    D <--> E
    D <--> F

4.2.1. Modeling#

データモデルは非常に重要だ。何を表現できるか、そしてどれだけ容易に扱えるかを決定する。統計学者のジョージ・ボックスが言ったように「すべてのモデルは間違っているが、一部は役に立つ」。誰にとっても完璧に機能するモデルなど存在しない。私の経験では、データモデリングは科学よりも技芸に近い。ただ、成功しているプロジェクトには一定のパターンが繰り返し現れる。

4.2.1.1. 基本原則#

データをどう整理するかは重要だ。 何を表現できるか、そしてシステムがそれをどれほど効率的に検証・利用できるかを決定する。フォーマットによってトレードオフが異なる。YAML は読みやすいが検証が手薄だ。JavaScript Object Notation (JSON) はどこでも使えるが冗長だ。Yet Another Next Generation (YANG) は検証機能を追加できるが学習コストが高い。実際に必要なものを基準に選ぶべきだ。

フォーマット	ユースケース	強み	トレードオフ
YAML	設定、人間による編集	読みやすく簡潔	スキーマ検証が限定的
JavaScript Object Notation (JSON)	Application Programming Interface (API)、ドキュメント保存	ツールと生態系が充実	人間には冗長
XML	標準ベースの交換	XSLT処理、スキーマ定義	構文が重い
Protocol Buffers	パフォーマンス、シリアライズ	コンパクト、バージョニング	バイナリ形式、コード生成が必要
YANG	ネットワークデバイスモデリング	業界標準(RFC 6020)、階層的な制約	学習コストが高い

データには異なるレベルが存在する。 同じネットワークの要素を、目的に応じて複数の方法で表現できる。

サービスレベル: ビジネスに親しみやすい表現(「ブランチXにMPLS L3VPNを設定する」)
技術レベル: 技術的な仕様(「BGP AS 65001、ルートターゲット 65001:100、ポリシー…」)
デバイスレベル: 実際の設定(「interface xe-0/0/0; unit 100;…」)

優れたモデルはこれらの層をつなぐ。ビジネスレベルから始めて、デバイス設定を自動的に生成できる。ただし、常に3層すべてが必要なわけではない。何を構築しているかによる。

4.2.1.2. データの永続化とスケール#

モデルデータの保存方法の選択は、一貫性、パフォーマンス、および進化に深い影響を与える。ネットワークが管理対象オブジェクト数百から数十万に成長するにつれて、これらの影響は非常に重大になる。

リレーショナルデータベース(例: MySQL、PostgreSQL): ほとんどのチームにとって安全な選択肢であり、それは称賛の意味で言っている。スキーマの一貫性を強制し、ACIDトランザクションを提供し、チームの全員がすでにSQLを知っている。正規化された階層(インターフェースを含むVLAN)の表現や、データの異常を防ぐことに優れている。欠点はスケール時のスキーマ変更が痛みを伴うことと、数百万行にわたる深いJOINでパフォーマンスが低下することだ。ただし、それは良い問題だ。つまり実際に何かをデプロイしたということだから。
ドキュメントデータベース(例: MongoDB、CouchDB): スキーマの柔軟性と水平スケーラビリティが必要な場合に優れる。ドキュメントはネストされた構造を自然にモデル化できる(デバイスとすべての設定・メタデータをひとつのまとまりとして)。ただし落とし穴がある。ドキュメント間の一貫性を自分で管理する必要があり、複雑なクエリはすぐにコストが高くなる。ドキュメントベースにする具体的な理由がない限り、リレーショナルを使うべきだ。
グラフデータベース(例: Neo4j): オブジェクトより関係の方が重要な場合に本領を発揮する。「このインターフェースはどのVLANに接続しているか? これら2拠点間でルーティングしているデバイスは?」といった任意の深さの関係を効率よく辿れる。ただし、複雑なトポロジークエリが常に必要でない限り、稀少な選択肢を選ぶことになる。運用チームが知らない、ツールの成熟度が低い、単純な更新での書き込みパフォーマンスが劣る。グラフデータベースは実際の問題を解決するが、自分が本当にその問題を抱えているかどうかを確認してから選ぶべきだ。

flowchart TD
    Q1{主要な要件は?}
    Q1 -->|深い関係を辿る必要がある| Q2{トポロジークエリが常時必要?}
    Q1 -->|スキーマが頻繁に変化する| DB_D[ドキュメントストア]
    Q1 -->|構造化クエリと参照整合性| DB_R[リレーショナルデータベース]
    Q2 -->|はい| DB_G[グラフデータベース]
    Q2 -->|ときどき| DB_R

    style DB_R fill:#ccffcc,stroke:#28a745
    style DB_G fill:#cce5ff,stroke:#4a90e2
    style DB_D fill:#ffffcc,stroke:#ffc107

データの永続化については、別の視点からオブザーバビリティの章でも取り上げる。

データベースの選択は、この分野の製品間での主要な差別化要因のひとつだ。例えば、NetBox と Nautobot はリレーショナルデータベースを使用し、Infrahub はグラフデータベースを使用している。詳細はセクション 4.2.8 を参照。

永続化は、YAML や JavaScript Object Notation (JSON)(またはCSV)のようなデータモデルを持つファイルベースのストレージで実装することもでき、バージョン管理のためにGitシステムで追跡されることが多い。

多くの本番 Source of Truth システムはポリグロット永続化を採用している。権威あるインテントと関係にはリレーショナルデータベースを、柔軟性とキャッシュにはドキュメントストレージやGitを、トポロジー分析にはグラフ機能を使う。

モデルの粒度はどれくらいにすべきか? これはパフォーマンスに影響する。すべてのデバイスのすべてのインターフェースを個別のオブジェクトとしてモデル化すると、中規模のネットワークで50,000以上のオブジェクトが生まれる。クエリが遅くなり、更新が苦痛になる。

実践的なアプローチは共通パターンにテンプレートを使うことだ。「インターフェース1〜40はこの標準テンプレートを使用する」と定め、例外だけを追跡する。40個のオブジェクトではなく2個のオブジェクトになり、クエリは高速のまま、レンダリングも機能する。

第11章では、このような判断がパフォーマンスにどう影響するかをさらに詳しく扱う。

4.2.1.3. ネットワークデータドメイン#

包括的な Source of Truth の実装では、通常以下の相互に関連するドメインをモデル化する。

インベントリと資産: 物理・論理デバイス、ハードウェア仕様、シリアル番号、調達日、契約条件、ライフサイクルステージ
データセンターインフラ: 拠点(地理的・階層的)、建物、フロア、部屋、ラック、電力分配、ケーブルルート
IPアドレス管理(IPAM): アドレスプール、サブネット、割り当て、DNS解決、DHCPスコープ、使用率追跡
仮想化とクラウド: VPC、サブネット、セキュリティグループ、コンピュートインスタンス、ストレージ、コンテナオーケストレーションとの関係
接続性: 物理回線(MPLS、Ethernet)、仮想トンネル、ピアリング関係、帯域幅割り当て、QoSポリシー
ルーティング: BGPコミュニティ、自律システム、ルーティングポリシー、プレフィックスリスト、L3VPNサービスのルートターゲット
サービス: 論理サービス定義(L3VPN、L2VPN、ファイアウォール通過)、サービスとデバイスのマッピング、SLA
セキュリティとコンプライアンス: アクセス制御リスト、ファイアウォールルール、セキュリティゾーン、コンプライアンスタグ、監査要件
管理: SNMPの詳細、gNMIサブスクリプション、NTPソース、syslogターゲット、TACACS+/RADIUS連携

これらのドメインは相互依存している。Routing は Connectivity を参照し、Services は Inventory と IPAM にまたがり、Security ポリシーはデバイスとサービスの両方に適用される。よく設計されたSoTは、各ドメインを独立したテーブルとして扱うのではなく、これらの関係を明示的にモデル化する。

graph TD
    INV[インベントリと資産]
    DC[DCインフラ]
    IPAM[IPアドレス管理]
    VIRT[仮想化とクラウド]
    CONN[接続性]
    ROUTE[ルーティング]
    SVC[サービス]
    SEC[セキュリティとコンプライアンス]
    MGMT[管理]

    DC --> INV
    INV --> IPAM
    INV --> MGMT
    CONN --> INV
    VIRT --> IPAM
    ROUTE --> CONN
    SVC --> INV
    SVC --> ROUTE
    SVC --> IPAM
    SEC --> INV
    SEC --> SVC

    classDef foundation fill:#ddeeff,stroke:#4a90e2,stroke-width:2px
    classDef overlay fill:#e8f5e9,stroke:#28a745
    classDef policy fill:#fff3cd,stroke:#ffc107
    class INV,IPAM,CONN foundation
    class ROUTE,VIRT,DC,MGMT overlay
    class SVC,SEC policy

ネットワーク固有のドメイン以外にも、多くのデータ型が必要だ。例えば、認証情報を保存するシークレットバックエンド。より広い意味では、包括的なデータ管理はグローバルなITインフラ管理システムの一部に収まる。

多くのチームが議論するよくある疑問を共有したい。NetBoxのようなネットワーク固有のデータソースを使うか、ServiceNowのような汎用のものを使うか、という問題だ。私の経験では、同様の成果を達成することは技術的には可能だが、ServiceNowが会社全体のシステムであるという事実が、進化を難しく(そして遅く)する。その結果、ネットワークチームが完全なネットワーク表現のために活用し始めるのが遅れる。

データの分類と共通属性

ネットワークドメイン全体で、特定の分類パターンが一貫して現れる。よく設計されたモデルには、一貫したデータ操作を維持するためにこれらの基本的な属性が含まれている。

Role(役割): このオブジェクトはどんな目的を果たすか?(コア、ディストリビューション、アクセス; プライマリ、セカンダリ)
Status(状態): アクティブ、計画中、廃止予定、または廃止済みか?
Kind(種別): どんな種類のオブジェクトか?(VLAN、デバイス、回線、サービス)
Ownership(所有者): どのチームや事業部が管理しているか?
Location(場所): このリソースは地理的または組織的にどこにあるか?

4.2.1.4. モデル設計パターン: 拡張性、ポリモーフィズム、マイグレーション#

一部のソリューションは、作成者がネットワークはこうあるべきという考えに基づいた組み込みモデルを提供している。自分のネットワークがその前提に合致していれば素晴らしいが、そうでなければ問題になる。一方、ゼロから構築できるソリューションもある。柔軟性は高いが規律が必要だ。通常、最善のアプローチはハイブリッドだ。一般的なケース(全員が行う80%)には組み込みモデルを使用し、自分固有のニーズのために拡張できることを確認する。

スペクトル: 規約的モデルからカスタムモデルへ

ここにはスペクトルがあり、自分がどこに位置するかを理解する価値がある。

高度に規約的なモデル(例: デフォルト設定のNetBox):
- 長所: デプロイが速い、意思決定が少ない、組み込みのベストプラクティス
- 短所: ネットワークが型にはまらない場合に苦痛、モデルの変更が難しい
完全カスタムモデル(Infrahubのようにゼロから構築):
- 長所: 固有のニーズに完璧にフィット、無駄なフィールドがない
- 短所: 設計に時間がかかる、試行錯誤が多い、参考にできる前例が少ない(参考資料はある)

Infrahubは完全にカスタムなモデルの構築を可能にするが、最初から使える規約的なモデルも同梱されている。

どこから始めるべきか? 誰にでも言うことがある。NetBox、Nautobot、Infrahub のような規約的なモデルを持つツールから始めることだ。以上。自分のネットワークがどれほど特殊だと思っていても関係ない。「自分たちの完璧なモデルを構築する」チームは2年経っても設計中だ。一方、これらのツールを使うチームはとっくに有効なモデルを何カ月も前に出荷している。

あなたはGoogleではない(もしかしたらそうかもしれないが)。多くの場合、ハイパースケールクラウドを構築しているわけではない。既存のものを使い、実際の限界(想像上の限界ではなく)に達したら拡張し、機能するものを出荷することだ。

もちろん、非常に特殊なネットワークのユースケースがあらかじめ予測できる場合は、どのツールがそれをよりよくサポートするかを検討してもよい。ただし、最初からすべてをゼロから再発明することはしないように。

重要な判断基準は一つだけだ。書き直さずに拡張できるか? 「コストセンター」を追跡するカスタムフィールドを追加するためにスキーマ全体を再構築しなければならないなら、そのツールは見送るべきだ。20分でカスタム属性として追加できるなら、適切なツールを見つけた。

80%の標準化と20%の柔軟性(自分固有の現実への対応)が理想だ。「無限の柔軟性」を謳うものは、設定に無限の時間がかかる。

ポリモーフィズム: ひとつのモデル、多くのバリエーション

すべてのインターフェースが同じではない。物理的な光ポートとトンネルインターフェースは共通のプロパティを持つが、本質的に異なるものだ。それぞれに完全に別々のモデルを作ることもできるが、すぐに煩雑になり使い勝手も悪くなる。

より良いアプローチは、共通点をカバーする共有ベースモデルを定義し、異なる詳細のための特化したバリアントを作ることだ。

# すべてのインターフェースはこれらの基本情報を共有する
interfaces:
  - name: "eth0"
    type: "physical"
    status: "up"
    mtu: 1500
    ipv4_address: "192.0.2.1/24"

# 物理的な光ポートには追加情報がある
  - name: "eth0"
    type: "physical_optical"
    status: "up"
    mtu: 1500
    ipv4_address: "192.0.2.1/24"
    optics_module: "100GBASE-LR4"
    tx_power_dbm: -2.5
    rx_power_dbm: -8.3
    laser_temperature: 48.2

# そしてトンネルは内部が全く異なる
  - name: "tun-vpn-dallas"
    type: "tunnel_gre"
    status: "up"
    mtu: 1476
    ipv4_address: "10.0.0.1/30"
    tunnel_source: "203.0.113.1"
    tunnel_destination: "198.51.100.5"
    tunnel_encap: "GRE"
    tunnel_key: 100

こうすることで、スクリプトは「このデバイスのすべてのインターフェース」をクエリするときに、光ポートなのかトンネルなのかを気にする必要がない。ただし、光ポート固有の詳細(TX電力の読み取りなど)が必要なときは、特化したフィールドにアクセスできる。将来新しいインターフェースタイプを追加する必要があっても問題ない。新しいバリアントを追加するだけだ。

モデルは変化する: それに備えよ

ネットワークは数十年にわたって存在する。モデルは静的ではいられない。新しいフィールドを追加し、物事の関係を変更し、機能しなくなったものを廃止する。しかし、スイッチをひとつ切り替えて古いスキーマで動いているすべてのものを壊すわけにはいかない。

モデルが変わると、多くの下流のものが壊れる可能性がある。バリデーターは新しいルールが必要になり、APIが返すものが変わり、データベースのクエリは特定の列の存在を前提にしており、テンプレートは異なるフィールドパスが必要になり、レポートは古い構造に対して書かれている。それらすべてが適応するか、少なくとも致命的に壊れないようにする必要がある。物事を壊さずに変更を処理する方法を以下に示す。

削除する前に非推奨とマークする。 フィールドをなくす場合は、2〜3リリース前に全員に通知する。移行のための猶予期間を与える。
移行期間中はフィールドエイリアスをサポートする。 古いコードが device_name を要求している? 裏で hostname にルーティングする。APIは引き続き機能し、人々は自動化を更新する時間を持てる。
マイグレーションヘルパーを作成する。 データを再構築する場合(インターフェースをフラットなリストからデバイス配下のネストに移動するなど)、作業をこなすスクリプトを提供する。
データに依存するすべてのものでテストする。 スキーマ変更をロールアウトする前に:
- APIは古い方法でデータを返すか?(エイリアス経由で)
- テンプレートはまだレンダリングされるか?
- SQLクエリはまだ機能するか?
- 外部システムとの連携は受け取るものをまだパースできるか?
本番環境でしばらく混在バージョンが存在することを想定する。 大規模な組織では、3つの異なるスキーマバージョンのデバイスが同時に存在することが多い。
```
150 devices on schema 1.9 (old)
300 devices on schema 2.0 (current)
50 devices on schema 2.1 (beta testing)
```

システムは3つすべてを壊さずに処理できる必要がある。その複雑さは価値がある。ネットワークは、不注意なスキーマ変更で壊してはならないほど重要なものだからだ。

4.2.1.5. 設定テンプレート#

テンプレートは抽象的なインテント(「VLANが欲しい」)を実際の Command Line Interface (CLI) コマンドに変換する。重要なルールがある。テンプレートにはロジックが含まれ、データは含まれない。テンプレートは「データモデルからVLAN IDを使い、ここに出力する」と言う。実際のVLAN IDはデータから来るのであって、テンプレートからではない。これによりデータの可搬性とテスト可能性が保たれる。Jinja2 は人間が読みやすく、PythonやAnsibleと統合されており、実際のネットワークに実用的なため人気がある。ただし、これが唯一の選択肢ではない。有効な代替手段は多数ある。

例えば、インターフェースのデータ構造が与えられた場合:

interfaces:
  - name: Ethernet1
    description: Uplink to core
    enabled: true
  - name: Ethernet2
    description: Server port
    enabled: false

そして、このCLI設定のJinja2テンプレート:

# Interfaces
{% for iface in interfaces %}
interface {{ iface.name }}
  description {{ iface.description }}
  {% if iface.enabled %}
  no shutdown
  {% else %}
  shutdown
  {% endif %}
{% endfor %}

以下のCLI出力が生成される。

# Interfaces
interface Ethernet1
  description Uplink to core
  no shutdown
interface Ethernet2
  description Server port
  shutdown

データと設定成果物の間の明確な関心の分離に注目してほしい。

Jinja の興味深い代替として、複数のデータ機能を統合する CUE 宣言型設定言語がある。

YAMLのような生データ
JSON Schema のようなデータバリデーション/スキーマ(詳細はEnforcementセクションで)
Jinjaのような動的なデータ生成

CUE は設定を、Jinjaのような緩く構造化されたテキストではなく、型付きで合成可能な、不変条件が強制されたデータとして扱う。

4.2.2. Design-Driven#

デバイスが50台、VLANが30個なら、個別に管理できる。各VLANを作り、各インターフェースを設定し、各IPを手動で割り当てる。面倒だが、なんとかなる。

デバイスが5,000台、サービスが数百になると、手動管理は不可能だ。新しいブランチオフィスを追加するだけで、拠点ごとに100以上の設定項目を手動で指定しなければならない。Design-Drivenの構成要素がこれを解決する。オペレーターは高レベルで望むものを記述し(「ブランチを追加する」)、システムがそれを完全な技術仕様に展開する。

4.2.2.1. ビジネスインテントから技術データへ#

シナリオ例 - 「ダラスにブランチオフィスを追加する」:

ビジネスインテント(高レベル):

{
  "type": "branch_office",
  "location": "dallas-tx",
  "site_code": "DAL-01",
  "circuit_count": 2,
  "employee_count": 50,
  "applications": ["erp", "voip", "video"]
}

設計処理

flowchart LR
    A[ビジネスインテント]
    B[テンプレート適用]
    C[リソース割り当て]
    D[ロジック解決]
    E[詳細レンダリング]
    F[Executor向けオブジェクト]

    A --> B --> C --> D --> E --> F

    style A fill:#fff3cd,stroke:#ffc107
    style B fill:#ffe6cc,stroke:#fd7e14
    style C fill:#d4edda,stroke:#28a745
    style D fill:#cce5ff,stroke:#4a90e2
    style E fill:#e2d9f3,stroke:#6f42c1
    style F fill:#d1ecf1,stroke:#17a2b8

フェーズ	タスク
1. テンプレート適用	サイトオブジェクトを作成リージョンのIPAM委任プールからサブネットを割り当てデータ、音声、ゲスト用VLANを作成セキュリティゾーンとファイアウォールルールを定義
2. リソース割り当て	サイト向け次の利用可能なサブネット /22: 10.15.0.0/22 次の利用可能なVLAN範囲: 2010-2014 次の利用可能なBGPコミュニティ: 65001:2010
3. ロジック解決	従業員数 < 100人? はい → スモールオフィステンプレート冗長回線が必要? はい → BGPネイバーを2つ作成アプリケーション = [erp, voip]? はい → ファイアウォールポリシーを追加
4. 詳細レンダリング	PEデバイス設定(BGPセットアップ、ルートターゲット、音声用QoS) CEデバイス設定(LANインターフェース、VLAN、NTP) ファイアウォールポリシー(ERPトラフィックを許可、音声を優先) オフィスサービスのDNSエントリ監視設定(SNMP、syslog、アラート)
5. 出力	デプロイ準備完了の50以上の設定オブジェクト

これにより、少ない労力の高レベルなインテントが包括的な技術詳細に変換される。

4.2.2.2. 設計パターンと再利用可能なビルディングブロック#

効果的な設計システムはパターンライブラリに依存する。

ネットワーク設計パターンライブラリ

パターン	コンポーネント
スモールブランチオフィス	単一のエッジルーター(バックアップで冗長化) 2〜3つのVLAN(データ、音声、ゲスト) バックアップBGPピアを持つ単一のMPLS VPN 音声用QoS(EF、AFクラス) ファイアウォールルール: ERPとVoIP以外はアクセス制限
ミディアムリージョナルハブ	冗長エッジルーター(アクティブ/スタンバイ) 10〜15のVLAN(部門別+ゲスト+OOB) 複数のMPLS VPN(一部はアプリケーションごとにカスタム) 高度なQoS(6クラス) 高度なファイアウォールポリシー(アプリケーション層)
データセンターエッジ	4重冗長のClosトポロジー 100以上のVLAN(顧客ごとに自動生成) BGP unnumbered、マルチパス自動VLAN割り当て

各パターンには実績のあるアーキテクチャの判断がエンコードされている。そこからの逸脱には明示的な承認が必要だが、パターンの展開は通常の運用と見なされるべきだ。

4.2.2.3. 設計の再現性を確保する#

問題がある。月曜日にサイトを設計し、VLAN 100を割り当てる。火曜日に別のサイトを設計し、VLAN 101を割り当てる。しかし、6カ月後に月曜日の設計を検証のために再実行すると、VLAN 100がすでに使用済みなので、システムはVLAN 102を割り当てるかもしれない。

これは再現可能ではない。解決策は、設計リクエストを行うたびに、どの設計にどのリソースが割り当てられたかを記録することだ。同じリクエストが再度来ても、同じVLANが得られる。これにはリクエストとリソースのマッピングを恒久的に追跡し、常に同じ順序で割り当てることが必要だ。

決定論的な割り当て順序: 常に同じ順序で候補を反復する
アトミックな割り当て: リソース予約はアトミックで、部分的な割り当ては不可能

これが多くの設計システムがコンテンツアドレッサブルストレージ(設計のハッシュ)を使用して一貫性を確保する理由だ。

4.2.2.4. レンダリングとビルドの区別#

設計システムは2つのフェーズを分離する。

フェーズ	入力	出力	副作用	答えられる問い	ユースケース
レンダリング	高レベルの設計	技術仕様	なし - リソース割り当てなし、変更プッシュなし	「何が作られるか?」「エラーはあるか?」「提案されたデータ展開を確認できるか?」	承認前のレビュー検証テスト変更範囲の見積もり
ビルド	レンダリングされた仕様	実際の変更(IPコミット、VLAN作成、設定プッシュ、監査証跡)	Atomic Operation、Idempotency、監視可能、ロールバック可能	「実際に何がデプロイされたか?」「いつ行われたか?」「ロールバックできるか?」	本番デプロイリソース予約実行ワークフローのトリガー

ビルドなしのレンダリングをサポートすることで以下が可能になる。

コミット前の安全な検証
リスクなしのWhat-if分析
チームレビューと承認ワークフロー
テスト環境での先行ステージング

4.2.2.5. 設計のバージョニングと進化#

ネットワーク設計は時間とともに進化する。新しいパターンが生まれ、ツールが改善される。2020年の設計は2025年のアップデートが必要になるかもしれない。

設計バージョニングの課題:

設計バージョン1(2020年): ブランチオフィステンプレート: シングルルーター、2つのVLAN
設計バージョン2(2023年): ブランチオフィステンプレート: デュアルルーター(冗長性)、4つのVLAN、セキュリティ強化

バージョン1でデプロイされたブランチはどうなるか?

旧バージョンのまま継続稼働? (セキュリティ負債)
すべてのブランチを強制アップグレード? (変更リスク)
段階的な移行? (運用の複雑さ)

解決策:

バージョニング付きのDesign-as-code

designs/
  ├─ branch_office_v1.yaml (deprecated 2023-01-01)
  ├─ branch_office_v2.yaml (current)
  └─ branch_office_v2_beta.yaml (testing)

Sites:
  - site: DAL-01
    design: branch_office_v2 (references specific version)
    design_parameters: {...}

これにより以下が可能になる。

各サイトを生成した設計バージョンを正確に把握
段階的な移行(サイトごとに更新)
v2に問題があった場合にv1へのロールバック
ロールアウト前にステージングでv3をテスト

スノーフレーク対応

ほとんどのサイトはdesign_v2テンプレートを使用するが、サイトDAL-01には特別な要件がある。

追加のラックスペース(古い建物の制約)
特殊なIPアドレッシング(レガシーの割り当て)
カスタムファイアウォールルール(歴史的なビジネス要件)

解決策:

ベースとしてdesign_v2をデプロイ
サイト固有のオーバーライドを適用
オーバーライドを個別に追跡(スノーフレークを文書化)

これにより以下を防ぐ。

テンプレートへの例外の組み込み(設計を汚染する)
例外の手動設定(時間とともにドリフトする)
例外が存在する理由のコンテキスト喪失

4.2.3. Consumption#

データベースに閉じ込められたデータは役に立たない。Consumptionレイヤーは、人とシステムが実際にデータを手にする方法だ。使いやすければ賛同が得られる。使いにくければ、人々はそれを迂回する方法を見つける。

4.2.3.1. API設計とセキュリティ#

異なるAPIスタイルは異なる消費パターンに対応する。現在最もよく使われるものをいくつか挙げる。

APIスタイルの比較

インターフェース	リクエストパターン	ユースケース	強み	トレードオフ
Representational State Transfer (REST)	リソースURLへの Hypertext Transfer Protocol (HTTP) 動詞(GET、POST、PATCH、DELETE)	汎用CRUD	シンプル、広く理解される、ステートレス	複数のリクエストが必要な場合がある; Versioning の課題
GraphQL	単一エンドポイント、クライアントが必要なフィールドを指定	複雑なマルチリソースクエリ	柔軟、クライアント主導、過剰フェッチを削減	サーバー実装がより複雑、N+1クエリのリスク
gRPC	HTTP/2上のProtobufベースRPC	高パフォーマンス、低レイテンシ	双方向ストリーミング、バイナリ効率性、RESTより10〜100倍高速	学習コスト、ブラウザサポートが限定的
Webhooks	サーバーが登録エンドポイントに変更をプッシュ	リアクティブ自動化、リアルタイム同期	非同期、疎結合、ポーリングのオーバーヘッドなし	配信の不確実性、リトライの複雑さ、セキュリティの課題

効果的な消費戦略は複数のインターフェースを組み合わせることが多い。

人間に優しいシンプルな操作にはREST
認可フィルタリング付きの複雑なマルチドメインクエリにはGraphQL
大量の自動化にはgRPC/ストリーミング
リアクティブな下流システムにはWebhooks

MCP(Model Context Protocol)について 従来のAPIスタイルに加えて、Model Context Protocol(MCP)などの新興インタラクションモデルにより、AIエージェントが構造化されたツール指向の方法でシステムと連携できるようになっている。RESTやgRPCがトランスポートとリクエストのセマンティクスを定義するのとは異なり、MCPはエージェント駆動のワークフローにおける安全なケイパビリティディスカバリー、コンテキスト的なデータ取得、および制御されたアクション実行に焦点を当てている。このパターンは、自動化された推論システムがテレメトリ、設定、および修復ツールへの構造化されたアクセスを必要とするAI支援オペレーションやオブザーバビリティのユースケースで特に重要だ。まだ進化中だが、MCPはリソース中心のAPIからエージェント指向のインタラクションモデルへの転換を表している。

重要なルールが一つある。認証と認可はAPIレイヤーで行い、下流では行わない。 これにより、セキュリティホールを防ぎ、監査が適切に機能する。

セキュリティへの影響については第12章で詳しく扱う。

4.2.3.2. API運用: バージョニング、パフォーマンス、キャッシング#

APIが設計・セキュリティ確保されたら、進化とパフォーマンスに関する運用上の懸念が重要になる。

APIバージョニングと進化

ネットワークは長期にわたるインフラだ。自動化システムは運用ワークフローを壊さずに進化しなければならない。

URLバージョニング: /api/v1/devices と /api/v2/devices は別々の実装を維持する
- 長所: 明示的、デバッグしやすい、クライアントがアップグレード時期を選択できる
- 短所: 複数の実装を維持する必要がある(これは実は良いことで、移行計画を強制する)
ヘッダーバージョニング: 同じエンドポイント、Accept: application/vnd.company+json; version=2 でバージョンを指定
- 長所: 単一エンドポイント、URLがきれい
- 短所: ログで見えない、デバッグが難しい、クライアントが頻繁に間違える

どちらの方法でも、廃止ヘッダーで6〜12カ月前に破壊的変更を告知する。

Deprecation: true
Sunset: Mon, 01 Jan 2026 00:00:00 GMT
Link: <https://docs/migration>; rel="deprecation"

URLバージョニング /api/v1/devices と /api/v2/devices を推奨する。ドキュメントではヘッダーバージョニングの方がきれいに見えるかもしれない。しかし、深夜3時に何かが壊れてログをgrepしているとき、リクエストヘッダーを掘り起こしてどのAPIバージョンが問題を引き起こしたかを把握するより、/v1/ か /v2/ かをすぐに確認できる方がずっといい。将来のオンコール担当の自分が感謝するだろう。

パフォーマンスとキャッシング

一つずつデータを消費することは一部のユースケースではうまく機能するが、スケールが大きくなると最終的にパフォーマンスの限界に達する。

バルク操作により、単一のAPI呼び出しで何千ものオブジェクトを更新できる。これはスケールには不可欠だが、トレードオフがある。

単一オブジェクトAPI: POST /api/devices/device メリット: すべての変更を検証、オブジェクトごとに明確なエラーメッセージコスト: 10,000デバイスの更新 = 10,000のAPIリクエスト + ラウンドトリップ = 数分
バルクAPI: POST /api/devices/bulk-update メリット: 10,000件の更新に単一のラウンドトリップ、バックエンド処理を並列化可能コスト: 検証の省略(高コストなチェックをスキップ)、オブジェクトごとのエラー報告が難しい

データ消費を改善する他の代替手段として、スコープを制限する方法がある。

ページネーションとフィルタリングにより、クライアントが誤って数百万のオブジェクトをメモリに読み込んだりタイムアウトしたりするのを防ぐ。 GET /api/devices?location=datacenter-1&status=active&limit=100&offset=0
カーソルベースのページネーションは、大規模なデータセットを扱う際にオフセットベースよりも優れている。分散システムでより効率的で、リクエスト間でデータが変更されても一貫性が保たれる。
キャッシング戦略でパフォーマンスを大幅に改善できる。
- サーバーサイドキャッシング: 「場所Xのすべてのデバイス」のRedisキャッシュを、その場所のいずれかのデバイスが変更されたときに無効化
- クライアントサイドキャッシング: HTTP ETagによりクライアントがキャッシュデータを再フェッチせずに検証できる
- 検証レイヤーバイパス: 読み取り専用クエリでは検証チェックをスキップ
レート制限によりバックエンドの過負荷を防ぐ。例えば:
- ユーザーごとに毎秒10リクエスト
- APIキーごとに毎分1,000リクエスト
- バックプレッシャーシグナル(HTTP 429)でクライアントにスローダウンを通知

4.2.3.3. コンテキスト対応データモデリング#

人によって必要なものは異なる。ネットワークエンジニアはデータを検索・発見し、バリデーションフィードバック付きで特定のフィールドを編集し、関係を確認したい。自動化ワークフローはAPI、トランザクション、Webhookを必要とする。運用チームはタスク中心のビューと監査証跡を求める。ビジネスは技術的な詳細なしでレポートを必要とする。外部システムは双方向でデータを同期する必要がある。

消費ブロックのユーザーインターフェースはプレゼンテーション層に属することに注意。詳細は第8章で扱う。

データは各消費者のコンテキストに適応する必要がある。例えば、すべてのデバイスの詳細をすべての人物に公開する必要はない。コンテキスト対応のカスタマイズにより、データ消費がより効率的かつ効果的になる。

ネットワークエンジニアはインターフェースとルーティングの詳細が必要だ。財務部門はコストと保証情報を求める。セキュリティはコンプライアンスゾーンを必要とする。500のフィールドすべてを全員に返す代わりに、各消費者が必要とするものだけを提供する。APIクエリパラメータ(?view=network_engineer)またはGraphQLでクライアントが特定のフィールドをリクエストする方法でこれを実現できる。

課題: 一つのデータモデルがすべての消費者に対応することはできない

SoT内の単一デバイスオブジェクトが数百の属性を持つとする。

ハードウェアの詳細(モデル、シリアル番号、ファームウェアバージョン)
ネットワーク設定(IPアドレス、VLAN、ルーティングプロトコル)
運用メタデータ(場所、コストセンター、保証有効期限)
サービス関係(このデバイスを使用している顧客)
セキュリティコンテキスト(コンプライアンスゾーン、アクセスポリシー)

異なる消費者はこのデータの根本的に異なるビューを必要とする。

例: 異なるコンテキストにおけるデバイス「router-core-01」

消費者	コンテキスト	データ表現	主要属性
ネットワークエンジニア	接続性のトラブルシューティング	ネットワーク中心のビュー	インターフェース、IPアドレス、BGPピア、ルート、VLAN、アップリンク状態
財務チーム	コスト配賦	ビジネス中心のビュー	コストセンター、減価償却スケジュール、保証状態、購入日、ベンダー
セキュリティチーム	コンプライアンス監査	セキュリティ中心のビュー	コンプライアンスゾーン、アクセスポリシー、最終セキュリティスキャン、パッチレベル、未解決の脆弱性
自動化ワークフロー	設定デプロイ	実行中心のビュー	管理IP、認証情報参照、デバイスプラットフォーム、設定テンプレート名
サービスカタログ	顧客影響分析	サービス中心のビュー	提供中の顧客、ホストしているサービス、SLAティア、冗長グループ

実装パターン

ビューベースの変換: APIクエリが希望のコンテキストを指定し、サーバーがそれに応じてデータモデルを変換

GET /api/devices/router-core-01?view=network-engineer
→ Returns: {interfaces: [...], bgp_peers: [...], vlans: [...]}

GET /api/devices/router-core-01?view=finance
→ Returns: {cost_center: "...", warranty_expiry: "...", purchase_cost: ...}

GraphQLフィールド選択: 消費者が必要なフィールドのみを明示的にリクエスト

query NetworkEngineerView {
  device(name: "router-core-01") {
    interfaces { name, ip_address, status }
    bgp_neighbors { peer_ip, state }
  }
}

query FinanceView {
  device(name: "router-core-01") {
    cost_center
    purchase_date
    warranty_expiration
  }
}

プロジェクションレイヤー: バックエンドが特定のアクセスパターンに最適化された派生ビューを計算
- ネットワークトポロジーグラフ: デバイスをノード、接続をエッジとして(トポロジー可視化用)
- サービス依存関係ツリー: サービス → デバイス → コンポーネントの階層ビュー(影響分析用)
- コンプライアンスマトリクス: ゾーン別にグループ化されたデバイスとポリシー準拠状態(監査用)
ドメイン固有言語(DSL): ユーザーのメンタルモデルに合わせた専用のクエリ言語
- ネットワークエンジニア: 「datacenter-1でBGPセッションがダウンしているすべてのデバイスを表示する」
- 財務: 「2025年Q3に購入したデバイスの月次減価償却を計算する」
- セキュリティ: 「PCIゾーンで重大なCVEを持つデバイスをリストアップする」

コンテキスト対応モデリングのメリット

メリット	影響	例
認知的負荷の軽減	ユーザーはタスクに関連するデータのみを参照	財務チームはVLAN設定を見ない; ネットワークエンジニアは発注書を見ない
パフォーマンスの最適化	APIが最小限のデータを返し、帯域幅と処理を削減	モバイルアプリがデバイスサマリー(5フィールド)をリクエスト vs フルデバイスオブジェクト(200以上のフィールド)
セキュリティの向上	消費者ロールに基づいて機密フィールドをフィルタリング	認証情報、セキュリティゾーンは権限のない消費者から隠蔽
APIの安定性	ビューが安定していればバックエンドスキーマの変更が消費者に影響しない	新しいデバイスフィールドの追加が既存のnetwork-engineerビューの消費者に影響しない
多言語サポート	フィールド名、列挙型、説明が消費者のロケールに基づいて翻訳される	カタルーニャ語を話すオペレーターは「Location」の代わりに「Ubicació」を見る

ただし、課題と注意点も考慮する必要がある。

ビュー維持のオーバーヘッド: 新しいビューごとに定義、テスト、ドキュメントが必要
ビュー間の一貫性: 複数のビューで公開される同じデータは一貫していなければならない
パフォーマンスの複雑さ: 動的ビューの計算はレイテンシを増加させる; キャッシング戦略が必要
発見可能性: 消費者はどのビューが存在し、いつ使用するかを知る必要がある

コンテキスト対応モデリングは、データ構造の最適化(効率的なデータ保存方法)と消費の最適化(消費者が自然にデータにアクセスする方法)の橋渡しだ。Source of Truth は多くの利害関係者に対応しており、それぞれが自分の仕事における「真実」の意味について独自の見方を持っているということを認識している。

4.2.3.4. AI支援インターフェース#

ConsumptionレイヤーへのAIの適用により、大規模で複雑なデータモデルを扱う際の認知的負荷が軽減される。現代のSoT実装で3つのパターンがますます一般的になっている。

コンテキスト対応の提案: デバイス名を入力すると、この場所で以前に編集したことのある一致するデバイスが提案される。サービスを作成すると、サービスタイプと過去のパターンに基づいた適切な技術パラメータが提案される。これらは検証の摩擦を増やさずに入力ミスを削減する。
書き込み時の異常警告: バルク更新の前に、操作が過去のパターンと比べて異常であればインターフェースが警告する。通常10台のデバイスに影響するバルクVLAN再割り当てが400台に影響しようとしている場合、確認ステップがトリガーされる。システムは操作をブロックしない; 疑問を投げかけるだけだ。
自然言語クエリ: LLMバックエンドのインターフェースにより、オペレーターは自然言語でSoTをクエリできる。「building-bで監視タグのないデバイスはどれか?」というように。インターフェースはこれを構造化されたAPIクエリに変換し、人間が読める形式で結果を返す。アドホックな調査には価値があるが、構造化された自動化インターフェースの代替にはならない。

3つのパターンはすべて同じ基盤に依存している。過去の操作データへのアクセスと、AIが推論できる適切にモデル化されたスキーマだ。セクション4.2.4.4では、同様の技術が書き込みパスでのデータ品質検証にどのように適用されるかを扱う。

4.2.4. Enforcement#

不正なデータは自動化を破壊する。誤ったインテントはネットワークの破損、セキュリティ侵害、混乱した運用チームにつながる。Enforcementは守護者だ。明らかに間違ったデータが入り込まないようにし、その理由を明確に説明する。

4.2.4.1. スキーマと制約の強制#

検証タイプ	目的	ルール例	エラー例
スキーマ検証	データ型とフォーマットを強制	VLAN id: 1〜4094の整数 VLAN name: 文字列、最大32文字 VLAN sites: サイト参照の配列 VLAN status: 列挙型(active, planned, deprecated)	`{ "id": 5000, "name": "CUSTOMER-VLAN" }` → エラー: VLAN ID 5000が最大値4094を超えている
一意性制約	重複エントリを防ぐ	VLAN 100: サイトごとに一意 IP 192.0.2.1: IPAM全体で一意ホスト名「pe-01」: リージョンごとに一意	同じリージョンに2番目の「pe-01」を作成しようとする → エラー: ホスト名はすでに存在する
参照整合性	関係の有効性を確保	回線参照: site_a、site_b(Sitesに存在必須)、vendor(Vendorsに存在必須)	回線で参照されているsite_aを削除 → 選択肢: 削除を拒否、カスケード削除、または「site unknown」として孤立
範囲検証	数値とパターン制約を強制	BGP AS: 1〜4294967295 IPv4: 正規表現 `^(\d{1,3}\.){3}\d{1,3}$` インターフェース速度: {1G, 10G, 25G, 40G, 100G}	インターフェース速度「5G」 → エラー: 無効な速度、{1G, 10G, 25G, 40G, 100G}のいずれかでなければならない
ビジネスルール検証	組織ポリシーを強制	VLAN status=‘active’ → ≥1サイトが必要 device type=‘firewall’ → security_zoneが必要 service type=‘L3VPN’ → route_distinguisherは顧客ごとに一意	サイトなしのアクティブVLAN → エラー: アクティブVLANは少なくとも1つのサイトに割り当てる必要がある

スキーマ検証を実装する方法は多岐にわたる。汎用のコーディング言語から特化したソリューションまである。

JSON Schema: 実際のデータと比較するためのデータ制約を記述するJSONドキュメント。
CUE: 制約と検証付きの型付きデータ生成を提供。
YANG: 組み込みの制約強制を持つネットワーク固有のモデリング言語。

例えば、JSON Schemaを使用してJSON(またはYAML)データを検証できる。

JSONデータ

{
  "hostname": "sw-core-01",
  "mgmt_ip": "192.0.2.10",
  "role": "core",
  "interfaces": [
    {
      "name": "Ethernet1",
      "enabled": true,
      "vlan": 100
    },
    {
      "name": "Ethernet2",
      "enabled": false,
      "vlan": 200
    }
  ]
}

JSON Schema

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["hostname", "mgmt_ip", "role", "interfaces"],
  "additionalProperties": false,
  "properties": {
    "hostname": {
      "type": "string",
      "pattern": "^[a-z0-9-]+$"
    },
    "mgmt_ip": {
      "type": "string",
      "format": "ipv4"
    },
    "role": {
      "type": "string",
      "enum": ["core", "distribution", "access"]
    },
    "interfaces": {
      "type": "array",
      "minItems": 1,
      "items": {
        "type": "object",
        "required": ["name", "enabled", "vlan"],
        "additionalProperties": false,
        "properties": {
          "name": {
            "type": "string",
            "pattern": "^Ethernet[0-9]+$"
          },
          "enabled": {
            "type": "boolean"
          },
          "vlan": {
            "type": "integer",
            "minimum": 1,
            "maximum": 4094
          }
        }
      }
    }
  }
}

4.2.4.2. ハード強制とソフト強制#

不正なデータは拒否する。完全な停止。「ソフト検証」システムが最終的に不良データの収集場所になってしまう例を多く見てきた。「今回だけ」が標準的な運用手順になるからだ。検証するだけの価値があるなら、強制する価値もある。

ただし、例外はある。

ポリシーガイドライン(ルールではない): 「通常は /24 を使用するところに /22 サブネットを使用している」は警告であり、エラーではない。ユーザーに警告し、ログに記録するが、オーバーライドすれば続行できる。
コストの高いクロスオブジェクトチェック: 検証に数秒以上かかる場合は、変更を受け入れて非同期で検証する。ただし、結果は依然として強制する。違反にフラグを立て、ユーザーに通知し、修正を要求する。
ブラウンフィールドネットワークの発見: 既存の設定をインポートする場合、至る所で違反が見つかる。フラグを立てるが、インポートはブロックしない。そもそもの目的は、理想的なモデルに違反していても、実際に何があるかを発見することだからだ。

それ以外は? 拒否する。自動化は信頼できるデータに依存している。不正なデータは障害を意味する。

4.2.4.3. 検証コストとパフォーマンスのトレードオフ#

検証はタダではない。検証コストの階層が設計上の決定に影響する。

graph LR
    SPEED["⚡ 速度"]
    V1["< 1ms<br/>型検証"]
    V2["~10ms<br/>一意性"]
    V3["5-50ms<br/>正規表現"]
    V4["50-200ms<br/>参照整合性"]
    V5["100-500ms<br/>ルールエンジン"]
    V6["1-5秒<br/>外部API"]
    V7["数時間以上<br/>整合性"]
    THOROUGH["網羅性 🎯"]
    
    SPEED --> V1
    V1 --> V2
    V2 --> V3
    V3 --> V4
    V4 --> V5
    V5 --> V6
    V6 --> V7
    V7 --> THOROUGH
    
    style SPEED fill:none,stroke:none,font-size:14px,font-weight:bold
    style THOROUGH fill:none,stroke:none,font-size:14px,font-weight:bold
    style V1 fill:#d4edda,stroke:#28a745,stroke-width:2px
    style V2 fill:#d7ecf1,stroke:#17a2b8,stroke-width:2px
    style V3 fill:#dfe8f1,stroke:#17a2b8,stroke-width:2px
    style V4 fill:#fff3cd,stroke:#ffc107,stroke-width:2px
    style V5 fill:#ffe8cd,stroke:#ffc107,stroke-width:2px
    style V6 fill:#f8d7da,stroke:#dc3545,stroke-width:2px
    style V7 fill:#f5c2c7,stroke:#dc3545,stroke-width:2px

実用的なシステムはパフォーマンス目標を選択し、同期書き込みパスではそのレベルまでしか検証しない。

高速パス(< 10ms): 型、正規表現、ローカルインデックスチェック
標準パス(< 100ms): 一意性、参照整合性
低速パス(< 5秒): ルールエンジン、複雑なビジネスロジック
非同期パス(数時間後): バックグラウンド検証、整合性チェック

4.2.4.4. AI強化データ品質#

機械学習はスループットを低下させることなくデータ品質を向上させる。これらのAI駆動の検証技術は、セクション4.2.3.4のユーザー向けAI機能を補完し、包括的なインテリジェントデータ層を構成する。

異常検知

新しいリクエストに対して過去のパターンを照合し、不整合を推測する。

過去のパターン: 新しいブランチをプロビジョニングする際、オペレーターは1000〜1999の範囲でVLANを作成し、site_aに割り当て、スタティックルーティングを設定する
新しいリクエスト: VLAN 2500を作成し、site_cに割り当て、OSPFを有効にする
アラート: 「このVLAN作成パターンは異常です。本当によろしいですか? (1000〜1999の範囲が正しいという98%の確信)」
ML技術: 過去の変更ベクトルのクラスタリングと外れ値検出

自動修正提案

最も可能性の高い有効な解への修正を自動的に提案する。

入力: IPアドレス「192.0.2.1/33」(無効なプレフィックス長 > 32)
システム: 「/24 を意図しましたか? (このサイトの類似サブネットから推測)」
ML技術: 同じ場所内のサブネット割り当てのパターンマッチング

一貫性のためのベクトル埋め込み

埋め込みを使用してピア設定からの大きな逸脱を検出する。

各デバイス設定の埋め込みを保存
新しいデバイス設定が送信される
同じロールの類似デバイスと埋め込みを比較
大きな差異がある場合: 「このデバイスはロール内のピアと異なります: 類似デバイスはNTPサーバーX、Y、Zとサーバーへのsyslogを持っています」
ML技術: デバイス設定埋め込みのコサイン類似度

ML実装上の考慮事項

側面	推奨事項	根拠
確信度しきい値	確信度90%以上の提案のみ表示	偽陽性によるアラート疲れを防ぐ
トレーニングデータ	6〜12カ月の検証済み変更を使用	最新性と統計的有意性のバランス
モデル更新	週次または漂流検知時に再トレーニング	進化するネットワークパターンへの適応
説明可能性	AIが問題をフラグした理由を常に表示	推奨事項へのオペレーターの信頼を構築
人間によるオーバーライド	オペレーターが誤検知をマークできるようにする	フィードバックループを通じてモデルを改善

「確信度」スコアの使用に注目してほしい。これはAIを使用する際の重要な概念で、推奨事項にどれだけ依拠できるかについてのより多くのコンテキストを提供する。AI提案には常に、それをトリガーした根本的なパターンの説明を添えること。

4.2.4.5. Enforcementのコスト: システム設計への影響#

高忠実度の検証はアーキテクチャに影響を与える。

アプローチ	利点	欠点	適したシナリオ
同期検証 (書き込み受け付け前に検証)	✓ ユーザーが即座にフィードバックを得る ✓ データの一貫性が保証される	✗ APIレスポンスが遅い(検証レイテンシ) ✗ 高スループットの自動化をブロック	重要なデータ整合性操作インタラクティブなユーザーワークフロー
非同期検証 (先に受け付け、後で検証)	✓ APIレスポンスが速い ✓ 高スループット	✗ データ一貫性のウィンドウが存在 ✗ 複雑なエラー報告(「書き込みは成功したが5分後に検証失敗」)	バルク操作大量自動化
ハイブリッドアプローチ	✓ 型/フォーマット検証を同期で高速実行 ✓ コストの高いクロスオブジェクト検証を非同期で実行 ✓ 検証状態確認のAPIエンドポイント	✗ より複雑な実装 ✗ 状態追跡が必要	ほとんどの本番システムパフォーマンスと正確性のバランス

4.2.5. Versioning#

ネットワークのインテントは常に変化している。デバイスが追加され、設定が更新され、サービスが移動し、ポリシーが調整される。Versioningにより、いつ何が真実だったか、どのようにしてその状態になったか、そして必要に応じて安全な状態に戻る方法を把握できる。

4.2.5.1. バージョン管理と不変の監査証跡#

すべての変更は不変の形で記録され、完全な履歴が作られなければならない。これは例えば以下のような形を取る。

変更ログ

Change Event:
  timestamp: 2025-02-07T14:32:15Z
  user: engineer@company.com
  action: UPDATE
  resource_type: vlan
  resource_id: vlan-100
  changes:
    description: "Customer VLAN" → "Production Customer VLAN"
    assigned_sites: [site-a, site-b] → [site-a, site-b, site-c]
  reason: "Adding new office location"
  request_id: req-12345

Git コミット

commit 0c0ad51152f9b3be307802badb15eca8d121c576 (HEAD -> new-site, origin/new-site)
Author: Engineer <engineer@company.com>
Date:   Sat Feb 7 09:43:59 2026 +0100

    Adding a new site: BCN01

diff --git a/sites.yaml b/site.yaml
index ae18c87..dabf6c5 100644
--- a/sites.yaml
+++ b/sites.yaml
@@ -219,51 +219,1279 @@ sites:

+ BCN01:

この不変のログは重要な問いに答える。

日付Xにおけるネットワークのインテントは何だったか? (タイムトラベル)
誰がなぜこの変更を行ったか? (説明責任)
このインテントに対応するデプロイ設定はどれか? (トレーサビリティ)
バージョンYとZの間で何が変わったか? (差分/比較)

不変性が鍵だ。管理者でさえ、過去の記録を編集できない。これによりもみ消しが防がれ、監査証跡が信頼できる状態に保たれる。

Versioningはデータ保持ポリシーとも関連しており、コンプライアンスと実用性のバランスを取る必要がある。例えば:

すべての変更を7年間保持する(規制要件)
2年後に中間バージョンを削除する(例: VLAN 100が10回変更された場合、開始と終了のみを保持)
1年後にコールドストレージにアーカイブする(コスト削減)

データ変更イベントに関連して、イベントソーシングパターン(完全なデータ再作成のためにすべての変更をイベントとして保存)は強力だが、ネットワークインフラ管理ではあまり一般的ではない。これはネットワークのインテントが高度にステートフルであるためだ。現在のデータは、そこに至るまでの変更のシーケンスよりも重要だ。さらに、ネットワークの変更はしばしばイベントだけでは完全に再作成できない外部の状態(デバイス設定、外部システムのIP割り当て)を伴う。ただし、イベントソーシングはコンプライアンス監査やフォレンジック分析などの特定のユースケースには価値がある。

4.2.5.2. バージョン管理パターン: ブランチング、マージング、ロールバック#

現代のSource of Truthシステムは、ソフトウェアのバージョン管理パターンを多く取り入れている。これらの機能により、安全な並行作業、実験的な変更、ミスからの迅速な回復が可能になる。

並行ワークストリームのためのブランチング

複数のエンジニアやAIエージェントが並行して作業する組織には、互いをブロックせずに作業する方法が必要だ。あるアクター(人間またはAI)が新しいデータのプロビジョニングに取り組んでいる間、Source of Truth全体をブロックすることはできない。

ソフトウェア開発から学んで、ブランチングメカニズムにより並行したワークストリームが可能になる。各チームは並行してデータトラックで作業し、準備ができたら「メイン」トラックにマージできる。このマージは、途中で生じた不整合を解決する機会でもある。

ワークフロー例:

main branch (production intent)
  │
  ├─── feature/add-dallas-office (Engineer A)
  │     • Creates site DAL-01
  │     • Allocates VLANs 2100-2110
  │     • Defines 5 new devices
  │
  └─── feature/upgrade-ntp-servers (Engineer B)
        • Changes NTP config for all devices
        • Updates 3,000 device records

両方のブランチが main にマージされると:

競合なし: 異なるオブジェクトを変更 → 自動マージ
競合検出: 両者がdevice-core-01のNTPを変更 → 手動解決が必要
検証: マージされた結果はコミット前にすべての強制ルールをパスしなければならない

従来のデータベースへのこのブランチングメカニズムの実装は、それ自体が重要な問題だ。例えば、リレーショナルデータベースに依存する NetBox と Nautobot は異なるアプローチを取っている。NetBox はブランチングにデータベースコピーを使用し、Nautobot はDolt(組み込みのGit的な Versioning を持つSQLデータベース)を活用している。Infrahub はGit的なブランチングを念頭に置いて最初から設計され、ネイティブのブランチング機能を組み込んだグラフデータベースを使用して実装されている。

Rollback と回復

ミスは起きる。データの Rollback は高速で信頼性が高くなければならない。これはインテントデータ自体の Rollback であり、ネットワーク設定を直接 Rollback するものではないことに注意。

データの Rollback には、設定変更を強制するためのExecutionコンポーネントが必要だ(利用可能であればネットワークインフラの設定を Rollback できるが、最終的には安定した状態を維持するためにネットワークとインテントの両方を同期させる必要がある)。

データの Rollback をサポートするには、主に2つのアプローチがある。

アプローチ	仕組み	ストレージオーバーヘッド	回復速度	複雑さ
スナップショット	データセット全体の定期的なフルコピー	高(スナップショットごとにフルコピー)	速い(直接復元)	実装の複雑さが低い
イベントソーシング	すべての変更をイベントとして記録し、再生して状態を再構築	低(差分のみ保存)	遅い(イベントを再生する必要がある)	実装の複雑さが高い
ハイブリッド	N時間ごとにスナップショット + スナップショット間のイベントログ	中程度	スナップショットまで速く、その後イベントを再生	中程度の複雑さ

Rollback は2つの方法でトリガーされる場合がある。

手動: オペレーターが問題を認識し、Rollback を開始
自動:
- デプロイ後にオブザーバビリティがエラーレートの増加を検出
- デプロイ後の検証が失敗(「変更後に500台のデバイスが到達不能」)
- ビジネス影響のしきい値を超過(「顧客SLA違反 > 10件」)

ブランチング(競合なしの並行作業)と Rollback(ミスからの迅速な回復)の組み合わせは、大規模なネットワーク自動化が要求する時間的な柔軟性を提供する。

4.2.5.3. アトミックトランザクションと一貫性の保証#

トランザクションの保証により、複数の関連する変更が一緒に成功または失敗しなければならない場合のデータの一貫性が確保される。

原子性: すべてが成功するか、すべてがロールバックされるか
一貫性: 変更前後でデータ制約が守られる
独立性: 並行トランザクションが干渉しない
永続性: コミットされたら、システムがクラッシュしても保持される

これを実装するには慎重な設計が必要だ。

データベーストランザクション(すべてのデータが単一DBにある場合)
分散トランザクション(データが複数のシステムにまたがる場合)
サーガパターン(ネイティブの分散トランザクションサポートがない場合)

第11章では、これらの要件が信頼性の高いシステムにどう影響するかをさらに詳しく扱う。

4.2.5.4. 変更承認ワークフロー#

データ変更が提案されたら、アクティブになる前に人間の承認ワークフローが必要な場合がある。データは通常、継続的インテグレーションパイプラインと同様に、最終的とみなされる前にいくつかのステージを経る。

graph LR
    A["📝 オペレーターが変更を提案<br/>新しいブランチデバイスを50台追加"] --> C["📦 ステージング<br/>ネットワークへの影響なし<br/>プレビュー、テスト、ドライラン"]
    C --> D["✓ 自動チェック検証<br/>スキーマと制約?"]
    C --> E["✓ シミュレーション<br/>ルーティング/MPLSへの影響?"]
    C --> F["✓ コンプライアンス<br/>セキュリティポリシー?"]
    D --> G{すべてのチェックが<br/>パスしたか?}
    E --> G
    F --> G
    G -->|パス| H["👥 人間のレビュー<br/>変更管理"]
    G -->|失敗| I["❌ 拒否<br/>提案者に通知"]
    H --> J{承認?}
    J -->|はい| K["✅ 承認済み<br/>デプロイ準備完了"]
    J -->|いいえ| I

データ変更ワークフローの例は以下のようになる。

オペレーターが変更を提案: 「新しいブランチデバイスを50台追加」
変更がSTAGINGに入る: (ネットワークへの影響なし、プレビュー・テスト・ドライラン可能)
自動チェックが実行される(継続的インテグレーション):
- 検証: スキーマと制約をパスするか?
- シミュレーション: ルーティング、MPLSなどを壊すか?
- コンプライアンス: セキュリティポリシーに違反するか?
- レポート: ✓ すべてパス
人間のレビュー:
- 変更管理委員会が通知を受ける
- 差分、理由、影響範囲をレビュー
- 承認または変更要求
承認決定、変更がAPPROVED状態へ。
デプロイのトリガー: 承認されたら、ワークフローコンポーネントをトリガーして最終的に関連する変更をネットワークにデプロイする(自動化された実行ワークフローの一般的なトリガー)

ただし、すべての変更が人間の承認を必要とするわけではない。これが多くの組織が間違えるところだ。変更管理委員会は自動化を殺す場所だ。承認をスキップしろと言っているのではない。承認を自動化しろと言っているのだ(つまり、スケールに応じた変更承認)。

週次でVLAN追加を承認するためにCABが集まるなら、すでに手遅れだ。変更の95%を自動承認するガードレールを構築し、実際にリスクのあるものにのみ人間のレビューを取っておく。例えば、AWS VPCをプロビジョニングする場合、オペレーターはネットワーク変更の承認を人間に待つことはない。定義された境界内で実証済みのテンプレートに従っているからだ。

ルールは一つだ。明確なガードレールに収まる変更は自動的に進める; ガードレールのロジック自体のみが人間のレビューと承認を必要とする。最小限のガードレールカバレッジと最大限の影響許容度を定義する。その後は邪魔をせず、システムに任せる。

そうしなければ、あなたの「自動化」は会議を待つためのより見栄えの良い方法に過ぎない。

4.2.6. Aggregation#

ネットワークのデータは真空の中に存在しない。HRシステムは誰がどこで働いているかを追跡する。資産管理システムはデバイスの詳細と保証期限を知っている。IPAMシステムはIPアドレスの割り当てを管理する。回線プロバイダーは接続情報を持っている。サービスチームはSLAの詳細を持っている。

別のデータサイロを構築してはいけない。組織にはすでにサイロが多すぎる。Source of TruthがServiceNow、Infoblox、CMDBからデータを取得できなければ、APIを持ったスプレッドシート2.0を作っているに過ぎない。誰もそれを維持しない。「SoTを更新してください」と頼み続ける人生を送ることになるが、人々はそれを無視して既存のツールを使い続ける。

Aggregationは任意ではない。既存のシステムからデータを取り込み、双方向で同期を維持し、統合されたビューを提供する。Source of Truthは代替データベースではなく、フェデレーションレイヤーであるべきだ。

4.2.6.1. ゼロから始めているわけではない#

ほぼ確実に、データは複数のシステムに分散している。各システムはそのドメインにおいて権威がある。HRは組織を所有し、資産システムはハードウェアの詳細を所有し、IPAMはIPの割り当てを所有する。Source of Truthはこれらのシステムを置き換えるのではなく、クライアントが5つの異なるシステムに問い合わせる必要がないよう、それらのデータを一貫したインターフェースにまとめる。

組織コンテキスト:
- HRシステム: 部門、チーム、役職、責任マトリクス
インフラ:
- 資産管理: ハードウェアの詳細、シリアル番号、調達、保証
- クラウドプラットフォーム: VPC、サブネット、セキュリティグループ、インスタンスの詳細
- 回線プロバイダー(外部): 接続状態、使用率、障害
- IPAMシステム: IPの割り当て、DHCPスコープ、DNSエントリ
- 設定管理: テンプレート、ベースライン
サービス:
- サービスカタログ: サービス定義、SLA、顧客
- 課金システム: チャージバック、キャパシティプランニング

各システムはそのドメイン内で権威がある(ドメインはデータ型、または明確に区切られたデータ型のサブセットとして理解される)。Source of Truthはそれらを置き換えるのではなく、一貫したインターフェースを通じてアクセスできる整合的な全体にそれらのデータを統合し、複数のソースからデータを関連付けるための複雑なクライアントアプリケーションの必要性を排除する。

4.2.6.2. フェデレーションシステムにおける競合解決#

データが複数のソースから来ると、競合が生じる。

中央IPAMシステムの言い分: 192.0.2.0/24 は顧客Xに割り当てられている
CMDBの言い分: 192.0.2.0/24 は顧客Yに割り当てられている

どちらが正しいか? それはガバナンスによる権限の指定次第だ。

例えば、リソースドメインの所有権戦略は以下のように指定するかもしれない。

中央IPAM、権威あるSource of Truth:
- IPアドレスの割り当て
- サブネットサイズ
- DHCPスコープ
CMDB、権威あるSource of Truth:
- VLANからサブネットへのマッピング
- インターフェースIPの割り当て
- ネットワークインターフェースの運用状態

競合解決の戦略には以下が含まれる。

ソース権限(最も一般的): ガバナンスの決定により一つのシステムを権威あるものと指定する(例: 資産システムはデバイス認証情報において権威がある)
タイムスタンプベース: 最終変更タイムスタンプを使用し、最新の変更が優先される。リスク: 修正変更とミスを区別しない
論理的解決: コンテキストを評価する:
- SoTの値が現在デバイスで使用中(現在、動作確認済み)
- 資産システムの値が Desired State であると主張(あるべき姿)
- 選択肢1: 現在のものを信頼(動作しているもの)
- 選択肢2: あるべき姿を信頼(ガバナンスモデル)
- 選択肢3: 検出: デバイス上の設定がどちらの値とも一致しない、さらに調査
手動エスカレーション: 確信度が中程度の場合(値が異なるが矛盾はしていない)、人間のレビューにエスカレーション

4.2.6.3. Aggregationのアーキテクチャ#

データアグリゲーションには2つの基本的なアプローチがある。

アプローチ	アーキテクチャ	仕組み	同期パターン	利点	欠点
集中型Aggregation (プルモデル)	中央SoTが外部システムからフェッチ	アグリゲーターがソースをポーリング/サブスクライブ統一スキーマに変換競合を検出ローカルデータを充実させる統合ビューを提供	双方向(SoT ↔ IPAM) 単方向(SoT ← HR)	✓ 一元管理 ✓ 積極的な検証/充実 ✓ 単一の消費者クエリポイント	✗ ソースへのネットワークレイテンシ ✗ 外部の可用性に依存 ✗ 結果整合性のみ ✗ スケール上の課題
分散フェデレーション (プッシュモデル)	各システムが自身のデータを管理し、SoTが調整	イベント駆動(メッセージバス) リアルタイム通知のWebhook 参照データのキャッシュレイヤー変化の遅いデータの定期更新	イベント駆動 Webhookベースキャッシュされた参照データ	✓ ドメイン所有のデータ品質 ✓ 重複なし ✓ ボトルネックなしにスケール ✓ ドメインごとの強い一貫性	✗ 消費者が複数システムをクエリ ✗ クロスシステムのJoinが高コスト ✗ 複雑なメッセージ調整

4.2.6.4. 同期メカニズム#

システム間でデータの一貫性を保つことがAggregationの核心的な課題だ。アーキテクチャの選択によって使用する同期アプローチが決まる。

メカニズム	仕組み	フロー例	利点	欠点	一般的なレイテンシ
定期同期 (スケジュールベース)	スケジュールに基づいてデータを取得	6時間ごと: 1. SoTがIPAMから読み取る 2. ローカルキャッシュと比較 3. ビューに変更を適用 4. SoTの変更を公開	✓ シンプル ✓ 予測可能 ✓ 低オーバーヘッド	✗ 数時間の不整合ウィンドウ ✗ バッチ競合	分〜時間
イベント駆動 (メッセージバス)	リアルタイムで変更に反応	IPAMがサブネット10.0.0.0/24を変更 → 「Subnet:Changed」をバスに公開 → SoTがメッセージを消費 → ローカルキャッシュを更新	✓ リアルタイム ✓ 反応的	✗ 複雑なコレオグラフィ ✗ デバッグが難しい	秒
ストリーミング/Webhook (ダイレクトプッシュ)	ソースが登録済みWebhookにプッシュ	SoTがWebhookを登録 → IPAMが10.0.2.5/32を割り当て → WebhookにHTTP POST → SoTが検証し更新	✓ ダイレクト通信 ✓ メッセージバス不要	✗ Webhookのサポートが必要 ✗ ネットワーク信頼性の問題	サブ秒〜秒

リアルタイムの同期システムは存在しない。データは結果的に整合するようになるが、それには時間がかかる場合があり、ユースケースごとに評価が必要だ。

4.2.6.5. データガバナンスと権限フレームワーク#

効果的なフェデレーションには、データドメインごとの明確な定義を持つ明確なガバナンスが必要だ。例えば:

ドメイン	権威あるソース	同期方向	頻度	競合解決
デバイスインベントリ	資産管理システム	資産→SoT(SoT内は読み取り専用)	日次	資産が常に優先
ネットワークトポロジー	中央SoT	SoT→(レポートシステム)	リアルタイム	該当なし(SoTがソース)
IP割り当て	IPAMシステム	双方向	インバウンドは時間次、アウトバウンドはリアルタイム	IPAMは空きプールで優先、SoTはスタティック割り当てで優先

各データ要素について、権限メタデータは以下を追跡すべきだ。

ソースシステム: どこから来たか?
最終同期時刻: いつ確認されたか?
更新方法: ポーリング、プッシュ、またはWebhook?
権限レベル: このデータはどれだけ信頼できるか?

このメタデータにより、システムはデータ処理に関するガバナンス上の判断を適切に下せる。

複数のエンティティを扱う場合、障害に備えること。外部システムは必ず障害を起こす。フェデレーションされたソースが利用不能になった場合(例: IPAMが30分間ダウン)、いくつかの戦略がある(いずれも一長一短だ):

操作をブロック: 「IPAMなしではIPアドレスを割り当てられない」
キャッシュデータを使用して陳腐化とマーク: 「2時間前のIPAMキャッシュデータを使用中; 整合していない可能性あり」
グレースフルデグラデーション: 「デバイスのプロビジョニングは続行できるが、IPの割り当てをスキップし、IPAMが回復したときのためにキューに入れる」

4.2.7. ブラウンフィールドオンボーディング#

上記の6つの機能は、SoTが充填され信頼されたときにどのように動作するかを説明している。そこへ到達し維持できるかどうかを決める2つの運用上の現実がある。既存のネットワークからどのように充填するか、そして時間の経過とともにどのように正確性を保つかだ。どちらも単一の機能にきれいにマッピングされないが、どちらも6つの機能が実際に機能するための前提条件だ。

既存のネットワークにSource of Truthをデプロイする場合、難しい問題に直面する。レガシーの混乱をすべて永続的な真実として埋め込むことなく、現在の状態でどのように充填するか。

間違ったアプローチ: デバイスをポーリングして「実行中のもの = あるべき姿」と仮定する。すべての回避策、ハック、技術的負債をSource of Truthに直接読み込んでしまう。

正しいアプローチ: 現在のネットワーク状態を真実としてではなく、出発点として使用する。スナップショットを撮り、読み込み、それからクリーンになるよう意図的に再設計する。実際に望む設計ができたら、ネットワークからの同期を停止する。Source of Truthがボスになり、ネットワークがそれに従う。実際にはこのようになる:

ブートストラップ: 現在のネットワーク(デバイス、IP、VLAN、回線)のスナップショットを撮り、出発データとしてSource of Truthに読み込む。
再設計: 数週間から数カ月にわたって、スタッフがそのデータをレビューし、意図された状態が実際にどうあるべきかを決定する。冗長なVLANの統合、レガシーの整理、命名の標準化、将来のデプロイのための設計テンプレートの作成が必要になるだろう。
方向を逆転する: 望む設計ができたら、ネットワークからSource of Truthへの同期を停止する。今やSource of Truthがボスだ。Execution(第5章)が変更をネットワークに向けて外側にプッシュする。
ドリフトの検出: Observability(第6章)が、Source of Truthが示すべき状態からドリフトしているデバイスを監視する。ドリフトが発生したとき、オペレーターは決断する。デバイスを修正するか、Source of Truthを修正するか?

Slurpit.io や NetBox、Nautobot の拡張機能など、この問題に特化したツールがある。

このアプローチは初期の労力が必要だが、デプロイされた状態を永続的な真実として扱うという罠を避けられる。SoTはネットワークが完全に整合するのに時間がかかっても、クリーンな設計インテントに向けて進化する。もちろん、ネットワークがドリフトしていないことを再確認するためにドライランモードで使い続けることもできる。

4.2.8. データライフサイクルと整合#

データは古くなる。スイッチが廃止されても、SoTから削除されない。インシデント中にIPアドレスが手動で再割り当てされる。請負業者が緊急作業でトランクポートにVLANを追加する。3カ月後、誰も覚えておらず、SoTは数週間前にネットワークが停止した何かを記録している。

Enforcement(セクション4.2.4)は入力時にデータを検証する。それだけでは十分ではない。作成時に正確だったレコードも、周囲の世界が変化したことで不正確になることがある。継続的な整合プロセスなしでは、SoTは徐々に信頼性を失う。チームはSoTへの信頼を失い、独自のスプレッドシートを管理し始め、その上に構築された自動化は静かに誤った結果を出し始める。

整合パターン

整合とは、実際のネットワーク状態をSoTと定期的に比較し、すべての不一致を分類することを意味する。

設定ドリフト: デバイスがSoTのインテントと異なる。SoTが正しく、ネットワークがドリフトしている。修正するためにExecution blockをトリガーする。
未記録の変更: ネットワークに意図的な変更が行われたが、SoTに記録されていない。ネットワークが正しく、SoTが古くなっている。インテントを更新するようオペレーターに警告する。
孤立したレコード: SoTにはネットワークにもはや存在しないオブジェクト(デバイス、プレフィックス、VLAN)がある。クリーンアップレビューのためにキューに入れる。

各クラスには異なる対応が必要だ。自動化はドリフトの修正を処理できる(定義されたガードレール内で)。未記録の変更には人間の判断が必要だ。正式化すべき緊急修正だったのか、元に戻すべき未承認の変更だったのか? 孤立したレコードには、自動削除はしないが候補をレビューのために表示するクリーンアップワークフローが必要だ。

注意すべきデータ劣化パターン

実際には、SoTが古くなる最も一般的な原因は以下の通りだ。

廃止されたデバイスが削除されない: SoTには管理IPを持つデバイスレコードがあるが、デバイスは物理的に削除されている。そのIPをターゲットにする自動化は失敗するか、さらに悪いことに別のロールで再デプロイされたデバイスに到達する。
手動で再割り当てされたIP: SoTでデバイスAに属するとリストされているIPが、インシデント中に割り当てられてデバイスBで使用されている。SoTとIPAMの両方が内部的に整合しているが、実際のネットワークに対しては誤っている。
VLANスコープクリープ: VLANが定義されたスイッチセットにデプロイされたが、トラブルシューティング中に追加のトランクに追加された。SoTのインテントはもはや実際のメンバーシップと一致しない。

整合の頻度

すべてのデータが同じ速度で古くなるわけではない。デバイスインベントリはゆっくり変化し、運用状態は常に変化する。実用的なアプローチはデータ型ごとに整合ケイデンスを段階化することだ。デバイスインベントリは日次で整合し、IP割り当ては時間次で整合し、VLANメンバーシップはすべての変更イベント後と日次のバッチスイープで整合する。

ブラウンフィールドオンボーディング(セクション4.2.7)は一度限りの移行だ。整合は本番稼働後にSoTの信頼性を維持する運用プロセスだ。整合をスキップするチームは、数カ月以内にSoTへの信頼が失われ、その上に構築された自動化が静かに誤った結果を生成し始めることに気づくだろう。

ライブ依存関係としてのSoT

参照として使用されるSoT(自動化がワークフローの開始時に読み取る)とライブ依存関係として使用されるSoT(自動化がワークフローの各ステップで、データが最新であることを信頼して読み取る)には構造的な違いがある。両方のパターンが有効だが、2番目は1番目が持たない運用上の要件を生み出す。

ExecutorまたはOrchestratorがワークフロー開始時にSoTからデバイスインベントリを読み取り、200台のデバイスへのファンアウトを進める場合、スナップショットから作業している。実行中にデバイスが廃止されたり、スナップショットの読み取りと実行ステップの間にIPアドレスが再割り当てされたりした場合、自動化は古いデータに基づいて動作する。短いワークフローでは通常これは許容可能だ。長時間実行ワークフロー(数時間実行されるファームウェアアップグレード、メンテナンスウィンドウにまたがるプロビジョニング実行)では、陳腐化のウィンドウは重大だ。

緩和策は、SoTの可用性を仮定ではなく依存関係として扱うことだ。

Orchestratorは、ファンアウトステップを開始する前に、SoTの読み取りが成功し現在のレコードを返したことを検証すべきだ(最終同期タイムスタンプをチェックするか、SoT自身のヘルスエンドポイントを使用することで)。
長時間実行ワークフローでは、開始時に一度だけではなく、各主要ワークフローステージでSoTを再読み取ることを検討する。
SoTが利用不能な場合、ワークフローは不明な年齢のキャッシュスナップショットで進むのではなく、明確なエラーでクリーンに失敗すべきだ。

これはまた、SoT自体が可用性のために設計される必要があることを意味する。すべての自動化の書き込み権威ソースであるSoTが高可用性構成を持たない場合、自動化プラットフォーム全体の単一障害点となる。セクション4.2.9は具体的なソリューションを扱い、第11章ではプラットフォーム全体の可用性設計を扱う。

4.2.9. ソリューション全景#

Source of Truthの製品は数多く存在する。オープンソースのものも、商用のものもある。汎用のものも、IP管理のような特定のドメインに特化したものもある。これは2026年初頭時点のスナップショットだ。この分野は常に変化しているので、選択前に常に最新の機能と動向を確認すること。

4.2.9.1. オープンソースソリューション#

ソリューション	カバーするデータドメイン	主要な技術的特徴
NetBox	IPAM、DCIM、回線、デバイス、仮想化、インベントリ	豊富なプラグインエコシステム(150以上のプラグイン) 成熟している(10年以上)、大きなコミュニティバージョン間で頻繁な破壊的変更
Nautobot	IPAM、DCIM、回線、デバイス、インベントリ、拡張可能なアプリ	NetBoxのフォークで拡張性を強化自動化ワークフローのジョブフレームワーク Gitデータソース統合プロフェッショナルサポート付きの安定したAPI
Infrahub	ネットワークトポロジー、デバイス、IPAM、スキーマ、関係	複雑な関係モデリングのためのグラフデータベースコアアーキテクチャに組み込まれたGit的ブランチング動的データモデルを持つスキーマ駆動変更レビューのための提案状態ワークフロー

4.2.9.2. 商用ソリューション#

ソリューション	カバーするデータドメイン	主要な技術的特徴
ServiceNow CMDB	設定アイテム、サービス、資産、変更	エンタープライズITSM統合 ITILに準拠したワークフローマルチベンダーフェデレーション機能 AI/ML駆動のインサイトと推奨
Device42	データセンター資産、依存関係、アプリケーションマッピング、IPAM	迅速なオンボーディングのための包括的な自動検出アプリケーション依存関係マッピング複数プラットフォームにわたるエージェントレス検出

上記のオープンソースソリューションはすべて商用オファリングも提供している。

4.2.9.3. 特化型プラットフォーム#

ソリューション	カバーするデータドメイン	主要な技術的特徴
Infoblox	DNS、DHCP、IPAM(DDI)	エンタープライズグレードのDDI権限 DNSセキュリティと脅威インテリジェンスマルチサイトレプリケーション
SolarWinds IPAM	IPアドレス管理、DHCP、DNS	SolarWinds監視エコシステムとのネイティブ統合自動IP競合検出 Active Directory統合
phpIPAM	IPアドレス管理、サブネット、VLAN	軽量でコスト効率が高いシンプルなデプロイ(LAMPスタック) DCIMの複雑さのないシンプルなIPAM

4.2.9.4. 選択の考慮事項#

Source of Truthソリューションを評価する際には、以下の適合要素を検討する。

スケール要件: デバイス数(数百対数十万)、変更率、クエリ量
データモデルのニーズ: リレーショナル構造(NetBox、Nautobot)対グラフ関係(Infrahub)対柔軟なドキュメントストア
統合エコシステム: データをフェデレーションする必要がある既存ツール(監視、ITSM、クラウドプラットフォーム)
チームの専門知識: Python/Djangoの習熟度、ローコードプラットフォームへの好み、Gitワークフローへの慣れ
運用モデル: セルフホスト対SaaS、変更承認プロセス、RBAC要件
進化の軌跡: ブラウンフィールド移行パス、スキーマの拡張性、APIの安定性

4.3. 実装例#

4.3.1. ユースケース: キャンパスネットワークのSoT構築#

第3章で紹介したキャンパスネットワークに戻る。複数の建物に分散したCisco、Arista、HPEの約800台のアクセスおよびディストリビューションスイッチで、運用チームは新しいVLAN、IPサブネットの割り当て、ルーティングポリシーの更新、アクセスコントロールの変更など、絶え間ないサービスリクエストを処理している。これらを確実に自動化できるようにする前に、データが一貫した権威ある場所に存在する必要がある。

現在、キャンパスは全体像の断片をそれぞれが所有する3つの独立したシステムで運用されている。

Infoblox: すべてのキャンパスサブネット全体のIPアドレス割り当て、プレフィックス割り当て、DNSを管理する権威あるIPAM
ServiceNow: スイッチの場所、ハードウェアモデル、建物の割り当て、メンテナンス履歴を追跡する資産インベントリとCMDB
キャンパススイッチ: 実際の実行中の設定。800台のデバイスに分散しており、どこに何がデプロイされているかの単一の統合ビューがない

課題: アプリケーションチームが新しいVLANサービスセグメントのリクエストを提出すると、ネットワークエンジニアはInfobloxで利用可能なサブネットを手動で相互参照し、ServiceNowでターゲット建物内のスイッチを確認し、デバイスの Secure Shell (SSH) セッションで現在のVLAN割り当てを確認しなければならない。各スイッチの意図された状態についての単一の合意がないため、Configuration Drift が蓄積する。新しいベンダーの設計テンプレートを追加するには、一貫性の保証なしに複数の場所でドキュメントを更新する必要がある。

解決策: InfobloxとServiceNowの両方と統合し、キャンパススイッチから現在の状態を取得し、InfobloxもServiceNowも提供できないネットワーク固有のデータモデルを追加するフェデレーションされたNetwork Source of Truthとして Nautobot をデプロイする。VLANの定義、ベンダーごとの設定テンプレート、アクセス層とディストリビューション層の設計パターン、そしてビジネスリクエストをExecutorが単一のPlaybookを実行する前に存在しなければならない技術的オブジェクトに接続するサービスリクエストデータモデルが含まれる。

この例は説明のためのものであり、規範的なものではない。このシナリオを解決できる有効なSoT製品とアーキテクチャは多数ある。ポイントは、6つの構成要素(Modeling、Consumption、Enforcement、Versioning、Aggregation、Design-Driven)が実際のシナリオでどのように連携するかを示すことだ。組織のSoTは、既存のツール、チームの専門知識、制約に基づいて異なる形になるだろう。

4.3.2. ソリューションアーキテクチャ#

graph TB
    IPAM["Infoblox<br/>権威あるIPAM<br/>IPレンジ、DNS"]
    CMDB["ServiceNow<br/>権威あるCMDB<br/>資産、場所、メタデータ"]
    DEVICES["🖧 キャンパススイッチ<br/>Cisco、Arista、HPE<br/>約800台"]
    
    SLURPIT["Slurpit<br/>ブラウンフィールド検出<br/>設定抽出"]
    
    subgraph NAUTO ["🔗 Nautobot (アグリゲーションハブ)"]
        direction TB
        AGG["アグリゲーションレイヤー<br/>権限ルール<br/>競合解決"]
        SOT["統合SoTとデータ展開<br/>デバイス、IP、サイト<br/>関係"]
        API["消費API<br/>REST、GraphQL<br/>Webhook"]
    end
    
    EXEC["🚀 実行システム<br/>設定生成<br/>デバイスデプロイ"]
    OBS["👁️ オブザーバビリティ<br/>状態検証<br/>ドリフト検出"]
    UI["🖥️ プレゼンテーション<br/>Web UI、CLI<br/>ダッシュボード"]
    
    IPAM -->|Webhook/ポーリング<br/>IPデータ| AGG
    CMDB -->|Webhook/ポーリング<br/>資産データ| AGG
    DEVICES -->|SSH/NETCONF<br/>デバイス状態| SLURPIT
    SLURPIT -->|変換済みデータ<br/>初期ブートストラップ| AGG
    
    AGG --> SOT
    SOT --> API
    
    API -->|インテントクエリ| EXEC
    API -->|設定テンプレート| EXEC
    API -->|データアクセス| UI
    
    OBS -->|状態ドリフト| API
    API -->|インベントリ| OBS
    
    EXEC -.->|設定をデプロイ| DEVICES
    OBS -.->|状態を監視| DEVICES

重要な洞察: Nautobot はInfobloxやServiceNowを置き換えていない。それらのデータを集約し、競合を解決し、下流システム(Execution、Observability、Presentation)が消費する単一のAPIとして機能している。この関心の分離により、各システムが最善のものを使用できる。

6つのコンポーネントの連携#

Modeling: 各データソースは固有のデータモデルを持ち、識別子によるデータ接続を可能にするいくつかの重複がある。責任は分散しており、各データソースは異なるデータを専門としている。構造はすべての情報が統合されるまで部分的なデータを許容しなければならない(例: デバイスはIPが割り当てられる前に Nautobot に存在できる)。

Consumption: Nautobot はREST APIとGraphQLインターフェースを提供し、他のシステムが複数のデータソースと統合する必要なく、中央ポイントとしてデータを一貫してクエリできるようにする。

Enforcement: Nautobot は一貫性のためのグローバル検証を強制する。IPAMが10.1.1.5がdevice-dal-01に割り当てられていると言うが、このプレフィックスがデバイスが属さない別のリージョン向けに割り当てられている場合、フラグを立てなければならない。また、孤立したデータを防ぐ。デバイスがServiceNowに存在しない場合、InfobloxからIPを割り当てられない(参照整合性)。さらに、ソフト検証が警告する。「デバイスはServiceNowで30日前に最終更新された; 古い可能性がある」(ブロックしない)、データをクリーンにする能力を持つ。

Versioning: すべての変更が変更ログレコードとして追跡される。オブジェクトが変更されIPAMがIPを自動再割り当てした場合、Nautobot は「IPAMウェブフック: IP 10.1.1.5が2024-02-08T14:32:00ZにインターフェースEth1.1のdevice-dal-02に割り当てられた」と記録する。これにより、デバイスが現在のIPを持つ理由を履歴を通じて追跡できる。ただし、ロールバック能力は限定的だ。過去の特定時点にロールバックするメカニズムがない(免責事項: Nautobot VCSアプリはより高度な機能を可能にするが、簡潔さのためここでは扱わない)。

Aggregation: このソリューションでは複数のデータソースを相互接続する必要があるため、これが重要な側面だ。Nautobot はIPデータにInfobloxを優先する(権威あるIPAMだから)。資産メタデータ(保証、コストセンター)についてはServiceNowが権威があり、Nautobot は不一致を解決するためにこれを使用する。同期戦略は以下のようになる。

ServiceNow → Nautobot: 4時間ごとに定期同期(資産メタデータのわずかな遅延は許容できる)
Infoblox → Nautobot: IP変更のリアルタイムWebhook(IPAMの変更は緊急で、ポーリングを待てない)
ネットワークデバイス → Nautobot: Nautobot オンボーディングアプリを使用して、ネットワークからのデータが Nautobot データモデルにオンボードされる(結果整合性は許容) また、障害がある場合、Nautobot はいくつかの回復力メカニズムを提供できる。
Infobloxが2時間ダウンしている場合、Nautobot は「陳腐化」とマークされたキャッシュIPデータを使用して動作を継続する
オペレーターには警告が表示される: 「IPデータは2時間前のもの; IPAMは現在利用不能; 新しい割り当ては延期」
Infobloxが回復したら、保留中の割り当てがアトミックに処理される

Design-Driven: Nautobot Design Builder Appを使用して、Nautobot は新しいVLANサービスリクエストを実行するための高レベルインターフェースを提供する。オペレーターが高レベルのインテントを提供する: { "vlan_name": "app-payments", "subnet_size": "/24", "location": "building-b", "vendors": ["arista", "cisco"] }。次に、設計テンプレートがこれを展開する。Nautobot にVLANオブジェクトを作成し、building-bのIPレンジからInfobloxで利用可能な/24プレフィックスをリクエストし、ベンダーごとの設定テンプレートを自動生成し(ディストリビューションスイッチ向けArista EOSシンタックス、アクセススイッチ向けCisco IOS-XEシンタックス)、ServiceNowにクエリして800台のキャンパススイッチのうちどれがbuilding-bに物理的に配置されているかを特定する。結果として、Executorが単一のPlaybookを実行する前に必要なすべての技術的オブジェクトが揃う。

4.3.3. 実装フロー#

初期データ読み込み

Infobloxのインポート: Nautobot がInfoblox APIに接続 → すべてのIPレンジ、予約、DNSレコードを取得
ServiceNowのインポート: Nautobot がServiceNow CMDBに接続 → すべてのIT資産、場所、関係を取得
Slurpitによるブラウンフィールドネットワーク検出: Slurpit.ioが既存のネットワークデバイスに接続して現在の設定状態を抽出する:
- デバイスインベントリ(モデル、シリアル番号、ソフトウェアバージョン)
- インターフェース設定と運用状態
- IPアドレッシングとVLAN割り当て
- ルーティングプロトコル設定
- デバイス設定を Nautobot 互換のデータモデルに変換
相違の検出と解決: Nautobot の監査プロセスが3つのソース(Infoblox、ServiceNow、Slurpit)からのデータを相関させる:
- 競合の例: デバイスインターフェースが10.1.1.5/24を示すが、InfobloxはこのIPが別のデバイスに割り当てられていると示す
- 解決ワークフロー: Nautobot が人間のレビューのために47件の競合にフラグを立てる
  - ネットワークエンジニアが各件を評価: 「デバイスの状態を信頼」または「IPAMを信頼; デバイスは修正が必要」
  - ガバナンスルールを適用: 「アクセスポートにはデバイスを信頼し、インフラIPにはIPAMを信頼」
- バッチ解決: 類似した競合を一貫したポリシーで解決
統合スキーマの充填: Nautobot が3つのソースをマージする: 検証済み、競合解決済みデータで devices[*].{ name, location_id, ipv4_address, serial_number, cost_center }

ライブ運用

新しいVLANサービスリクエスト: アプリケーションチームがServiceNowでリクエストを提出。Nautobot がWebhookをキャッチし、VLANとプレフィックスオブジェクトを作成し、building-bのアドレスレンジから次の利用可能な/24をInfobloxに問い合わせ、自動的に割り当て、リクエスト者、承認者、タイムスタンプでレコードをスタンプする。Executionブロックはすべてのターゲットスイッチにサービスをデプロイするために必要なすべてのデータポイントを Nautobot にクエリできる。
新しいキャンパススイッチのオンボード: オペレーターがServiceNowに資産エントリを作成。Nautobot がWebhookをキャッチし、場所、ベンダー、ロールのメタデータを持つデバイスオブジェクトを作成し、サイト管理レンジの管理IPをInfobloxに問い合わせ、デバイスのロールとベンダーに基づいて適切な設計テンプレートを割り当てる。スイッチは誰もCLIに触れる前にSoTに登録され、将来のデプロイの対象となる。
Infobloxのメンテナンスウィンドウ: IPAMが2時間オフラインになる。Nautobot は「IPデータは14:30 UTC時点で有効; 更新保留中」とキャッシュデータを表示する。オペレーターはデバイスインベントリとVLAN定義をクエリできるが、新しいIP割り当ては延期される。Infobloxが戻ると、保留中の割り当てがキューに入り、アトミックに処理される。

不整合の処理と定期的なドリフト検出

初期オンボーディング後、Nautobotはすべての3つのデータソースにわたって乖離を継続的に監視する:

継続的な同期: 変更が発生したときにトリガーされるイベント駆動の更新に加えて、4〜6時間ごとに定期同期が実行される:
- Infoblox同期: IP変更のWebhook駆動 + 定期的な整合
- ServiceNow同期: 資産メタデータ更新の定期ポーリング
- Slurpit検出: 実際のネットワーク状態を取得するための定期デバイスポーリング
Nautobotの監査と相関: Nautobotの監査プロセスがすべてのソースのデータを比較して不整合を検出する:
- データソースの競合: デバイスインターフェースのIPがInfoblox割り当てと異なる
- Configuration Drift: デバイス状態がNautobotのインテントと異なる(NTPサーバーが変更、VLANがトランクに追加)
- 陳腐なメタデータ: ServiceNow資産が90日前に最終更新された(潜在的な陳腐化)
乖離の分類と修正:
- タイプ1 - Configuration Drift: デバイスがNautobotのインテントと異なる → デバイスを修正するためにExecutionをトリガー
  - 例: デバイスのNTPサーバーが変更された → Executionが設定を再生成して修正をプッシュ
- タイプ2 - インテントの陳腐化: 意図的な変更がまだNautobotに反映されていない → SoTを更新するようオペレーターに警告
  - 例: オペレーターがインシデント中に手動でVLANを追加した → 現在のインテントを反映するようNautobotを更新
- タイプ3 - 外部権限の不一致: 権威あるソース間の競合(Infoblox対デバイスの現実)
  - 例: IP割り当ての不一致 → ガバナンスルールに基づいた人間の判断が必要
自動対手動の修正:
- 自動修正: 事前承認された変更(NTP、DNS、syslogサーバー)はExecutionを通じて自動的に修正
- 手動承認: 重要な変更(BGP設定、ルーティングプロトコル、セキュリティポリシー)は修正前に人間のレビューが必要
- エスカレーション: 解決不能な競合や繰り返しのドリフトパターンはネットワークチームにエスカレーション
監査証跡: 検出されたすべての乖離、解決策、修正アクションがコンプライアンスとトラブルシューティングのために記録される

4.3.4. アプローチのトレードオフ#

このアプローチの利点#

利点	説明	メリット
置き換えなしの統合	InfobloxとServiceNowが権威あるソースとして残る	Nautobotは既存の投資を置き換えるのではなく調整する
ほとんどのユースケースでのマルチソースの真実	5〜30秒の同期遅延がほとんどの操作で許容できる	デバイスプロビジョニング(4時間同期)、IP割り当て(30秒遅延)、設定生成(夜間)すべてがうまく機能する
ドメイン専門知識の尊重	各チームがそのドメインを所有する	Infobloxチーム: IP戦略; ServiceNowチーム: 資産ライフサイクル; ネットワークチーム: 設計/デプロイ
豊富なデータモデル	システム間の関係をモデル化	クロスドメインクエリを可能にする: 「保証が切れた高セキュリティ場所のデバイスは?」
運用の回復力	停止中にキャッシュデータが利用可能	Infobloxがダウン → キャッシュIPデータ; ServiceNowがダウン → 最終既知のメタデータ
監査とコンプライアンス	すべての変更が完全な系譜とともに追跡される	規制クエリ: 「誰が、いつ、なぜIPを10.1.1.5から10.1.2.5に変更することを承認したか?」

制限と制約#

制限	影響	緩和戦略
同期遅延	5〜30秒(Webhook)から4時間(ポーリング)のレイテンシ	重要な割り当ては、Nautobotをバイパスして直接Infobloxを呼び出す; 非同期で同期
競合の複雑さ	重複する属性には明示的な解決ロジックが必要	権限マトリクスを使用して競合を明示的にする(例: ServiceNowがMACアドレスを所有)
運用オーバーヘッド	各Webhook/API/同期ジョブが潜在的な障害ポイント	統合ヘルスを監視する(Webhookの失敗、タイムアウト、ラグ); 障害モードごとのランブックを維持
データ品質依存	ゴミを入れればゴミが出る	ソフト検証(ブロックではなく警告); 疑わしいデータの異常検知
陳腐化データのウィンドウ	停止中、オペレーターは数時間前のキャッシュデータで作業する	許容できる陳腐化ウィンドウを文書化; 「遅延 > 2時間の場合はキャッシュを使用」基準でオペレーターをトレーニング
統合メンテナンス	APIバージョンのアップグレードがNautobotの更新を必要とする	抽象化レイヤーを使用(統合アダプター); 四半期ごとの統合テスト

ユースケースにより適した他の方法やソリューションがある。ニーズと要件に基づいて自分自身の判断を下すこと。常にトレードオフが伴う。

4.4. まとめ#

冒頭のストーリーの孤立したファイアウォールルールは、設定のミスではなかった。誰も仕事を怠ったわけではない。ルールが残ったのは、VLANをサービスにファイアウォールポリシーに接続するシステムが存在しなかったからだ。VLANが削除されたとき、その接続が存在しなかったため、ルールのクリーンアップをトリガーするものが何もなかった。Source of Truthはそれらの接続を明示的にするシステムだ。

6つの機能がそのシステムを構築する。Modelingはネットワークがどう見えるべきか、そしてどのレベルの抽象化で見えるべきかを定義する。Design-Drivenはビジネスリクエスト(「ダラスにブランチを追加する」)を、Executorがデバイスに触れる前に必要な50以上の技術的オブジェクトに変換する。Consumptionはそのインテントを人間、自動化ワークフロー、他のシステムに一貫して提供する。Enforcementは、SoTに入るデータが下流で誤ったネットワーク状態を生成できる前に有効であることを確認する。Versioningは著者、理由、タイムスタンプとともにすべての変更を記録し、SoTを監査可能かつ回復可能にする。AggregationはSoTをすでにデータの一部を所有している権威あるシステム(アドレスのIPAM、資産のCMDB、接続性の回線プロバイダー)に接続する。

キャンパスの実装例は6つすべてが連携して機能することを示した。フェデレーションハブとしてのNautobot、それぞれのドメインで権威あるソースとしてのInfobloxとServiceNow、VLANサービスリクエストを自動デプロイに必要なすべてのものに変換する設計テンプレート。結果はネットワーク状態のデータベースだけではない。他のすべての構成要素がネットワークがどうあるべきかを知るために参照する唯一の参照点だ。

第5章はそのインテントを行動に変える。Executionブロックは SoT から読み取り、変更をネットワークにプッシュする。SoT の Versioning 機能が可能にする一貫性の保証とロールバック動作を伴って。

参考文献とさらなる学習#

データモデリングとスキーマ標準

IETF RFC 6020 & RFC 7950: YANG データモデリング言語標準
IETF YANGモデル: IETF、IEEE、OpenConfigを含む標準YANGモデルのリポジトリ
OpenConfig: コミュニティ主導のベンダー中立設定モデル
NETCONF (RFC 6241): YANGを補完するネットワーク設定プロトコル

APIとデータ消費

GraphQL仕様
gRPC: 高パフォーマンスAPIのための現代的なRPCフレームワーク
REST APIデザインガイド: バージョニング、ページネーションのMicrosoftのベストプラクティス
OAuth 2.0 (RFC 6749) & OpenID Connect (RFC 6750): 認証/認可標準

データ品質と検証

Data Quality Fundamentals (DAMA DMBOK): エンタープライズデータ品質フレームワーク
JSON Schema: 宣言型スキーマ検証標準
YANG制約 (RFC 6020, section 8.2.4): ネットワーク固有の検証パターン

バージョニング、監査、変更管理

Pro Git (Scott Chacon & Ben Straub): バージョン管理の概念と設計パターン
The Phoenix Project (Gene Kim、Kevin Behr、George Spafford): 変更管理と運用規律
Semantic Versioning: APIとデータモデルのバージョニング戦略

データ統合とアグリゲーション

Enterprise Integration Patterns (Gregor Hohpe & Bobby Woolf): データ統合アーキテクチャパターン
Master Data Management (David Loshin): フェデレーションガバナンスフレームワーク

ネットワークプログラマビリティと自動化

Network Programmability and Automation, 2nd Edition (Jason Edelman、Matt Oswalt、Scott S. Lowe、Christian Adell): ネットワーク自動化の基礎概念
Infrastructure as Code, 2nd Edition (Kief Morris): バージョン管理されたコードとしてのインフラ設定の取り扱い

分散システムとスケーラビリティ

Designing Data-Intensive Applications (Martin Kleppmann): スケーラビリティ、一貫性、APIデザインパターン
Distributed Systems (Andrew S. Tanenbaum & Maarten van Steen): フェデレーションシステムの基本概念

💬 Found something to improve? Send feedback for this chapter