· 253 words · 2 min read

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)が高速イーサネットを通じて通信している。エンタープライズやサービスプロバイダーは、レガシーインフラ、新サービス、クラウド/オンプレミス/エッジの拡散、コスト増大に悩まされている。

テックの世界では他のあらゆる分野がAPIファースト、セルフサービスへと移行した。開発者はネットワークにも同じことを求める。MLワークロードには構造化データが必要だ。セキュリティとコンプライアンスには自動化された監査可能なプロセスが必要だ。

もはや問いは「自動化すべきか？」ではない。「なぜまだ自動化していないのか？」だ。

明確なメリットがあるにもかかわらず、採用を遅らせてきた障壁がいくつかある。その多くは今も残っている。

  • インテントモデルの欠如: ネットワークはデバイスの設定で記述されてきた。「ネットワークは実際にどう動作すべきか」という観点がなかった。明確なインテントデータがなければ、自動化は脆弱でデバイス中心のままにとどまる。
  • 雑然とした一貫性のない設計: 自動化には予測可能性が必要だ。例外、場当たり的な回避策、一品物で満ちたネットワークは自動化できない。クリーンで標準化された設計が勝る。
  • ベンダーの乱立: ベンダー、プラットフォーム、サービスの混在は、絶え間ない統合の頭痛をもたらす。
  • スキルのミスマッチ: ネットワーキングとソフトウェア開発の両方を知るエンジニアはほとんどいなかった。そのギャップが自動化の適切な設計を難しくした。
  • 変化への恐れ: ネットワークは重要インフラだ。保守的な変更管理が自動化の正当化を困難にした。
  • 安全なテスト環境の不在: ほとんどのチームには本番環境に匹敵する適切なラボがなかった。自動化を安全にテストすることはほぼ不可能だった。

これらの障壁は独立して機能しているわけではない。相互に強化し合っている。インテントモデルがなければ自動化は脆弱になり、脆弱な自動化は変化への恐れを増幅させ、変化への恐れは脆弱性を減らすためのスキルとテスト環境に投資するための原資を断ち切る。

flowchart LR
    subgraph 技術的要因
        A[インテントモデルの欠如]
        B[雑然とした設計]
        C[ベンダーの乱立]
        D[テスト環境の不在]
    end
    subgraph 組織的要因
        E[スキルのミスマッチ]
    end
    A --> F[変化への恐れ]
    B --> F
    C --> F
    D --> F
    E --> F
    F -->|投資を制限する| E
    F -->|進行を遅らせる| A

    style F fill:#ffcccc,stroke:#cc0000,stroke-width:2px

朗報がある。2025年までに、これらの障壁のほとんどは解消されつつある。企業もベンダーも前進している。Chris Grundemann（Network Automation Forum）によるState of Network Automation Surveyは、今まさに起きているこの変化を示している。それでも、唯一の魔法の公式は存在しない。まずはマインドセットを理解することが先決だ。

1.2. ネットワーク自動化へのアプローチ#

本書は、ネットワーク自動化を成功させるために必要な根本的なアーキテクチャの概念を扱う。特定のツールを追いかけてはいけない。万能の解決策など存在しない。成功は3つの柱の組み合わせから生まれる。People（人）、Process（プロセス）、Technology（技術）、この順番で。

1.2.1. 成功の三本柱#

マズローのピラミッドのように（上を積み上げるには確固たる土台が必要）、各柱はその上の柱を支える。

flowchart BT
    A[人] --> B[プロセス]
    B --> C[技術]

    style A fill:#ffcccc
    style B fill:#ffe6cc
    style C fill:#ffffcc
  • People（人）: 自動化の成否は、設計・構築・運用する人々にかかっている。彼らのニーズを理解し、トレーニングとコラボレーションを通じて力を引き出す。
  • Process（プロセス）: 組織的な連携が重要だ。コスト削減、デリバリーの加速、信頼性の向上といった測定可能な価値に自動化の成果を結びつける。
  • Technology（技術）: ツールは存在する。課題は適切なものを選び、健全なアーキテクチャの中に統合することだ。

この三つのバランスが取れて初めて、自動化は単なる技術プロジェクトではなく組織の能力となる。変化は反復的だ。進歩は一歩ずつ積み重なる。自社開発か外部調達かというジレンマには繰り返し直面することになる。本書を通じてその問いに向き合っていく。

1.3. 現実の姿#

どの組織も独自の道を歩む。多くは小さなスクリプトから始まり、設定管理、コンプライアンスチェック、トラブルシューティングへと拡張していく。

1.3.1. 自動化のスペクトラムを理解する#

自動化の成熟度は、手動運用から自律ネットワークへと移行していく。

graph LR
    A[手動運用] --> B[スクリプトによるタスク自動化]
    B --> C[ワークフロー自動化]
    C --> D[インテントベースシステム]
    D --> E[自律ネットワーク]

    style A fill:#ffcccc
    style B fill:#ffe6cc
    style C fill:#ffffcc
    style D fill:#ccffcc
    style E fill:#ccccff

手動運用（Manual Operations）: すべての変更は人間の判断によってCommand Line Interface (CLI)を通じて手作業で実行される。1人のエンジニアが慣れ親しんだデバイスを操作する場合は素早いが、いかなる規模においても信頼性に欠ける。ネットワークは最後に触れた人間と同じ程度にしか一貫性を保てない。ログイン記録以外に監査証跡はない。

スクリプトによるタスク自動化（Scripted Tasks）: 繰り返し作業がスクリプトでラップされる。スプレッドシートからコンフィグを生成するスクリプト、同じ変更を50台のデバイスに適用するループ。端の部分では脆弱だ。デバイスの状態、ベンダーの挙動、命名規則のわずかな違いが、新しいスクリプトや新しい例外処理を必要とする。ほとんどのチームがここから始まり、多くのチームがここに留まる。

ワークフロー自動化（Workflow Automation）: スクリプトが構造化されたプレイブックとパイプラインに置き換えられる。変更は再現可能で監査可能になり、セルフサービスのインターフェースから実行できる。ただし自動化はまだデバイスをどのように設定するかを記述しており、ネットワークがどうあるべきかは記述していない。状態の調整は手動作業のままだ。このステージのチームは自動化がうまく機能していると語ることが多い。環境が変わるまでは。

インテントベースシステム（Intent-Based Systems）: ネットワークは設定（どう実現するか）ではなくインテント（何を望むか）で記述される。信頼できる情報源（Source of Truth）がそのインテントを構造化データとして保持する。自動化エンジンがインテントをデバイスの状態に変換し、結果を検証する。環境が変わっても、インテントは安定したままで実行レイヤーが適応する。本書の大部分はこのレイヤーをうまく構築することについて書かれている。第2部の信頼できる情報源、実行、オブザーバビリティ、オーケストレーション、プレゼンテーションブロックがインテントベースシステムのコンポーネントだ。

自律ネットワーク（Autonomous Networks）: システムが自身の状態を観測し、インテントからの逸脱を検出し、人間の介入なしにループを閉じる。これにはインテントベースのレイヤーが信頼性高く、十分に理解され、規律をもって運用されていることが必要だ。第4部と第5部では、クローズドループ自動化、自己修復ネットワーク、自律運用を信頼できるものにする組織的条件といった、これを可能にするパターンを探る。

本書の第1部から第3部はインテントベースシステムのアーキテクチャ的基盤を構築する。第4部と第5部は自律運用に向けた一歩を踏み出すために何が必要かを扱う。今日ほとんどの組織は、スクリプトによるタスク自動化とワークフロー自動化の間に位置している。目標は先を飛ばすことではない。次のレイヤーが以前のものを再構築せずに済むよう、各レイヤーを確固たる基盤の上に構築することだ。

規模が大きくなって実際に変わるのは目標ではなくアーキテクチャだ。50台のデバイスを想定して設計した自動化は、500台になると手抜きが露呈する。暗黙の命名規則の前提を組み込んだプレイブックは、ネットワークが1チームの知識を超えて成長すると失敗する。第3部では、自動化プラットフォームが数十台から数千台へ移行するときに何が壊れるかを検討し、最初から設計する方法を示す。

ネットワーク自動化の隠れた利点の一つは、自動化を容易にするためにネットワークアーキテクチャをできるだけシンプルにする動機が生まれることだ。手動で管理していたときは許容できた複雑さが、自動化がすべての例外を処理しなければならなくなると積極的な障害となる。

完全な自動化は長期的な目標だ。自動化は人間を置き換えるのではなく、専門性を増幅させ、エンジニアが設計と問題解決に集中できるようにする。真の成果は一貫性、信頼性、スピードだ。自動化はまた、手動では規模的に不可能なことを可能にする。リアルタイムの検証、即時のコンプライアンスチェック、数百のサイトにわたる協調的な変更の同時実行などだ。

さまざまな環境における自動化の具体例を挙げる。

ハイパースケーラー

  • 設計を受け取り、ネットワークインテントに必要なすべてのデータに展開する。ラック、デバイス、ケーブル、Internet Protocol (IP)、オーバーレイ、ネットワーク。それを使ってBill of Materials (BOM)を生成し、デバイス接続時にZero Touch Provisioning (ZTP)で提供するブートストラップコンフィグを作る。
  • オブザーバビリティデータ（メトリクス、ログ、フロー）をコンテキストで補完されたリアルタイムイベントに集約する。ユーザーの問題を緩和するワークフローをトリガーする。SLA内でキャパシティを維持しながらコネクションをドレインするなど。

サービスプロバイダー

  • トランジットプロバイダー間のインターネットリンクをフルメッシュでテストする。パケットロスとレイテンシを許容範囲内に保つ。問題を検出し、疑わしいリンクからトラフィックをドレインする。修正されたら戻す。
  • プロバイダーからの回線メンテナンス通知（メール、Webhook）を監視する。構造化データに変換する。アラートをミュートするか、影響を最小化するために事前に対応する。

エンタープライズ

  • ユーザーがセキュリティポリシーを定義するセルフサービスポータル。適用ポリシーに従ってファイアウォールルールに変換する。未使用ルールをクリーンアップするルールライフサイクルを有効にする。
  • デバイスの更新とライフサイクル管理。End of Life (EOL)デバイスを検出し、ソフトウェアの脆弱性にフラグを立て、アップグレードを自動化し、プラットフォーム移行を促進する。

鍵となるのは、最も時間がかかり、エラーが起きやすく、またはビジネスにとって重要なプロセスを特定することだ。それらがビジネスをどのように支えているかを理解する。そして、より効率的で自動化されたバージョンへと進化させる。

これらのソリューションはシンプルなものも複雑なものもあるが、共通のパターンを共有している。本書ではそのパターンを分析し、第5部 - パターンとユースケースで洗練された実世界のユースケースを紹介して締めくくる。

良い意図があっても、物事はうまくいかないことがある。以下は注意すべき一般的な落とし穴だ。

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

本書を通じて多くの落とし穴を発見するだろう。筆者自身が経験したものばかりだ。常に念頭に置くべきものをいくつか挙げる。

  • すべてを一度に自動化しようとすること: 小さく始めよ。自信と専門性を積み上げるために、影響が大きくリスクが低いユースケースを選ぶ。
  • インテントをツールの中に埋め込むこと: 命名規則、IPアロケーション戦略、ベンダー挙動の前提がプレイブックやスクリプトの中に分散していると、ネットワークがどうあるべきかという単一の記述が存在しなくなる。環境が変わると、埋め込まれたすべての前提が同時に崩れる。インテントは一箇所に置き、すべての自動化コンポーネントが共有すべきだ。
  • データ品質を軽視すること: 自動化はそのデータと同程度にしか良くない。早い段階で正確性と一貫性に投資する。
  • テストなしで構築すること: 本番環境にデプロイする前にテストと検証を行う。
  • 変化のための設計ではなく現在のネットワークを自動化すること: 現在のトポロジー、ベンダー、命名規則に合わせて構築された自動化は、何かが変わるまでは機能する。自動化コンポーネントを構築する前に、「今これは動くか？」ではなく「環境が変わったときにもこれは動くか？」と問え。現在のネットワークを自動化に刻み込むことは、ビジネスが進化するたびに複利で増大する技術的負債を生む。
  • 構築したエンジニアのためではなく、使う人のために構築しないこと: 構築したチームだけを対象とした自動化プラットフォームは単一障害点だ。サービスリクエストを送るアプリケーションチーム、変更ゲートを承認するオペレーター、コンプライアンスレポートをレビューする監査担当者、それぞれ異なるニーズ、異なる語彙、異なる期待を持っている。これらのユーザーを最初から念頭に置くことが、あらゆるアーキテクチャ上の決定を形作る。APIの構造、エラーの表示方法、ステータスの伝達方法すべてにおいて。エンジニアは理解できるが使う側には使えない自動化は、静かに回避されるだろう。

最後に、成果を実績で証明しよう。どうすれば？ネットワーク自動化の効果とビジネスへの影響を客観的に示す指標を定義し、追跡する。

1.3.3. 自動化の成功を測定する#

技術的指標とビジネス指標の2つのグループに焦点を当てる。どちらもリーダーシップにとって重要だ。

技術的指標:

  • 平均復旧時間（MTTR）: ネットワーク障害をどれだけ早く検出、診断、解決できるか？
  • 変更成功率: ネットワーク変更のうち、インシデントを引き起こさずにデプロイされた割合は？
  • Configuration Drift（構成ドリフト）: ネットワーク全体でデバイスの設定がどれだけ一貫しているか？
  • デプロイ速度: 新しいサービスや設定変更をどれだけ迅速に実装できるか？

ビジネス指標:

  • サービス可用性: 自動化管理のサービスは手動管理のものより信頼性が高いか？
  • エンジニアリング生産性: チームは運用タスクではなく戦略的な仕事に多くの時間を費やせているか？
  • コンプライアンス態勢: コンプライアンス違反をどれだけ迅速に検証し是正できるか？
  • リソース利用率: ネットワークのキャパシティとパフォーマンスをより有効活用できているか？

これらの指標を定期的に追跡する。継続的な投資を正当化し、改善すべき箇所を示してくれる。第6章ではオブザーバビリティブロックがこれらの指標をどのように収集し表示するかを扱い、第14章ではそれらをビジネス価値とプラットフォームプロダクト思考に結びつける。

1.4. まとめ#

物流会社の自動化プラットフォームは技術的には優秀だった。失敗はアーキテクチャ上のものだった。インテントの単一の記述がなく、ネットワークがどうあるべきかとそれをどう実現するかの分離がなく、環境が変わったときにシステムについて推論する方法がなかった。この失敗のパターンは珍しくない。自動化が原則ある設計を持つプラットフォームではなくスクリプトの集まりとして扱われたときのデフォルトの結果だ。

自動化を推進する力は構造的なもので、任意ではない。現代インフラの規模、開発者スピードのセルフサービスへの期待、ネットワークを手動で運用するコストの増大。自動化をツールの問題として扱う組織は、新しい環境が来るたびにゼロから作り直さなければならないことに気づく。アーキテクチャの問題として扱う組織は、複利で成長するものを構築する。

3つの柱（People、Process、Technology）は依存関係のチェーンであり、チェックリストではない。拡張できる技術的選択とは、問題を理解した人々によって明確なプロセスのもとで行われた選択だ。この順序を正しく理解することが、成長する自動化と数年ごとに再構築しなければならない自動化を分ける。

自動化のスペクトラムは手動運用から、スクリプトによるタスク自動化、ワークフロー自動化、インテントベースシステム、自律ネットワークへと続く。今日ほとんどの組織はその途中のどこかにいる。本書はインテントベースのレイヤーのアーキテクチャ的基盤を構築する。第1部と第2部はなぜとどのようにを確立し、第3部は規模が大きくなると何が変わるかを検討し、第4部と第5部は自律運用への一歩を可能にするパターンを探る。

物流企業のストーリーにある具体的なアーキテクチャ上の失敗は偶然ではない。明示的な原則なしに自動化を設計したときのデフォルトの結果だ。共有されたインテントがなく、ネットワークがどうあるべきかとそれをどう実現するかの分離がなく、環境が変わったときにシステムについて推論する方法がなかった。第2章ではそれらの原則に名前を付け、それぞれが防ぐ失敗のクラスにマッピングする。

💬 Found something to improve? Send feedback for this chapter