AWS での 5G コアネットワークディザスタリカバリ

本記事は、「Disaster Recovery 5G Core Network on AWS」（2023年6月26日公開）を翻訳したものです。

通信サービスプロバイダ（CSP）は、通信業界においてさらなるネットワークの活用事例を見つけようとしています。AWS上の5Gコアネットワーク導入事例として、企業向けのプライベートネットワークや新たな5Gネットワークの設計導入などのユースケースが挙げられるなど、ますます注目されています。AWS のホワイトペーパーで紹介されているように、AWS のグローバルクラウドインフラストラクチャである AWS Regions、AWS Availability Zones（AZ）、AWS Local Zones、AWS Outposts は、ネットワーク機能（NF）の特性に合わせて 5G コアネットワークをホストするための効果的かつ柔軟な環境を提供できます。一例として、ユーザプレーン機能（UPF）は、低遅延で処理するために AWS Local Zones や AWS Outposts に配置することができます。

5G NF on AWS のさまざまなユースケースの中でも、すでに 5G コアネットワークを構築している CSP にとって、導入障壁の低いユースケースの1つは、AWS を活用した災害復旧（DR）です。この 5G DR ネットワークは、5G NF の障害、データセンターの完全停止、またはメンテナンス期間中に対するスケーラブルかつ即時の対策を目指しています。具体的には、この DR 用のネットワークは、計画されたメンテナンスもしくは災害による予期せぬ停止等に応じてのみ追加される環境であるため、迅速なスケールインとスケールアウトによってリソースのコストを最小限に抑える必要があります。従来の、CSP のデータセンターに冗長なネットワークを構築する場合と比較して、CSP が通常運用時にコストとエネルギー消費を最小限に抑えることを実現できます。また、輻輳によるトラフィックの急増やメンテナンスイベントなどの変動的な需要にも迅速に対応できます。

この記事では、AWS を 5G ネットワーク導入における予備系の仮想データセンター環境として活用し、「災害耐性」と「災害復旧」の目標を達成する方法について説明し、AWS における 3GPP の高可用性概念や関連する AWS サービス（オートスケーリング、自動化ツール、ネットワークのコスト最適化など）を活用することに焦点を当てています。具体的には、Amazon Elastic Compute Cloud（Amazon EC2）の Autoscaling 機能、Amazon Elastic Kubernetes Service（Amazon EKS）の Horizontal Pod AutoscalingとCluster Autoscaling機能を使用して、DR 用の VPC 内のコンテナベースのネットワーク機能（CNF）の必要リソースを最小限に抑えることができます。また、トラフィックの急増に対応するための迅速なスケールアウトもできます。

さらに、コストと消費電力を最適化するために、Graviton インスタンスを用いて 5G コア NF を AWS 上に構築することも検討できます。このブログでは、まず DR モデルとその特徴を説明します。最初に 5G ネットワークのケースにどのように適用されるかを説明し、次に 3GPP アーキテクチャを活用してこの DR 目標を達成する方法や、いくつかのオープンソースの例を用いて EC2 Autoscaling、Cluster Autoscaling、およびその他の機能などの AWS サービスをどのように活用できるかといった重要なアイデアを示します。

AWS での 5G コアネットワークの DR モデル

こちらの DR に関する記事とホワイトペーパーで説明されているように、DR には2つの目標 (Recovery Time Objectice (RTO), Recovery Point Objective (RPO)) があります。リカバリタイムオブジェクティブ（RTO）は、サービスの中断と復旧の間の許容遅延時間を意味し、リカバリポイントオブジェクティブ（RPO）は、最後のデータ復旧ポイントからの許容時間を意味します。AWS 上で実行される一般的なアプリケーションの場合、DR のための AWS サービスには AWS Elastic Disaster Recovery（AWS DRS）や Amazon Route 53 Application Recovery Controller（Route 53 ARC）などがあります。

しかし、5G コア NF では、3GPP 標準に基づくネットワークインタフェースとプロトコルに対するより強い要件があります。AWS DRS などのサービスはコアネットワークのすべてのコンポーネントに常に適用できるわけではありません。この記事ではより包括的な視点から、3GPP の標準アーキテクチャのコンテキストで、AWS のサービスが DR 実装にどのように役立つかに焦点を当てます。

5G NF の場合、AMF、SMF、UPF などのコア機能コンポーネントは、5G 音声およびデータサービスの高速な復旧に重要な役割を果たすため、RTO がより重要です。一方、UDM は RPO と RTO の両方に強く影響されます。なぜなら、UDM は加入者のプロファイルと情報を扱うからです。各 NF には異なる目標があり、異なるタイプのDRモデルを適用することが必要となります。以下の図は、DR ホワイトペーパーで強調されている DR の 4つのモデルを示しています。左から右へと進むグラフィックは、DR モデルによって RTO と RPO が変わることを示しています。5G コア NF の場合、ミッションクリティカルなサービスを提供しているため、より短い RTO が求められる場合があります。

図1: 一般的なアプリケーションの DR モデル

例えば先に述べたように、UDM はリアルタイムに近い RTO と RPO の両方が必要です。従って、AWS 上の UDM の DR サイトを構築する場合、UDMを常にアクティブな状態に保つためには、従来のデータセンターの UDM と同期する必要があります。この場合、Hot-standby（Active-Active）モデルがより適切です。

一方、その他の NF には、Warm-standby、Pilot light、Backup ＆ Restore などのモデルをユースケースと NF の特性に基づいて適用できます。Backup ＆ Restore は、ミッションクリティカルではい、優先度の低いユースケース（1 時間未満という厳しい RTO が要求されない場合）に適用できます。CSP のデータセンターと AWS の間に事前に確立された Amazon Direct Connect（もしくは帯域幅制限と安定性を備えた Site-to-Site VPN で代替可能）があれば、AWS CloudFormation、AWS Cloud Development Kit（AWS CDK）、AWS CodePipeline などの AWS ツールを利用して、「NF の即時インスタンス化」を実現できます。Infra as Code（IaC）の利点によってさらに加速化することも可能です。詳細については、こちらの AWS 記事 DR Architecture on AWS, Part II を参照してください。また、AWS 上での 5G NF デプロイ CI/CD パイプラインも迅速なサービス回復に貢献できます。詳細については、こちら AWS ホワイトペーパー CI/CD for 5G Networks on AWS を参照してください。

Cold-standby は、ミッションクリティカルでない 5G ネットワークユースケースに対して、コスト効果の高い選択肢です。このモデルでは、すべての EC2 インスタンスがシャットオフ状態ですが事前に作成されており、通常運用時は DR サイトにトラフィックを処理させない状態になっています。そのため、Backup ＆ Restore よりも高速で、Warm-standby よりもコスト効果が高くなります。一方、Warm-standby は、音声通話およびデータ通信サービスの RTO を考慮して、AWS 上に DR 用 5G ネットワークを構築する最も実用的な方法です。このモデルでは、DR サイトのほとんどの 5G NF が最小限のデプロイで少量のトラフィックを処理し、トラフィックカットオーバー時にトラフィックを処理できるように拡張します。これにより、5G ネットワークの災害耐性を実現しながら、サービスの連続性を確保することができます。5G NF が Amazon EKS 上に実装されている場合、一般的なオートスケーリンググループベースの機能だけでは、トラフィックの急増を吸収するための瞬時スケールの要件を満たせない場合があります。これは、要求されるRTOがKubernetesオートスケーリングアクションの一般的な応答時間よりも短いためです。そのため、この記事の後半では、Amazon EKS 環境でこのより速い Warm-standby を実現するための効果的な実装方法を詳細に紹介します。最後に、コスト最適化の観点から、Graviton インスタンスはコストパフォーマンスの面で著しい利点を提供し、エネルギーの節約に関連する問題に取り組んでいます。

3GPP で定義された耐障害性メカニズムと AWS での活用

3GPP は、5G コアネットワークのネットワーク耐性を構築するため、NF Set と呼ばれる概念を TS23.501 で定義しています。この概念では、NF は単一のインスタンスとして展開されるか、もしくは同じ NF の複数のインスタンスが NF Set を形成することができます。これにより、NF インスタンスが障害になった場合、 NF set 内の代替 NF インスタンスに置き換えて、代わりにリクエストされたサービスを提供したり、サービス要求の急増を処理したりできるため、サービスの冗長性とスケーラビリティが高まります。5G コアネットワークでは、AMF、SMF、UDM など、NF Set の概念をサポートする多くの NF があります。DR のユースケースでは、N2 トラフィックを gNodeB から受け取る AMF set の利用により、AMF が各データセンターにある NF にトラフィックを転送します。次の図は、AMF set 構成の例です。AMF set はトラッキングエリアコード（TAC）ごとに構成され、AMF が3つの異なるデータセンターに跨ってトラフィック負荷を分散し、障害時のスイッチオーバーを行います。3GPP では AMF set. のロードバランシングの概念も定義しており、各 AMF の Weight Factor を使用して、各データセンターの AMF の容量に基づいて UEの登録（Registration）を制御できます。

図2: 複数のデータセンターにまたがる3GPP NF Setのデプロイ

AMF set のような NF set の概念により、NF のグループがデータセンター間でトラフィック負荷分散することができますが、Network Repository Function（NRF）は、AMF 以外の NF に対するトラフィック負荷を局所化することができます。具体的には、3GPP の標準に従い、NRF は Nnrf_Management（nnrf-nfm）および Nnrf_Discovery（nnrf-disc）サービスを使用して、サービスを要求する他の NF（Consumers）にサービスを提供する NF（Producers）のステータスに関する情報を維持および提供することを担います。NRF サービス Nnrf_Management は、「NFRegister」の動作をサポートし、5Gコアネットワークのすべての NF が NRF に対してそれぞれのプロファイルを登録するために使用されます。登録プロセス中、NF は NFProfile の一部として、nfInstanceID、nfType、nfStatus、FQDN、IPv4/IPv6アドレスなどの必須情報を NRF に送信し、オプションとして、優先度や地域など、NF Set に関連する情報も送信します。

図3: NRF への NF 登録と NRF へのサービスリクエストの例

NRF サービス Nnrf_NFDiscovery は、5G NF（Network Function）の「Consumer」に「Producer」の情報を提供するための「NFDiscover」という操作をサポートしています。通常、商用ネットワークがより高い可用性を実現するために、CSP は複数の Producer NF のインスタンスを展開します。3GPP では、Producer NF を発見するためのオプションが Consumer NF に提供されています。Consumer は、必要なサービスの要件に一致するすべての Producer NF の一覧リストを要求するか、追加のクエリパラメータで返されるリストを絞ることができます。Consumer NF が使用できるクエリパラメータの1つは、異なる Producer NF に対して NRF から返された優先度情報に基づいています。Consumer NF が使用できるもう1つのパラメータは、「preferred-locality（優先ローカリティ）」です。AMF setと NRF preferred-locality は、DR on AWS のユースケース、特に Pilot light、Warm-standby、または Hot-standby のために活用することができます。例えば、AMF の重み係数が既存のデータセンターと AWS 上の仮想 DR データセンターで同じ値で構成されている場合、DR サイトは Hot-standby モードで動作します。

障害時におけるオンプレミスデータセンターから VPC へのトラフィックシフト

一般的なオンプレミス商用 5G コアネットワークにおいては、少なくとも1つの DR サイトが展開されます。DR サイトの数は、CSP の方針に依存します。さらに、1+1、N+1、または N+K いずれかの冗長構成が適用されます。DRサイトの数に関係なく、オンプレミスの DR サイトには、アクティブサイト障害のトラフィックを引き継ぐために必要となる最低限のリソースが常に割り当てられます。

CSPは、NF set のメカニズムを使用して、NF インスタンスのグループをアクティブサイト（または既存のデータセンター）と DR サイト（AWS上の仮想データセンター）に分散させることができます。AWS 上の DR サイトでは、3GPP をサポートする 5G NF が既存のオンプレミスの NF set の一部として構成することができます。NF set の一部として追加できない 5G NF は、新しいインスタンスにデプロイできます。NRF のデプロイモデル（集中型または分散型）に応じて、DR サイトのNFはオンプレミスの中央集権型 NRF に登録するか、AWS 上のローカルNRFに登録することができます。ただし、いずれの NRF 展開オプションにおいても、Warm-standby モデルでは、DR サイトのNFは登録時に、オンプレミスのNFよりも低い優先度（AMF の場合は低い Weight Factor）を使用することが重要です。これにより、通常時はアクティブなオンプレミスサイトがトラフィックを継続的に処理し、災害、NFの故障の発生時、またはメンテナンス作業時にのみ、トラフィックが AWS 上の DR サイトに移行されます。

DR サイトがアクティブになると、AWS のスケーラビリティと柔軟性を活用して NF の容量を拡張することも重要です。また、NF の登録プロセス中に「preferred-locality」情報を使用することで、トラフィックを DR サイトの 5G NF 内に保つことができます。これにより、遅延を抑え、サービスリクエストの応答時間が向上します。

図4: AWS 上の 5GC ネットワーク DR サイト

通常時のシナリオでは、大部分のトラフィックはオンプレミスのアクティブサイトで処理されるため、CSP は AWS 上で最小限の DR サイトにおけるリソースから始めることができます。その後、障害のタイプに応じて、単一または複数の NF が次の章で説明する高速オートスケーリングメカニズムを利用し、適切なリソースまで拡張します。このモデルは、完全なオンプレミスサイトの故障だけでなく、部分的な故障のケースやオンプレミスのメンテナンス作業時の間にも適用することができます。

トラフィック急増を対応するための高速オートスケーリング

前章で説明したように、Warm-standby モデルの場合、5Gコア NF は最小限のリソースでAWSに展開され、アクティブサイトのトラフィックの一部を処理します。しかし、プライマリサイトに障害が発生した場合、トラフィックがプライマリサイトから AWS 上の DR サイトに移行するため、大規模なトラフィックの急増が予想されます。この場合、5G NF と AWS のコンピュートプラットフォームの容量を迅速にオートスケーリングすることが重要です。5G NF のオートスケーリングは通常、Kubernetes HPA（Horizontal Pod Autoscaler）に基づいて行われます。ただし、POD のスケーリングだけではワーカーノードのスケールアウトに対応できません。5G NF は Amazon EKS を利用して AWS にデプロイされているため、この課題の解決策は Autoscaling Groups と関連しています。Amazon EKS は、Kubernetes のワーカーノードのデプロイと管理（スケールアウトを含む）に Autoscaling Group を利用します。ただし、Autoscaling Group の Cluster Autoscaler 機能は、5G のスケールアウトの反応時間要件に対して遅くなることが懸念されます。これは、cluster autoscaler が受動的な仕組みで、POD がスケジュールできないと判明した後にのみクラスターのスケーリングが誘発されるためです。その代わりに、Autoscaling Group の cold-standby 機能を利用することで、トラフィック急増する際に迅速に Amazon EKS ワーカーノードのスケールアウトを行うことができます。

図5: Amazon EKS ワーカーノードの状態変更による Cold-standby モデルの高速スケールアウト

さらに、Cold-standby モデルの使用により、Amazon EKS ワーカーノードは NF をホストするために事前に設定されるだけではなく、使用されていない間は電源をオフにしてコストを節約することができます。これは、起動時のスクリプトによる特別なチューニングを必要とするワークロード（通常は Multus と DPDK を使用するワークロードなど）に特に有効です。これらのワーカーノードは、Amazon Elastic Container Registry（Amazon ECR）または他の場所から POD コンテナイメージを事前にダウンロードするなど、さまざまな事前処理を行うことができます。そのため、POD の起動時にコンテナの準備完了状態までの時間が短縮されます。Cold-standby ワーカーノードの自動化は、こちらの記事の GitHubリポジトリで示されているカスタム Lambda 関数によって実現できます。

図6: Cold-Standby Amazon EKS ワーカーノードの自動起動プロセス

カスタムメトリクスに基づいたスケーリングの自動化

Warm-standby モデルでは、プライマリサイトがメンテナンス中または災害/障害のためにダウンした時に、トラフィックの急増がアプリケーションのカスタムメトリクスで検知されます。例えば、AMF 登録試行数のメトリクスが急増します。Amazon Distro for Open Telemetry（ADOT）のアプリケーション Metrics Scraping を利用し、Cold-standby ノードの起動を誘発する手法も利用できます。以下の図には、Amazon Managed Prometheus サービスからカスタムメトリクスを収集するために KEDA を使用し、事前に定義された条件と閾値に基づいてKubernetes ジョブをキックオフし、ワーカーノードをオンライン状態にするソリューションの一例が示されています。

図7:カスタムメトリックと KEDA を活用した高速オートスケーリング

Hot-standby と Warm-standby の DR モデルのコスト比較

5G コアの AWS とオンプレミスの地理的冗長ソリューションの TCO 比較はかなり複雑ですが、Warm-standby DR モデルと前述した Cold-standby の仕組みの組み合わせによるコスト削減効果を比較することができます。一例として、全トラフィックを処理できる Hot-standby（Active-Active）サイトには、6つの m5.8xlarge EC2 インスタンスが必要となると仮定し、Warm-standby モードでは、一部分のトラフィックのみを処理するため、2つの m5.8xlarge EC2 インスタンスが必要と仮定します。そして、AWS 上の DR サイトへのトラフィックシフトが平均して毎月4時間発生すると仮定します。この例では、毎月4時間のみ、DR サイトはすべてのトラフィックを処理するために追加の4つのm5.8xlarge EC2インスタンスが必要となります。

Hot-standby の場合、AWS Calculator と US-East（Ohio）の EC2 インスタンスの saving plan 価格（64GB の EBS ストレージを搭載したインスタンスで、この記事作成時の価格）を使用すると、常時稼働している6つの m5.8xlarge EC2 インスタンスの年間費用は $47,830.32 になります。一方、Warm-standby の場合、AWS Calculator for Warm Standby を使用して計算すると、コストは$16,914.60 になります。これには、2つの常時稼働している m5.8xlarge EC2 インスタンスの年間費用 $15,943.44 と、毎月 4 時間稼働する 4 つの追加 m5.8xlarge EC2 インスタンスのオンデマンド価格による年間費用 $294.96、および 4 つの 64GB EBS ボリュームの年間費用 $676.20 が含まれます。

以下のグラフから分かるように、Warm-standby モードの利用により、Hot-standby（Active-Active）モードと比較して約 65% の節約が実現されます。

図8: 6つの m5.8xlarge EC2 インスタンスの Hot-standby と Warm-standby のコスト比較

CSP は、5G コアネットワークに対して、上記のアプローチを適用する際に、AWS Calculator for EC2 を利用して EC2 インスタンスの数量を入力し、Warm-standby DRモデルの実施による潜在的なコスト削減を計算することができます。

結論

5Gモバイルコアネットワークは、音声通話やデータストリーミングなどのミッションクリティカルなサービスを提供するため、サービスの災害耐性を確保し、ネットワークコンポーネントの迅速な災害復旧の能力を持つことが重要です。障害や災害からの迅速な復旧を実現するために、従来のオンプレミスデータセンターではなくクラウド上に DR 5G ネットワークの構築を検討することが考えられます。また、この DR 5G ネットワークが限られた期間に使用されることが主な目的である場合（サービスの回復やトラフィックバーストの吸収）、クラウドの従量課金モデルとの相性が良いと考えられます。AWS は、CSP のお客様に対して、DR 仮想データセンターを構築するための環境だけでなく、この記事の GitHubリポジトリのサンプルで示されているようなネットワークの自動化とスケーリングツールなどの支援も提供します。この高速スケーリングアウト能力を、Graviton インスタンスなどの適切なタイプ/サイズのインスタンスと組み合わせることで、CSP にとってコストとエネルギーの節約の最適化を実現することができます。AWS での CSP の 5G ユースケースの詳細については、thinkwithwp.com/telecom/contact-us にお問い合わせください。

著者について

Ashutosh Tulsi

Ashutosh Tulsi は、AWS ワールドワイドテレコムビジネスユニットのプリンシパルソリューションアーキテクトであり、通信サービスプロバイダー (CSP) や通信事業者 ISV パートナーと連携しています。彼は 4G/5G ネットワークの AWS クラウドへの移行を支援するソリューションを提供することで、CSP の運用効率向上とコスト効率向上を目標としています。

Neb Miljanovic

Neb Miljanovic は、通信事業 ISV パートナーの AWS への移行をサポートする AWS テレコムパートナーソリューションアーキテクトです。彼は 4G/5G/IMS コアアーキテクチャに関する豊富な経験を持ち、その経験をクラウドネイティブなデザインを使用して 4G/5G/IMS ネットワーク機能の AWS への移行に応用することを使命としています。

Dr. Young Jung

Dr. Young Jung は、AWS ワールドワイドテレコムビジネスユニットのプリンシパルソリューションアーキテクトであり、NFV 分野を専門としており、さまざまなグローバル通信パートナーと協力して、AWS 環境のパートナー向けにクラウドネイティブ 4G/5G NFV ソリューションの作成に貢献しています。

翻訳はソリューションアーキテクトの陳誠が担当しました。

Amazon Web Services ブログ