はじめに
実際にMECを触ってみるという観点で学習するべく、AWSのWavelengthを実際に利用することとしました。
それでは実際に触ってみます。
AWSでの構築
KDDIのAWS Wavelengthを用いた構成図は以下のものとなります。
引用元
https://developers.kddi.com/blog/5CamLwJtvfgyQQkW2BZ1CQ
下準備~Wavelengthの有効化~
デフォルトだとWavelengthの利用は無効になっているため、まずはここを有効化します!
VPCの作成
それでは、中身であるVPC,サブネットを作っていきます。
既存のAWSでVPCやサブネットを使う時と大きな変化はないです。
(従来通りの設計でMECを利用できることこそがAWS Wavelengthのメリット)
まずはこのようにしてVPCを作成します。
VPCを作成し終えると次にサブネットを作るのですがその際1点注意点があります。
アベイラビリティーゾーンの設定を通常の東京リージョンではなく、
"アジアパシフィック(KDDI)-東京"
を選択します。(これがWavelength Zoneになります。)
Carrier Gatewayの作成
これはWavelengthを利用するとき特有なのですが、Carrier Gatewayを
作成する必要があります。
通常のVPCだとインターネットと接続するにはインターネットゲートウェイが必要になりますが、Wavelengthの場合はCarrier Gatewayを用いて、KDDIのキャリア網と通信をします。
紐づけて、「キャリアゲートウェイを作成」を押下すると、キャリアゲートウェイができます。
次にこの作成したキャリアゲートウェイとサブネットを紐づけます。
キャリアゲートウェイを作成すると、自動的に1つルートテーブルが作成されます。
このルートテーブルに、Wavelength Zoneに紐づくサブネットを関連付けます。
EC2インスタンスの作成
Wavelength ZoneにEC2を作成します。
普通のAZでEC2を作る時と、操作は同様です。
ただし、1個注意する必要があり、インスタンスタイプを選択するのですが、
Wavelength Zoneでは使うことのできるインスタンスが以下の4つに制限されています。
t3.medium、t3.xlarge、g4dn.2xlarge、r5.2xlarge
セキュリティグループはVPC内部に限定した通信を許可し、インスタンスを作成します。
ここで問題が、、、
Wavelength Zoneにインスタンスを作成したが、いつまで経っても状態が保留中のままで、利用可能な状態になりませんでした。
Wavelength zoneではなく通常の東京AZにインスタンスを作成してみると、問題なく実行中になりました。。
原因が特定できず(リソース不足?セキュリティグループの設定?)、現時点で解決出来なかったためハンズオンはここまでとし、以下では僕がやりたかったことを紹介します。
やりたかったこと
踏み台サーバー経由でのWavelength zoneへのアクセス
インターネットからだと直接Wavelength Zoneにアクセスできないため、踏み台サーバー経由でアクセスすることになります。
(Elastic IPをWavelength内のEC2に付与すると、KDDI網から直接アクセスできるようになる)
そのため、自分の端末-踏み台サーバー(東京AZ内のEC2)-Wavelength Zone内のEC2
という経路で通信ができるか確認したかったです。
通信速度の比較
端末(galaxy note ultra)-サーバー(wavelength zone内サーバー,通常リージョンのサーバー)
背景赤色、水色部分(networkがmili,sub6)が5G
その中でもlocationにWLがついているもの(背景赤色)がWavelength Zone内のものです
Wavelengthの方が、1.3倍ほど通信速度が速かったです。
終わりに
最後まで自身のハンズオンでできなかったのは不完全燃焼でありました。(後学のために調査は引き続き続けます)
ただ、実際に触ってみて通常のAWSの操作感でMECサービスを利用する感覚は学ぶことができ、すぐさま利用できる点や手軽さがメリットであると感じました。