「ACI がどのようにお役に立てるのか」について、技術的な詳細というよりもお客様視点での価値にフォーカスして、5 回にわたってご紹介するシリーズ。2017年12月に始まった本シリーズですが 2020年を迎え、ついにこの全5回シリーズが完結します。第 1〜4 回をまだご覧なられていない場合は、ぜひ第 1 回からお読みいただければ幸いです。
- 第1回：ACI をシンプルに L2/L3 スイッチとして考えてみる
- 第2回：アプリケーションとネットワークを結びつけるポリシーってどう役立つの？
- 第3回：連携してもいい・連携しなくてもいい、という使い方 ～物理・仮想・コンテナ・L4-7サービス…
- 第4回：ネットワークをサービスとして提供するために必要なこととは
- 第5回：進化し続ける ACI
第5回のテーマは、ずばり「進化し続けるACI」です。
第1回を公開してからすでに2年以上が経過している現在でも、ACI は意欲的に進化を続けています（バージョンアップサイクルのスピードは今でも維持され続けています）。しかし同時に、第1〜4回で書いた内容は今でも通用する、ACI の普遍的な価値であり続けています。シスコが目指す “Intent-based Networking” を実現する 3つの大きな柱の1つ（残り2つは SD-Access と SD-WAN）として、ACI は世界中で、そしてもちろん日本国内でも非常に多くのお客様に、お客さまのビジネスを支えるアプリケーションのためのデータセンターネットワーク基盤としてご採用いただいています。ACI事例はこちらで公開されています
ので、ぜひ御覧ください。
リリースから本日に至るまで ACI に関わり続けてきましたが、特にこの1年で、国内のお客様の ACI の採用理由や活用方法がかなり先進的になってきていると感じています。単に従来のネットワークを置き換えるリプレイス対象としての検討だけに留まるのではなく、ACI が備える様々な連携や機能を活用することで運用の省力化や自動化を現実的に実現する手段として、さらには、ACI が備えるオープンな API や Ansible を始めとする構成管理ツールを活用したより先進的なオペレーションの実現など、少し前までは「こんなことができたらいいな」と単なる『構想』として掲げられていたことが、今では多くのお客様において優先度の高い、具体的な解決すべき課題として検討されるようになり、その解決手段の一部として ACI が実際に活用され始めています。
前述の通り、ACI は技術的な面としては継続的かつ野心的に進化し続けていますが、このシリーズのテーマであるお客様視点での「ACI がどのようにお役に立てるのか」という価値としては、ブレない軸を持っています。その軸が何なのかについては、このシリーズを振り返ってみることで明らかになるはずです。改めて簡単に振り返ってみましょう。
シリーズの第1回：手段としての ACI について
シリーズの第1回では、手段としての ACI についてご説明させていただきました。
SDN を導入することも、VXLAN Fabric を導入することも、ビジネスを支えるアプリケーションや利用者の「つながり」を必要とされているお客様にとっては手段にはなれど目的ではないはずです。ACI は SDN 的な側面と IP Fabric 的な側面とを持ち合わせていますが、その両面に渡って、人が都度判断したり構成したりする必要のない項目は可能な限り自動的・透過的に構成できるように実装されており、お客様の限られた時間をより重要な目的のためにお使いいただくための手段に徹した実装となっています。そして、SDN だから、IP Fabric だから、といって従来とは全く異なる運用管理を必要とするのではなく、既存のノウハウや経験を活用していただける、NX-OS をベースとした、あたかも ACI 全体で 1台の L3 スイッチのような感覚で ACI は利用できます。もちろん各スイッチを個別に構成管理する従来のネットワークと比較して、APIC によって統合管理される ACI の採用に際しては最初にある程度の学習コストが発生することは事実です。しかし ACI の様々な機能をより活用いただくことで、最終的にはネットワークサイズが拡大していったとしても複雑化しない仕組みによって、初期の学習コストを大きく上回る価値をご提供できると確信しています。
第2回：ACIの重要な要素であるポリシーについて
第2回では、ACIの重要な要素であるポリシーについて解説させていただきました。
最低限のセキュリティの基盤となる「許可された通信だけを可能とする」ホワイトリスト型のネットワークを実現するためには、ポリシーは欠かせない要素となります。しかし ACI の導入に際して最初から、いきなりポリシーベースでの管理に移行する必要はありません。多くのケースにおいて、まずは従来のネットワークのデザインをそのまま取り入れるところから ACI の利用は始まります。とはいえ、ネットワークとアプリケーションという、IT の両端に位置するような 2つの世界を結びつける手段として、ポリシーを備えた ACI の活用は重要な一歩です。ACI の EPG（End Point Group）と Contract という仕組みは、接続しているネットワーク（接続ポートや VLAN、IP アドレスなど）やコンピューティングリソースの形態（物理サーバ、仮想マシン、コンテナなど）に一切依存しません。ビジネスの変化のスピードに追随するためには、段階的に、できるところからであったとしても、ネットワークの管理をコンフィグベースからポリシーベースへと移行していくことが必要です。
第3回：ACI の連携について
第3回では、ACI の連携について解説させていただきました。
私としては、ACI には連携することによってより便利に・統合された管理を実現できることと同じくらい、連携しなくても多くの価値を提供できることにも大きな価値があると考えています。連携と一口に言っても、その実態は密結合〜疎結合なものまで様々です。しかし、いずれにしても連携することが前提となっているのだとしたら、それは連携先に依存したソリューションです。ACI はオープンな API と Opflex によって様々な対象（vSphere, Hyper-V, OpenStack, Kubernetes, L4-L7 FW/LB, NSO, CloudCenter, Ansible, Terraformなど）との間で連携することが可能ですが、同時に一切連携を構成しなかったとしても多くの価値を提供することができる、依存性のないソリューションです。
第4回：本シリーズのまとめ
第4回は、事実上の本シリーズのまとめ的な内容となっています。
ACIをご採用いただくことの最大のメリットは、ネットワークのパラメータとアプリケーションとしてのつながりを結びつける手段を提供できる点です。個別のネットワーク機器を個別に構成管理する手法では実現困難であった「ネットワークをサービスとして提供する」ために必要な仕組みを ACI がどのように提供しているのか、そしてそれは他の SDN Controller や Fabric Controller などによるネットワークの管理とはどう違うのか。ACI が 2014年にリリースされてから今に至るまで、数多くの機能の追加や拡張が実装され続けていますが、その目的はずっとこの「ネットワークをサービスとして提供する」手段を提供することにあったということを、このシリーズを通じてお伝えしたいということが、このシリーズの大きなテーマでした。
このように、第1回〜4回で何度も継続的に繰り返し書いてきたことですが、ACI は特定の目的だけ最適化されたネットワークではありません。特定のサーバ仮想化 Hypervisor、特定のコンテナ基盤、特定のクラウドに対しては、それぞれ ACI よりも最適化されているソリューションがあるかもしれません。しかし、ACI はあえて個別最適は目指さずに、シスコがデータセンターと位置づける『アプリケーションが実行される場所』全体に対して、共通の管理性と境界のない接続性を提供することを目指しています。特定の用途に最適化されたソリューションは、往々にしてそのソリューションの対象外との間に様々な境界を生み出しがちです。一見、特定の範囲の中だけではとても便利に使えるかもしれませんが、その範囲外との接続において途端に複雑性が発生したり、可用性や性能面での新たな制約となることがあります。ソリューションの導入に際しては、もちろんお客様が解決したい課題を解決できるのかが最も重要な点ではありますが、同時にそのソリューションを導入することによって新たに発生する可能性のある課題についても必ず目を向けるべきです。ACI が登場してからこの 5年間でお客様が IT リソースに求める使い方が大きく変化してきたように、この先 5年間でも大きく変化していくことになるはずです。だからこそ、個別最適を目指さずに、特定のソリューションだけに依存することなく、アプリケーションが必要とするつながりの実態であるネットワーク全体に対する共通の管理性と接続性を提供する ACI の方向性は間違ってはいなかったと思います。
ACI は導入しておしまいのソリューションではありません。将来において ACI を導入した際には使うことを想定していなかった使い方が必要になる可能性もありますし、今はまだ存在しないコンピューティングリソースの形態が登場してくるかもしれません。今後どのようにビジネスの状況が変化していくのかを見極めることが困難な状況だからこそ、ACIはその価値を発揮します。お客様のビジネスが変化・進化し続けるからこそ、ACIもまたその変化に対して柔軟に対応できるよう進化し続けています。
ACI の採用実績が増加しつつある中で、導入や構成だけではなく、運用フェーズにおける可視化や最適化についても検討されるお客様が増えてきたことに対応し、シスコは ACI との組み合わせることで運用を受け身型から予防型へと改善していくことを支援する以下の2つのツールの提供も開始しています。
- Network Assurance Engine (NAE) : 構成上の競合や不足の解消、コンプライアンスチェック、構成変更の時系列比較など
- Network Insights (NI) : リソースのライフサイクル（EOL、Bug、PSIRT、Field Notice等）やリソース消費量（CPU、温度、Fan、電源、TCAM 等）、通信フローの可視化（遅延やパケットドロップ等）
ACI が皆様のお役に立つ手段となり得そうであれば、ぜひご検討ください。ACI が進化し続けるのは、より多くのお客様にとって活用いただける手段となるためです!! このシリーズが、そして合わせてリンクで紹介し続けてきた ACI How To サイトの技術的情報が、少しでも皆様のお役に立てたのであれば幸いです。
本連載の最後までお読みいただき、ありがとうございました。引き続き、ACIの情報発信は続けていきたいと思いますので、今後とも宜しくお願い致します。
ACI の参考技術情報を公開してきた「ACI How To」サイトですが、Cisco Learning から Cisco Community へと移行されます。ブックマークなどをされている方は、大変お手数をおかけしますが、以下に変更をお願い致します。
Cisco ACI (Application Centric Infrastructure) – How To
Authors
2 コメント
ACIの公開されているCase Studyは以下のURLにまとめられていますが、Multi-cloudに関連する公開事例はまだないようです。
https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/case-studies.html
海外のCloud ACI活用の事例についてはClosedでのご紹介は可能です。具体的なご検討などあるようでしたら、弊社担当もしくはパートナー様にご連絡頂ければと思います。よろしくお願い致します。
弊社にて次期クラウドネットワーク基盤のロードマップ策定を担当しています。マルチクラウド管理・運用の強化の視点でACIをベースとしたサービス化を検討しておりますが、マルチクラウド管理での実際の導入事例とかありますでしょうか？