えー…まるまる2か月以上ぶりのエントリーでございます<(_ _)>
Ciscoの Application Centric Infrastructure (ACI) は、新しいデータセンターネットワーク基盤を実現するために根本的にこれまでのネットワークのあり方を再デザインしたものとなっており、ハードウェアとソフトウェアの両面を含む様々な要素と階層から構成されているため、メディア記事やCiscoのウェブサイトなどを読んでみたり、スライドベースなどで簡単な紹介を受けても、わかるけどわからない？と感じている方もけっこう多いのではないかと思います。
そこで、このエントリーでは、Cisco ACIについての基本をご理解して頂けるよう、あれもこれもまとめてご説明するのではなく、一歩ずつACIについてご紹介していきたいと思います。
まずは、ACIのどんなところがこれまでのネットワークとはどこがどう違うのか、というそもそもの概念的な部分ついてから見ていくことにしましょう。
どこから話を始めるとよいのか、ちょっと悩むのですが、IT、とひとくくりにしているものは実際には様々な要素から構成されている、という基本的なところから改めて考えてみることにしましょう。企業におけるITを大きく二つにわけてみるとすると、ちょっと無理やりかもしれませんが、究極的にはアプリケーションとインフラという2つの要素に行きつくのではないかと思います。そして、ITは根源的には利用者にとってはオフィスや文房具、店舗などと同じく数あるツールの1つですので、利用者がそれを使って様々な活動を行うために存在しています。利用者という枠には、その企業の社員だけの場合も、その企業にとってのお客様も含まれている場合もあるでしょう。
もちろんITのインフラは、ITを支える重要な要素であり、インフラがなければアプリケーションは動きません。しかし、利用者にとってのITはサービスですのでより重要なのはアプリケーションであり、極端に言ってしまえばその裏側のインフラは何であっても、アプリケーションが問題なく、使いたいときに使えるようにしてくれてさえいればどうなっていてもよい存在であるとも言えます。
企業内でITサービスを提供する責任者にとっても、最も重要なのは利用者にとって見える部分、つまりは満足するアプリケーションが問題なく使用でき、より満足するアプリケーションを提供することによって満足してもらえるようにすることであり、その基盤たるインフラはアプリケーションを問題なく動作するために必要となる単なる「下回り」です。インフラにはサーバやストレージ、セキュリティやネットワークなどの様々な要素が存在していますが、これらはそれ自体が問題なく動いているかどうかが重要なのではなく、それらに依存しているアプリケーションの動作にマイナスの影響を与えないかどうかこそが重要なのです。
ITはサービスであり、利用者のニーズは変化していきますので、当然ながらIT側もまた変化していく必要があります。その変化のスピードがそれほど速くなければ、年単位や、せいぜい月単位であれば、人が直接的に変更作業を行っていくことで対応できていました。しかし、ITが利用者にとって欠かせないツールになればなるほど、利用者はより多くをITはに求めるようになり、当然ながらニーズの変化のスピードは次第に速くなりつつあります。そして、初期のころは変換のスピードに対応するためにはアプリケーション側だけで対処することができていました。しかしここ数年で、アプリケーションの開発手法や開発体制は大きく変化し、そしてアプリケーションを提供する企業自体も大きく変化してきました。そして現在では、アプリケーションだけではなくインフラに対しても、アプリケーションの変化に追随するスピード感での変換への対応が求められるようになりつつあります。
たとえば、オンラインサービス系では爆発的な利用者の増加もあり得ますし、社内システムであったとしても他のシステムとの連携が開始さたり、組織体制の変更などによって新たなアプリケーションが早急に必要となったり、既存のアプリケーションの使い方が大きく変化することもあるでしょう。ウェブアプリケーションの増加に伴って、利用者はすぐに使い始められて、しかもどんどんと改善されていくアプリケーションを当たり前のものとして欲するようになってきています。
そうした、変化のスピードに追随するために、インフラリソースのうち、最もアプリケーションに近いレイヤーであるサーバについては仮想化によって対応が進められてきました*1。そして現在、ネットワークやストレージについても変化のスピードへの対応が求められるようになりつつあります。
ネットワークをよりすばやく、全体的に、変化させていくためのソリューションとして、この数年で様々なソリューションが登場してきています。いわゆるSDNと呼ばれているようなソリューションです。ソリューションの数だけ特徴や仕組みは異なりますが、その多くの根本的な考え方は共通で、ネットワークデバイスを管理機能である"Control Plane"とネットワーク通信を処理する"Data Plane"に分離して扱えるようにする、という形が採られています。
一番シンプルな方式は、いわゆるOpenFlow的に、ネットワークデバイス自体からはControl Planeを取り出してしまい、ネットワークデバイス自体は単なるData Planeとして位置付けて、1か所のControl Planeから管理できるようにする、という手法です。これによって、1か所のControl Planeから複数のData Planeを統合管理することができるようになりますので、ネットワークの制御は、個別のネットワークデバイスを構成しなければならない場合と比べて、格段に容易になります。
しかし、この方式にはいくつかの問題があります。1点目は、Control Planeが単一管理点であるということ自体です。このControl Planeによって管理されているすべてのData Planeは、当然ながらこのControl Planeに強く依存することになりますので、Control Planeで何か障害が発生すると、ネットワーク全体が使用できなくなってしまいます。また、Control PlaneはすべてのData Planeのすべての通信を把握して管理しなければならないため、非常に高い処理性能と全体ステータスの詳細把握が求められます。そのため、現時点では、いわゆるフローエントリーとして管理できる数にはそれほど十分ではない限界があります。そして最後に、最も根本的な課題は、この方式では管理は1か所になってはいますが、各機器の各構成をそれぞれ管理しなければならないという状態は実際には変わっていない、という点です。あるネットワーク構成の変更に対して、管理者はどのネットワークデバイスに対してどういう変更を加えなければならないのか、ということを意識して管理する必要があります。
最近では、ネットワークデバイスから完全にControl Planeを取り除いてしまうのではなく、各ネットワークデバイス内でのControl Planeも維持しつつ、統合的な管理を実現する仕組みも色々と登場しつつあります。CiscoのOnePKなどは、既存のネットワークデバイスにおける自律的な動作をそのまま維持しつつ、APIによる集中的な制御を実現するハイブリッド的なソリューションです。たとえばRouting Tableであれば、基本的には各ネットワークデバイス間でそれぞれ自立して動作しているControl Plane間でOSPFやBGPなどのダイナミックルーティング情報の交換で動作しつつ(もしくは個別のStatic Routing定義情報を保持しつつ)、APIによって特定の端末からの特定のアプリケーションの通信についてだけは管理者が指定した経路で通信されるように制御する、といったことを実現することができます。このようにすることにより、統合管理する側のControl Planeがすべてを把握し、すべてを制御するのではなく、特定の、特別に制御したい通信だけを制御するといったかたちでいわゆるコントローラによる統合管理と各ネットワークデバイスの自立管理はそれぞれの役割を分担し合うことができるようになります。これによって、統合管理する側は管理しなければならない情報を大幅に削減することができますし、もし統合管理する側で何らかの障害が起きたとしても、ベースとしては自律分散動作しているネットワークが維持されていますので、単に新規の特別な通信制御の追加構成や削除などの操作ができなくなるだけで、現状の通信構成はそのまま維持されます。
…と、ここまでControl PlaneとData Planeという視点で色々と書いてきたのですが、こうしたネットワーク視点での改善自体はいずれもアプリケーション側とは直接結びついていませんでした。それは、これではネットワークの管理をネットワークの視点で改善しようとしているだけに過ぎないからです。つまりは、結局のところアプリケーションの要件をネットワークの設計に対してどのように実現するのかについては、人間が判断してネットワーク設定に落とし込む必要があるということになります。もちろん、階層化によってレイヤー区分し、レイヤー間では密結合しないとう意味では、この仕組みは正しい実装といえました。しかし、アプリケーションの変化に追随するためには、ネットワークをどう構成するべきなのかについて人間の判断が介在してしまってはどんなに集中管理を実現したとしてもスピードを向上させることは困難です。
アプリケーションエンジニアが描くネットワークイメージと、ネットワークエンジニアが設計する実際のネットワークは、これまでおそらく大きなかい離がありました。そして、アプリケーション要件を実現するために必要となるネットワークを設計し構成することが、これまでネットワークエンジニアに求められていた仕事でした。しかし、アプリケーション自体やアプリケーションが要求するインフラ構成が状況によって刻々と増減し、変化していくような使われ方がされる時代に置いては、じっくりと腰を据えてネットワークを設計し、設定していく手法を採っていてはそのスピードに対応することはもはや困難です。
VRFやVLAN、Subnet、Bridge Domain、Routing、そしてIP Addressなどのネットワークとしての要素と、アプリケーションが求めるロジカルな関係性(たとえば、WebサーバとAppサーバ、AppサーバとDBサーバの間の通信要件や、DNSなどの共有リソースとの通信要件など)を、結びつけるためには、もはやネットワークを構成として管理していてはスピード感においつきません。たとえば100台の仮想マシンが構成されたり削除したり、しかもそれらの仮想マシンがホスト間をActiveなまま移動することが容易にできて、通信する対象が異なるHypervisor上の仮想マシンであったり、物理マシンであったりする様な状況に対して、人間が介在しなくてもそれらの仮想マシンの増減に適切に対応することができるネットワーク、それがACIが実現しようとしているネットワークです。
では、次回はACIがどうやってそうしたネットワークを実現しようとしているのか、について見ていきたいと思います。
キーワードは、ポリシーとプロファイルです。
*1:最近は、Dockerなどによって改めてコンテナ型も見直され、本格的に普及し始める兆しを見せてはいますが。
