「ACI がどのようにお役に立てるのか」について、技術的な詳細というよりも実践的な価値にフォーカスして、5 回にわたってご紹介するシリーズ。今回が第 2 回となります。第 1 回をまだご覧なられていない場合は、ぜひ第 1 回からお読みいただければ幸いです。
- 第1回：ACI をシンプルに L2/L3 スイッチとして考えてみる
- 第2回：アプリケーションとネットワークを結びつけるポリシーってどう役立つの？
- 第3回：連携してもいい・連携しなくてもいい、という使い方 ～物理・仮想・コンテナ・L4-7サービス…
- 第4回：ネットワークをサービスとして提供するために必要なこととは
- 第5回：進化し続ける ACI
第2回のテーマは、「アプリケーションとネットワークを結びつけるポリシーってどう役立つの？」です。
ポリシーとは？
シスコが Application Centric Infrastructure（ACI）をリリースして以来、言い続けてきた”ACI を特徴づけるキーワード“が「ポリシー」です。前回のエントリーにおいて『「これまでのネットワークでは解決できなかった／難しかった課題を解決するソリューション」が SDN であるとするならば、ACI は SDN であるというご説明は正しい』と書きましたが、同時に私たちは ACI は SDN を超えたソリューションであるとも訴えてきました。その理由が、ACI が備えるこの「ポリシー」という考え方が一般的に SDN と呼ばれるソリューションの範囲を超える、まさに「これまでのネットワークでは解決できなかった／難しかった課題を解決するソリューション」であると考えているからです。
手元の辞書によると、ポリシーとは「物事を行うときの原則。方針。」とあります。ACI はネットワークのソリューションですので、ACI におけるポリシーは「通信のルール」ともいえます。
ネットワークにポリシーを！
これまでのネットワークは、当たり前ですがネットワークとしてネットワークを管理・制御していたため、ネットワークの設計・構成はネットワークそのものが対象でした。しかし、ネットワークを必要としているのは、通信を行いたいサーバであり、さらにはそのサーバは何らかのサービスやアプリケーションを実行するために使われています。にもかかわらず、これまでのネットワークはアプリケーションの要件を人が設計に落とし込んだ結果としてのネットワークでした。つまり、アプリケーションがネットワークを使うにも関わらず、その間に直接的なつながりがなかったわけです。
対して、ACI は柔軟に変化に対応するつながりを実現するために、単なるネットワークとしてのネットワークから一歩踏み出した、アプリケーションとしての接続要件を自律的にネットワークの設計に落とし込んでくれる仕組み、つまりはポリシーも兼ね備えた新しいネットワークのカタチです。
ポリシーの必要性
しかし、いきなり「ネットワークにポリシーを」と言われても困るという方も多いであろうことは重々承知しております。ネットワークは「つなげる」課題を技術の進化に合わせて解決してきた技術の積み重ねであり、日々の業務を支える 1 つの重要な基盤インフラ リソースです。そのネットワークをある日突然ポリシーベースに置き換える、というようなことはなかなか難しいでしょう。しかしそれであっても、私たちは大きな方向性として、ぜひ皆様のネットワークにポリシーという考え方を取り入れていって欲しいと考えています。
ではなぜポリシーは「これまでのネットワークでは解決できなかった／難しかった課題を解決するソリューション」となるのでしょうか？
今あるネットワークの姿は、先人たちの叡智の積み重ねの上に形作られています。スイッチングも、ルーティングも、IP も、様々な技術が生まれ、淘汰され、そして標準化されていった過程を経て今この時も通信を支えています。ただし、その最適化は、基本的にはネットワークがそれほど大きくダイナミックには変化しない使われ方をすることを前提としていました。
たとえば、仮想マシンやコンテナといった、完全に物理的な世界とは切り離されたコンピューティング リソースのカタチが当たり前になる以前では、ネットワークに接続しているデバイスが移動することはほぼなく、システムを構成するサーバの増減もそれほど頻繁には発生しないイベントでした。ところが現在では、仮想マシンは数分で作成することができ、作成される場所は物理的な接続性に依存することなく当たり前のように動的に変化します。コンテナに至っては数秒で作成できるうえ、数分・数時間という単位で使い捨てていくリソースとして、負荷に応じてその数もダイナミックに増減させて対応する使い方が当たり前となりつつあります。つまり、サービスとしての継続性と、サービスを構成する要素としてのコンピューティング リソースの継続性は全く別のものとして扱われるようになってきているのです。
このようにコンピューティング リソースの使われ方、ひいてはアプリケーションを構成する要素が動的に変化しつつもサービスが維持されるような使われ方が求められる状況そのものが「これまでのネットワークでは解決できなかった／難しかった課題」の 1 つです。
これまでのネットワークでは、通信する対象を IP アドレスや MAC アドレスアドレス、そして VLAN などのヘッダ情報だけで識別していました。つまり、ネットワーク エンジニアはアプリケーションの接続要件を VLAN やサブネット、ルーティング、セキュリティ などのネットワーク的な設計に変換した上で、さらにファイアウォール、ロードバランサ、ルータ、スイッチなどの個別機器の設定に落し込んで設定を行い、テストし、サービスインする、という流れでした。そのため、ネットワーク側は IP や VLAN に基いてルーティングやスイッチングはしていましたが、それらの通信が、どのテナントの、どのアプリケーションの、どの役割を持ったものなのかといったアプリケーション的なつながりは一切意識していませんでした。ACI のポリシーには色々な側面がありますが、その大きな価値の 1 つが、ネットワークの管理にアプリケーション的な接続性に基づく管理性を紐付けられるようになる、という点です。
ACI ポリシーの要素
ACI のポリシーを実現している2つの重要な要素が、End Point Group（EPG）と Contract（契約）という概念です。EPG とは、エンドポイント、すなわち ACI に接続するあらゆる対象（物理サーバ、仮想マシン、コンテナ、ファイアウォール、ロードバランサなど）を、同じテナントの、同じアプリケーションの、同じ役割を持ったグループという視点でグルーピングしたものです。そして Contract は、その EPG と EPG の間の通信ルールを定めるものとなります。いずれも完全に抽象化された概念であり、ACI ファブリックの範囲にある限り、物理的・論理的なネットワークには依存しません。ACI では、EPG と EPG の間の通信可否については、Contract に基いて決定されます。この仕組みによって、ACI はアプリケーションを意識した管理を行うことができるようになります。
ACI ポリシーをケーススタディで考える
ACI のポリシーによる管理性を活かすことによって「これまでのネットワークでは解決できなかった／難しかった課題」を解決する例をいくつか考えてみましょう。
ケース１：アプリケーションの DB サーバを物理サーバから仮想マシンに変更する
「アプリケーションとしての接続性は変わらないが、構成要素が物理サーバから仮想マシンに変わる」というケースはあるかと思います。P2V（Physical to Virtual）によるマイグレーションもあるかもしれませんし、新規に仮想マシンで構築し直すこともあるかもしれません。そうした際に、アプリケーションとしての接続性は変わらないとはいえ、サーバの接続点が物理スイッチから仮想スイッチに変わったり、場合によっては IP アドレスやサブネット、VLAN などのネットワーク的なパラメータが変わることによって、大掛かりなネットワーク側の設定変更作業が必要になる可能性があります。
ACI においては、アプリケーションとしての接続性が変わらないのであれば、必要となる変更作業は EPG に紐付けられるエンドポイントを物理サーバから仮想マシンへと変更するだけで完了です。移行期間中は併存するような場合でも、まず仮想マシンを EPG に追加登録して動作確認を行い、移行完了後に物理サーバの登録情報を消すだけで、余計な設定が残ったりしてしまうこともありません。
また、ACL などでセキュリティを構成していた場合、ACL の追加はできても、削除や変更は「想定外の影響があると困る」という理由で移行が困難となるケースもあります。これも ACI であれば、Contract は影響範囲が明確であるため、追加だけでなく、削除や変更などの操作についても影響範囲を明確に把握した上で実施することができます。
ACI は、VMware vSphere とは vCenter サーバを通じて、Microsoft Hyper-V とは System Center（SCVMM）を通じて、Red Hat Virtualization とは Red Hat Virtualization Manager を通じて連携することが可能です。vCenter などが複数あっても（たとえば、100台の vCenter サーバがあったとしても）、問題なく連携できます。連携によって、ACI 側の構成と、vSphere 側の構成をそれぞれ行うのではなく一元化できます。もちろん、何らかの都合で連携できない／しない場合であっても、ACI はこれらの仮想化環境と組み合わせてご利用いただけます。連携したら便利に、でも連携しなくても使える、という所は ACI をご利用いただくことのメリットの 1 つといえるかと思います。
ケース２：アプリケーションの Web サーバを仮想マシンからコンテナに変更する
仮想マシンをコンテナに移行する場合も、基本的には物理サーバから仮想マシンへの変更の場合と同じなのですが、コンテナの場合はよりダイナミックにコンテナの数が増減したりする使われ方が多いのではないかと思います。ACI では、Kubernetes や OpenShift 等との連携によって、コンテナについてもエンドポイントとして扱うことができるようになっています。コンテナは単体で使うのではなく、Kubernetes のような管理ツールによってダイナミックに作成・削除されたり、作り直されたりしつつも一定の構成数を維持するような使い方によって活用される技術です。
動的に増減したり変化したりするコンテナを活用するためには、それらコンテナの増減に合わせて動的に通信ルール、つまりはポリシーを追随できる仕組みが必要です。ACI はアプリケーションレベルの役割を意識できる仕組みによって、非常にコンテナとの相性が良いネットワークソリューションです。ACI はすでにサポートされている Kubernetes や OpenShift を始めとして、今後 CloudFoundry など様々なコンテナ管理ツールとの連携を提供していく予定となっています。
ケース３：Contract に L4-7 連携を追加定義し HTTP/HTTPS 通信だけを ADC でロードバランスする構成に変更する
Contract は IP や TCP といった L3/L4 レベルのプロトコルやポート番号などに基づくフィルタ ルールのためだけに存在するものではありません。ここに L4-7 サービスを紐付けることも可能です。この仕組によって、フィルタルールにマッチングした通信だけを折り曲げる、つまりは PBR（Policy-based Routing / Redirect） 動作を利用することが可能です。たとえば、EPG-A と EPG-B の間で Ping 疎通が可能な ICMP を許可するルールと、HTTP/HTTPS 通信が可能なルールの 2 つを構成し、HTTP/HTTPS 通信のルールに対してロードバランサに折り曲げる設定を追加することができます。これにより、HTTP/HTTPS 通信のみがロードバランサーに流れ込むため、ロードバランサー側としても余計な処理をせずに済むようになります。また、EPG に追加のエンドポイントをマッピングすることによって自動的にロードバランスの振り分け先として追加定義させるような動作を構成することも可能です。
これ以外にも様々なケースが考えられますが、ご紹介したケースはいずれも動的に変化するネットワークをシンプルに実現する仕組みを ACI が備えるからこそ価値を発揮できる利用例となります。ネットワークに求められる使い方の全てが動的な要求となるとは思いませんが、ちょっと先の未来ですら予測することが困難な時代において、「設定したらそのまま使う」であったり「予め設定しておく」といったような使い方では想定外のケースなどに柔軟に対応することは困難です。
まとめ
ACI は、必要になったタイミングで、必要な設定を、物理的なスイッチの台数や接続ポートなどに依存することなく、抽象化された「EPG」や「Contract」というかたちで実現することができるソリューションです。こうした構成は、GUI 操作はもちろん、Ansible のような構成管理ツールを通じて行うこともできますし、API を活用して裏側の仕組みとして制御することも可能です。
ACI には「ネットワークを管理する」側面と「ポリシーを管理する」側面の 2 つが融合しているため、最初はちょっととっつきづらいかもしれませんが、これらが融合していることこそ ACI の価値のコアとも言える部分です。また、ポリシーは最初から完全に適用するのではなく、部分的に適用していくことも可能です。
まずは既存ネットワークを置き換える IP ファブリックとして ACI を導入いただいたとしても、その先のステップとしてよりポリシーを活用した使い方に発展させていくことが可能です。前回と同じ〆の文章となってしまいますが「SDN によって、どんな課題を解決したいのか」という基本に立ち返り、その手段として ACI をぜひご検討ください!!
次回は、今回も少しだけ触れた仮想化やコンテナ、L4-7 連携などについて、もう少し詳細を解説していきたいと思います。
ACIの技術的な情報については、以下のACI How Toサイトで公開しています。ぜひ御覧ください。
https://learningnetwork.cisco.com/community/connections/jp/aci-howto
Authors