「ACI がどのようにお役に立てるのか」について、技術的な詳細というよりもお客様視点での価値にフォーカスして、5 回にわたってご紹介するシリーズ。今回は 2019年 7月公開の第 3 回に続く第4回となります。第 1〜3 回をまだご覧なられていない場合は、ぜひ第 1 回からお読みいただければ幸いです。
- 第1回：ACI をシンプルに L2/L3 スイッチとして考えてみる
- 第2回：アプリケーションとネットワークを結びつけるポリシーってどう役立つの？
- 第3回：連携してもいい・連携しなくてもいい、という使い方 ～物理・仮想・コンテナ・L4-7サービス…
- 第4回：ネットワークをサービスとして提供するために必要なこととは
- 第5回：進化し続ける ACI
第4回のテーマは、「ネットワークをサービスとして提供するために必要なこととは」です。
ネットワークにも用途や目的によって様々な種類がありますので、ここでは ACI が対象とする「サービスを提供するコンピューティング リソースのためのネットワーク」にフォーカスして考えてみたいと思います。
「サービスを提供するコンピューティング リソース」は、一般的にはサーバと呼ばれています。ただし、物理サーバに加えて仮想マシンやコンテナ等、その実体としての形態は様々です。さらに、いわゆるストレージや L4-L7 ネットワーク デバイスなども広義にはそこに含まれると考えて良いでしょう。以下の説明のなかに出てくる「サーバ」は、ストレージや L4-L7 ネットワーク デバイスなども含む広義な「サービスを提供するコンピューティング リソース」を意味するものとしてお読みください（ACI ではネットワーク的に接続するあらゆる対象をまとめて「Endpoint」と呼びます）。
ユーザがつながるネットワークは今では無線の利用が多いと思いますが、サーバ側のネットワークでは引き続き有線での接続が一般的です。サーバが多くのユーザに対してサービスを提供するうえで重要となる性能や信頼性などといった点において有線接続のほうが優位であること、またユーザとは違って物理的な移動は必要としないためです（可用性や性能を目的として論理的な移動や増減はする場合があります）。そのため、サーバとネットワークの接点は一般的にスイッチとなります。仮想マシンやコンテナの場合は、物理的なスイッチとの間に仮想スイッチが挟まるケースもあります。
Cisco ACI（Application Centric Infrastructure）は、物理的なスイッチ群を統合管理する Fabric Controller としての側面と、サービスを構成するサーバ同士や外部との接続などといった論理的なつながりを管理する SDN Controller 的な側面の両方を併せ持ちます。お題である「ネットワークをサービスとして提供する」ためには、この両方を併せ持っている点がとても重要です。なぜならば、サーバの形態を問わない論理的な接続性を一元的に管理するためには、サーバに依存しないネットワークである必要がありますし、単に物理スイッチを統合管理するだけの Fabric Manager だけでは最終的にユーザが必要とするネットワークである「サービスとしての適切なつながり」を提供することができないからです。もちろんFabric Controller と SDN Controller を別々に導入して利用することも可能ですが、その場合はそれぞれを別々に管理する必要性が生じてしまい、利便性が大幅に低下してしまいます。
SDN という単語自体も人によって認識が異なりますが、SDN をソフトウェア“だけ”で実現するものだと考えるのは間違いです。たとえば、Hypervisor に依存した SDN は Hypervisor 範囲外に管理対象を広げることが困難（できたとしても多くの制約や管理性の差異が生じる）ですし、特定のコンテナ技術のみに最適化された SDN はコンテナ以外に対しての共通の管理性を提供することはできません。物理サーバであろうと、仮想マシンであろうと、コンテナであろうと、そして今後登場するかもしれない新たなコンピューティング リソースの形態であろうと、共通のポリシーに基づく共通の管理を行うためには「サーバには依存しないがサーバに最も近い場所」であるスイッチで「サーバの形態を問わない論理的な接続性を一元的に管理する（=SDN?）」ことが最も汎用性の高い SDN の実装方法であるといえます。ACI は Cisco Nexus 9000 スイッチで構成された ACI Fabric はもちろん、各種 Hypervisor の仮想スイッチ(VMware vSphereの分散仮想スイッチや、System Cneterによって管理されたHyper-Vの論理スイッチ等)や、OpenStack や Kubernetes などで利用される Open vSwitch 等との連携によって、あらゆるコンピューティング リソースにとってのネットワークとの接続点である物理・仮想スイッチでの統合された制御を実現しています。
従来のネットワークでは、アプリケーションが必要とするつながりを様々なネットワークのパラメータに変換することによって実現していました。ネットワークを利用する側にとっては、使いたいときに、使いたいアプリケーションを、ストレスなく使えればいいわけですが、その裏ではネットワークエンジニアが物理的な接続（どのスイッチのどのポート等）や、論理的な接続（VLAN や IP アドレス/サブネット等）といったネットワーク的なパラメータを設計・設定することによって「あるべきつながり」を実現していたわけです。これらの様々なネットワークパラメータは、アプリケーションを構成する要素同士のつながりやユーザからの接続を適切に管理するためには必要なものですが、アプリケーション自体やユーザにとっては究極的にはどうでもいいものであるともいえます（みなさんも携帯電話や PC でアプリケーションを使うときにサーバの IP アドレスや物理ポートを意識したりはしないですよね？）。逆説的ですが「ネットワークパラメータに依存しない『つながり』を管理できる仕組みを実現する」ことこそが、究極的にはネットワークをサービスとして提供するためには必要なのです。
しかし実際には、ネットワークとしてのパラメータは現実の通信を成立させるためには必要となります。ACI は、従来の「ネットワークの世界」と、アプリケーションが必要とする「つながりの世界」を結びつける手段です。そのために必要だからこそ、Fabric Controller と SDN Controller の両方を融合させた幅広い範囲を管理対象としています。アプリケーションを構成するサーバが物理から仮想へ、そしてコンテナへと変化したとしても、ACI においてはアプリケーションとしての接続要件(WebサーバからDBサーバへ特定の通信プロトコルで通信することを許可する、等)が変わらない限り同じ構成のままで管理することが可能です。アプリケーションを構成する要素であるEndpoint が複数のスイッチに分散して配置されていたとしても、Endpoint の台数が 10台から 1000台に増えたとしても、ACI における論理的な接続性の管理においては一切複雑性が増すことはありません。
サーバや従来のネットワークは、IP アドレスや VLAN、サブネット、各種ルーティングプロトコルといった従来のネットワークの世界に存在しています。どのスイッチの、どのポートで、どの VLAN Tag をつけて、どの MAC アドレス、どの IP アドレスで通信するものが、どのテナントの、どのアプリケーションの、どの役割を持ったサーバなのかを ACI では紐付けて管理することが可能です。ただし ACI においては、これらのネットワーク的なパラメータ要素は単にそのサーバを識別するために利用するのであって、接続しているスイッチやポート、そして VLAN や IP アドレス自体に ACI による「つながり」の管理性は制限されません。テナントA とテナントB で同じ IP アドレスが使われていたとしてもそれらは別のものとして扱われますし、あるサブネットに属するサーバが全て同じ VLAN で通信しなければならないわけでもありません。ACIにおいてはネットワークの世界のパラメータは、論理的なつながりを実現するための識別子として利用される存在となります。
対して、アプリケーションのつながりを管理するためには、それらネットワークの世界には依存しない管理性が必要です。アプリケーションを構成する DB サーバに接続を必要とする Web サーバにとって、そして Web サーバに接続を行うユーザにとって、それらのサーバが「どのスイッチの、どのポートで、どの VLAN Tag をつけて、どの MAC アドレス、どの IP アドレスで通信する」のかは関係ありません。単純にユーザは Web サーバに、Web サーバは DB サーバに、必要な通信ルールに基づいて通信ができればいいだけです（同時に、セキュリティという意味ではユーザは DB に直接アクセスできないことも重要です）。サーバの実体が物理サーバなのか仮想マシンなのか、また 1台だけなのか 100台あるのか、それら「ネットワーク的なパラメータ」には依存しない、あくまでもアプリケーションとしての Web と DB、ユーザと Web といったつながりを適切に管理できる仕組みこそが必要なのであって、単に物理ネットワークの上に仮想スイッチ・仮想ルータ・仮想ファイアウォールなどを配置した「物理ネットワークに依存せずに通信を行うソフトウェアだけで構成されたネットワーク(=SDN?)」 が必要なわけではないはずです（それでは単に物理ネットワークと仮想ネットワークの 2つのネットワークを管理しなければならなくなるだけですし、アプリケーションの要件をネットワーク設計に落とし込む手間は、対象がそれら仮想デバイスに置き換えられたとしてもさほど変わりません）。
ACI は従来の「ネットワークの世界」と、アプリケーションが必要とする「つながりの世界」、その両面を管理する機能を持ち合わせるからこそ、その 2つの世界を結びつけることができます。Fabric Controller と SDN Controller を別々に構成することは、その 2つの世界を多少は近づけはすれど、結びつけることはできません。ネットワークをサービスとして提供するためには、まずその手段として「従来の『ネットワークの世界』と、アプリケーションが必要とする『つながりの世界』を結びつける」ことが必要です。その上で、自動化やセルフサービス化、コンテナを活用したマイクロアーキテクチャの導入などを活用することによって、全てを人が頑張ってそれらのつながりをネットワークパラメータとして管理するのではなく、アプリケーション視点のつながりとして管理することでネットワークは初めてサービスとして提供されるリソースとなりえるのです。
その技術的な仕組みや実現方法については、ぜひ「ACI How To」サイトをご参照ください。
日本語での ACI の技術的な情報については、以下の「ACI How Toサイト」で公開しています。ぜひ御覧ください。
https://learningnetwork.cisco.com/community/connections/jp/aci-howto
Authors