サービスプロバイダー

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

佐々木俊輔
2019年12月23日

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

4.1　はじめにー 5G におけるテレコムクラウド基盤

ここまでの章では、5G において、 4G 以前と比べてアーキテクチャが大きく進化を遂げる点を見てきました。

第 1 章では vRAN のコンセプトが RAN に導入され、従来一体型だった DU と CU の分離および仮想化が可能となることを見ました[1]。続いて第 3 章では、5G Core ではコントロールプレーンとユーザプレーンの分離（CUPS）が可能になり、それぞれのネットワークファンクション（Network Function, NF）を分離してデプロイされることを見てきました[2]。こうしたモバイルソフトウェアアーキテクチャの進化により、5G では、提供するサービスに応じて、 RAN や 5G Core NF およびサービス向けアプリケーションを仮想化基盤上に柔軟に配置できるようになりました。

こうしたアーキテクチャの進化に対応して、モバイル事業者は、ネットワーク機能を配置するための仮想基盤をネットワークの各所に用意し始めています。ここでは、この基盤をテレコムクラウド基盤と呼びます。テレコムクラウド基盤には、パブリッククラウドと同様に拡張性と柔軟性、コスト最適化が期待されます。一方で、NF に一定の性能が求められることや、モバイルネットワーク上に配置されるというモバイル事業者独自の要件も考慮にいれる必要があります。

本章では、このテレコムクラウド基盤、特にデータセンター（DC）ファブリックについて、アーキテクチャや求められる要件を考えていきます。

4.2　モバイル事業者のテレコムクラウド環境の展開（コア/アグリゲーション/エッジ）

ここでは、全国規模でサービスを展開するモバイル事業者のネットワークを考えます。テレコムクラウド基盤が必要となる場所は多岐にわたります。本章では、それぞれの場所の特性に応じて以下のように呼び分けることにします。

バックボーンネットワークの中央拠点にあたる「コア」
地域単位でネットワークを集約する「アグリゲーション」
無線基地局に物理的に近い場所にある「エッジ」

それぞれについて、テレコムクラウド基盤としての要件を考えてみましょう。

図 4-1 の下の表に、コア・アグリゲーション・エッジのそれぞれについて、ロケーションの数、サーバを設置するファシリティの環境、サーバ/NFVI（Network Function Virtualization Infrastructure, ネットワークファンクション仮想化インフラ）/NFV [3] の制約条件についての指標を示します。なお、これらの数値は国や事業者により大きく差があるため、日本における平均的な目安として考えていただければと思います。

図 4-1　モバイル事業者のテレコムクラウド基盤の配置場所 [5]

コアに配置されるデータセンターは、具体的には北海道・東北・関東といったエリア拠点が想定されます。集約拠点であるため数は 10 以下です。一方で、テレコムクラウド環境の構築にあたってファシリティやリソースの制約はありません。ワークロードが集中するため、サーバ環境/NFVI/NFV の性能と拡張性が求められます。コンピューティングとしては、ベアメタル・仮想化基盤・コンテナ基盤といった多様な実行環境が求められることになります。いわゆるパブリッククラウド環境のアーキテクチャに近いと考えてよいでしょう。

アグリゲーションは、具体的には都道府県単位で設置される拠点のデータセンターが想定されます。設置数は 100 が目安となるでしょう。コアに比べて数が多い半面、拠点の規模やファシリティなどの充実度は下がることが想定されます。テレコムクラウド基盤としては、サーバ/NFVI/NFV については拠点のリソース制約に合わせて最適な構築が求められます。

エッジのデータセンターの場所は無線基地局に近い場所が想定されます。設置数としては 1,000 以上を想定としていますが、もしも将来、スモールセル（1 章を参照）の展開が増えた場合には、エッジの数はさらに増えることも考えられます[4]。他社設備を借用する可能性もあり、コストの観点から電源や物理スペースの制約が大きくなると想定されます。サーバについても一般的な 19 インチラック収容のサイズではなく、より小型でかつ耐環境性が高いものが求められるでしょう。NFVI/NFV については、サーバのリソースに合わせて分散配置・スケールアウトが可能なコンテナ環境が主流になると考えられます。

＊

コア・アグリゲーション・エッジでの、それぞれのテレコムクラウド基盤の展開イメージを図 4-1 の上図に示しました。

各データセンターに共通して言えることは、5G サービスの展開に合わせて多数の物理サーバが配備されることになり、それらを収容するために DC ファブリックが必要になると見込まれることです。

物理サーバ上には仮想・コンテナ基盤が構成され、その上にネットワークファンクションやアプリケーションが動作します。各データセンターは分散して配置されることになりますが、一方で、データセンター上のサーバ・NFVI・NFV および DC ファブリックのライフサイクル管理および制御は、モバイル事業者が所有するインフラ全体で一元的・統一的に行われる必要があるでしょう。これを担うのが同図中のエンドツーエンドオーケストレーションのレイヤです。モバイルネットワークサービスに対する共通のポリシーの下に、サービス展開の自動化や統一的なライフサイクル管理を実現することが求められます。

＊

ここまでは、モバイル事業者のテレコムクラウドインフラの全体像をフレームワークとして説明してきました。これらを踏まえて、データセンターの内部に視点を移し、本章のテーマである DC ファブリックのアーキテクチャについて見ていくことにしましょう。

4.3　DC ファブリックに求められる機能

テレコムクラウド基盤における DC ファブリックとは、サーバを収容するポートと低遅延・広帯域接続を提供する CLOS トポロジ [6] のネットワークです。CLOS トポロジは、Spine スイッチと Leaf スイッチの 2 種類のスイッチを水平スケールさせていくトポロジです。ポート数と高帯域が確保しやすくメンテナンス性と拡張性が高いことがメリットの一つで、大型のWeb 企業を中心に採用が広がりました。

この DC ファブリックに求められる機能や特性は次の通りです。

拡張性、柔軟性、統合運用

テレコムクラウド基盤では、5G ネットワークファンクションやアプリケーションのワークロードを柔軟にスケールさせることが期待されるため、それを支える x86 サーバは膨大な数になります。サーバを収容するためのポートを提供する ToR （Top of Rack）スイッチも大量に必要となり、ネットワーク管理者による個別の設定・管理が難しくなることが想定されます。そのため DC ファブリックを構成するスイッチ群を、いわゆる SDN（Software Defined Network）技術によって統合運用する仕組みが求められています。

SDN で構築される多くの DC ファブリックは、アンダーレイネットワークとオーバーレイネットワークを分離したアーキテクチャを採用しています。アンダーレイには L2ではなく、マルチパスが可能で経路制御が容易なL3 の IP ルーティングプロトコル（IS-IS, OSPF, BGP）が採用されます。論理的なオーバーレイには、VXLAN EVPN（RFC 8365）などが用いられています[7]。さらに、ファブリックスイッチへの設定を SDN コントローラが一元的に行うことが一般的です。

運用面で必要になる機能として、ToR スイッチ増設時のディスカバリーや初期設定がゼロタッチで行える機能、故障機器の交換やメンテナンス時に安全にトラフィックを迂回できる機能、交換後に元のスイッチの設定が自動的に復元できる機能等が要件として挙げられるでしょう。これらを実現するための機能を提供するのも SDN コントローラの役割となります。

また、基本的なこととして、サーバ側の多様なポート要件を満たすためには、1G/10G/25G/40G/100G/400G といった幅広い通信レート、光・メタルといった多様なインターフェイス種別をサポートするスイッチのラインナップが必要となるでしょう。

仮想化基盤との連携

DC ファブリックの基本的で最も大事な機能は、テレコムクラウド上で稼働するモバイルネットワークファンクションやアプリケーションに対してネットワーク接続性を提供することです。5G においてはそうしたアプリケーションの多くが仮想基盤やコンテナ基盤上で動作するため、DC ファブリックは仮想ネットワーク・コンテナネットワークとも適切に連携する必要が出てきます。

一例として、アプリケーションインスタンスに割り当てる IP アドレスや、所属させる VLAN などの基本的な情報は、アプリケーションのデプロイ時に仮想・コンテナ基盤によって設定が行われます。DC ファブリックに対しても、それと整合的な設定がアプリケーションのデプロイと同時に行われる必要があります。

これを実現する方法は複数考えられますが、一般的には 1) アプリケーションのデプロイを行うオーケストレータが仮想・コンテナ基盤と DC ファブリックの両方に適切な設定を投入する方法、または 2) 仮想・コンテナネットワークが設定されると同時に、DC ファブリック側に自動的に設定が入るプラグインの仕組みを使う方法のどちらかが採用されています。運用の主体や設定ポリシーによってどういった方式が望ましいかを検討する必要があります。

分析・可視化機能

モバイル事業者にとって、通信品質の監視と維持は 5G になっても変わらず運用上の重要課題です。4G 以前のモバイルネットワークでは、物理的なモバイルネットワーク機器の負荷や外部ポートと内部バスのパケットカウンタ等を SNMP や CLI で監視することで通信品質について一定の監視が行えていました。ところが 5G では、ネットワーク機能が DC ファブリック配下に分散配置されることになるため、DC ファブリック上の通信状況をいかに把握して可視化するかが課題となります。また、大量の DC ファブリックスイッチに対するデータ収集方法として SNMP や CLI ではコレクターの負荷が大きすぎてスケールしないという課題もあります。

ここで活用され始めているのが、Telemetry（テレメトリ）技術です。SNMP や CLI がプル型のデータ収集であるのに対してプッシュ型の方式で、スイッチからコレクター装置に対して高頻度で統計データを送信します。対象となるデータは「ソフトウェアテレメトリ」と呼ばれる装置自体の CPU 利用率やルーティングプロトコル情報、インターフェイスカウンタ、温度などのセンサー情報に加えて、「ハードウェアテレメトリ」と呼ばれるデータプレーンレベルの統計情報があります。後者には、通信フローの情報や ASIC 内部のカウンタ情報などが含まれ、フローの可視化に活用できるほか、通信品質の問題が発生した場合の重要な情報源となります。

テレメトリデータは GPB（Google Protocol Buffer）[8] や JSON 形式の構造化データとしてエンコードされ、それぞれ gRPC（Google remote procedure call）と HTTP(S) プロトコルで運ばれるのが一般的です。収集されたデータはコレクター装置でデコードされたのち、集約・分析・可視化されます。この領域には機械学習（ML, Machine Learning）や AI （Artificial Intelligence）など最新のテクノロジも活用されることが期待されています。

5G でミッションクリティカルなサービスが提供されるようになると、DC ファブリックにおける分析・可視化機能はさらに重要性を増すと想定されます。テレメトリの設定やトポロジ情報が DC ファブリックの設定を行う SDN コントローラと適切に連携できることも重要なポイントになると考えられます。

トランスポートネットワークとの連携

データセンター上で動作するネットワークファンクションやアプリケーションは、モバイルユーザやインターネットなどの外部ネットワークと通信する必要があります。そのため DC ファブリックは、トランスポートネットワークとの間で、データプレーンレベルおよびルーティングプロトコルレベルの両方で適切に連携する必要があります。

ここでは例を使って説明します。図 4-2 は、DC ファブリックとトランスポートネットワークの連携の一例を示したものです。DC ファブリックは図の赤い枠で囲まれた部分にあたります。この例では、DC ファブリックはアプリケーションを論理ネットワーク（VRF）で収容し、その経路を BL（Border Leaf）スイッチがトランスポートの PE（Provider Edge）に eBGP で広報しています。トランスポート側では、第 2 章で見た Segment Routing の上に L3VPN が構成されており、アプリケーションへの到達性を VPNv4 経路としてエンド・ツー・エンドで広報します。

BL と PE の接続方式としては多様な方式がありえますが、この例では Inter-AS Option A またはB（ともに RFC4364）が考えられます[9]。どの方式が望ましいかは通信事業者の接続ポリシーにも依存するため一概には言えませんが、Option B であればトランスポートから DC ファブリックまで切れ目なく Segment Routing MPLS でデータプレーンが延伸されることになります。PE では VLAN インターフェイスが必要なく、ラベルだけを見て転送できるようになるため、PE のスケール面で利点があると言えます。

図 4-2 DC ファブリックとトランスポートの連携の例

4.4　エッジにおける DC ファブリックの要件

エッジにおける DC ファブリックについては、前節までの議論に加えて、ファシリティ面の制約を考慮にいれて要件を考える必要があります。図 4-1 でも見たように、エッジデータセンターはスペースや電力容量が少ない場合があり、コアやアグリゲーションのような規模で DC ファブリックやサーバを配置できるとは限りません。小規模なファブリックの場合、専用のスパインスイッチや SDN コントローラを配置すると非経済的になってしまう可能性もあります。

図 4-2 の例では、コアとアグリゲーションのデータセンターには SDN コントローラが管理する DC ファブリックが配置している一方、エッジについてはリモートリーフ（Remote Leaf）を配置した例を記載しています。

リモートリーフとは、センター側の DC ファブリックからエッジに対して仮想的にリーフスイッチを延伸するような形で配置しリモート制御できる機能です。リーフスイッチのライフサイクル管理や設定の投入などのオペレーションは、コアやアグリゲーションに配置した SDN コントローラから行う仕組みです。こうした機能により、小規模なエッジ DC 拠点にもコスト的に有利な形で DC ファブリックが展開可能となります。

4.5　第 1 回のまとめ

今回は、5G のアーキテクチャ変化に対応したテレコムクラウドの展開と、DC ファブリックのアーキテクチャについて議論しました。Web 企業で採用が広がっている DC ファブリックの最新アーキテクチャに加えて、モバイル事業者のネットワーク内の配置場所に応じて制約事項や求められる要件が異なることを見てきました。第 2 回では、こうした要件に応える実際のソリューションを紹介したいと思っています。

←「はじめに」へ戻る

第 4 章（1）トップへ

第 4 章（2）へ