5G MEC (KDDI / AWS Wavelength) を試す（設定編）

皆さん 5G MEC を起こしてみましょう

私は 5G MEC に興味（期待）があり、先日から KDDI の MEC サービスを試し始めています。まずは MEC を構成して、インターネットからアクセスするところまで試せたので、その構成や手順などを共有します。

KDDI MEC を試すのは以下のように超簡単でした！

• MEC を用意する作業については、KDDI の窓口を通すことが一切ない
• つまり AWS コンソールをポチポチするだけで実験環境の構築が完了する
• あとは 5G 端末があればすぐ試すことができる（see; 実測編）
• 5G 端末は単に KDDI の 5G 契約つきスマートフォンで良い（機器の限定やユーザの限定などは必要ない）

5G MEC に興味がある人は 全員一度試すべき！ と思います。

2021/4/20 追記： 先行記事筆者の @mksamba さん曰く、5G でなく 4G 端末からでも（少し遅延が増えるが）アクセス可能とのこと。補足ありがとうございます。

2021/6/23 追記： @ChujoHiroto さんが、AWS CloudFoundation を使って（勿論 MEC として機能する）Wavelength 環境を自動的に構築する記事を書かれました。これで本記事を読まなくても（おい）同様の環境が作成できます！

この文書の目的と構成

先行事例である @mksamba さんの記事「 【初心者】AWS Wavelengthを使ってみる」に大いに助けられました。ありがとうございます。基本的にはこちらを皆さん追いかけて頂ければ何とかなるかと思います。

そこで基本的な手順は上の先行記事で見て貰うとして、この文書では KDDI に関連する事項と、概念的な整理に集中しようと思います。私同様 AWS あるいは Wavelength 初心者の人たちで、私と同じようにハマる傾向のある人たちの助けになれば、と思ってまとめてみます。

全体構成

先に今回構築しようとする KDDI MEC 実験システムの全体構成を示します。（この図も先行記事の冒頭図とほぼ同じものです。）

パープルの点線は、システム管理者であるあなたや、MEC 上のアプリケーションにアクセスしようとする 5G 端末のユーザのアクセス経路を示しています。

以下に、今回の構成について注目すべき箇所について列挙します。私は作業を始める前にこのあたりのことが頭に入っておらず迷うことが度々ありました。

Wavelength のアクセス制限

• 外部から MEC (Wavelength instance) への直接のアクセスは 5G 端末から行うものと考える
• インターネットから MEC に対する直接アクセスは ICMP 以外は遮断されている
• そのため MEC のセットアップなどを Internet から行うためには、隣接Subnetの踏み台 (bastion server) から行うことにする

Wavelength のこのアクセス制約のため、最低でも上図のように踏み台用とMEC用の 2 つの instance を、Zone 2 つに分けて起こす構成になると思います。

対称性

ところで全体構成を見ると、左右二つの Zone, Gateway, instance の構成がかなり対称的に見えると思います。それぞれの呼び方について表にまとめておきます。AWSの操作経験のある人はこれでコンソールでの表現が読みやすくなるかと。

呼称	Internet(踏み台)側	Wavelength側
Zone	Availability Zone	Wavelength Zone
Gateway	Internet Gateway	Carrier Gateway
Global IP	Elastic IP (Public IP)	Carrier IP

Global Address

驚いたことに MEC のグローバルアドレスが（一つまでなら無料で！）超簡単に割り当てられます。

• Wavelength user にはキャリア(KDDI)の保有する global IP address がアサインされる（一つまでは無料）
• これを Carrier IP Address と呼ぶ
• Carrier IP は Carrier Gateway にセットされ、Wavelength instance のある Subnet 内アドレスに変換して届けられる

Elastic IP Address も一つまでは無料で割り当てられますが、いやあ、簡単でいいですね。

実験環境の構築

この実験環境を構築するための操作について、以下の順で示します。（AWS のアカウント登録は既に行っているものとします）

1. Wavelength Zone のアクセス・リクエストを出す
2. VPCを作成する
3. 踏み台用の（つまり普通の）EC2 インスタンスを作成する
4. Internet Gateway を設定して外部からの到達性を確認する
5. MEC用の（つまりWavelengthの）EC2 インスタンスを作成する
6. Carrier Gateway を設定して外部からの到達性を確認する

それぞれの細かな作業については、先行記事 をご覧下さい。以下では私が引っ掛かったところ、悩んだところなどに絞って書いておきます。

1. Wavelength Zone のアクセス・リクエストを出す

まずKDDIの5G関連ページなどを見ていると、以下のようなリンクにたどりつくと思います。

このリンク先、https://aws.amazon.com/jp/wavelength/getting-started/ つまり AWS Wavelength 一般の開始方法のページになっています。つまりこの段階では、というか全体を通して KDDI 特有の手続きなどは何もありません。

このページの「(1) Wavelength Zone にオプトインする」からの手順を追いかければおおよそうまくできるようになっています。まず、Wavelength Zone へのアクセスをリクエスト リンクをたどって、申請を行ってください。オプトインする、と書かれているのでちょっとピンと来ないかもしれませんが、単にリクエストを送る、という意味です。

このリクエストを送ると、何日かで承認された、というメイルが届きます。私の場合（2021/4）は二日で承認確認のメイルが届きました。（承認されるまでは、Wavelength 関連のメニューや選択肢が AWS コンソールに現れてきません。）

2. VPCを作成する

手順については先行記事に詳しい説明があります。

ただ一点、注意があります。大阪に MEC を作りたい人も、VPC 作成の際には 東京 Region を指定する必要があります。以下詳細。

ここでいきなりつまづきました。私は関西在住なので大阪の Wavelength instance を作ろうとして、まず大阪 (ap-northeast-3) Region を選択しました。しかし大阪 Region には Wavelength Zone が無いのです。（2021/4 現在の状況です）
AWS は2021/2/4に「本日、大阪の KDDI の 5G ネットワークにおける新しい AWS Wavelength Zone の提供を開始します」と発表しているのに。。

右上矢印のところで大阪 Region が指定されていることが確認できます。しかし大阪の全 Availability Zone の表示に、Wavelength Zone がありません。しばらく探し回って、東京 Region に含まれていることを発見しました。

以下に 東京 Region (ap-northeast-1) に含まれる Zone の一覧表示を出しておきます。

右上矢印のところで東京 Region (ap-northeast-1) を指定すると、東京の全 Zone に、Wavelength Zone が存在するのが分かります。また、その Wavelength Zone には、二つの Zone が含まれている事が分かります。特に図で赤丸をつけたところに注目してください。（kix-Osaka, nrt-Tokyo）

つまり以下のような内部配置になっているような感じですね。

• Wavelength Zone は東京と大阪の二つがあるが、
• その両方とも 東京 Region にある
• つまり 東京 Region の中に東京と大阪の二つの Wavelength Zone が含まれており、
• 大阪 Region は存在するが、そこには Wavelength Zone は無い

これ以降、常に東京 Region を選択して作業をしてください。大阪に MEC を作る場合でも、大阪 Region にはせず、東京 Region です。その中にしか大阪 Wavelength Zone はありません。

（これらはすべて 2021/4 現在の状況です。なお、先述の Wavelength のアクセス・リクエストが承認されていないと、東京 Region でも Wavelength Zone の表示がまったく表示されませんので念のため。）

できあがった VPC

3. 踏み台用の（つまり普通の）EC2 インスタンスを作成する

やはり手順については先行記事に図があります。

ここは余り悩むところは無いかと。私は無料利用枠の対象である t2.micro タイプを選択しました。そうそう一つだけ。セキュリティグループの設定時に、デフォルトでは SSH しか通さないようになっているので、ICMP に返事をさせる設定を追加しました。

できあがった Instance

できあがった Subnet

（下のスクリーンショット時点ではもうルートテーブルにデフォルトルート(0.0.0.0/0)が追加されており、そこに Internet Gateway が関連づけられています。）

4. Internet Gateway を設定して外部からの到達性を確認する

余りハマりどころはありません。せいぜい Internet Gateway は VPC に関係づける（アタッチする）ことに注意することくらいでしょうか。後に出てくる Carrier Gateway は VPC 内の Subnet に関係づけられていますからね。

Wavelength Zone は AWS 網の中で無く、キャリアの閉域網の中に設置される Zone ですから、内部構造が幾らか異なることが想像されます。

できあがった Internet Gateway

状態が Attached になっていることが重要です。

ping テスト

Internet 上のサイトから、この踏み台となる Instance にめがけて ping を掛けて疎通確認をします。

$ ping 13.231.xxx.xxx
PING 13.231.xxx.xxx (13.231.xxx.xxx): 56 data bytes
64 bytes from 13.231.xxx.xxx: icmp_seq=0 ttl=229 time=15.804 ms
64 bytes from 13.231.xxx.xxx: icmp_seq=1 ttl=229 time=12.534 ms
64 bytes from 13.231.xxx.xxx: icmp_seq=2 ttl=229 time=13.521 ms
^C
--- 13.231.xxx.xxx ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 12.534/13.953/15.804/1.369 ms
$ 

このとき、作成した踏み台のインスタンスが本当に返答している事を tcpdump で確かめておきます。

$ ssh -i /usr/home/.../secret_rsa.pem -l ec2-user 13.231.xxx.xxx
....(snip)....
[ec2-user@ip-10-0-1-41 ~]$ sudo su
[root@ip-10-0-1-41 ec2-user]# tcpdump icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
02:26:51.131164 IP host123.example.com > ip-10-0-1-41.ap-northeast-1.compute.internal: ICMP echo request, id 6676, seq 0, length 64
02:26:51.131189 IP ip-10-0-1-41.ap-northeast-1.compute.internal > host123.example.com: ICMP echo reply, id 6676, seq 0, length 64
02:26:52.132112 IP host123.example.com > ip-10-0-1-41.ap-northeast-1.compute.internal: ICMP echo request, id 6676, seq 1, length 64
02:26:52.132145 IP ip-10-0-1-41.ap-northeast-1.compute.internal > host123.example.com: ICMP echo reply, id 6676, seq 1, length 64
02:26:53.137131 IP host123.example.com > ip-10-0-1-41.ap-northeast-1.compute.internal: ICMP echo request, id 6676, seq 2, length 64
02:26:53.137155 IP ip-10-0-1-41.ap-northeast-1.compute.internal > host123.example.com: ICMP echo reply, id 6676, seq 2, length 64
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel
[root@ip-10-0-1-41 ec2-user]# 

正しく到達できていることが確認できました。次に進みましょう。

5. MEC用の（つまりWavelengthの）EC2 インスタンスを作成する

手順については先行記事に詳しい説明があります。先行記事では米国の Zone の中に作っていますが、これが KDDI になります。それによって Subnet を作成する Zone の候補は以下のようになります。


私は以下のように、大阪（つまり kix ）の Wavelength Zone を指定しました。


インスタンス作成では インスタンスのタイプ に注意が必要です。
（Wavelength非対応のものを指定するとエラーが出ます。）

以下にインスタンス作成直前の確認画面を出しておきます。

ここで、サブネットを Wavelength 向けのもの、自動割り当てパブリックIPは不要、 キャリア IP の自動割り当てを有効、としておきます。（ただ、ここ、ちょっと分かっていません。先行記事 の図では、この「キャリアIPの自動割り当て」の項目がありません。また、自動割り当てにセットしないとインスタンス作成時にエラーが出るようなのですが（後述）、だからといってCarrier IP が自動的に付与されるわけでもありません。はて何か間違えたか。。）

2021/4/20 追記： 先行記事筆者の @mksamba さんから、この事に関する詳しい説明を頂きましたので、そちらを参照ください。自動割り当てパブリックIPは不要、キャリア IP 自動割り当てに関しても（後で手作業で割り当てるのであれば）不要、とのことです。

できあがった Wavelength Instance

インスタンス作成時に出たエラー

私が遭遇したエラーについて出しておきます。

"The requested configuration is currently not supported"

このとき私は Wavelength が対応していないインスタンス・タイプを選んでいました。資料 によると、選べるのは t3.medium, t3.xlarge, r5.2xlarge, g4dn.2xlarge だけとなっています（2021/4現在）。t3.medium を選択しなおしたところ、作成に成功しました。

"The Availability Zone does not support associating a public IP address""

自動割り当てパブリックIPは「なし」、キャリア IP の自動割り当てを「有効」にしていなかった場合、このエラーが出ました。少し上に図示したように合わせてやると、作成に成功しました。

できあがった Subnet

（下のスクリーンショット時点ではもうルートテーブルにデフォルトルート(0.0.0.0/0)が追加されており、そこに Carrier Gateway が関連づけられています。）

6. Carrier Gateway を設定して外部からの到達性を確認する

手順については先行記事に詳しい説明があります。

キャリア IP の取得

先行記事 に手順があるのですが、ここ、少しワナ？があります。取得操作では以下のような画面になります。


しかしこの「ネットワークボーダーグループ」は Wavelength Zone のものではありません。この ap-northeast-1 の後ろに「 - （ハイフン）」を書き足す（タイプする）と、Wavelength Zone の候補（先述の kix, nrt）がリストアップされて選択できるようになります。（気がつきにくく、不親切）


ここを指定して割り当てを行うと、今度はこの Carrier Gateway とインスタンスの関連付けを行うよう促されます。以下のようにインスタンスを指定します。

できあがった Carrier Gateway

状態が Available になっていることが重要です。

ping テスト

Internet 上のサイトから、この Wavelength Instance にめがけて ping を掛けて疎通確認をします。（繰り返しますが、Internet から MEC に直接アクセスできるのは ICMP だけです。MEC へのアクセスは 5G 閉域網から行うものだ、と思って下さい。）

$ ping 106.161.xxx.xxx
PING 106.161.xxx.xxx (106.161.xxx.xxx): 56 data bytes
64 bytes from 106.161.xxx.xxx: icmp_seq=0 ttl=239 time=19.278 ms
64 bytes from 106.161.xxx.xxx: icmp_seq=1 ttl=239 time=7.426 ms
64 bytes from 106.161.xxx.xxx: icmp_seq=2 ttl=239 time=30.325 ms
^C
--- 106.161.xxx.xxx ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 7.426/19.010/30.325/9.350 ms
$ 

このとき、作成した Wavelength Instance が本当に返答している事を tcpdump で確かめておきます。

（踏み台サーバから Wavelength Instance に ssh login）
[ec2-user@ip-10-0-1-41 ~]$ ssh 10.0.2.244
Last login: Fri Apr 16 15:18:07 2021 from 10.0.1.41
....(snip)....
[ec2-user@ip-10-0-2-244 ~]$ sudo su
[root@ip-10-0-2-244 ec2-user]# tcpdump icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
03:18:17.884429 IP host123.example.com > ip-10-0-2-244.ap-northeast-1.compute.internal: ICMP echo request, id 12038, seq 0, length 64
03:18:17.884461 IP ip-10-0-2-244.ap-northeast-1.compute.internal > host123.example.com: ICMP echo reply, id 12038, seq 0, length 64
03:18:18.887099 IP host123.example.com > ip-10-0-2-244.ap-northeast-1.compute.internal: ICMP echo request, id 12038, seq 1, length 64
03:18:18.887135 IP ip-10-0-2-244.ap-northeast-1.compute.internal > host123.example.com: ICMP echo reply, id 12038, seq 1, length 64
03:18:19.890770 IP host123.example.com > ip-10-0-2-244.ap-northeast-1.compute.internal: ICMP echo request, id 12038, seq 2, length 64
03:18:19.890799 IP ip-10-0-2-244.ap-northeast-1.compute.internal > host123.example.com: ICMP echo reply, id 12038, seq 2, length 64
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel
[root@ip-10-0-2-244 ec2-user]# 

おわりに

5G MEC は既に docomo も KDDI もサービスインしているのですが、何しろ情報が少ないです。そこで「こんなに簡単に試せるよ」ということを示して、事例が増えることを期待しています。

今回はまず、AWS 側のセットアップまででした。次は 5G 端末からのアクセス実験、実測編 をご覧下さい。