1. 目的
- これまで、AWS Wavelengthの検証を行ってきたが、単一のWavelength Zone(以下、WL Zone)のみを使用する構成がメインだった。
- 2022/6時点で、米国であれば10以上、日本にも2個(東京、大阪)のWL Zoneがあるため、複数のWL Zoneを使用するようなユースケースを想定した検証を実施する。
2. やったこと
想定するユースケース例
- 想定構成
- 東京のライブ会場から映像をWL Zone(Tokyo)に送信。
- WL Zone(Tokyo)内の映像中継サーバで、映像をAWSの内部NWを経由してWL Zone(Osaka)へ送信。
- 東京のエンドユーザは、WL Zone(Tokyo)の映像中継サーバにアクセスして映像を受信。
- 大阪のエンドユーザは、WL Zone(Osaka)の映像中継サーバにアクセスして映像を受信。
- メリット
- エンドユーザが最寄りのWL Zoneのサーバにアクセスすることによる低遅延での映像配信。
- 全ての通信経路がキャリア網およびAWS内部ネットワークで完結（インターネットに出ない）。
- なお、今回は例として簡単な構成確認、疎通確認をしたのみで、低遅延の追求などをしているわけではない。
WL Zone間の疎通確認
- まず、WL Zone間で通信が可能なことを確認する(pingレベル)。
- WL Zone (Tokyo) - WL Zone (Osaka) 間 ※2つのWL Zoneの親リージョンが同一の場合
- WL Zone (Tokyo) - WL Zone (San Francisco Bay Area) 間 ※2つのWL Zoneの親リージョンが別の場合
WL Zoneを2つ用いたSRT映像伝送
- 次に、より具体的な動作確認としてSRTでの映像伝送を行う。
- 構成概要としては以下の通り(構成図も参照)。
- WL Zone (Tokyo) にSRT Gateway00を立てる。
- WL Zone (Osaka) にSRT Gateway01を立てる。
- User00から、SRT Gateway00へ映像を送信する。
- SRT Gateway00は、SRT Gateway01へSRTで映像を転送する。
- User01は、SRT Gateway00から映像を受信する。
- User02は、SRT Gateway01から映像を受信する。
- 想定ユースケースとしては、User01が東京、User02が大阪にいて、User02は最寄りのWL Zone(Osaka)にアクセスするイメージだが、今回は検証の都合上User02も東京からアクセスする。(筆者が東京のため)
- 海外のWL Zone内のインスタンスに外部(Carrier Gateway経由)からアクセスする環境が手元にないため、海外のWL Zoneを含めて映像伝送の検証することは断念。
3. 構成図
4. 設計上の注意点
- 複数のWL Zone間での通信に関して、公式ドキュメント「Considerations for multiple Wavelength Zones」 に以下の注意点あり。
| 注意点 | 対策 | |
|---|---|---|
| 1 | 同一VPC内のWL Zone間通信不可。 | WL Zone(Tokyo)を持つVPCとWL Zone(Osaka)を持つVPCを別々に作成し、Transit Gateway (以下、TGW)で接続する。 |
| 2 | WL ZoneのsubnetはTGWのアタッチメントの接続先として指定不可。 | WL Zoneを持つVPCにて、Wavelengthの親リージョンの親AZにsubnetを作成し、そこにTGWを接続する。 |
- 注意点1について
- WL Zone(Tokyo) - WL Zone(Osaka) 間は、それぞれのWL Zone を持つVPCを1つずつ作成し、東京リージョンに作成したTGWに2つのVPCを接続する。
- WL Zone(Tokyo) - WL Zone(San Francisco Bay Area) 間は、それぞれのWL Zone を持つVPCを作成し、東京リージョンのTGW、オレゴンリージョンのTGWにそれぞれのVPCを接続した上で、TGW同士をピアリングする。
Considerations for multiple Wavelength Zones
EC2 instances that are in different Wavelength Zones in the same VPC are not allowed to communicate with each other. If you need Wavelength Zone to Wavelength Zone communication, AWS recommends that you use multiple VPCs, one for each Wavelength Zone. You can use a transit gateway to connect the VPCs.
- 注意点2について
- WL Zone(Tokyo/Osaka)の親リージョンは東京リージョンだが、親AZはドキュメントとしては公開されていない。自分の検証アカウントで確認した限りでは、WL Zone(Tokyo)の親AZが apne1-az4、WL Zone(Osaka)の親AZが apne1-az1 だったため、そのAZにSubnetを作成し、TGWを接続している。
- WL Zone(San Francisco Bay Area)の親リージョンはオレゴンリージョンだが、親AZは公開されていない。こちらも確認すると親AZは usw2-az2 だったため、そのAZにSubnetを作成し、TGWを接続している。
For each Wavelength Zone, a subnet in an Availability Zone that is the parent Availability Zone for the Wavelength Zone. In the example, you create subnet 1 and subnet 2. For information about creating subnets, see Create a subnet in your VPC. Use describe-availability-zones to find the parent zone.
A transit gateway. The transit gateway connects the VPCs. For information about creating a transit gateway, see Create a transit gateway in the Amazon VPC Transit Gateways Guide.
For each VPC, a VPC attachment to the transit gateway in the parent Availability Zone of the Wavelength Zone. For more information, see Transit gateway attachments to a VPC in the Amazon VPC Transit Gateways Guide.
5. 手順
各WL Zoneの親AZの確認
- 今回、WL Zone(Tokyo, Osaka, SFO)の3つを使用する。それぞれのWL Zone内のインスタンスが、TGWを通じて別のVPCと通信する場合、自分のVPCの親AZのsubnetに対して、TGWのアタッチメントが作成され接続されている必要がある。
- CLIで各WL Zoneの親AZを確認する。
| WL Zone | 親AZ | |
|---|---|---|
| 1 | Tokyo(NRT) | apne1-az4 |
| 2 | Osaka(KIX) | apne1-az1 |
| 3 | San Francisco Bay Area(SFO) | usw2-az2 |
- 以下は東京リージョンでのコマンド実行例(抜粋)。"ParentZoneId" のところを確認する。
[ec2-user@ip-10-0-0-101 ~]$ aws ec2 describe-availability-zones
{
"ParentZoneId": "apne1-az1",
"OptInStatus": "opted-in",
"Messages": [],
"ZoneId": "apne1-wl1-kix-wlz1",
"GroupName": "ap-northeast-1-wl1",
"State": "available",
"NetworkBorderGroup": "ap-northeast-1-wl1-kix-wlz-1",
"ParentZoneName": "ap-northeast-1c",
"ZoneType": "wavelength-zone",
"ZoneName": "ap-northeast-1-wl1-kix-wlz-1",
"RegionName": "ap-northeast-1"
},
{
"ParentZoneId": "apne1-az4",
"OptInStatus": "opted-in",
"Messages": [],
"ZoneId": "apne1-wl1-nrt-wlz1",
"GroupName": "ap-northeast-1-wl1",
"State": "available",
"NetworkBorderGroup": "ap-northeast-1-wl1-nrt-wlz-1",
"ParentZoneName": "ap-northeast-1a",
"ZoneType": "wavelength-zone",
"ZoneName": "ap-northeast-1-wl1-nrt-wlz-1",
"RegionName": "ap-northeast-1"
}
VPC作成
- 構成図の通り、VPC00～VPC02の3つのVPCを作成する。
- WL Zone、および親リージョンの親AZにsubnetを作成する。
- Carrier Gatewayを作成し、WL ZoneのsubnetのデフォルトルートをCarrier Gatewayに設定する。
TGWの作成
-
東京リージョンにTGWを作成する。
-
TGWアタッチメントを2つ作成する。
- アタッチメントタイプ: VPC(VPC00を選択)、親AZに作成したsubnetを選択
- アタッチメントタイプ: VPC(VPC02を選択)、親AZに作成したsubnetを選択
-
オレゴンリージョンにTGWを作成する。
-
TGWアタッチメントを2つ作成する。
- アタッチメントタイプ: VPC(VPC01を選択)、親AZに作成したsubnetを選択
- アタッチメントタイプ: Peering(東京のTGWを選択)
-
TGW(Tokyo)にて、TGW(Oregon)からのPeering接続要求を承認する。
-
結果として、TGW(Tokyo)には3つ、TGW(Oregon)は2つのアタッチメントがある状態となる。(以下はTGW(Tokyo)のアタッチメントの状況)
ルーティング設定
- WL Zone の各Subnetに、他VPCへのルーティング情報を追加する。
| WL Zone | 宛先subnet | Nexthop | |
|---|---|---|---|
| 1 | Tokyo(NRT) | 10.1.0.0/16, 10.2.0.0/16 | tgw |
| 2 | Osaka(KIX) | 10.0.0.0/16, 10.1.0.0/16 | tgw |
| 3 | San Francisco Bay Area(SFO) | 10.0.0.0/16,10.2.0.0/16 | tgw |
- WL Zone(Tokyo)のsubnetのルーティングテーブルは以下のようになる。
- TGWのアタッチメントに紐づくルートテーブルに、対向のリージョンへのルーティング情報を追加する。
| TGW | 宛先subnet | Nexthop | |
|---|---|---|---|
| 1 | TGW(Tokyo) | 10.1.0.0/16 | TGW(Oregon) |
| 2 | TGW(Oregon) | 10.0.0.0/16, 10.2.0.0/16 | TGW(Tokyo) |
- TGW(Tokyo)に接続されたアタッチメントに紐づくルートテーブルは以下のようになる。
ping疎通確認
-
各WL Zoneにping用のEC2インスタンス(Amazon Linux 2)を起動し、ping疎通確認を行う。
-
WL Zone(Tokyo) -> WL Zone(Osaka) のping
[ec2-user@ip-10-0-0-101 ~]$ ping 10.2.0.30
PING 10.2.0.30 (10.2.0.30) 56(84) bytes of data.
64 bytes from 10.2.0.30: icmp_seq=1 ttl=254 time=18.2 ms
64 bytes from 10.2.0.30: icmp_seq=2 ttl=254 time=15.5 ms
64 bytes from 10.2.0.30: icmp_seq=3 ttl=254 time=15.4 ms
64 bytes from 10.2.0.30: icmp_seq=4 ttl=254 time=15.3 ms
^C
--- 10.2.0.30 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 15.366/16.142/18.205/1.196 ms
- WL Zone(Tokyo) -> WL Zone(SFO) のping
[ec2-user@ip-10-0-0-101 ~]$ ping 10.1.0.53
PING 10.1.0.53 (10.1.0.53) 56(84) bytes of data.
64 bytes from 10.1.0.53: icmp_seq=1 ttl=252 time=131 ms
64 bytes from 10.1.0.53: icmp_seq=2 ttl=252 time=128 ms
64 bytes from 10.1.0.53: icmp_seq=3 ttl=252 time=128 ms
64 bytes from 10.1.0.53: icmp_seq=4 ttl=252 time=128 ms
^C
--- 10.1.0.53 ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 4006ms
rtt min/avg/max/mdev = 128.568/129.390/131.564/1.306 ms
[ec2-user@ip-10-0-0-101 ~]$
SRT Gatewayの作成
-
映像伝送プロトコルであるSRTの送受信が可能なSRT Gatewayを、WL Zone(Tokyo)、WL Zone(Osaka)に作成する。
- AMI:「Haivision SRT Gateway」(ami-0966f74458e325ed3)
- インスタンスタイプ: t3.medium (推奨構成ではないが、最低限動けばよいので)
-
「Haivision SRT Gateway」の設定方法は割愛するが、以下のような内容を設定する。
- SRTGW00(Tokyo)で、Source: Listener 自分のport/5000 を設定。(port/5000でUser00からの映像送信を待ち受け)
- SRTGW00(Tokyo)で、Target: Listener 自分のport/5001 を設定。(port/5001でUser01からの映像取得を待ち受け)
- SRTGW00(Tokyo)で、Target: Caller SRTGW01(Osaka) port/5002 を設定。(SRTGW01のport/5002に対してcallerモードで接続し、映像を送信)
- SRTGW01(Osaka)で、Source: Listener 自分のport/5002 を設定。(port/5002で、SRTGW00からの映像送信を待ち受け)
- SRTGW00(Osaka)で、Target: Listener 自分のport/5003 を設定。(port/5003で、User02からの映像取得を待ち受け)
-
SRTに関する構成図は以下の通り。
SRTの疎通確認
- PCをモバイルルータにテザリング接続する。
- User00として、スマホアプリ(Larix Broadcaster)から映像をSRTGW00(Tokyo)に対して送信する。(写真内手前のスマホで、PCの時計を撮影)
- User01として、PCアプリ(VLC Media Player)で、映像をSRTGW00(Tokyo)から受信する。(写真内 PC画面左下)
- User02として、PCアプリ(VLC Media Player)で、映像をSRTGW01(Osaka)から受信する。(写真内 PC画面右下)
- 特に何も設定チューニングなどしていない状態で、3秒くらいの遅延になっているが、映像自体は問題なく伝送できた。
6. 所感
- 複数のWL Zone間で問題なく通信ができることが確認できた。ユースケースに応じて、また詳細な確認などを実施してみたい。