AWS Wavelengthを活用した動的な5G エッジディスカバリアーキテクチャー

AWS Hybrid Cloud and Edge Computing サービスの導入は開発者に対してコンピューティングリソースおよびストレージへの低遅延なアクセスを提供し、AWSインフラストラクチャのグローバルな展開を急速に拡大しています。米国内だけでも、19個のAWS Wavelengthゾーンが一般提供されています。アプリケーションを展開する場所の選択肢が増えることにより、どの場所がアプリケーションリクエストにとって最適になるのかが新たな課題になっています。

エッジを意識したデプロイ: エッジディスカバリの原点は、効果的に地理分散したデプロイになります。カバレッジと低遅延アクセスを最適化したい開発者は、お客様の要件を満たすために複数のWavelengthゾーンにアプリケーションをデプロイする必要があります。自動的な決断メカニズムが大規模でエッジコンピューティング展開において極めて重要です。別の投稿では、この課題に対処するためのテクニック（例: Pod Topology Spread Constraints）について説明しました。

エッジディスカバリ: アプリケーションがデプロイされた後、特定のクライアントセッションに対する最適なアプリケーションエンドポイントを決定するための選択基準、方法論、またはアルゴリズムが必要です。これには通信遅延、利用可能なネットワーク帯域幅、ネットワークトポロジーなどが含まれて考慮する必要があります。

ドメインネームシステム（DNS）は、サーバーなどのリソースに到達するためのデファクトアプローチですが（例: myedgeapplication.com）、エッジコンピューティングに必要な精度と粒度が通信プロバイダ（CSP）ネットワーク内で常に提供されているわけではありません。たとえば、Amazon Route 53などのDNSサービスは、ロケーションベースのルーティングを提供しています。DNS名（例: myedgeapplication.com）は、ユーザーの地理的な位置に基づいてエンドポイントにルーティングすることができますが、基本的にはユーザーのDNSリゾルバのIPアドレスによって決定されます。

ただし、再帰的なDNSルックアップで使用されるIPアドレス（eDNSが有効でない限り）は、要求デバイスではなくそのDNSサーバーのIPアドレスになります。DNSサーバーの場所がクライアントがアタッチされているUPFの場所と一致しない場合、結果は不正確なマッピングになります。開発者には、リクエストを出すデバイスの場所をより詳細で正確な特定方法が必要です。

この課題を対処するために、この記事では、CSPが開発したエッジディスカバリサービス（EDS）APIを使用し、イベント駆動アーキテクチャと統合するリファレンスパターンを記載します。例として、この記事では、Verizon Edge Discovery Serviceを使用して、高度に分散したエッジコンピューティング環境でモバイルクライアント向けのダイナミックなワークフローを提供する方法を示します。

モバイルネットワークの基本

モバイルエッジ環境に接続する際、モバイルトラフィックはRadio Access Network（RAN）を介してルーティングされます。すなわち、LTE無線（eNB）または5G無線（gNB）およびパケットコアネットワークを介してルーティングされます。UEがモバイルネットワークにアタッチすると、LTEでは特定のPacket Gateway（PGW）、5GではUser-Plane Function（UPF）と呼ばれるノードとの接続が確立され、ユーザ端末（UE）のすべての入出力データトラフィックが処理されます。これにより、キャリアグレードのNAT（CG-NAT）が使用され、UEのトラフィックはプライベートモバイルネットワークからパブリックインターネットへと変換されます。

モバイルネットワークでは、UEはコアネットワーク内でアタッチされているLTE PGW（または5G UPF）との間で確立されたIPセッションを維持しながら、無線RANセル間でシームレスに移動し、ハンドオーバーすることができます。カバーエリアが失われた場合やUEが再起動した場合（デバイスをオンオフにした場合）、UEまたはネットワークは再アタッチをトリガーし、コアネットワークとのIPセッションを再確立します。したがって、モバイルハンドオーバーはWavelengthゾーンのネットワークトポロジー上の近さに影響を与えないケースがほとんどです。たとえクライアントが数百マイルを移動したとしても、地理的に最も近いWavelengthゾーンが変わったが、ネットワークトロポジー上最も近いWavelengthゾーンは変わりません。その結果、モバイルアプリケーションでは、現在接続しているエンドポイントが最適かどうかを定期的にチェックすることが推奨されています。

具体的な例を挙げましょう。ある朝、ニューヨーク市で電源を入れた4G/5Gデバイスがあると仮定します。このデバイスはニューヨーク市のPGWにアタッチされます。したがって、最も低遅延のWavelengthゾーンはニューヨーク市となります。このモバイルデバイスが2,000マイル西にあるデンバー市に移動したとしても、最も低遅延のWavelengthゾーンはニューヨーク市のままです。ネットワークに再アタッチしない限り、この状況は続きます。

デンバー市からは、クライアントはすべてのトラフィックをニューヨーク市のパケットコアを介して、キャリアのバックボーンを経由でデンバー市に戻ってきます。ジオロケーションベースのディスカバリはこの動きに影響を与えることはありません。これは、従来のCSPが設計した継続性と信頼性を重視する長寿命セッションの性質によるものです。ただし、5Gのネットワークでは、CSPはリアンカリングとセッションの継続性に対し、より大きな柔軟性が与えられています。したがって、この例で、今では最も近いWavelengthゾーンはデンバー市のになる可能性があります。

開発者を5Gネットワークの深い専門知識から解放するために、Edge Discovery API には使いやすいサービスメッシュが用意されています。これにより、5G ネットワークトポロジーに対応した方法を公開して、クライアントを最適なエッジコンピューティングゾーンにルーティングできます。Edge Discovery API は、ネットワークのパフォーマンス特性 (最大遅延、必要な帯域幅など) を考慮したユーザー定義のサービスプロファイルを使用して、トポロジー的に最適なモバイルエッジコンピュートノードを選択できます。この方法により、「最適な」エッジゾーンをどのように決定するかというロジックは、アプリケーション開発者から通信プロバイダにオフロードされます。

キャリア開発したEDSデザイン

EDS は、データベース、キュー、マイクロサービス、その他のクラウドリソースなど、あらゆるアプリケーションリソースをカスタム名で登録できる API です。各カスタム名は ServiceEndpoints オブジェクトと呼ばれる一意の識別子で、通信事業者向けのアプリケーションサービスのエンドポイントメタデータで構成されます。各 ServiceEndpoint オブジェクトは、キャリアの IPv4 アドレス (AWS Wavelength では IPv6 は現在サポートされていません)、オプションとして FQDN 、ポート、およびその他のメタデータで構成されています。

モバイルクライアントが最適なエッジエンドポイントを特定しようとする場合、クライアントはまず、TURNサーバーやその他のツール（例: ifconfig.me）を使用してCG-NATパブリックIPを特定する必要があります。IPアドレスを特定した後、この値を必要なUEIdentity属性とともに指定されたserviceEndpoints識別子に渡すことで、最適なサービスエンドポイントを取得します。APIリファレンスについて詳しくは、「 5G Future Forum API specifications 」や「5G EDS documentation」を参照してください。

図1: EDSワークフロー

EDSワークフロー

例として、VPC（10.0.0.0/24）に2つのサブネットがあり、各サブネットにはAmazon Elastic Compute Cloud（Amazon EC2）インスタンスが起動されています。各インスタンスにはキャリアIPアドレスがアタッチされています。

1) サンフランシスコWavelengthゾーン（us-west-2-wl1-sfo-wlz-1）CIDRレンジ10.0.0.0/26

キャリアIPアドレス: 155.146.21.144

2) ラスベガスWavelengthゾーン（us-west-2-wl1-las-wlz-1）CIDRレンジ10.0.0.64/26

キャリアIPアドレス: 155.146.118.11

図2: Amazon VPCアーキテクチャ

EDSへのアクセス

EDS を使用するには、まず API を認証してサービスプロファイルを作成する必要があります。このオブジェクトは、Edge アプリケーションに必要なリソースを記述し、EDS が応答する選定基準を定義します。注目すべきサービスプロファイルフィールドには、最小帯域幅、最大リクエストレート、最小可用性、最大遅延などがあります。

次に、ServiceEndpoints オブジェクトを一連のレコードとともにサービスプロファイルにアタッチします。ワークフロー全体の例として、サービスプロファイルとServiceEndpointsの関係を示した前の図を参考してください。

最後に、最適な Edge エンドポイントを特定したいモバイルクライアントの場合、API を認証して、選択した ServiceEndpointSid からエンドポイントを取得する必要があります。EDS から、サービスプロファイルで定義されている最適なエンドポイントのリストが回答されます。

EDSの拡張: 動的エンドポイントの更新

UEがEDS APIを呼び出す基本的な部分に加えて、開発者体験向上のための最適化ができます。例えば、EDS APIをAWSネイティブのワークフローと統合することで、エッジコンピュートサービスエンドポイントのマッピング管理を簡素化することができます。たとえば、図3は、3つ目のWavelengthゾーンが導入された場合に何が起こるかを示しています。手動で操作しなければ、Wavelengthゾーン3 に地理的に近い UE は適切にルーティングされません。これは、エンドポイントを登録するために EDS に対して新しいクエリを行わなければ、新しいロケーションがマッピングされないためです。

エンドポイントを動的に登録するソリューションを構築するために、次のAWSサービスを使用します。

Amazon EventBridge: AWSサービスからデータを取り込むサーバーレスのイベントバスを使用して、カスタムルールを設定して自動応答をトリガーできます。
AWS Lambda: AWS Wavelengthメタデータを抽出し、サードパーティのEDSを埋めるサーバーレス関数を作成できます。
AWS Systems Manager Parameter Store: EDSのAPI応答から、AWS Systems Manager Parameter Storeに必要な情報（例: serviceEndpointsIdおよび認証情報）をキャッシュすることができます。
Amazon EC2 Tag: 単一のアカウントから複数のエッジアプリケーションを管理できるようにするために、アプリケーションリソースに適切にタグを付け、Lambdaで選択される特定のタグを使用します。

図3: Amazon EC2を使用したエッジディスカバリアーキテクチャ

前述した動的なエッジディスカバリの手法は以下のワークフローに基づきます：

デプロイ前に、アプリケーションリソースに使用する一連のAWSタグを事前に選択します。この例では、eds-data-plane-app-nameとcustomer-wavelength-appをそれぞれタグキーと値として選択しました。これらのタグは、EDS APIに自動的に登録されるリソースを一意に識別します。
次に、Amazon EC2ライフサイクルイベントに基づいた特定のルールを使用してEventBridgeを設定します。エッジ環境のすべての変更をキャプチャするために、最も確実な方法は、EC2インスタンスの実行・終了状態の変更を表すイベントを全てキャプチャすることです。イベントが検出されると、EventBridgeは関連するメタデータをキャプチャするためのLambda関数をトリガーします。
Lambda関数の第一部分では、現在実行中のEC2インスタンスで、タグ（ステップ1から）が一致するすべてのEC2インスタンスをAmazon EC2 APIから取得します。取得された各EC2インスタンスに対して、アタッチされたキャリアIPアドレスを抽出します。アタッチされたアドレスは、起動後にアタッチされる静的アドレス（Elastic IP）または起動時に割り当てられるエフェメラルIPアドレスとして表示される可能性があることに注意してください。
Lambda関数の第二部分では、EDS API に対して認証を行い、ServiceEndpoints オブジェクトに最新のエッジエンドポイントを設定します。これには、新しいレコードの作成や古いレコード (EC2 インスタンスの終了/停止など) の削除が含まれる場合があります。
EDSの現在の設計では、serviceEndpointsオブジェクトが更新されるたびに、新しいserviceEndpointsId識別子が返されます。AWS環境が最新のメタデータを持つことを確認するために、Lambda関数はAWS Systems Manager Parameter StoreにserviceEndpointsIdの最新値を書き込みます。
モバイルデバイスの観点からは、最も近いAWS Wavelengthゾーンのエンドポイントを特定するたびに、EDS APIを認証・クエリして、最適なエンドポイントを取得します。
EDSの応答に従い、モバイルクライアントはIPアドレスとポートまたはFQDNと直接接続できます。

EDSと自動スケーリング環境の統合

エッジアプリケーションのトラフィック量が多い場合、AWS Auto Scaling を使用してキャパシティを動的に調整し、スケーリングプロセスを管理できます。上記の例の環境が下記のように拡張されたと仮定します。

サンフランシスコWavelengthゾーン（us-west-2-wl1-sfo-wlz-1）

インスタンス1：アタッチされたキャリアIPアドレス：155.146.21.144

インスタンス2：アタッチされたキャリアIPアドレス：155.146.21.135

インスタンス3：アタッチされたキャリアIPアドレス：155.146.21.128

ラスベガスWavelengthゾーン（us-west-2-wl1-las-wlz-1）

インスタンス1：アタッチされたキャリアIPアドレス：155.146.118.41

インスタンス2：アタッチされたキャリアIPアドレス：155.146.118.32

インスタンス3：アタッチされたキャリアIPアドレス：155.146.118.2

図4：AWS Auto Scalingを使用したエッジディスカバリアーキテクチャ

モバイルクライアントがEDS APIをクエリし、最適なエッジリソース名（ERN）がサンフランシスコWavelengthゾーン（us-west-2-wl1-sfo-wlz-1）である場合、APIレスポンスとしては3つのインスタンスIPアドレス（155.146.21.144、155.146.21.135、155.146.21.128）の間でロードバランシングしません。このシナリオでは、EDSは次の方法でDNSを併用すべきです：

高可用性を実現するために、各WavelengthゾーンにApplication Load Balancer（ALB）を作成し、各Wavelengthゾーンのインスタンスを対象グループとして設定します。例えば、サンフランシスコWavelengthゾーンにALBを構成し、上記の3つのEC2インスタンスを対象グループとして設定します。AWS Wavelengthでのロードバランスについて詳しくは、「Enabling load-balancing of non-HTTP(S) traffic in AWS Wavelength.」をご覧ください。

ドメイン（例：edgeapp.com）を取得した後、各Wavelengthゾーンのサブドメインを作成し、エイリアスレコードを使用してロードバランサーのFQDNを指定するようにします。例えば、sfo.edgeapp.comは、サンフランシスコWavelengthゾーンALBのFQDNに変換するようになります。

次に、EDS APIを設定します。servceProfileを作成した後、serviceEndpointsオブジェクトを作成し、エッジリソース名（ERN）ごとに単一のリソースレコードを設定します。この場合、2つのレコードがあります。サンフランシスコWavelengthゾーンERN（us-west-2-wl1-sfo-wlz-1）に対応するレコードと、ラスベガスWavelengthゾーンERN（us-west-2-wl1-las-wlz-1）に対応するレコードです。

前のシナリオでは、各リソースレコードに対してIPv4アドレスとポートが指定されますが、今回は、そのWavelengthゾーン内のALBの完全修飾ドメイン名が指定されます（上記ステップ4を参照）。UEからEDS APIをクエリする際、出力はALBのDNS名であり、IPアドレスではありません（ステップ7と8を参照）。

直接 vs. 間接的なエッジディスカバリ

現在、EDS API にはモバイルネットワーク内からだけではなく、パブリックインターネットからもアクセスできます。これにより、API の呼び出しが柔軟になり、特に EDS をモバイルクライアントから直接問い合わせるもしくは間接的に問い合わせるかを可能となります。

直接（クライアントサイド）：特定のユースケースでは、開発者は簡素化を求め、各モバイルエンドポイントが直接EDSと対話するようにしたいのです。この例では、モバイルデバイスは上記のステップ6-7に従います。このアーキテクチャの「コスト」は 2 つあります。1 つは、数百（もしくは数千）のデバイスが API キーのコピーを保持しなければならないセキュリティ上のリスクと、EDS への不必要に大量の呼び出しのことです。

間接（サーバーサイド）：他の場合では、開発者はエッジディスカバリをAWSネイティブのエンティティに「オフロード」したい考えもあります。これはコンテナ化されたアプリケーションまたはLambda関数として存在し、モバイルデバイスはこのキャッシュ層との直接対話のみを行うようにします。このモデルの例については、MongoDB World 2022で紹介された「real-time data architecture on Amazon EKS in AWS Wavelength.」をチェックしてください。この例では、ウェブアプリケーションにはJavaScriptを埋め込み、直接EDSと対話するサーバーレス関数を呼び出します。

結論

この記事では、エッジコンピューティング環境でEDSを使用して、地理的に分散した低遅延のアプリケーションに最適なエンドポイントを特定する方法を示しました。そして、AWSサーバーレスサービスがEDS APIを強化するアーキテクチャを紹介しました。さらに、EventBridgeとLambdaを介したサーバーレスワークフローが、Edge Discoveryアーキテクチャにエンドポイントを自動的に登録する方法も示しました。

エッジディスカバリは、エッジアプリケーションのウェルアーキテクチャーの重要なコンポーネントの1つです。詳しくは、hands-on lab from re:Invent 2022をチェックするか、re:Invent 2021のVerizon’s presentation on network intelligenceセッションをご覧ください。

さあ、始めてみましょう。Verizon EDS documentationまたは5G Future Forum websiteをご覧いただき、Edge Specialist Sales Teamに質問してみてください。

著者について

Robert Belson

Robert は、AWS エッジコンピューティングを専門とする AWS ワールドワイドテレコムビジネスユニットのデベロッパーアドボケイトです。開発者コミュニティや大企業のお客様と協力して、自動化、ハイブリッドネットワーキング、エッジクラウドを使用してビジネス上の課題を解決することに重点を置いています。

本記事は、「Deploying dynamic 5G Edge Discovery architectures with AWS Wavelength」を翻訳したものです。

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

Amazon Web Services ブログ