はじめに
基礎から自分の知見をまとめてみようと投稿を始めてみたのですが、今回は少し最近かじっていることを書いてみたいと思います。
題材は「Cisco ACI」です。
初めてACIに関わると聞いたとき、僕は「そういう製品を扱うのかな？」と思っていました。
ところが調べてみると出てくる説明はだいたいこんな感じです。
Cisco社が提唱する次世代型SDNソリューション
……これで「なるほど！」ってなる人、どれくらいいるんでしょうか。笑
僕は完全にお手上げでした。
ここで言われていることをざっくり言えば、
「コントローラー」と呼ばれる機器を置いて、そこから各ネットワーク機器（スイッチなど）の設定を一元管理する仕組み
ということです。
従来のネットワークでは、スイッチやルータに1台ずつログインして設定していました。
ACIではコントローラーに対して「どんなネットワークにしたいか」をまとめて指定すると、
内部で自動的に各機器へ設定が反映されます。
つまりACIは「個別に操作していたものをまとめて管理する」ための仕組みであり、
その背景にあるのが SDN（Software Defined Network）＝ソフトウェアでネットワークを定義して制御する考え方 です。
この記事では、この考え方を前提に、初心者でもイメージできるACIの全体像を書いていきたいと思います。
ACIの仕組みをもう少し具体的に
ACIを理解する上で大事なのは、ネットワークを構成する物理的な構造と、それを管理するコントローラーの2つです。
Spine-Leaf構成
ACIでは「Spine-Leaf」という構成をとります。
ざっくり言うと「Spineスイッチ」と「Leafスイッチ」の２種類を用意して２階層の構造を作ります。
みたほうが早いと思うので簡単な図を作ってみました。
-
Leafスイッチ：
サーバやルータを収容するスイッチ。 -
Spineスイッチ：
Leaf同士をつなぐスイッチ。すべてのLeafはSpineを経由して通信し、それ以外の機器はつながりません。
このように Leaf ↔ Spine ↔ Leaf というシンプルな構造にすることで、
どのサーバ同士も同じように通信できる（イーサネットの“どこからでも均等アクセス”を保つ）仕組みになっています。
コントローラー（APIC）
そして、このSpine-Leaf全体を管理するのが APIC（Application Policy Infrastructure Controller） と呼ばれるコントローラーです。
従来：
- エンジニアがスイッチやルータに1台ずつログインして設定（CLIで show run を書き換えるイメージ）
ACI：
- エンジニアはAPICに「こういうネットワークを作りたい」とポリシーを入力
- APICが自動で各Leaf/Spineに必要な設定を配布して反映
つまり、エンジニアはAPICに対してのみ操作をすれば、あとはAPICが「司令塔」となって全体に指示を出す形です。
設定の考え方
ACIでは「どんな構成にしたいか」をJSONやXML形式でまとめて指定します。
（例：このサーバ群はAのネットワーク、このサーバ群はBのネットワーク）
するとAPICがそれを理解し、各スイッチに「show run」でおなじみの設定形式に変換して投入してくれます。
エンジニアは「どういうネットワークを作りたいか」を考えることに集中でき、
細かいコマンドの打ち間違いなどを気にする必要が減ります。
要するにACIは、
- 物理的には Spine-Leafのシンプルな構造
- 論理的には APICが一元管理して設定を配布
という二段構えで動いています。
ACIで何ができるのか
では、実際にACIを導入すると何が便利になるのでしょうか。
ここでは代表的なメリットを3つ紹介します。
1. 設定の一元管理でヒューマンエラーを減らせる
従来はスイッチやルータに1台ずつログインして、同じような設定を繰り返し投入する必要がありました。
この方法だと「コマンドミス」や「反映漏れ」が発生しやすいのが課題です。
ACIではコントローラー（APIC）に一度ポリシーを設定すれば、それが自動的に全体へ配布されます。
つまり、「1回の入力 → ネットワーク全体へ反映」 という流れになるので、設定作業の手間とミスが大幅に減ります。
2. テナントごとにネットワークを分離できる
ACIの特徴のひとつが「テナント」という単位での分離です。
個人的にはこのテナントはVDC(仮想データセンター)のようなものをイメージしていました。
- 部門ごと（開発部・営業部・総務部）
- 環境ごと（開発・検証・本番）
- 顧客ごと（A社向け・B社向け）
- システムごと（〇〇システム向け・△△システム向け）
といった単位でネットワークを論理的に分けられます。
これにより、物理的には同じネットワーク機器を使っていても、論理的には完全に独立したネットワークとして運用できるようになります。
セキュリティやマルチテナント環境の管理において大きな強みとなります。
3. 変更に柔軟に対応できる
従来のネットワークでは「ポートを増やしたい」「セグメントを分けたい」といった変更があると、
1台ずつ設定を追加していく必要がありました。
ACIではコントローラーに変更内容を反映すれば、自動的に各スイッチに配布されます。
そのため、短期間で環境を切り替えたり、構成を増減させたりできるのが特徴です。
クラウド環境に近い「柔軟なリソース管理」をオンプレミスでも実現できると言えるでしょう。
まとめると…
- 設定作業の効率化 → ミス削減
- テナントごとの分離 → セキュリティ強化
- 変更への柔軟対応 → プロジェクトのスピードアップ
こうした点から、ACIは「変化の多い現場」や「複数環境を同時に扱う現場」で特に威力を発揮します。
実務で触れるシーン
ここまで紹介したメリットが、実際の現場ではどんなときに役立つのでしょうか。
代表的なケースを挙げると以下のようなものがあります。
-
企業システムで「部門ごとにネットワークを分けたい」ケース
→ 開発部と営業部で通信を分離しつつ、同じ基盤上で運用したいとき -
「顧客ごとに環境を分ける」マルチテナント
→ A社用とB社用のシステムを、同じACI基盤上に論理的に構築するケース
クラウドみたいなものを顧客に提供したいとき -
頻繁に構成変更があるプロジェクト
→ 開発・検証・本番を短いサイクルで切り替える必要があるとき
まとめ
この記事ではACIの概要を「仕組み」と「できること」の2つの視点から整理しました。
- ACI＝個別設定をまとめて制御できる仕組み
最初は「次世代型SDNソリューション」と言われてもピンと来ませんでしたが、
実態は「コントローラーを置いて集中管理する」というシンプルな考え方です。
次回は テナント／VRF／Bridge Domain など、ACIを理解するうえで欠かせないキーワードについて触れていきたいと思います。