AWS Wavelength で実現する 5G エッジコンピューティング - 超低レイテンシアプリケーションの設計
Wavelength による 5G エッジでのアプリケーション実行、Wavelength Zone の設計、ユースケースを解説します。
Wavelength の概要
Wavelength は Verizon、KDDI、Vodafone など主要通信事業者の 5G ネットワーク内に AWS コンピュートリソースを配置するサービスです。5G デバイスからのトラフィックが通信事業者のネットワーク内で処理され、インターネットを経由しないため、シングルミリ秒のレイテンシを実現します。AR/VR、ゲームストリーミング、リアルタイム推論など超低レイテンシが必要なアプリケーションに適しています。
Wavelength Zone とアーキテクチャ
Wavelength Zone は通信事業者のデータセンター内に設置された AWS インフラで、レイテンシは 10 ミリ秒以下 (通常 2〜5 ミリ秒) を実現し、EC2、EBS、VPC サブネットを利用できます。既存の VPC に Wavelength Zone のサブネットを追加し、5G エッジのリソースとリージョンのリソース (RDS、S3) を VPC 内で接続します。5G デバイスからのリクエストは Wavelength Zone の EC2 で処理し、データの永続化はリージョンの DynamoDB や S3 に行うアーキテクチャが一般的です。日本では KDDI の 5G ネットワークで東京と大阪の Wavelength Zone が利用可能です。
アプリケーション設計パターン
Wavelength Zone にはレイテンシに敏感な処理 (リアルタイム推論、ゲームサーバー、映像処理) を配置し、バックエンドのデータストアや管理機能は親リージョンに配置するスプリットアーキテクチャが基本です。 Wavelength Zone の EC2 インスタンスはキャリアゲートウェイ経由で 5G デバイスと通信し、 VPC 内のルーティングで親リージョンのサービスにアクセスします。 ECS や EKS のタスク/Pod を Wavelength Zone のサブネットに配置し、コンテナベースのエッジアプリケーションを運用できます。 Auto Scaling で 5G トラフィックの変動に対応し、ピーク時のキャパシティを自動調整します。エッジでの推論には SageMaker のモデルを EC2 にデプロイし、 5G デバイスからの推論リクエストをミリ秒単位で処理します。 Wavelength のトラブルシューティングを学ぶうえで関連書籍 (Amazon)が参考になります。
Wavelength の料金と制約
Wavelength Zone の EC2 インスタンスは親リージョンと同じ料金体系ですが、利用可能なインスタンスタイプが限定されます。キャリアゲートウェイ経由のデータ転送には通信事業者のデータ転送料金が適用され、リージョンのインターネット向けデータ転送料金とは異なります。Wavelength Zone と親リージョン間のデータ転送は AZ 間転送と同じ料金 (約 0.01 ドル/GB) です。利用可能な通信事業者とロケーションは限定されているため、ターゲットユーザーの地理的分布と通信事業者のカバレッジを事前に確認する必要があります。Wavelength Zone で利用できる AWS サービスは EC2、EBS、VPC、ECS、EKS、IAM、CloudWatch などに限定されており、RDS や S3 は親リージョンのものを使用します。
超低レイテンシが効くユースケース
Wavelength は、通信事業者のネットワーク内に AWS の環境を配置し、モバイル端末からごく短い遅延で到達できるようにする仕組みです。この特性が活きるのは、わずかな遅延も体験を損なう用途です。AR や VR のような没入型アプリケーション、対戦型のゲーム、映像をリアルタイムに解析する処理、自動運転やコネクテッドカーの制御、工場の機器をリアルタイムに監視・制御する IoT などが代表例です。これらは、データを遠くのデータセンターまで往復させていては要件を満たせません。端末の近くで処理することで、即応性が求められるアプリケーションを実現できます。
アーキテクチャの設計
Wavelength を使う設計では、何を端末近くのエッジで処理し、何を通常のリージョンで処理するかを切り分けることが要点です。低遅延が求められる即時処理はエッジに配置し、大規模なデータ蓄積やバッチ分析、管理機能はリージョン側に置く、という役割分担が基本です。エッジとリージョンの間はネットワークで連携させ、エッジで処理した結果を集約します。すべてをエッジに置くのではなく、遅延に敏感な部分だけを厳選して配置することで、エッジの限られたリソースを有効に使えます。アプリケーションを遅延要件で分解し、適切な場所へ配置する設計が鍵です。
他のエッジ選択肢との比較
AWS には、エッジで処理するための選択肢が複数あり、要件で使い分けます。Wavelength は、モバイル回線からの超低遅延に特化しています。特定の都市圏でリージョンに近い性能を求めるなら Local Zones が適します。自社の拠点に AWS 環境を置きたいなら Outposts が選択肢になります。静的コンテンツの配信を高速化するだけなら CloudFront で十分です。モバイル端末向けの超低遅延が必須なのか、地理的な近さが目的なのか、オンプレミス設置が要件なのかによって、最適な手段は変わります。何を解決したいのかを明確にして選ぶことが重要です。
制約と運用上の注意
Wavelength は特殊な環境であるため、いくつかの制約を理解して使う必要があります。エッジで利用できる AWS サービスは、通常のリージョンより限られるため、エッジに置く処理は必要最小限の機能で構成します。利用できる範囲は、対応する通信事業者のネットワークとエリアに依存するため、対象とするユーザーの所在と提供エリアが合っているかを確認します。エッジのリソースには物理的な上限があるため、容量を計画的に管理します。これらの制約を前提に、エッジとリージョンを組み合わせた現実的な構成を設計することが、Wavelength を活用する際の勘どころになります。
まとめ
Wavelength の導入判断は、アプリケーションのレイテンシ要件が 10 ミリ秒以下かどうかが基準です。通常のリージョンで 20〜50 ミリ秒の遅延が許容できるなら、Wavelength のコストと運用複雑性は見合いません。導入する場合は、レイテンシに敏感な処理のみをエッジに配置し、データの永続化や分析はリージョンで行うスプリットアーキテクチャが推奨されます。対応キャリアとリージョンが限定されるため、事前に利用可能なロケーションを確認します。