1. ACIの概要
Cisco Application Centric Infrastructure
大きなビルの「電話・LAN・セキュリティを一括管理するビル管理システム」と同じイメージ。従来は部屋（サーバー）ごとにケーブルを配線し、スイッチに個別設定していたが、ACIならアプリのようにポリシー（設計図）を作るだけで、DC内の何百台ものスイッチに自動反映される。
構成要素（3点セット）
集中管理コントローラ
ファブリックの背骨
サーバー収容口
vRAN／UPF／アプリ等
APIC
ファブリック全体のポリシー（誰と誰が通信できるか等）を一元管理する集中コントローラ。通常3台以上でクラスタ構成。
Spineスイッチ
ファブリックの中核。全Leafスイッチと接続する「背骨」で、機器自体には個別設定を持たない。
Leafスイッチ
サーバーやストレージが実際に接続される末端スイッチ。Nexus 9000シリーズが代表機種。
Tenant / EPG / Contract
「誰が」「どのグループで」「何を許可するか」を定義するポリシーモデル。物理配線を変えずに通信ルールを変更できる。
ACIが選ばれる理由
- 自動化：数百台規模のスイッチ設定をAPICから一括投入。人手による設定ミスを削減
- マルチテナント：1つの物理ファブリック上に、論理的に分離された複数のネットワーク（テナント）を共存させられる
- スケールアウト：Leaf/Spineを追加するだけでファブリック容量を線形に拡張できる
- East-West通信への強さ：サーバー間（横方向）通信が多い仮想化・コンテナ環境に最適化された構造
- クラウド連携：AWS／Azure等のパブリッククラウドともポリシーを一元管理可能（Cisco Cloud ACI）
2. 楽天モバイルとの関連性
Open RAN／仮想化ネットワークとACIの接点
楽天モバイルのDC階層とACIの位置づけ
楽天モバイルはOpen RAN／vRANアーキテクチャを採用し、無線処理をソフトウェア化して汎用サーバー上で実行する構成をとっている。そのため従来キャリア以上に「DC＝サーバー群のネットワーク基盤」の比重が大きく、DC内ネットワークの自動化・仮想化基盤が事業運営に直結する。
RU/DU収容
約50拠点
UPF・BSS/OSS等
Cisco ACIによる自動化・マルチテナント管理が使われる
なぜOpen RAN構成でACIが重要になるのか
East-West通信の急増：vDU・vCU・UPF・MEC等の仮想化ネットワーク機能（VNF/CNF）が拠点内で相互に大量通信する。従来型ネットワークより自動化・可視化のニーズが高い。
多拠点・同一設計の展開：Regional DCは全国約50拠点に及ぶため、拠点ごとに個別設定するのではなく、同一ポリシーテンプレートを横展開できるACIの仕組みと相性が良い。
Kubernetes基盤との連携：Open RANのCNF（Cloud-Native Network Function）はコンテナ基盤上で動くため、ACI CNIプラグイン等によりK8sネットワークとファブリックを統合管理できる。
マルチテナント分離：通信事業者網・法人向けサービス・社内システムなど複数の用途が同居するDCで、論理分離をポリシーベースで実現できる。
3. Regional DCにおけるACI機器更改の実務
約50拠点規模でのハードウェア・リプレース作業
ACI機器（APICコントローラ／Spineスイッチ／Leafスイッチ）は他のネットワーク機器同様、CiscoのEoL（End of Life）／EoS（End of Support）ライフサイクルに従う。導入から数年が経過した拠点では、サポート切れリスクや性能・容量の陳腐化を理由に、計画的な更改（リプレース）が必要になる。約50拠点あるRegional DCでは、これを一斉にではなく、段階的なローリング更改として進めるのが一般的な進め方である。
更改プロジェクトの5フェーズ
現状評価・棚卸し
「何を」「いつまでに」「どの順番で」更改すべきかを可視化する準備工程
- 拠点ごとのAPIC／Spine／Leafの機種・台数・稼働年数の棚卸し
- Cisco EoL/EoS告知情報との突合、サポート切れ時期の一覧化
- 現行ファブリックのソフトウェアバージョン（APIC OS／NX-OS）確認
- ポート使用率・トラフィック量から将来の容量要件を試算
- 既存のTenant／EPG／Contract等ポリシー設定のバックアップと文書化
移行方式の設計
サービスを止めずに切り替える方法を拠点特性に応じて選定
- 新ハードウェア（次世代Nexus 9000シリーズ／新世代APIC）の選定・サイジング
- 移行方式の決定：既存ファブリックへの段階的な機器差し替え（ブラウンフィールド）か、新ファブリックを並行構築して切替（グリーンフィールド）かを拠点規模・冗長構成に応じて選択
- 冗長構成（vPC等）を活かした無停止差し替え手順の設計
- APICクラスタの新規追加→既存ノード退役という無停止更改シーケンスの設計
- ロールバック手順・切り戻し基準の明文化
検証（ラボテスト）
本番投入前に机上検証を徹底し、切替当日のトラブルを未然に防ぐ
- 新旧機種混在時の相互接続性（Fabric Discovery）を検証環境で確認
- 収容予定のVNF/CNF（vDU・vCU・UPF等）やKubernetes CNIとの疎通確認
- ポリシー（Tenant/EPG/Contract）の移行後の動作一致を確認
- 監視・ログ連携（SNMP／Syslog／Cisco Nexus Dashboard等）の再設定確認
拠点展開（ロールアウト・カットオーバー）
約50拠点への横展開を計画的にこなす、プロジェクトの中核工程
- 拠点ごとの実施スケジュール策定（優先度：EoS切迫拠点／トラフィック増大拠点から着手）
- 現地作業チームの手配・全国拠点への展開体制構築
- 深夜・休日等トラフィック閑散時間帯での切替作業実施
- Leaf→Spine→APICの順など、影響範囲の小さい機器から段階的に切替
- 切替直後の疎通試験・性能試験（トラフィック監視、アラート確認）
- 問題発生時の即時切り戻し対応
運用移行・ドキュメント更新
更改後も安定運用できる状態に引き継ぐ仕上げ工程
- ネットワーク構成図・運用手順書（ランブック）の更新
- 旧機器の資産管理からの除却・廃棄（データ消去含む）
- 運用チームへの新機種操作・トラブルシュート研修
- 保守契約（TAC／SmartNet等）の新機種への切替
ブラウンフィールド vs グリーンフィールド
| 方式 | 概要 | 向いている拠点 |
|---|---|---|
| ブラウンフィールド （既存ファブリックに順次差し替え） |
既存Spine/Leafを1台ずつ新機種に入れ替え、冗長構成を活かして無停止で進める | ラックスペース・電源に余裕がない拠点、冗長構成が確保できている拠点 |
| グリーンフィールド （新ファブリックを並行構築） |
新しいAPIC/Spine/Leaf一式を並行で構築し、ワークロードを順次移設後に旧設備を撤去 | 大規模な設計変更を伴う拠点、旧世代からの構成刷新が必要な拠点 |
4. 提案のポイント
富士通が価値を出せる領域
「約50拠点あるRegional DCのACI機器を、サービスを止めずに、かつスケジュール通りに更改しきるには、拠点横断のプロジェクトマネジメント力と全国規模の現地作業リソースが鍵になります。富士通は大規模インフラの多拠点展開・保守運用の実績があり、評価・設計から現地カットオーバー・運用引き継ぎまで一気通貫で支援できます」という切り口で提案できる。
- EoL/EoS棚卸しと更改優先順位付けの支援（アセスメントフェーズからの入り口）
- ラボ検証環境の構築・新旧機種混在時の相互接続性検証
- 全国拠点への段階展開におけるスケジューリング・現地作業チームの提供
- 更改後の運用ドキュメント整備・保守体制（TAC連携含む）の構築