re:Invent 2024: AWSのOutpostsとLocal Zonesで実現する低レイテンシーアプリケーション
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Delivering low-latency applications at the edge (HYB307)
この動画では、AWSのハイブリッドクラウドサービスにおける低レイテンシーアプリケーションの実現方法について、AWS OutpostsとLocal Zonesの2つのソリューションを中心に解説しています。AWS OutpostsはEC2などのAWSサービスをオンプレミス環境に拡張し、42Uラックや1U/2Uサーバーのフォームファクターで75カ国以上に展開されています。一方、Local Zonesは都市圏にAWSインフラを展開し、Los Angeles、Lagos、Perthなど世界各地で一桁ミリ秒台の低レイテンシーを実現しています。Epic GamesやMindBodyなどの事例を通じて、マルチプレイヤーゲームやハイブリッド環境での活用方法が紹介され、両サービスの使い分けについても具体的に説明されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWS ハイブリッドクラウドサービスの紹介と本セッションの概要
みなさん、こんにちは。AWS のハイブリッドクラウドサービスの Senior Manager of Product Management を務めております Erik Durand です。私は主に AWS Outposts の担当をしています。本日は、エッジでの低レイテンシーアプリケーションの実現についてお話しできることを大変嬉しく思います。私は AWS のハイブリッドサービスの立ち上げ当初から携わっており、2019年に Outposts や Local Zones がローンチされて以来の歩みを見てきました。これまでに提供してきた数々の機能やイノベーション、そしてグローバルな展開の様子を間近で見てきました。本日は Local Zones を担当する Principal Product Manager の Pranav Chachra と一緒にお話しさせていただきます。
本日のアジェンダですが、まず低レイテンシーのユースケースについてお話しし、その後 Outposts と Local Zones について詳しく掘り下げていきます。そして、お客様がこれら2つの異なるハイブリッドエッジサービスを使って、どのように低レイテンシーのニーズに対応しているかについてお話しします。最後に、ここでは Q&A の時間は設けていませんが、セッション後に外でお会いできますので、ご質問のある方はそちらでお願いいたします。
ハイブリッドクラウドの活用事例と低レイテンシーワークロードの重要性
AWS のハイブリッドソリューションは、様々な業界で広く採用されています。多くの業種のお客様が、さまざまなユースケースで AWS ハイブリッドサービスを活用しています。例えば、スライドの右側には、エンタープライズワークロードの移行とモダナイゼーションを行うお客様を示しています。これには、バックオフィスアプリケーションの Software as a Service への移行なども含まれます。このような移行では、移行規模自体の課題や、オンプレミスのインフラストラクチャやデータとの相互依存関係、その他移行を遅らせる要因に対処する必要があるため、ハイブリッドサービスが有用となります。
スライドの左側には、本日のメインテーマである低レイテンシーワークロードを示しています。リアルタイムの医療画像処理、コンテンツ制作、メディアストリーミングなど、エンドユーザーへの迅速なレスポンスが重要な要件となるものです。中央には、データのローカリティとしてまとめていますが、これは特定の場所にデータを保持する必要がある場合にハイブリッドサービスを利用するケースです。規制要件やセキュリティ上の理由、あるいはローカルでのデータ処理が必要な場合などが該当します。
ハイブリッドサービスに関して、お客様から一貫して求められているのは、AWS リージョンで作業する時と同じ体験をエッジでも得られることです。これには、一貫性のある API セットとサービスの提供が含まれます。クラウドでもエッジでもアプリケーションを構築する際に同じ自動化ツールを使用でき、アプリケーションの展開場所やデータの保存場所に関係なく、統一されたセキュリティポリシーのために同じセキュリティコントロールを使用でき、エッジでもリージョンでも一貫した運用体験を得られることが重要です。AWS のハイブリッドエッジサービスにより、お客様は必要な場所でアプリケーションを提供することに集中できるため、イノベーションを加速することができます。また、一貫したツールとスキルセットでグローバルな展開を管理し、アプリケーションがどこに展開されていても、クラウドセキュリティの態勢を採用することができます。
先ほど申し上げたように、ハイブリッドクラウドサービスは様々な業界で活用されており、その主な要因の1つが低レイテンシーのユースケースです。エンドユーザーにリアルタイムアクセスを提供する必要性が高まっており、アプリケーションはエンドカスタマーに対して応答性の高い体験を確保するため、遅延を最小限に抑える必要があります。場合によっては、一桁ミリ秒やサブミリ秒のレイテンシーが求められるシステムもあります。例えば、数十ミリ秒単位のレイテンシーが必要なマルチプレイヤーゲームや、サブミリ秒レベルのレイテンシーで動作する必要のある金融取引所やコアトレーディングシステムなどが挙げられます。
低レイテンシーが求められる具体的なユースケース
リアルタイムのマルチプレイヤーゲームでは、RiotやEpic、Supercellといった企業が、アプリケーションをゲーマーにより近づけるため、世界中にゲームサーバーを展開しています。ゲーマーにとって、ラグはゲーム体験を損ない、リアルタイム感を失わせてしまいます。このシナリオでの理想的なレイテンシーは20〜40ミリ秒の範囲です。
光速の制約があるため、これを実現する唯一の方法は、インフラをゲーマーの近くに配置することです。ゲーム会社は、顧客にリアルタイムでインタラクティブなゲームセッションを提供するため、世界中の複数の場所にレイテンシーに敏感なゲームサーバーを展開しています。
メディア・エンターテインメント業界では、Netflixのような企業が、Los Angelesなど、タレントが所在する特定の場所に高価なアーティストワークステーションを設置し、ビデオ編集やライブプロダクションを行っています。主要なレイテンシー要件は、これらのリモートワークステーションでコンテンツを管理・操作する際に、ジッターのない体験を提供することです。このようなユースケースでは、オフィスやアニメーション制作拠点からアーティストワークステーションまでのレイテンシーを5ミリ秒未満に抑える必要があります。
金融サービス業界では、NASDAQのような企業がNew York Cityなどの主要都市で金融取引所を運営しています。これは超低レイテンシーのユースケースで、マーケットデータや取引システムのリアルタイムデータの取り込みと配信に、サブミリ秒レベルのレイテンシーが必要とされます。
ヘルスケアおよびライフサイエンス分野では、低レイテンシーのコンピューティングが必要とされています。ヘルスケアのお客様は、放射線科の診療、医療システム、臨床研究をサポートする管理ソフトウェアに依存しています。医用画像のユースケースでは、放射線科医が患者の診断のために高品質な画像に迅速かつ低レイテンシーでアクセスする必要があります。低レイテンシーによって、放射線科医はシステムのパフォーマンスを気にすることなく、患者のアウトカム改善に集中できるのです。
次に見ていく低レイテンシーのユースケースは、エンタープライズ移行です。一見すると低レイテンシーのユースケースには見えないかもしれませんが、私たちのハイブリッドクラウドサービスで見てきたのは、多くのお客様が既存のオンプレミスデータセンターに、メインフレーム、レガシーデータウェアハウス、既存のストレージ上の大量のデータセットなど、相互に依存するシステムを持っているということです。お客様は新しいアプリケーションをリージョン内に完全にプロビジョニングすることができないため、リージョンをそれらのデータソースに近づけ、レガシーデータセットにローカルで接続し、時間をかけて移行を行えるハイブリッド環境が必要となります。
AWS Outpostsの概要と提供形態
私たちは、リージョンから分散ロケーションまでをカバーする完全なクラウドコンティニュアムのサービスを提供しています。リージョンから外に向かって、主要な大都市圏や大規模な産業センターにLocal Zonesを展開しており、そのフットプリントを継続的に拡大しています。また、モバイルアプリケーションの処理を改善するために、5GコアネットワークロケーションにAWSのコンピューティングとサービスをもたらすWavelength Zonesも提供しています。オンプレミスソリューションとしては、リージョンとAWSインフラストラクチャをお客様のコロケーション施設や施設内に拡張するAWS Outpostsがあります。さらに、特定のお客様向けに、お客様が指定した場所に展開される完全管理型環境であるDedicated Local Zonesも提供しています。
AWS管理のオファリングとサードパーティのコモディティハードウェア上で実行できるソリューションとして、Amazon ECS AnywhereやAmazon EKS Anywhereを提供しています。これらのソリューションにより、どのようなハードウェア上のコンテナ環境もAWSと統合することができます。さらにエッジでは、接続性が限られているか全くない遠隔地や過酷な環境にクラウドコンピューティング機能を拡張するAWS Snowballのようなソリューションを提供しています。
ここで、AWS OutpostsによるオンプレミスへのAWSサービス拡張について具体的に見ていきましょう。先ほど述べたように、OutpostsはAmazon EC2や厳選されたサービス群を含むAWSインフラストラクチャを、お客様のオンプレミス環境に直接拡張します。この環境は、データセンター、コロケーション施設、ITクローゼット、バックオフィス、さらには工場のワークフローにも設置可能です。
それでは、これを実現する様々なフォームファクターについてお話しします。
これが私たちが「Outpostsファミリー」と呼んでいるものです。Outpostsには2つのハードウェアアーキテクチャがあります。1つはデータセンターでよく見かける標準的な42U フルラックで、もう1つは1Uと2Uの2種類のサーバーフォームファクターです。42Uラックは、AWSが自社のリージョンのデータセンターで使用しているものと同じハードウェア、同じラックです。このラックはAWSが完全に管理しています。このラックは、オンプレミスで導入できる最小単位のリージョンハードウェアだとお考えください。リージョンで行っていることと同じで、このラックを導入されるお客様の責任は、電源、スペース、ネットワーク接続を用意することだけです。残りは私たちが担当します。
1Uと2Uのサーバーフォームファクターは、より小規模で柔軟な導入オプションを提供します。これらのサーバーフォームファクターは、必ずしもラックを必要とせず、バックオフィスやITクローゼット、工場の作業現場など、様々な場所に設置できます。これは本当に、42Uラックが設置できない場所でも、EC2の機能を拡張したい場合のためのものです。一貫性のあるAPIセットで運用する機能を拡張したい場合に最適です。1台か2台のサーバーが必要な場合もあれば、3、4台必要な場合もあり、さらには大規模なフリートとして管理する場合もあります。ビジネスクリティカルなアプリケーションを実行する場合は、高可用性のために常に2台での運用をお勧めしています。
ここで、既存のOutpostsのお客様とOutpostsパートナーの皆様に感謝の意を表したいと思います。これらのお客様は、金融サービス、ゲーム、製造業、通信・テレコム分野、そして公共セクターなど、私たちが話してきたすべての業界にまたがっています。これらのお客様は、低レイテンシーなどの用途でオンプレミスでEC2を使用するためにOutpostsを活用しており、これによって、どのような環境に導入する場合でも、真に一貫性があり安全な体験を実現できます。これは開発者とオペレーターの両方に効率性をもたらします。開発プロセスは同じで、必要な場所に導入できます。リージョンでもエッジでも、場所に関係なく運用方法を理解できます。
また、これらのお客様はハードウェアの管理ではなく、アプリケーションの開発に集中できるため、イノベーションを加速することができます。このスライドに含まれているパートナーの中には、お客様のオンプレミスインフラストラクチャの最新化、アプリケーションの最新化を支援し、業界最高レベルのサポートを提供している企業もあります。
AWS Outpostsの技術詳細と運用方法
先ほど申し上げた通り、私たちは2019年にOutpostsをローンチしました。それ以来、世界中でサービスと提供地域の拡大に力を入れてきました。現在、Outpostsは - ラックとサーバーの両方で - 世界75カ国以上の国と地域で利用可能です。これは段階的に実現してきました。サービス開始当初、このリストはそれほど長くありませんでした。当時は、AWSがすでに事業展開していて、よく知られている国や地域にのみOutpostsを出荷・展開することができました。
ここ数年で取り組んできたのは、私が第二段階と考える拡大フェーズで、これは非常に速いペースで進んできました。新しい事業体の設立や出荷デポの設置、そして新しい地域への展開に必要なロジスティクス機能の構築、さらには各種規制要件への対応など、多くの取り組みを行ってきました。現在は第三段階に近づいており、これはより多くの国々へのロングテール展開といえます。この優先順位付けを決めているのは、お客様からのフィードバックです。お客様は常に、どこでOutpostsが必要かを教えてくださいます。私たちはそのデータを基に頻繁に議論を重ね、私自身もチームと協力しながら、継続的な拡大に取り組んでいます。もしOutpostsが利用できない国でニーズがある場合は、担当のAWSアカウントマネージャーにお知らせください。
AWS Outpostsは、簡単に言えば、オンプレミスにEC2を持ち込むものです。もちろん他のサービスも提供していますが、最も基本的な要素として、オンプレミスでEC2を活用できるようにします。これにより、デプロイメントの柔軟性が得られ、クラウドとオンプレミスの両環境で、同じAPIや同じツール、そして同じサービス（少なくともリージョンで使用している特定のサービス群）を使用できる一貫した体験が得られます。これにより開発の一貫性が確保されます。
開発者は同じツールセットとAPIを使用できます。異なる環境だからといって、オンプレミスの管理に別途トレーニングを受ける必要はありません。クラウドで使用しているのと同じスキルセットで対応できます。また、インフラストラクチャ管理という差別化につながらない重労働からも解放されます。これは完全マネージド型のサービスで、私たちがハードウェアを管理し、そのハードウェアの稼働を確実にする責任を負っています。
ハイブリッドサービスでは、いくつかの追加事項を含む同じ責任共有モデルを採用しています。AWS Outpostsでは、お客様は物理的なスペース、電力、ネットワーク接続の提供を担当します。私たちはすべてのハードウェアとインフラストラクチャを管理し、各Outpostsをリージョナルフリートの拡張として管理します。必要に応じて担当者をオンサイトに派遣し、ハードウェアの交換やあらゆる修理を行います。最後に重要な点として、シングルペインでの管理が可能です。OutpostsはAWSコンソールから完全に設定・管理できます。リージョンでサービスをデプロイする際に使用するのと同じコンソールで、ラックやサーバーを問わず、すべてのOutpostsを管理できます。また、AWS CloudTrailやAmazon CloudWatch、その他リージョンで設定するようなネットワークアラーム系のサービスなど、同じツールを使用してこのインフラストラクチャを管理することができます。
これにより、お客様のIT管理の複雑さが軽減され、開発者の生産性が向上し、より迅速な開発サイクルが実現できます。オンプレミスのアプリケーションとインフラストラクチャをクラウドのペースで進めることができるようになります。これはオンプレミスでクラウドファーストの考え方を実現し、インフラ管理ではなく、ビジネスを差別化するアプリケーション開発にリソースを集中させることができます。
ラックについてもう少し詳しくご説明しましょう。これは標準的な42Uラックで、ほとんどのデータセンターに設置可能ですが、かなり大きく重量もあります。設置の際には、適切な電力、スペース、床荷重要件を確認するため、事前に専門チームを派遣します。フル装備のラックは約1700ポンドの重量があります。これらは当社の製造施設でお客様の注文に応じて製造され、改ざん防止機能付きの安全な梱包で出荷されます。出荷後は、お客様の施設で配送・設置を行います。
このラックは冗長性を考慮して設計されており、すべてのコンポーネントが最低2つずつ装備されています。電源、ネットワークスイッチ、ネットワーク接続など、すべて最低2つ用意されています。唯一、必ずしも2つである必要がないのは、お客様が設定する計算用サーバーですが、これも2つにすることを強く推奨します。私たちはお客様と協力して、必要なインスタンスタイプ、実行する計算ワークロード、必要なストレージ容量を決定します。その後、適切な数と適切なサイズのサーバーをラックに配置し、リージョナルフリートの延長として常時監視を行い、稼働時間と信頼性を確保します。
このラックにはトップオブラックスイッチが搭載されており、アップリンク用に1/10/40/100ギグのネットワークファイバーをサポートしています。デュアルネットワークスイッチを備え、電力に関しては、構成によって相当な電力を使用します。5kVA-15kVAの電源を使用し、最大限の信頼性と稼働時間を確保するため、これらの電源を異なる独立した電源に接続することを推奨しています。これは、コロケーション施設やデータセンターの2つの独立した電源供給、または1つの電源供給と1つのバックアップジェネレーターのいずれかになります。これらは導入時に一緒に検討させていただきます。Outpostsからは、お客様の環境へのアップリンク用に2つのネットワーク接続が出ており、これらを異なるネットワークに接続することを推奨しています。ほとんどのコロケーション施設では複数のオプションを提供していますが、避けるべきなのは、これらの接続が道路上のどこかで1本のファイバーに集約され、バックホーで切断されてしまうことで冗長性が無意味になってしまうケースです。前述の通り、計算リソースはカスタマイズ可能で、お客様のニーズに基づいて必要な量を選択できます。オンプレミスで実施するため、キャパシティ管理を行い、お客様のビジネス要件に合わせて計算ニーズ、スペース、電力、その他の要件のバランスを取る必要があります。
予期せぬワークロードの急増やサービスの拡大に備えて、要件に基づいて計画を立て、余分な容量を含めることをお勧めします。
AWS Outpostsの最新機能と顧客事例
Rackアーキテクチャは、実質的にAWSリージョンの拡張機能です。インフラストラクチャをオンプレミスリソースに拡張し、Outpostsのリソースは、ホームリージョンに接続されたVPC内のプライベートサブネットとして表示されます。すべてのOutpostは、他のリソースをそのホームリージョンから管理するのと同じように、管理を行う特定のホームリージョンに紐付けられています。そのリージョンの地域制御プレーンによって管理され、これにより複数のアベイラビリティーゾーンや、同じリージョンに紐付けられた他のLocal Zonesとのシームレスな統合が可能になります。
Outpostsでは、リージョンとは異なる2つの新しい論理的なネットワーク構成要素が導入されました。1つはローカルゲートウェイで、これによってローカルインフラストラクチャへの接続が提供されます。これには、データセンター内の他のインフラ、サードパーティのストレージ、アクセスが必要な他のシステム、またはコロケーション施設からのインターネット接続が含まれます。もう1つの論理的な構成要素はサービスリンクで、これはサイト間VPNのようなものと考えることができます。これは、OutpostとAWSリージョン間でやり取りされるすべての管理トラフィックが通過する経路です。これには、Outpostの初期プロビジョニング、新しいAMIやサービスの追加、そしてOutpost自体の管理とモニタリングのための少量のトラフィックが含まれます。
Amazon EC2についてはたくさん触れてきましたが、Outpostsで利用可能な他のサービスについてもお話ししましょう。リージョンと同じツールとサービスを提供しており、これによってオンプレミスとクラウドの両方でシームレスな開発と運用モデルが可能になります。Outpostsではローカルで約12のサービスが利用可能で、さらにOutpostsはリージョンに接続されているため、必要に応じてリージョン内のサービスも活用できます。
データレジデンシーを考慮してアプリケーションを設計する場合、特にストレージサービスについては、Outpostsにローカルで配置されているサービスを使用するようにする必要があります。規制上の影響を受けるデータは、Outposts以外の場所に保存したくないはずです。低レイテンシーを考慮して設計する場合は、最速のレスポンスタイムを確保するために、エンドカスタマーへの直接的なパスにあるサービスを考慮する必要があります。ただし、データ変換などのために、ユーザーに直接影響を与えないバックエンドのLambda関数を使用する場合は、リージョン内で実行することも可能です。
コアとなるコンピューティングサービスを多数提供しています。Amazon EC2以外にも、Amazon EBS、Outposts上のローカル版Amazon S3、Route 53 Resolver、Amazon ECSやAmazon EKSなどのコンテナサービス、そしてAmazon RDSによるデータベースサービスがあります。また、Amazon EMRやその他の様々なサービスも提供しています。Outpostsでローカルに提供していないサービスについては、多くのAmazon Partner NetworkソリューションやISVが、リージョンでの展開との一貫性を保ちながらOutpost上で実行できるAPI互換のソフトウェアを開発しています。
サーバーについて見ていきましょう。サーバーはラックよりもかなりコンパクトで柔軟性があります。これは数年前に発表した比較的新しいオファリングですが、現在も非常に注目されており、多くの導入実績があります。2Uサーバーは Intel プロセッサーをベースにしており、1UサーバーはGravitonプロセッサーで構築されています。1Uサーバーの発売は、実はAWSデータセンター外でGravitonを利用できるようになった最初の機会でした。
これらのサーバーは、ラックと比べて消費電力が大幅に少なく、必要な電力は1-2kVAで、ほとんどのラックや環境で一般的に利用可能な標準的なAC電源で動作します。10Gbpsのアップリンクを備えており、1Gbpsにも対応しているため、どちらの速度でも運用できます。
ここで構成が異なるのは、単一のサーバーであるため、ローカルゲートウェイを持っていない点です。ラックの場合は複数のサーバーとスイッチがあるため、ローカルゲートウェイを備えています。この場合は、LNI（Local Network Interface）と呼ばれるものだけを使用します。これは、トラフィックが通過するローカルネットワークへのレイヤー2接続です。このケースでは、お客様自身のスイッチに接続し、ネットワークを管理することになります。冗長化されたサーバー間のトラフィックはレイヤー2でローカルネットワークを通過し、また、リージョンへの論理的な接続であるService Linkも利用します。
AWS Outposts サーバーは、Outposts ラックと同じ論理的な構成を使用します。EC2インスタンスは、ラックと同様にホームリージョン内のプライベートサブネットでホストされます。VPCは複数のAvailability Zoneにまたがることができ、高可用性のためにOutpostsサーバーとOutpostsラックを含めることができます。そのため、先ほど述べたように、Outpostsサーバーを導入する際は最低2台必要となります。各サーバーには固有のOutpost IDがあり、アプリケーションを設定して、個々のOutpostsサーバー間でフォールトトレランスを実現できます。製造現場のユースケースでこれらのサーバーを大規模に導入しているお客様もいらっしゃいます。そういったお客様は、AWS CloudFormationテンプレートを使用して構成を標準化し、デプロイメントを迅速化しています。
先ほど説明したように、Local Network Interfaceは、オンプレミスのリソースとOutpostsサーバー間の直接通信のために、お客様のスイッチへのレイヤー2接続を提供します。Service Linkは、この物理リンクを通過して、ラックと同様にリージョンへのサイト間トンネルを作成します。これは、サーバーを最初にデプロイする際のメタデータやプロビジョニングソフトウェアに使用されます。また、このService Link経由でリージョンに接続し、追加のサービスを利用することができます。これらのサーバーは、工場やスマートリテールストアのコンポーネント、製造現場で使用されており、研究所での実験用に使用しているお客様もいます。AWSの社員の中にも、自身の研究所で実験用に使用している人が多くいます。
re:Inventの日曜日に発表された新機能についてお話ししたいと思います。AWS Outpostsでサードパーティのブロックストレージを簡単に利用できるようにする新機能が登場しました。これは今後さらに拡充される機能の第一弾となります。オンプレミスのデータセンターをお持ちのお客様は、すでにオンプレミスストレージに投資されているかと思います。今回のローンチパートナーはNetAppとPure Storageです。OutpostsラックやOutpostsサーバー上のEC2インスタンスに、NetAppアレイやPure Storageアレイで構成されたブロックデータボリュームを接続できるようになりました。これにより、既存のストレージ投資を活用でき、追加の容量を確保できるだけでなく、長年オンプレミスストレージを管理してきたストレージベンダーの優れた機能を活用することができます。シンプロビジョニング、重複排除、スナップショットによる高度なデータ管理機能などが提供されます。今後もストレージパートナーとの連携を深め、オンプレミスでより柔軟な導入オプションを提供できるよう、パートナーシップを拡大していきます。
AWS Local Zonesの概要と展開状況
また、低レイテンシーアプリケーションにとって非常に重要な点として、Outpostは接続型サービスであることが挙げられます。リージョンへのサービスリンクを通じてOutpostを管理しています。
Outpostでインスタンスの変更や設定変更を行う場合は、リージョンへの接続が必要です。最近、AWS OutpostsのAmazon EC2インスタンスに対する静的安定性の第一段階を発表しました。これにより、ネットワーク接続が失われたり、Outpostsラックやサーバーが電源再起動された場合でも、すでに実行中のインスタンスは継続して実行されます。インスタンスが実行中だった場合、自動的に再起動して動作を継続します。この発表により、ビジネスクリティカルなアプリケーションは、ネットワークや電源の損失時に以前よりも高い回復力を得られるようになりました。
現在、エンジニアリングチームによる検証済みのテストに基づき、最大7日間の切断期間をサポートしています。より長期間の切断を経験されているお客様もいらっしゃるため、さらなるテストを継続して実施していく予定です。低レイテンシーが必要で、電源停止や接続損失に関係なくオンプレミスで継続的に動作する必要があるアプリケーションを設計する場合、サードパーティのストレージアレイからのブートボリュームを活用できます。これは常に切断状態での動作を想定して設計されています。EC2インスタンスの静的安定性により、ネットワーク停止時でも永続的なコンピューティングと永続的なストレージを備えたアプリケーションを設計できるようになりました。
ラテンアメリカの主要なeコマースプラットフォームであるMercado Libreは、オンプレミスの運用技術システムに対する厳格な低レイテンシー要件を維持しながら、物流センターの運用を最適化する必要がありました。 物流センターの既存インフラを強化するためにAWS Outpostsラックを導入し、倉庫運営を効率化するための自動化システムを統合しました。物理的なアクセス制御とWiFiアクセスポイント制御をOutposts上でホストするように移行しました。さらに、Outpostsフリートを拡張し、運用効率を高めるため、Outpostsサーバー上でロボット制御サービスのテストも行っています。これにより、物流センターやサービスセンターのクリティカルなワークロードに対して、一桁ミリ秒台のレイテンシーとリアルタイムの応答性向上という目標を達成し、さまざまな拠点で一貫した管理体験を維持することができました。
Vector Limitedはニュージーランドで最大の電力・ガス供給会社であり、国全体の人口の約30%にサービスを提供し、国のGDPの約3分の1を占めています。同社は、ニュージーランドの送電網を管理する重要な国家インフラシステムであるGE Advanced Distribution Management System（GE ADMS）を用いて配電網を管理しています。このシステムをAWS Outpostsに移行し、ネットワークの冗長性を確保するため、デュアル冗長AWS Direct Connectを使用してアーキテクチャを構築しました。これにより、GE ADMSによるゼロタッチのエッジデプロイメントが可能になり、電力関連の問題をほぼリアルタイムで位置特定できるようになったため、停電の分類とメンテナンス時間内での対応がより効果的に行えるようになりました。また、レイテンシーに敏感ではないワークロードにはAWS Regionを使用しているため、同じ運用チームでITとOTの両方を管理できるようになり、全体的な運用効率が向上しました。
最後の事例は、今週初めにre:Inventで発表されたもので、お客様がビジネスクリティカルなシステムを管理するためにOutpostsを採用するペースを示しています。これは、Körber PharmaのPAS-X MESという製造実行システムです。同社は、製薬メーカーである最終顧客が製造環境を管理するために使用するソリューションをAWS Outpostsで検証しました。
Körber Pharmaは、製薬会社向けに2つの異なる構成でAWS Outpostsの検証を行いました。1つ目は、高可用性と回復性を実現しながら、このアプリケーションが持つデータレジデンシーの懸念事項と低レイテンシー要件に対応するマルチラックOutpost構成です。2つ目のアーキテクチャは、冗長化されたOutpostsにPAS-X MESをデプロイするもので、さらに高いレベルの冗長性と回復性を実現するマルチサイトデプロイメントを可能にします。
このマルチラックOutpostデプロイメントでは、 冗長性はKubernetesコントロールプレーンで処理されています。PAS-Xは、マルチラックデプロイメント全体のオーケストレーションと管理を改善するために、ローカルのKubernetesコントロールプレーンインスタンスを活用しています。また、管理型のAmazon RDS on Outpostsを利用することで、より優れたシームレスなデータ処理とデータ可用性を確保しています。フェイルオーバーはKubernetesクラスターを通じて実行され、これらのクラスターはRegionへの依存関係がないため、サービスリンクの停止中でも運用を継続できます。これにより、この重要なMESシステムの最大限のアップタイムが保証されます。
次のアーキテクチャでは、 複数のOutpostsを使用したアクティブ-アクティブ構成が採用されています。これは、2つの異なるサイトにある2つのOutpostsデプロイメント間でデータの一貫性と高可用性を確保するため、RDSの同期レプリケーションを最大限に活用しています。アクティブ-アクティブ構成により、1つのサイトで障害や停止が発生した場合でも、アクティブ-アクティブ方式で他のサイトにフェイルオーバーし、この重要なシステムのアップタイムを確保できます。Outposts上のRDSで行われる同期レプリケーションにより、データベースは常に一貫性が保たれ、最新の状態に保たれます。サイト全体やOutpostが失われたり、そのサイトの電源接続が失われたりしても対応できます。これら2つのアーキテクチャにより、アプリケーションの低レイテンシー要件に対応しながら、信頼性要件を満たす能力を大幅に向上させることができました。
AWS Local Zonesの技術詳細と活用事例
ご清聴ありがとうございます。ここからは、Local Zonesについて、Pranavにバトンを渡したいと思います。皆様、こんにちは。AWSのPrincipal Product Managerを務めるPranavです。私はこの5年間、Local Zonesの開発に携わってきました。LAでのUS Local Zonesの立ち上げを主導し、それ以降、これらのLocal Zonesにどのようなサービスを導入し、どのように体験を向上させるかを検討してきました。このセクションでは、Local Zonesとは何か、どこで利用可能か、どのようなサービスが提供されているのか、そしてエンドユーザーや自社のオンプレミス環境に対して低レイテンシーを実現しているお客様の事例についてお話しします。
Local Zonesの詳細に入る前に、まずその概要を理解しましょう。論理的に考えると、Local Zonesは異なる物理的な地理に存在するという点を除けば、Availability Zonesと非常によく似ていると考えることができます。つまり、AWSはこれらの都市圏にインフラストラクチャを展開しており、これがLocal Zonesとなります。これらのLocal Zonesは、冗長性が確保された安全なバックボーン接続を通じてリージョンに接続されています。これにより、Local Zonesのサービスを利用しながら、リージョンの多くのサービスにもアクセスすることができます。リージョンと同様に、Local Zonesでも従量制の柔軟な料金体系を採用しており、Availability Zonesと同じ運用とセキュリティ体制を提供しています。
通信、医療、製造、ゲームなど、多くの業界のお客様がLocal Zonesを活用して、エンドユーザーや自社のオンプレミス環境への低レイテンシーを実現していることは、当然の結果と言えるでしょう。次のスライドに進む前に、なぜLocal Zonesが必要なのかについて説明させていただきます。この視覚的な例で考えてみましょう。私がLagosメトロエリアに住むゲーマーだとします。ゲーマーとして、マルチプレイヤーゲームセッションにアクセスする必要がありますが、この場合、最寄りのリージョンはCape Townリージョンということになります。
Lagosにいるゲーマーがケープタウンのリージョンにアクセスする場合、レイテンシーは都市間のトラフィックに依存し、数十ミリ秒かかる可能性があり、これは良好なゲームプレイ体験には適していません。お客様からのフィードバックを受けて、私たちはLagosを含む複数の都市圏でLocal Zonesを立ち上げました。これにより、Lagosのエンドユーザーは同じ都市圏内のLocal Zoneにアクセスでき、一桁ミリ秒のレイテンシーでゲームサーバーに接続できるようになりました。これにより、レイテンシーの観点から理想的な体験が提供され、お客様が期待する以上に予測可能で低いレイテンシーが確保されます。この分散型ゲームのユースケースは一例であり、お客様がオンプレミス環境や社内資産へのレイテンシーを削減するためにLocal Zonesを使用するハイブリッドシナリオなど、他のユースケースについても見ていきましょう。
2019年にLos Angelesで最初のLocal Zonesを立ち上げて以来、私たちはグローバルに展開を続けています。米国では16以上のLocal Zonesを追加し、お客様が一桁ミリ秒のレイテンシーでサービスにアクセスできるようにしています。また、Copenhagen、Lagos、Muscat、Auckland、Perthなどで15以上のLocal Zonesを展開し、国際展開も進めています。さらに、Bogota、Hanoi、Athensなど、白色で示された10以上の計画地域も発表しています。私たちの目標は、お客様が世界中のどこでもAWSのインフラストラクチャにアクセスできるようにすることです。
Local Zoneの提供地域についてお話ししましたので、次はこれらのLocal Zoneで利用可能なサービスについて見ていきましょう。Local Zoneの立ち上げにあたり、私たちは低レイテンシーが重要なサービスの提供に焦点を当てました。これには、Amazon EC2、ブロックストレージ用のAmazon EBS、コンテナニーズに対応するAmazon ECSとAmazon EKS、そしてRoute 53、AWS Shield Standard、AWS Direct Connect、Amazon VPCなどのネットワークサービスが含まれます。また、ワークロードを簡単にLocal Zoneに移行できるよう、AWS Application Migration Serviceも含まれています。
より多くの場所にLocal Zoneを展開していく中で、場所によってユースケースが異なることが分かってきました。Amazon FSx、NAT Gateway、Amazon RDS、Amazon GameLift、Amazon EMR、Amazon ElastiCacheなどの特定のサービスは、選択された地域でのみ利用可能となっています。これらのサービスをLocal Zoneに展開する方法は確立されており、お客様からのフィードバックに基づいて、より多くの地域への展開を計画しています。 また、Local Zoneは当社のバックボーン接続を通じて親リージョンに接続されているため、AWS CloudTrail、AWS CloudFormation、Amazon EC2 Auto Scaling、Amazon CloudWatch、Amazon S3など、親リージョンのすべてのサービスにアクセスすることができます。
この2年間のお客様からのフィードバックを受けて、サービス全体にわたって機能を追加してきました。Atlanta、Chicago、Dallas、Houston、Miamiなどの地域では、Gen 6やGen 7を含む最新世代のインスタンスへのアクセスを提供しています。また、GP3やST1などのAmazon EBSボリュームの追加や、IPv6やSPOTインスタンスなどの機能も追加しました。これらの機能が強化されたLocal Zoneは特定の地域で利用可能であり、今後も既存のメトロエリアや新しい地域にこれらの機能を展開していく予定です。
Local Zoneはリージョンの論理的な拡張として機能しており、これは料金体系にも反映されています。Local Zoneの有効化自体に費用はかかりません。有効化後は、Local Zoneで実行されるAmazon EC2インスタンスやサービスの料金は独自に設定されており、各サービスの料金ページで確認することができます。データ転送に関しては、Local ZoneはAvailability Zoneやリージョンと非常によく似た扱いとなっています。
親リージョンのAmazon S3にLocal Zoneからアクセスする場合、データ転送は無料です。オンデマンド料金に加えて、特定のLocal Zone地域ではEnterpriseプランやSPOTインスタンスを利用することができます。
Local Zonesの活用事例をご紹介する前に、実際の仕組みについてお話ししましょう。利用者の観点からすると、Local ZonesはAvailability Zonesと同様に考えることができます。まず、アカウントでLocal Zonesを有効にすることで利用を開始します。有効化すると、Availability Zonesと並んで表示されるようになり、VPCにサブネットを作成してLocal Zoneにリンクすることで、そこにリソースをデプロイできるようになります。
このアーキテクチャを見てみましょう。US West（Oregon）リージョンのVPCがSeattle Local Zoneまで拡張され、サブネットを作成してSeattle Local Zoneにリンクしています。この設定を行うと、ゲートウェイやルートテーブルなどは自動的に設定されます。Local ZonesはインターネットやAWS Direct Connectに関して独自のイングレス/イグレスを持っているため、オンプレミス環境やエンドユーザーから極めて低いレイテンシーでアクセスすることができます。
AWS Direct Connectは興味深いユースケースです。Local Zonesをローンチした際、多くのお客様がLocal Zonesを自社のオンプレミスインフラの拡張として捉えていることに気づきました。お客様は、データセンターやコロケーション施設、アニメーション制作拠点やオフィスなどのオンプレミス環境からAWS Direct Connectを使用して、Direct Connect接続ポイントに接続し、そこからバーチャルゲートウェイを介してLocal Zoneに接続します。MindBodyのようなお客様は1〜2ミリ秒という超低レイテンシーを実現しており、これによってハイブリッドアーキテクチャが可能になります。つまり、アプリケーションの一部をオンプレミスで実行しながら、他のアプリケーションをLocal Zoneに移行することができます。
Local Zonesの利用方法について説明しましたが、ここで低レイテンシーアクセスと高可用性の両立について触れたいと思います。この実現には複数のオプションがあります。リージョン内の2つのAvailability Zone間でアプリケーションを分割するのと同様に、Local ZoneとリージョンのAvailability Zoneの間でアプリケーションを分割することができます。HoustonやDallasのように、近接する複数のLocal Zone間でワークロードを分割しているお客様もいます。同じメトロエリアに2つのLocal Zoneが利用可能な場所もあり、そこで高可用性を実現できます。また、FanDuelのようなお客様は、Local ZoneとAWS Outpostsの間でワークロードを分割することで、低レイテンシーアクセスを確保しながら高可用性を実現しています。
プレゼンテーションの冒頭で、Erikがマルチプレイヤーゲームを含む低レイテンシーのユースケースについて説明しました。Epic Gamesは、エンドユーザーにより近い場所にゲームサーバーをデプロイする必要がありました。DallasにLocal Zonesがローンチされると、Epicはアメリカおよびメキシコなどの南米地域のFortniteプレイヤーに低レイテンシーアクセスを提供するためにこれを活用し始めました。これにより、Epicは理想的なゲームプレイ体験と低レイテンシーアクセスを確保することができました。自社でデータセンターを維持管理する必要がないため、ゲーマーやマルチプレイヤーゲームセッションの需要に応じて柔軟にスケールアップ/ダウンすることが可能になりました。
2つ目の例はMindBodyで、これは先ほど説明したアーキテクチャに関連していますが、MindBodyのような顧客からは、相互に依存関係のあるアプリケーションのポートフォリオをクラウドに移行するのは大変だという声を聞いています。
彼らはLocal Zonesをオンプレミス環境の拡張として利用し、Direct Connectを使ってオンプレミス環境からLocal Zonesに接続することで、ハイブリッドアーキテクチャを実現しました。これがMindBodyのケースです。一部のアプリケーションをオンプレミスに残しながら、他の部分をLocal Zoneに移行し、同じメトロエリア内で超低レイテンシーのアクセスを確保しました。その結果、多くのアプリケーションを改修することなく、一部のアプリケーションをクラウドに移行することができたのです。
Epic GamesとMindBodyの両社は、顧客がLocal Zonesを活用して、エンドユーザーやオンプレミス環境への低レイテンシーアクセスを実現している素晴らしい例です。OutpostsとLocal Zonesの両方について説明しましたので、この2つのオプションをどのように使い分けるべきかについてお話ししたいと思います。基本的には、コンピューティングを実行したい場所と、アプリケーションに求められるレイテンシープロファイルという2つの要因によって決まります。まず、レイテンシー要件を満たす場所により近いRegionが利用可能な場合は、より多くのサービスとスケールにアクセスできるRegionをお勧めします。
Regionではレイテンシー要件を満たせない場所があり、そこでより近くにLocal Zoneが利用可能で、レイテンシーのニーズを満たせる場合は、Local Zonesが最適な選択肢となります。最後に、RegionもLocal Zoneもレイテンシー要件を満たせないシナリオがあります。このような場合、例えば超低レイテンシーが必要な製造業などでは、顧客はOutpostsを利用します。これは、RiotやFanDuelのような顧客が、必要な場所にアプリケーションを配置するためにOutpostsとLocal Zonesの両方を組み合わせて活用している、まさにその通りの例です。
これで本セッションは終了となります。ご参加いただき、ありがとうございました。サイレントセッションのため、ここでQ&Aはできませんが、Ericと私の両方が外でご質問をお受けしますし、オフラインでも喜んでご質問にお答えさせていただきます。最後に、モバイルアプリでセッションのアンケートへのご回答をお忘れなく。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion