こんにちはSCSK 木澤です。
9/21~23にかけて米国シアトルで開催されたAWS Ambassador Global Summit 2022に参加してきました。
折角米国に行ったこともあり、AWS Local Zonesを体験してきましたのでご報告します。
AWS Ambassador Global Summit 2022について
最初にカンファレンス自体についても簡単にご報告したいと思います。
AWS Ambassodor Global Summitは、AWSパートナー企業からグローバルで選出されるAWS Partner Ambassadorが一挙に集う年次のイベントになります。
2019年から開催されているとのことですが、2019は日本からの参加は無く、2020年以降はコロナ禍においてオンライン開催となっておりましたので、今年のシアトルでの開催は日本からの参加も含めて会場で参加できる初めての機会となりました。
今年は全世界では90名程の参加でしたが、日本からはAWS Partner Ambassador認定36名中15名、SCSKからは広野と私の2名で参加しました。
詳細な内容はお伝えできませんが、自由闊達なディスカッションが行われており有意義な情報が聞けました。
ただ、私の英語力では話題に付いていくのが難しいものも多く、英語力の無さを痛感させられました。
ディスカッションに参加できるように英語力も鍛えねば…
日本からはNRIネットコムの上野さんと、ビッグツリーテクノロジー&コンサルティングの熊谷さんがLTに登壇され、日本のAWSエンジニアの状況について発表いただきました。
お二人のブログ記事で素敵なことを書かれているのでリンク掲載させて頂きます。
日本はアンバサダーが1人あたり取得しているAWS資格数が世界一ということもあり、日本のAWSエンジニアは何故こんなにもAWSに関する学習や資格取得に熱心なのかという点での発表でした。
日本の取り組みは世界でも注目されておりますが、逆に日本語でのAWS関連情報が充実していること(※)から、日本から海外への情報発信が少なく「謎のAWS資格大国ニッポン」になっているのかなーという印象です。その意味でも海外への情報発信を強化することが今後は大事なのかもしれませんね。
※海外のAmbassadorさんから、日本語のAWS関連ブログ記事は多いので、日本語から翻訳して読んでいるよ!なんて話も聞きました。
最後に、今回日本から同行した15名の中では色々な交流ができ、良い関係ができたと思っています。
皆様ありがとうございました。今後ともよろしくお願いします。
米国に行かないと体験できないAWSサービス
米国に行かないと体験できないAWSサービスって?
さて本題に入ります。
折角久しぶりに米国に訪問することもあり、米国に行かないと体験できないAWSサービスを触ってみたいなと思いました。
パッと思いついたのが以下の2つ
- AWS Local Zones
- AWS Private 5G
AWS Private5Gは米国内にて登録制で自由にLocal 5Gを利用できるCBRS(Citizens Broadband Radio Service)に依存しており、実際に提供されている場所に行かないと体験はできず困難です。
そのため、AWS Local Zonesを使ってみようとなりました。
AWS Local Zonesの概要
AWS Local Zonesはネットワークレイテンシーを短縮するため、よりエンドユーザーに近い場所でコンピューティングリソースを実行できるサービスです。
詳細は以下のブログに記載がありますが、各Local Zonesに紐付くリージョンのVPCを延伸する形でLocal Zonesにサブネットを作成し、その中にEC2インスタンスやALBなどを配置することができます。
現在の対応エリアは以下ページに記載があります。
2022年9月段階で展開済なのは米国内16拠点ですが、ヨーロッパや南米・東南アジア方面にも展開がアナウンスされています。
なおその地域によってAZ数に差異があり、今回訪問したシアトルのAZ数は1となります。
AWS Local Zonesの利用開始・設定方法
さて、実際にシアトルLocal Zoneを使って、本当にレイテンシーが短いのか確認してみたいと思います。
今回は単純な構成として以下のような構成を組んでみます。
AWS Local Zonesの有効化
AWS Local Zonesはオプトインのサービスとなりますので、意図的に有効化する必要があります。
EC2のマネジメントコンソール(追加のゾーンを有効にする)から設定できますが、Local zones紹介ページから辿る方がわかりやすいかもしれません。
ここからシアトルLocal Zoneを開始します。
シアトルLocal Zone(us-west-2-sea-1)を有効化します。
確認ダイアログが表示されますので、指示の通り入力します。
サブネットを作成する
さて、有効化されたシアトルLocal Zoneにサブネットを作成します。(デフォルトVPCの利用でも問題ありません)
なおLocal ZoneはIPv6には対応しておらず、デュアルスタックのサブネットは作成不可でした。
Local Zoneが有効化されていますので、AZとしてシアトルLocal Zoneが見えます。
AZとしてLocal Zoneを指定してサブネットを追加します。
EC2を起動する
作成したサブネットにEC2インスタンスを起動します。
なお、サービス紹介ページには、以下の記載がありますが
例えばT3インスタンスであれば何でも利用可能という訳ではなく、正式にはEC2マネジメントコンソールの左側にある「インスタンスタイプ」にて確認します。2022/9現在、シアトルLocal Zoneでは以下4つのインスタンスタイプに対応しています。
(なお検証当日はt3.mediumがInsufficient Instance Capacityで起動できず、t3.xlargeで確認しました)
今回は検証のため、パブリックサブネットにパブリックIPの自動割り当てを有効化したインスタンスを起動しました。
起動後セキュリティグループでPINGを通すように設定します。
レイテンシーの確認結果
さて、本当にLocal Zoneは低遅延なのか、確認します。
今回は宿泊先のホテルのWi-Fiに繋いだPCから、シアトルLocal Zonesと 親リージョンであるOregonリージョン(us-west-2)へのPING(100回)を実施しTTLの確認を行いました。
結果
結果は以下の通りとなりました(全て単位はmsec)
最小 | 平均 | 最大 | |
---|---|---|---|
シアトルLocal Zone | 3.526 | 6.313 | 13.962 |
オレゴン | 12.419 | 15.013 | 22.133 |
思ったよりもハッキリ低遅延が確認できました。すごい。
シアトルが所属するワシントン州はオレゴン州に隣接しており、州都としては概ね300km程度しか離れていません。それほど明確な差は出ないのではと予想しておりましたが、ハッキリ差がありました。
但し、あくまでこれはクライアント側回線の構成・仕様が恵まれた場合の結果であることに留意が必要です。
Wi-Fiが混雑していたと思われるAmbassador Summitイベント会場や、モバイル回線ではここまでの差は確認できませんでした。
参考:リージョンーLocal Zone間のレイテンシー
リージョンーLocal Zone間のTTLも確認しました。
最小 | 平均 | 最大 | |
---|---|---|---|
シアトル-オレゴン(VPC内) | 7.325 | 7.456 | 13.024 |
こちらも非常に安定していますね。
クライアントの回線に依存はするものの、Local Zoneによる低遅延の効果はあると考えて良いものと思います。
興味深い点
ここで、ネットワークに詳しい方であれば興味深いというか、若干気味が悪い感じに思われたと思います。
そう、Internet GatewayはVPC内で共通であり、OregonとシアトルLocal Zoneで同じ設定を利用しているんです。
つまり、Internet Gatewayはリージョン内で特定の物理的な場所と紐付くわけでは無く、各AZやLocal Zoneに応じて柔軟に選択されトラフィックルーティングされているということになります。
いままで特定リージョン内の設定しか考慮していなかったためここまで考えが及ぶことはありませんでしたが、Local Zoneを交えて検討すると興味深いですね。
日本ではどうなのか
日本に帰国後、私の自宅(都内某所)より各環境への遅延を測定した結果が以下の通りです。(全て単位はmsec)
最小 | 平均 | 最大 | |
---|---|---|---|
シアトルLocal Zone | 138.603 | 145.777 | 157.111 |
オレゴン | 134.505 | 139.565 | 147.708 |
東京リージョン | 9.848 | 15.657 | 25.985 |
大阪リージョン | 13.618 | 18.134 | 37.414 |
予想通りシアトルとオレゴンの差は無くなり、ほぼ同様となりました。
また、私が利用しているプロバイダの関係からか、東京リージョンと大阪リージョンの大きな差は有りませんでした。
日本では東京-大阪リージョンの距離が500km弱と、比較的近くに2リージョンが存在するため、Local Zonesの展開の可能性は低いものと考えます。但しLocal Zoneにおける低遅延を享受したいユースケースが現われれば可能性はあるかもしれませんね。
まとめ
AWS Local Zonesについて、当初はエッジコンピューティングの文脈でエンドユーザーへのレイテンシーを短縮するユースケースで説明されておりましたが、現在ではニュアンスが少々変わっており、AWSリージョンが未展開の国/地域でのAWS利用を促進する目的も含まれてきているようです。
そうした目的で今後多数のゾーンが展開予定となっているように感じます。
日本国内中心の利用において現時点でのメリットはほぼありませんが、今後ワールドワイドをターゲットとするシステムにおいてはメリットを見出させる可能性もあり、要チェックであると感じます。
今後もウォッチしていきたいと思います。