Amazon Web Services ブログ

AWS Wavelength 上で非 HTTP (s) トラフィックのロードバランシングを有効にする

このブログ記事は、Telco Solutions Architect の Jack Chen と、Developer Advocate の Robert Belson が執筆しています。

AWS Wavelength は、AWS のコンピューティングサービスとストレージサービスを 5G ネットワーク内に組み込み、超低レイテンシーアプリケーションの開発、デプロイ、スケーリングのためのモバイルエッジコンピューティングインフラストラクチャを提供します。AWS は、Wavelength Zones における Application Load Balancer (ALB) のサポートを開始しました。ALB はレイヤー 7 の負荷分散のユースケースに対応していますが、Wavelength Zones にデプロイされる一部の低レイテンシーアプリケーションでは、QUIC、WebRTC、SRT などの UDP ベースのプロトコルに依存しており、レイヤー 7 ロードバランサーでは負荷分散できません。この投稿では、AWS Wavelength の一般的な負荷分散パターンについて説明します。これには、DNS ベースの負荷分散が、複数の Amazon Elastic Compute Cloud (Amazon EC2) インスタンス間で非 HTTP (s) トラフィックを負荷分散するという顧客の要件にどのように対処できるかを示すアーキテクチャ案が含まれます。 このソリューションは、Wavelength Zones で実行されるワークロードの自動スケールアップおよびスケールダウン機能の基盤も構築します。

AWS Wavelength における負荷分散のユースケース

AWS リージョンでは、可用性の高いエッジアプリケーションのデプロイを検討しているお客様が、受信したアプリケーショントラフィックを 1 つ以上のアベイラビリティーゾーン(AZ) の複数のターゲットに自動的に分散するアプローチとして Amazon Elastic Load Balancing (Amazon ELB) を検討することがよくあります。ただし、本投稿の公開時点では、AWS マネージドである Network Load Balancer (NLB) は Wavelength Zonesではサポートされておらず、ALB は世界中のすべての Wavelength Zones に展開されています。そのため、この投稿は、AWS Wavelength の負荷分散ソリューションに関する一般的なアーキテクチャガイダンスを文書化することを目的としています。

最も顕著な AWS Wavelength のユースケースの 1 つとして、WebRTC のようなプロトコルを大規模に使用した UDP 通信の没入感が高い動画ストリーミングがあります。ここでは、ライブイベントや一般的な顧客アクセスパターンによるトラフィック急増に対応するために負荷分散ソリューションが必要になることがよくあります。レイヤー 4 トラフィックに依存するこれらのユースケースでは、レイヤー 7 の ALB で負荷分散することはできません。代わりに、レイヤー 4 の負荷分散が必要です。

現在までに、レイヤー 4 ロードバランサーを含め以下の2つのインフラストラクチャデプロイメントが最もよく見られます。

  • Amazon EC2 ベースのデプロイメント : 多くの場合、初期段階の企業や ISV が選択する環境ですが、EC2 インスタンス群は、ビデオストリーミング、データ分析、産業 IoT (IIoT) アプリケーションなどの高スループットのユースケースでロードバランサーを活用します。
  • Amazon EKS デプロイメント : インフラストラクチャのパフォーマンスとコスト効率を最適化したいお客様は、エッジでのコンテナデプロイメントにより Wavelength Zones のアプリケーションを管理できます。次に、外部ロードバランサーを NodePort オブジェクトを介して公開されたサービスを指すように構成できます。さらに、Kubernetes の Ingress を作成するときに、 AWS Load Balancer Controller を活用して ALB をプロビジョニングするという方法も一般的です。

デプロイメントタイプにかかわらず、以下の設計上の制約を考慮する必要があります。

  • ターゲット登録 : AWS が管理していない負荷分散ソリューションの場合、ロードバランサーのターゲット登録をシームレスに行うためのソリューションはお客様が管理する必要があります。考えられる解決策の 1 つとして、最近の HAProxyConf でのプレゼンテーションをご覧ください。
  • エッジディスカバリ : キャリア向けエンドポイントごとに DNS レコードを Amazon Route 53 に入力することはできますが、DNS はモバイルクライアントを最適なモバイルエンドポイントに確定的にルーティングするわけではありません。利用可能な場合にモバイルクライアントを最もレイテンシーの低いエンドポイントに最も効果的にルーティングするには、エッジディスカバリサービスが必要です。
  • クロスゾーン負荷分散 : AWS Wavelength のハブアンドスポーク設計を考えると、お客様管理のロードバランサーはその Wavelength Zones にのみトラフィックをプロキシする必要があります。

ソリューションの概要 — Amazon EC2

このソリューションでは、Amazon EC2 ベースのデプロイメントで、単一の Wavelength Zones で可用性の高い負荷分散を実現します。別の投稿では、 AWS Wavelength における Amazon Elastic Kubernetes Service (Amazon EKS) クラスターの AWS Load Balancer Controller に必要な設定について説明します。
提案ソリューションでは、DNSベースの負荷分散を導入しています。これは、インテリジェントな負荷分散ソフトウェアの複雑さを解消し、Domain Name System (DNS) リゾルバーがトラフィックをエンドポイントセットに（均等に、または加重分散で）分散できるようにする手法です。

本ソリューションでは、Amazon Route 53 の加重ルーティングポリシーを活用して、Wavelength Zones 内で実行されている複数の EC2 インスタンスに対するインバウンド DNS クエリを解決します。特定ワークロードの EC2 インスタンスは Wavelength Zones にデプロイされるため、起動時にキャリア IP アドレスをネットワークインターフェイスに割り当てることができます。

このソリューションにより、AWS Wavelength インスタンスにアタッチされたキャリア IP アドレスが、お客様提供のパブリックホストゾーンの DNS レコードとして自動的に追加されます。

パブリックホストゾーンのレコードがいくつあったとしても、Route53 がクエリにどのように応答するかを決定できるよう、Route53 には多数のルーティングポリシーが用意されています。

シンプルルーティングポリシー — Wavelength Zones の単一リソースにトラフィックをルーティングする必要がある場合は、シンプルなルーティングを使用できます。1 つのレコードに複数の IP アドレスを含めることができますが、Route 53 は値をランダムな順序でクライアントに返します。

加重ルーティングポリシー — 指定した比率を使用してトラフィックをより確定的にルーティングさせる場合は、このポリシーを選択できます。たとえば、キャリア IP アドレス A にトラフィックの 50% を受信させ、キャリア IP アドレス B にトラフィックの 50% を受信させたい場合は、それぞれ 50 と 50 の重みを持つ 2 つの個別の A レコード (キャリア IP アドレスごとに 1 つ) を作成します。Route 53 のルーティングポリシーの詳細については、 Route 53 デベロッパーガイドをご覧ください。

提案ソリューションは、Route 53 DNS の加重ルーティングポリシーを利用して、Wavelength Zones で実行されている複数の EC2 インスタンスにトラフィックをルーティングします。

レファレンスアーキテクチャ

次の図は、本ソリューションの負荷分散コンポーネントを示しています。このコンポーネントでは、Wavelength Zones の EC2 インスタンスにキャリア IP アドレスが割り当てられます。ホスト (www.example.com など) の加重 DNS レコードは、キャリア IP アドレスで更新されます。

デバイスが DNS クエリを実行すると、指定されたドメイン名に関連付けられているキャリア IP アドレスのいずれかが返されます。デバイス数が多い場合は、リソースプール内のすべての EC2 インスタンスに負荷が均等に分散されると予想されます。非常にエフェメラルなモバイルエッジ環境であることを考慮すると、キャリア IP はワークロードに対応するために頻繁に割り当てられ、さらにすぐにリリースされる可能性があります。ただし、この予測不可能な動作により、古い DNS レコードが生成され、「ブラックホール」、つまり存在しなくなったエンドポイントへのルートが発生する可能性があります。

Time-To-Live (TTL) は、DNS 再帰リゾルバーがこのレコードに関する情報をキャッシュする時間を秒単位で指定する DNS 属性です。

この例では、30 秒に設定して、DNS リゾルバーが権威ネームサーバーから最新のレコードを取得するように強制し、古い DNS 応答を最小限に抑える必要があります。ただし、TTLを低くするとコストに直接影響します。これは、再帰リゾルバーから常に最新のレコードを取得するために Route 53への呼び出しが増えるためです。

ソリューションの中核となるコンポーネントは次のとおりです。

Wavelength Zones の上記のサービスに加えて、AWS リージョンでは以下のサービスも利用されています。

  • AWS Lambda — Route 53 サービスに API 呼び出しを行って DNS レコードを更新するサーバーレスのイベント駆動型関数
  • Amazon EventBridge — EC2 インスタンスのライフサイクルイベントに反応し、Lambda 関数を呼び出して DNS を更新するサーバーレスイベントバス
  • Amazon Route 53 — AWS Wavelength がホストするリソースを指すドメインレコードを含むクラウド DNS サービス

本投稿では、特定の負荷分散ソフトウェアソリューションは意図的にお客様に任せています。お客様は、HAProxy や NGINX など、 AWS Marketplace で入手可能なさまざまな一般的なロードバランサーを活用できます。DNS レコードの自動登録に重点を置いて機能的な負荷分散を実現するために、このソリューションはステートレスワークロードのみをサポートするように設計されています。ステートフルなワークロードをサポートするには、スティッキーセッション（ターゲットグループ内の同じターゲットにリクエストをルーティングするプロセス）を基盤となるロードバランサーソリューションで構成する必要があり、DNSがネイティブに提供できる範囲外です。

自動化の概要

前述のコンポーネントを使用して、以下のワークフローの自動化を実装できます。

Amazon CloudWatch アラームは、Auto Scaling グループのスケールアウトまたはスケールインイベントをトリガーし EC2 インスタンスを追加または削除することができます。EventBridge は EC2 インスタンスの状態変更イベントを検出し、Lambda 関数を呼び出します。この関数は、EC2 インスタンスの状態変化に関連する加重 A レコードを追加（スケールアウト）または削除（スケールイン）することにより、 Route53 の DNSレコードを更新します。

自動自動スケーリングポリシーの設定は、この記事の範囲外です。メモリ使用率などの事前定義済みのカスタムメトリクスに基づいて、使用を検討できる Auto Scaling トリガーは多数あります。デモでは、手動による自動スケーリングを利用します。

すでに説明したコアコンポーネントに加えて、このソリューションでは AWS Identity and Access Management (IAM) ポリシーと CloudWatch も利用しています。どちらのサービスも、AWS Well-Architected なソリューションを AWS で構築するための重要コンポーネントです。また、AWS Systems Manager Parameter Store を使用してユーザー入力パラメータを追跡しています。ソリューションのデプロイは、AWS CloudFormation テンプレートによって自動化されます。提供される Lambda 関数は AWS Simple Storage Service (Amazon S3) バケットにアップロードする必要があります。

Amazon Virtual Private Cloud (Amazon VPC)、サブネット、Carrier Gateway、およびルートテーブルは、AWS ベースのネットワークインフラストラクチャにおける基本的な構成要素です。今回のデプロイメントでは、新しい VPC を作成し、選択した Wavelength Zones に 1 つのサブネット、Carrier Gateway を作成し、このサブネットのルートテーブルを更新して、デフォルトルートを Carrier Gateway を指すようにします。

導入の前提条件

本ソリューションを AWS アカウントにデプロイするための前提条件は次のとおりです。

  • Wavelength Zones へのアクセス : アカウントが Wavelength Zones を使用するための許可リストにない場合は、こちらから Wavelength Zones にオプトインしてください。
  • Route 53 でホストされているパブリック DNS ホストゾーン : このソリューションをデプロイするには、登録済みのパブリックドメインへのアクセス権が必要です。このドメインのゾーンは、AWS Wavelength ワークロードをデプロイ予定のアカウントと同じアカウントでホストする必要があります。
    パブリックドメインをお持ちでない場合は、新しいドメインを登録できます。ドメイン登録にはサービス料がかかりますのでご注意ください。
  • Amazon S3 バケット : Route 53 の DNS レコードを更新する Lambda 関数では、ソースコードを.zip ファイルとして Amazon S3 バケットに保存します。
  • Amazon EC2 キーペア : デプロイには既存のキーペアを使用できます。このソリューションをデプロイする予定のリージョンにキーペアがない場合は、これらの手順に従って作成してください。
  • 4G または 5G 接続デバイス : インフラストラクチャは基盤となる接続デバイスとは独立して導入できますが、接続をテストするには、いずれかの Wavelength パートナーネットワークが利用可能なモバイルデバイスが必要です。詳細については、通信プロバイダーと Wavelength Zones のロケーション一覧を確認してください。

まとめ

この投稿では、AWS Wavelength Zones で実行されているワークロードに DNS ベースの負荷分散を実装する方法を示しました。EventBridge ルール と Lambda 関数を使用して Route 53 がホストする DNS レコードを更新するソリューションをデプロイしました。AWS Wavelength について詳しく知りたい場合は、こちらからAWS Compute ブログチャンネルを購読してください。

原文はこちらです。翻訳はソリューションアーキテクトの新谷 歩生が担当しました。