Outposts/Wavelength/Local Zonesを解説、「AWSが越えられなかった壁」を乗り越える

Outpostsなど“AWS低遅延3兄弟”を知る！ KDDIコミュニティが勉強会

　2020年1月8日、KDDIグループ内のテックコミュニティであるTech-in AWS支部が「Tech-in AWS番外編 ～Outposts/Wavelength/Local Zones勉強会」を開催した。

ふだんは社内／グループ内限定で開催している「Tech-in AWS勉強会」だが、今回初めて社外公開のかたちで開催した

　同勉強会の中で、KDDI プラットフォーム開発本部の大橋衛さんは「AWS Outposts/Wavelength/Local Zonesの基本と概要」と題した解説を行った。先月の「AWS re:Invent 2019」でも注目を集めたこの3サービスについて、AWSの狙いやそれぞれの位置付け、ユーザー視点に基づく技術解説、想定されるユースケース、利用料金などについて説明したほか、会場参加者からの具体的な質問にも答えた。

KDDI プラットフォーム開発本部の大橋衛さん。社内のパブリッククラウド活用推進を図る戦略策定を担当しており「AWSの社内“勝手”エヴァンジェリスト」を名乗る

「AWSが越えられなかった壁」を乗り越えるための“低遅延3兄弟”

　re:Invent 2019では、前年に発表されていたOutpostsの一般提供開始と、Local Zones、Wavelengthの新規発表が行われた。大橋さんは、一昨年のOutposts発表時に大きな衝撃を受け、今回のre:Inventでも「現地で興奮しながら見てきました」と語る。

　Outposts/Wavelength/Local Zonesの3サービスについて、大橋さんは「これまでAWSが越えられなかった最大の課題、『ネットワーク遅延の壁』を越えるために作られた最終兵器」だと説明する。提供形態や適用ようとは異なるものの、いずれもネットワーク遅延という課題を解消するために設計されたものであることから、大橋さんは3つのサービスをまとめて“低遅延3兄弟”と呼ぶ。

　re:Invent基調講演において、AWS CEOのアンディ・ジャシー氏は、AWSでは今後もグローバルにリージョンを増やしていく方針だが、それだけではレイテンシ（遅延）の課題を解消するのは難しいと述べた。通信のレイテンシは物理的な距離によって必ず生じるため、従来のリージョン／インフラ構成で、極めて低いレイテンシが要求されるサービス／ワークロードに対応するのは困難だ。

AWS re:Invent 2019の基調講演で、AWS CEOのアンディ・ジャシー氏はOutposts/Wavelength/Local Zonesを大きく取り上げ紹介した

　そこで、ユーザーとの物理的距離がより近い場所にAWSのサービスを展開可能にし、レイテンシの課題を解消しようというのが“低遅延3兄弟”である。AWSでは、WavelengthやLocal Zonesについて「1桁ミリ秒（10ミリ秒未満）」のレイテンシを実現すべく設計していくと発表している。

Outposts：オンプレミス版のAWS、「低遅延」に限らないユースケースも

　AWSが発表した“低遅延3兄弟”について、大橋さんはまずOutpostsから説明を始めた。

　AWS Outpostsは、端的に言えば“オンプレミス版のAWS”だ。AWSがサービス提供で使っているものとほぼ同じハードウェアをレンタルし、ユーザーのデータセンター（オンプレミス環境）内に設置できる。ハードウェアの設置やアップグレードといった維持管理はすべてAWSが行うフルマネージドサービスであり、既存のAWSリージョン（親リージョン）を延伸したかたちで提供される。

想定されるOutpostsのユースケース。低遅延だけでなく、法規制などでデータやワークロードをクラウドに上げられない場合の利用も考えられるとした

　Outpostsは幅24インチの42Uラックで設置されるが、注意点としては「奥行きが48インチと長いこと」だと大橋さんは語る。一般的なラックよりも30センチメートル程度長く、既存のラック列にそのまま並べると冷却用アイルをふさぐなどの可能性もあるため、設置場所に注意が必要だという。またネットワーク接続が1Gbps以上、供給電力もテスト環境で最小5kVA、商用環境として使う場合は10kVA～15kVAが必要となるなど、さまざまな導入要件がある。

Outpostsのハードウェア。設置やメンテナンスはすべてAWSエンジニアが行い、ふだんはフロントドアがロックされているため、ユーザーが内部を触ることは一切できない

　オンプレミス設置されたOutpostsは、どこか1つのAWSリージョン（親リージョン）配下にひもづけられ、コントロールプレーンは親リージョン側に配置される。親リージョンのコントロールプレーンから、OutpostsのAPIを叩いて制御するかたちだ。したがって、AWSリージョンとネットワーク接続できない環境下にOutpostsを設置することはできない。ただし、稼働中にネットワーク障害などでコントロールプレーンとの通信を失っても、Outposts上のサービスは継続して稼働するしくみを備える。

　論理的に見てみると、Outposts環境は親リージョン配下にあるAZのひとつ（自社専用のAZ）であり、ユーザーはマネジメントコンソールからこのAZを選択して利用するかたちとなる。大橋さんがAWSに確認したところ、Outpostsを複数拠点に設置してマルチAZ構成を組むことも可能だという。

論理的なOutpostsの位置付け。日本国内ならば東京リージョン配下にある“自社専用のAZ”として見える

　現在のところOutposts環境で利用可能なAWSサービスは、EC2（M5/M5d、C5/C5d、R5/R5d、G4dn、I3enの各インスタンス）やEBS、RDS for PostgreSQL/MySQL（プレビューリリース）、ECS、EKS、EMR、VPC。さらにS3 for Outpostsも今年中にはリリースされる予定。

　大橋さんは、S3がリリース予定として発表されたのは「おそらくローカルにデータを蓄積したいという顧客ニーズが高かったため」だと推測する。なお、通常のS3サービスではデータを最低3つのAZにコピーして可用性を高めているが、S3でOutpostsローカルストレージへの保存を選択する場合は単一AZでのデータ保存になる見込みであり、その点は意識して利用する必要があると説明する。

　Outpostsのネットワークは、物理的にはオンプレミスのネットワーク機器と2系統以上で接続される。この経路上で、オンプレミスにあるシステムなどと接続するための「ローカルゲートウェイ（LGW）」と、前述したAWS側のコントロールプレーンやクラウドリソースと接続するための「サービスリンク」という2系統の論理接続（タグVLAN）が用意される。このサービスリンクをVPNや専用線経由でAWSに接続するかたちだ。なお、AWS側のVPCをOutpostsまでシームレスに拡張できるので、ユーザーはローカル接続経由でOutposts／AWS上のリソースを使うことができる。

物理ネットワークは2系統以上で冗長化。論理的にはVLANで隔離されたローカル接続、親リージョンとの接続（サービスリンク）が存在する

　サービス料金については、最小構成／全額前払い（契約期間3年間）の場合で「約29万ドル（3000万円強）」と公式サイトで公表されている。「商用で使う構成になると、やはりふつうに7000万円、1億円とかかる」（大橋さん）ため、将来的にはOutpostsを自社導入してそのリソースを分割／再販するようなリセラー事業者も出てくるのではないかと予想する。

　なおデータ転送料金は、Outposts自身のインバウンド／アウトバウンドトラフィックとも無料だ。ただし、AWS側のサービスでは従来どおり課金される。たとえばAWS上のS3からOutpostsにデータを転送する場合、S3のアウトバウンド料金のみが課金される。

　なお、OutpostsのSLAに対する参加者からの質問に対して、大橋さんは「Outpostsのサービスレベルは設置されるデータセンターのネットワーク環境などに依存するため、サービス全体としてのSLAはおそらく設定されないと思います」と答えている。