サービスプロバイダー

5G－シスコが考えるサービスプロバイダー E2E アーキテクチャ第4章 5G 時代のデータセンターファブリックアーキテクチャ（2）

佐々木俊輔
2019年12月25日

第 4 章 5G 時代のデータセンターファブリックアーキテクチャ（2）

はじめに

本章の第 1 回では、5G のアーキテクチャ変遷をとらえながら、テレコムクラウド環境におけるデータセンターファブリック（以下 DC ファブリック）に求められる要件を考えてきました。今回はそうした要件に対応した具体的なシスコのソリューションをご紹介します。

シスコでは、業界ごと・お客様ごとに異なるニーズに応えるため、複数の DC ファブリックソリューションを展開しています（図 4-3）。その中でも、今回は、テレコムクラウド向けに急速に採用が広がっている Cisco ACI（Application Centric Infrastructure）を取り上げ、その利点をご紹介します。

図 4-3　シスコの DC ファブリックソリューション

テレコムクラウドに限らずデータセンターでのファブリックの需要は Web 企業を中心に引き続き旺盛で、次々と新しいテクノロジへの開発投資が行われています。近年では Segment Routing IPv6（SRv6）を DC ファブリックに活用する事例も出てきています [1]。

今回ご紹介する Cisco ACI も、進化途上にある多様な DC ファブリックの実装の一例としてご理解いただけたら幸いです。

4.6　Cisco ACI（Application Centric Infrastructure）

このセクションでは、Cisco ACI の概要をご紹介するとともに、前回の記事で見てきたコア、アグリゲーション、エッジのそれぞれのデータセンターの諸々の要件に、ACI がどのように応えることができるかを考察します。

まず、 ACI の構成要素を図 4-4 に示しました。ACI は Nexus 9000 シリーズスイッチがつくるファブリックと、ファブリックを制御するコントローラである APIC（Application Policy Infrastructure Controller）から構成されます。

ACI ファブリックは、前回ご紹介した CLOS トポロジとなっており、ToR スイッチである Leaf とコアスイッチである Spine からなります。Leaf のうち、WAN トランスポートと接続するものを Border Leaf（BL）と呼びます。これらの Leaf, Spine, Border Leaf は、APIC または APIC に接続済みのスイッチに接続すると自動的にディスカバリーされ、集中管理下に置かれます。普段のすべてのオペレーションは APIC から実施され、スイッチを個別に設定する必要はありません。

図 4-4　Cisco ACI の構成要素

ACI の大きな特徴に、APIC による物理ネットワークの抽象化があります。APIC は、「ポリシーモデル」という考え方をもとに、従来の DC ファブリックの設定を抽象化しました。従来のやり方では、DC ファブリックにアプリケーションやそれを動かすサーバデバイス（以下ではまとめてアプリケーションと呼びます）を収容する場合、アプリケーションが想定する論理ネットワーク構成を、物理ネットワーク上の設定項目に「翻訳」する必要がありました。

論理的なネットワーク構成の例:

フロントエンド Web サーバ <—> （Layer 3 ネットワーク） <—> アプリケーションサーバ <—> （Layer 2 ネットワーク）<—> データベースサーバ

物理ネットワークの設定項目の例（一部）:

フロントエンドサーバの IP アドレス、接続された Leaf ポート、アプリケーションの利用する TCP/UDP ポート
Layer 3 ネットワークの VLAN とゲートウェイ設定、ポートへの VLAN 設定、通信フィルタ用の ACL の設定
フロントエンドサーバへのロードバランス用の仮想 IP（VIP）の設定
アプリケーションサーバの IP アドレス、VLAN、接続された Leaf ポート、アプリケーションの利用する TCP/UDP ポート
Layer 2 ネットワークの VLAN 設定、ポートへの VLAN 設定
データベースサーバの IP アドレス、VLAN、接続された Leaf ポート、アプリケーションの利用する TCP/UDP ポート

こうした「翻訳」作業は、アプリケーション開発者から見るとアプリケーション動作に本質的ではないため、複雑なネットワーク要件のインプットが煩雑に感じられていました。また、アプリケーション側で増設・移設などがあった際には毎回同様の設定変更が必要で、大規模なデータセンター環境ではネットワーク運用者の負担が大きくなっていました。

こうした課題に根本的にアプローチするため、ACI では、アプリケーションが意図する論理的なネットワークの構成を「ポリシー」として APIC 上に記述することで、ネットワーク設定項目への翻訳が自動的に行われるという仕組みを採用しました。これが「Application Centric」の言葉の由来です。

本章では、ACI のポリシーモデルの考え方については深入りすることは避け、別稿に譲りたいと思います[2]。ここでは、ACI が従来のファブリックと全く異なるアプローチを取っていること、それによって様々なメリットを享受できるようになることを感じていただけたら幸いです。

4.7　テレコムクラウド DC ファブリックとしての ACI

ACI が、前節で見たテレコムクラウド基盤における DC ファブリックの要件をどのように満たすことができるかを表 4-1 にまとめました。

表 4-1　ACI による DC ファブリック要件への対応

テレコムクラウドにおける要件	サブ項目	説明
拡張性、柔軟性、統合運用	ACI ファブリックの拡張性	ACI は水平スケールアウトが可能な CLOS ファブリックを提供します。Leaf スイッチの選択肢は多岐にわたり、100/1000 Base-T ポートから 1/10/25G/100G/400G ポートまで、多様なインターフェイスを持つサーバ等のデバイスを収容可能です[3]。 ACI では、ファブリックを構成するためのアンダーレイネットワークは自動的に構成されます。内部的には MP-BGP と VXLAN を始めとする標準的な技術をベースに構築が行われますが、ユーザが手動で設定したり、状態を意識したりする必要は一切ありません。また、 ACI では、複数の拠点にまたがる構成もサポートしています（Multi-Pod および Multi-Site）。Multi-Site 構成では、執筆の時点で最大1,600 台の Leaf スイッチがサポートされており、今後さらに拡張予定です。
	インテントベースファブリック	APIC では、論理ネットワーク設定をポリシーとして抽象化しています。エンドポイントの識別子として End Point Group（EPG）の概念を導入しており、アプリケーション視点でネットワークを提供できる業界唯一のソリューションです。 DC ファブリックの設定を、従来のように「何をどういう順番で設定するか（How）」という概念から、「アプリケーションやユーザは何がほしいか（What）」という概念に切り替えたという意味で、ACI はインテント（意図）ベースファブリックと呼ぶことができます。シスコでは、データセンターにおける ACI を始めとしてあらゆる領域でインテントベースのコンセプトを展開しています。
	APIC の運用性	APIC はファブリックスイッチの完全なライフサイクル管理を実現しています。ACI ファブリックに接続されたスイッチは自動的にディスカバリーされ、ファブリックに組み込むことができます。ファームウェアのアップグレードや故障機器の交換のための作業も APIC から一元的に行うことが可能です。 APIC はファブリック上のネットワークの設定・監視および可視化を提供します。ファブリックのすべての設定とステートに対応した情報にアクセスする GUI と API を備えており、上位の OSS/BSS と連携して監視・運用の自動化を実現します。
	ACI ファブリックの柔軟性：サービスチェイニング	ACI では、ファブリック内の複数のサービスへトラフィックを転送するサービスチェイニングが簡単に設定できます。従来のサービスチェイニングは、ルータ機器上での Policy-Based Routing（PBR）と Access Control List（ACL）による複雑な設定を使って、サービスノード単位でトラフィックを曲げることが必要でした。 ACI では、上で説明した抽象化ポリシーによってこれらの設定を簡素化することが可能となっています。複数のサービスノードがある場合の負荷分散やヘルスチェック、ノードの追加・削除を柔軟に行うことができます。モバイル事業者のテレコムクラウド基盤では、GiLAN ネットワークでサービスチェイニングが多く使われており、ACI によりオペレーションの簡素化が可能です。
	ACI ファブリックの柔軟性：リモートリーフへの対応	ACI は Remote Leaf 機能をサポートしています。Leaf スイッチをトランスポート越しに配置して、集中管理することができます。エッジなどの小規模拠点まで DC ファブリックを延伸する場合に利用できます。 Remote Leaf に収容されるトラフィックはローカルオフロードすることが可能です。通信を拠点内やローカルな地域内で直接行うことができるため、例えば MEC（Mobile Edge Computing）の展開時にも活用できます。
仮想・コンテナ基盤との連携	APIC の連携機能	APIC は仮想基盤（OpenStack および VMware vCenter）、コンテナ基盤（kubernetes）との連携機能を備えています。例えば、EPG 設定に合わせて仮想スイッチの VLAN 設定を APIC から自動的にプッシュすることで論理ネットワークを仮想レイヤまでシームレスに拡張することができます。一方で、仮想マシンに関するオペレーションは従来どおり仮想レイヤ側のツール（例： vCenter）で行うことで、ファブリック管理と仮想基盤管理の適切な連携と分担が実現できます。さらに、仮想マシンやコンテナを ACI ファブリックに収容されるエンドポイントとして認識することができます。従来のように IP アドレス・サブネット単位だけではない細やかな通信の可視化とフィルタリングが可能になります。
分析・可視化機能	ACI ファブリックのテレメトリ機能	ACI を構成するスイッチは、ソフトウェアテレメトリに加えて、ハードウェアテレメトリに対応しています。データプレーンパケットをラインレートで分析する機能を備えており、SNMP など従来の手法では難したかった粒度でフロー情報やネットワークデバイスの各種情報を取り出すことができます。これらは ASIC レベルで実装されており、スイッチ負荷を最小に抑えながら実行が可能です。テレメトリの情報は、 ACI と連携するコレクター製品であるCisco Network Insights for Resouces [4] や、ビッグデータ分析基盤であるCisco Tetration Analytics [5] により収集・分析が可能です。
トランスポートネットワークとの連携	ACI とセグメントルーティングの連携機能	第 1 回で触れた DC ファブリックとトランスポートネットワークの連携について、シスコでは 5G で求められるエンドツーエンドスライシングの視点から重要と考えています。 ACI でもこの機能に積極的に投資を行っており、特に第 2 章で解説したセグメントルーティングとの連携に力を入れています。 ACI の Border Leaf は、データプレーンレベルでの連携（802.1q, MPLS Label）とコントロールプレーンレベルでの連携（BGP Labelled Unicast [6]）が可能となる機能を具備します。これにより、ACI ファブリックに収容されるアプリケーションのポリシーに基づいたトランスポートスライスの選択が可能になります。

このように、ACI はテレコムクラウド基盤における DC ファブリック要件に十二分に応えることができるソリューションです。特に、説明の中でも触れたように、エンドツーエンドスライシングや MEC、サービスチェイニング、トランスポートスライスとの連携など、5G 時代に求められる機能をカバーしている点に、ぜひ着目いただきたいと思います。

4.8　MEC で広がる 5G の可能性

本章の最後に、MEC について触れたいと思います。

5G で実現が期待されているサービスの一つが MEC（Mobile Edge Computing）です。第 3 章で見たように 5G では CUPS アーキテクチャが採用されて CU 分離が実装されたことで、エッジコンピューティングが実現できると期待されています。MEC の目的は大きく 2 つあります。1 つはエッジに低遅延のアプリケーション実行環境を提供すること、もう 1 つはユーザトラフィックのオフロードによるトランスポートネットワークへの影響の緩和です。

当然ながら、すべてのサービスをエッジに配置すればよいわけではなく、サービスが求める遅延とその効果、それにかかる費用などを考慮して最適なバランスを判断する必要があります。

図 4-5 に、MEC として想定されるユースケースと、アプリケーション許容遅延時間についてまとめました。なお、遅延の値は一般的なサービスが求める参考値を記載したもので、アプリケーションによって大きく異なることにご注意ください。また、遅延はトランスポート遅延に加えて MEC サーバや仮想基盤で追加される遅延、アプリケーション処理にかかる遅延も含まれることにもご注意ください。

図 4-5　MEC のアプリケーション特性と配置についての考察 [7]

図 4-5 の表をみると、既存のスマートフォンを活用したモバイルビデオ配信や、Virtual Reality（VR; 仮想現実）に関しては許容遅延が比較的大きいことがわかります。このようなサービスは、トランスポートに流れるトラフィック量の抑制によるコスト削減効果が得られやすく、かつ QoE（ユーザ体感品質）を損わない範囲で MEC を配置することが可能と考えられます。配置場所としては、アグリゲーションやコアが候補となるでしょう。

一方で、MEC をよりユーザに近いエッジに設置することで、4G 以前は実現できなかった 10ms 以下、場合によっては 1ms 以下の超低遅延サービスが実現できると期待されています。こうしたサービスの候補を示したのが、表の中の下段です。5G の超低遅延サービス（URLLC）では、MEC の低遅延特性を活かした多くのサービスが実現に向けて議論されています。すでにトライアルが実施されているサービスもあります。

実証実験の例として、モバイル Augmented Reality（AR; 拡張現実）では、5G を利用して、重機と距離を置いた安全な操作室から重機を操作する実証実験があります[8]。この実験では重機操作における遅延の許容が 100ms まで可能です（重機備え付けのカメラ映像処理を含む）。重機の操作室を、県を代表するアグリゲータの近くの企業オフィスに置けば、その県の配下の重機を操作することも可能になります。