re:Invent 2024: AWSがクラウドからエッジまでカバー - Outpostsの進化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - AWS wherever you need it: From the cloud to the edge (HYB201)
この動画では、AWS の Amazon EC2 Networking and Edge 部門の Jan Hofmeyer 氏が、ハイブリッドクラウドとエッジコンピューティングにおける AWS の革新について解説しています。AWS Outposts や AWS Local Zones などのハイブリッドサービスを活用することで、データレジデンシー要件やレイテンシー要件に対応しながら、クラウドと同じ体験をオンプレミス環境で実現できる方法を紹介しています。Merck の Jeff Weis 氏も登壇し、AWS Outposts を活用して VMware ワークロードの移行を実現した事例を共有しています。また、NetApp や Pure Storage との新しい Outposts サードパーティ統合の発表や、AWS Nitro System によるセキュリティ強化、衛星通信によるレジリエンシー向上など、最新の機能強化についても詳しく説明しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWS Hybrid and Edgeサービスの概要と本セッションの目的
おはようございます。ご参加の皆様、ようこそお越しくださいました。私は Jan Hofmeyer で、AWS の Amazon EC2 Networking and Edge 部門のバイスプレジデントを務めております。re:Invent に初めて参加される方々、ようこそ。これが素晴らしい体験の第一歩となることを願っています。本日は、ハイブリッドクラウドとエッジコンピューティングにおける革新についてお話しできることを大変嬉しく思います。アプリケーションがオンプレミスであれ、エッジで実行される場合であれ、AWS をどこでも活用していただけるよう、私たちのイノベーションについてご説明させていただきます。また本日は、Merck の Hosting Solutions エグゼクティブディレクターである Jeff Weis をお迎えできることを光栄に思います。Jeff には、Merck が AWS の経験をオンプレミスに持ち込むことで、どのようにヘルスケアイノベーションを変革しているかについてお話しいただきます。
まず、クラウドからエッジまで広がる私たちのクラウドサービスの全体像と、ハイブリッドおよびエッジサービスが対応できるワークロードやユースケースの広がりについてご説明します。その後、お客様との対話で一貫して浮上してきた具体的なトピックについて掘り下げていきます。これには、AWS リージョンに簡単に移行できない依存関係を持つ VMware の移行を、オンプレミスでの AWS エクスペリエンスがどのように促進できるか、また、データレジデンシー要件のある規制対象のワークロードをどのように実行できるかが含まれます。そして最後に、皆様のサービスをグローバルにサポートできるよう、AWS サービスの最新の地理的拡大についてもお話しします。
AWSクラウドコンティニュアム：エッジからクラウドまでの一貫したサービス提供
AWS クラウドコンティニュアムについて、さっそく詳しく見ていきましょう。多くのアプリケーションは簡単にクラウドに移行できますが、お客様からは、一部のアプリケーションは移行前にリアーキテクトまたはモダナイズする必要があるとお聞きしています。また、多くのお客様は、低レイテンシー、データ処理、データレジデンシーの要件により、オンプレミスに留めておく必要のあるアプリケーションをお持ちです。これらのユースケースに対応するため、AWS サービスをエッジに拡張することを最初に考えた時、お客様から非常に明確な要望がありました。エッジ専用に作られた特別なソリューションではなく、同じ AWS エクスペリエンスが欲しいということでした。同じように信頼性が高く、安全で高性能なインフラストラクチャを求められました。リージョンにある M6 インスタンスと、お客様のデータセンターに置かれる M6 インスタンスのパフォーマンスが同一であることを望まれたのです。
お客様は、同じ運用の一貫性、同じサービス、同じ API、自動化デプロイメントとセキュリティコントロールのための同じツール、そしてクラウドで経験する同じペースのイノベーションを求めていました。これらの要件から逆算して、私たちは AWS Nitro システムのようなクラウドインフラストラクチャのイノベーションを分散環境に持ち込み、完全に管理された真に一貫したクラウドエクスペリエンスを実現した最初のクラウドプロバイダーとなりました。AWS では、様々なタイプの分散ロケーションで一貫したクラウドサービスのコンティニュアムを提供しています。このクラウドコンティニュアムは、リージョンから始まり、AWS Local Zones による主要な都市部や産業の中心地、そして AWS Wavelength Zones による 5G ネットワーク内のロケーションへと広がっています。
エッジやオンプレミスに目を向けると、AWS Outposts はお客様自身のデータセンター、コロケーション施設、エッジサイトに AWS のインフラストラクチャとサービスを拡張します。大規模なデジタル主権要件に対応するため、お客様の拠点内に設置できる AWS Dedicated Local Zone を提供しています。AWS および非 AWS プラットフォーム全体で自社環境との統合を望むお客様向けには、EKS Hybrid ノードと S3 Anywhere があります。最も遠いエッジでは、Snowball によってクラウドへの接続がない遠隔地や過酷な環境にもクラウド機能を拡張でき、Amazon EKS Anywhere では、エアギャップ環境にネイティブコンテナをデプロイできます。類似のソリューションと私たちが真に異なる点は、AWS リージョン、Local Zones、オンプレミス、エッジのすべてのアプリケーションに対して、同じインフラストラクチャ、API、管理コンソール、自動化ガバナンスポリシー、セキュリティコントロールを活用できることです。
このアプローチにより、インフラストラクチャの管理に必要な時間、リソース、運用リスク、メンテナンスのダウンタイムを削減できます。アプリケーションを複数のロケーションにスケールする際も、置き換えやパフォーマンス検証は不要です。また、開発者のワークフローを効率化し、お客様が新しい製品やソリューションをより迅速に提供できるようになります。これらの包括的な機能と環境全体にわたるシームレスな統合は、高く評価されています。最新の2024年 Gartner Magic Quadrantの分散型ハイブリッドインフラストラクチャ部門において、AWSはハイブリッドインフラ管理、エッジコンピューティング、Assured Workloads、AI/MLユースケースを含む4つのユースケースで1位にランクされています。
多様な産業におけるAWS Hybrid and Edgeサービスの活用事例
AWS Hybrid and Edgeサービスは、事実上すべてのオンプレミスおよびエッジワークロード向けに構築されています。現在、私たちは幅広いエッジワークロードをすでにサポートしています。まず、マルチプレイヤーゲーム企業は、最高のパフォーマンスとレイテンシーを実現するため、ユーザーにできるだけ近い場所にアプリケーションをデプロイしスケールするための高度な自動化を開発しています。ゲームはすでにAWSリージョンで稼働しており、さらにAWS Local Zonesを活用してリージョンの近くにいないユーザーに対して1ミリ秒台のレイテンシーを実現しています。ゲーム企業は、ゲーマーが集中している地域でリージョンやLocal Zoneが利用できない場合の解決策として、AWS Outpostも活用できます。Epic Gamesのような企業では、AWSのクラウドコンティニュアムを活用することで、まったく同じゲームサーバー、自動化、モニタリングを使用して、リージョン、Outpost、Local Zonesへのデプロイが可能になっています。
NRIは、日本の金融サービス顧客向けに安全で信頼性の高いクラウドベースの管理サービスを提供しています。データレジデンシー要件によりオンプレミスに置く必要がある重要なシステムに対して、AWS Outpostを使用してクラウドサービスを提供しています。Outpostにより、NRIは従来のオンプレミスインフラと比較して、新規サービスのデプロイ時間を30%削減することができました。また、昨年と一昨年のセッションで取り上げたNASDAQは、AWS上で完全にクラウドネイティブになるための journey を進めており、超低レイテンシーで公平かつ平等なアクセスネットワークをサポートするOutpostラックを使用して、北米の4つの取引所をOutpostに移行しました。これらの市場の中で最大のものは、1日あたり120億のメッセージを処理しています。
グローバルセキュリティリーダーであるPalo Alto Networksは、5大陸のAWS Local Zonesに彼らのPrisma Accessサービスのデプロイを開始しました。AWS Local ZonesにPrisma Accessサービスをデプロイした結果、Palo Alto Networksは顧客のネットワークレイテンシーを最大50%削減することができました。AWS Local Zonesにより、Palo Alto Networksは99.999%の可用性を維持しながら、地理的にサービスを拡大することが可能になりました。通信分野では、今年初め、ドイツのO2 Telefonicaが、ヨーロッパのネットワーク機器プロバイダーであるNokiaとAWSのテクノロジーを使用して、クラウドで完全に構築された新しい5Gクラウドネットワークを備えた5Gクラウドコアを発表しました。O2 Telefonicaが使用するAWSサービスには、Nokiaのコンテナ化されたクラウドネイティブネットワーク機能のオーケストレーションのためのEKSが含まれており、クラウド全体での一貫性を活用して、5Gネットワークのコントロールプレーンをフランクフルトのリージョンにデプロイし、データ集約型のネットワーク機能をネットワーク内のOutpostにデプロイすることができます。これは、大手通信事業者が既存のネットワークと顧客を、AWS上で稼働する新しい5Gクラウドネイティブネットワークに移行する初めてのケースとなります。
もう一つの例は、データセンター向けの高品質なコンピューティング製品、ストレージ製品、およびラックソリューションを提供するクラウドITインフラストラクチャプロバイダーのWiwynn Corporationです。Wiwynnは、レイテンシーに敏感な製造自動化システムと倉庫管理システムをOutpostにデプロイし、完全マネージド型ソリューションとしてのOutpostを活用することで、新しい工場サイトでのこれらのシステムのデプロイ時間を90%削減しました。ITインフラストラクチャの管理に必要な人員を8分の1に削減できた点は、驚くべき改善と言えます。
Outpostによって実現されたこの素晴らしい改善は、AWSのハイブリッドおよびエッジサービスが産業界をどのように変革しているかを示す一例に過ぎません。次に、産業界全体で注目を集めている新しいタイプのエッジワークロード、つまり人工知能と機械学習についてお話ししたいと思います。現在、製造業、公共部門、医療など、さまざまな業界のお客様がAWSのハイブリッドおよびエッジサービスを活用して、MLワークロードのリアルタイム推論を実現しています。例えば、Actonは製造ライン内の視覚検査にOutpostを使用しており、ある政府機関は密輸防止のためのリアルタイム物体検出にOutpostを活用し、また Apollo Hospitalは AI支援による予防医療処置にSnowballを利用しています。
エッジでのGenerative AIワークロードの実現
機械学習により、従来のプログラミングでは実現不可能または非現実的だったアプリケーションの開発が可能になりましたが、Generative AIはこの可能性をさらに大きく広げ、テキスト、画像、動画、音声、さらにはコードなど、新しいコンテンツを生成できるアプリケーションの展開を可能にしました。ほとんどのGenerative AIワークロードはクラウドで実行できますが、デジタル主権、データレジデンシー、ローカルでの処理に必要な低レイテンシーの要件により、オンプレミスまたはエッジに残す必要があるものもあります。AWSのハイブリッドおよびエッジサービスは、Generative AIのユースケースにおける3つの主要なカテゴリーをサポートしています。
1つ目は、データレジデンシー要件の対象となるお客様が、トレーニングのためにデータをクラウドに送信する前に、個人情報やその他の機密情報を削除できるケースです。例えば、ある金融サービス企業とコンプライアンスレポートの生成を自動化するGenerative AIソリューションの開発を進めています。このソリューションでは、レポート生成のためにAWSリージョンの大規模言語モデルにデータを送信する前に、オンプレミスの小規模言語モデルで個人識別情報を匿名化します。2つ目は、既存の小規模言語モデルを活用し、オンプレミスの企業データで最適化およびチューニングを行い、Local ZonesとOutpostのGPU対応インスタンスを使用して、エッジ推論が必要な場所の近くに微調整されたモデルを展開できるケースです。
Local ZonesのAP5インスタンス、またはLocal ZonesとOutpost両方で利用可能なG5/G4DNインスタンスから選択できます。これにより、レイテンシーを最小限に抑え、データレジデンシー要件に準拠しながら、モデルの性能を向上させることができます。最後に、AWSリージョン、オンプレミス、エッジロケーション全体で分散型のRetrieval Augmented Generation（RAG）を実装し、オンプレミスに保持する必要がある機密データを使用してプロンプトの結果の精度を向上させることもできます。
このスライドは、AWS Local ZonesまたはOutpostでGenerative AIモデルを実行するための参照アーキテクチャを示しています。これらのモデルは外部依存関係なく、完全にエッジに展開されています。このアーキテクチャは、チャットボット、要約、テキストやコードの生成、複雑なレポート作成ワークロードなど、さまざまなユースケースをサポートできます。ユーザーは、ALBの背後でAuto Scaling Groupで実行されているアプリケーションサーバーにクエリを送信します。アプリケーションはリクエストを受け取り、Generative AIモデルに配信するためにフォーマットします。特に要約のユースケースでは、ドキュメントはSLMに配信するために小さなセクションに分割されます。
実装方法によって、フォーマットされたリクエストはALBまたはメッセージキューを通じて、Auto Scaling Group内のGPUインスタンス上で動作するSLMに送信されます。私たちのラボでのテストでは、これらのモデルを実行するための最適な環境を提供するLlamaCPPフレームワークで動作する様々なモデルに焦点を当てました。さらに、HybridモードまたはLocalモードのいずれかで展開可能なRAGを実装することで、プロンプトの応答精度を向上させることができます。Hybridモードでは、オンプレミスに機密データを持ちながらもAWSリージョンのデータを活用したい場合、Bedrockエージェントを設定して、プロンプトをリージョンに送信するかLocal ZoneやOutpostに送信するかを判断させることができます。
RAGエージェントが、Local ZoneやOutpostで実行される規制対象データや制限付きデータを使用してユーザープロンプトに対応する必要があると判断した場合、RAGエージェントはLocal ZoneやOutpost特有のアクションのグループを呼び出し、ローカルのナレッジベースから情報を検索して応答を返します。データのローカルレジデンシー要件によってリージョンへのデータ送信が厳しく禁止されている場合は、RAGをローカルに実装するオプションもあります。この場合、プロンプトのトークン化と埋め込み、類似性検索、質問の埋め込み、応答の生成がOutpost上でローカルに行われ、リージョンへの依存関係はありません。
SLMモデルの選択と最適化テクニックについて、より詳しく掘り下げたデモセッションをHybrid 318で行っています。ご興味がある方は、このセッションに参加するか、ブースで専門家に相談することをお勧めします。
オンプレミスでのクラウド機能活用：Merckの事例
様々な業界のユースケースにおける多様なワークロードの処理方法について説明した後は、クラウドのパワーと柔軟性をオンプレミスインフラストラクチャに直接もたらし、インプレースでの移行とモダナイゼーションを加速する方法に焦点を当てましょう。ほとんどのワークロードは簡単にクラウドに移行できますが、いくつかの理由でオンプレミスに残す必要があります。まず、アプリケーションの相互依存性です。一部のワークロードは、オンプレミスのレガシーデータベースや運用システムとの低レイテンシーの相互接続を維持する必要があります。レガシーアプリケーションは、さまざまなアプリケーションコンポーネント間に複雑なレイテンシーに敏感な相互依存関係を持っていることがよくあります。クラウドサービスをオンプレミスに導入することで、レイテンシー要件を満たしながらこれらのレガシーアプリケーションをモダナイズすることができます。
2番目の要因は、契約上または情報セキュリティ上の理由で、データを特定の国や州のオンプレミスに保持する必要があるデータレジデンシーです。そして最後に、加速された移行スケジュールです。一部の組織では、オンプレミス環境からクラウドへの迅速なリフト＆シフトを迫られており、時間をかけてモダナイズと最適化を計画しています。このアグレッシブなタイムラインは、クラウドファースト戦略の採用、ソフトウェアライセンスコストの最適化の必要性、データセンターの撤退または統合に関するビジネス判断、合併後の統合、新しい地域へのビジネス拡大の加速など、いくつかの要因によって推進されることがあります。
この意欲的なスケジュールを達成するために、既存のストレージシステムやデータベースとクラウドサービスを統合し、現在のオンプレミスのネットワーク構成をできる限り活用する必要があるかもしれません。特にVMwareの最近のライセンス変更により、多くのお客様がデータセンター戦略を見直し、クラウドによるアプリケーションの近代化を加速させています。その結果、データレジデンシー要件、契約上の制約、またはアプリケーション間の相互依存性により、すぐにはAWSリージョンに移行できないVMwareワークロード向けのOutpostなどのサービスへの顧客の関心が非常に高まっています。
AWSは顧客の企業ファイアウォールの内側で動作し、クラウド移行を加速する2つの方法を提供します。1つ目は単純な再ホスティングです。VMwareワークロードをOutpost上のEC2インスタンスに簡単にリフト＆シフトし、WindowsまたはLinux上で動作する自己管理型データベースをEC2上で実行できます。Outpostはローカルゲートウェイを通じて、既存のオンプレミスネットワークまたはローカルプロバイダーネットワークに接続されます。2つ目のオプションは再プラットフォーム化です。Amazon ECSとAmazon EKSはOutpost上でネイティブにサポートされています。これにより、VMwareワークロードをコンテナ化し、AWSリージョン、オンプレミス環境、エッジサイトにわたって単一のビルド、テスト、本番パイプラインを標準化でき、開発者の生産性を大幅に向上させることができます。
さらに、時間の経過とともにデータインフラストラクチャを近代化し、Outpost上のAmazon RDSやAmazon EMRなどのマネージドデータベースや分析サービスに移行することもできます。組織のクラウドスキルが成熟するにつれて、クラウドのスケールとメリットを最大限に活用する地域サービスを使用して、アプリケーションのさらなるリファクタリングを検討することができます。
British American Tobacco（BAT）は、クラウドファーストの戦略でビジネスのあらゆるレベルを近代化しています。世界中に47の工場を持つBATは、GMSやIgnitionなどのローカル工場ワークロードを最小限のレイテンシー要件で実現するために、エッジでのAWSサービスを必要としています。BATは24時間365日の運用をサポートするための低レイテンシーと回復力をスケールで提供するためにAWS Outpostを選択しました。このアーキテクチャ図は、Outpostの使用前後で重要な製造アプリケーションがどのようにデプロイされているかを示しています。BATは、AWSリージョンで見られるのと同じコンピューティング、ネットワーキング、データベースの構成を活用して、これらのアプリケーションを直接Outpostにリフト＆シフトできることがわかります。
Outpostは以下のような利点があります。管理を一元化することでコストを45%削減し、リソースの監視と制御が容易になります。オンプレミスで実行または維持する必要があるワークロードを含めて、クラウドファースト戦略を拡張できます。AWSのインフラストラクチャをサービスとして活用することで、スケーリングを簡素化できます。スケールアップする際は、追加のOutpostラックを注文してキャパシティプールに追加し、ビジネスを拡大するだけです。また、マルチベンダーのオンプレミスインフラストラクチャとソフトウェア環境の管理および運用の複雑さを解消できます。
AWS Outpostsの新機能と規制対象ワークロードへの対応
彼らは、ミッションクリティカルなワークロードをサポートするために冗長性を備えた耐障害性のあるインフラストラクチャを、AWSリージョンをクラウドベースのソリューションとして活用して展開することができます。また、クラウドベースのバックアップと災害復旧にAWSリージョンを活用したり、ワークロードをAWSにリフト＆シフトで移行したりすることができます。ここで、ある大手南米銀行が、顧客向けの銀行サービス提供方法を変革した事例を見てみましょう。この銀行は2020年以降、AWS完全移行戦略を採用し、デジタルチャネルを含むワークロードの70%をAWSに移行しました。
現在、この銀行はAWS Blue Ageを使用してメインフレームのモダナイゼーションを進めており、今後3〜5年でIBM Series 1メインフレームをAWSへ移行することを目指しています。NoSQLデータベースを使用するOpenShift上のサテライトアプリケーションを含め、メインフレームシステムと10ミリ秒未満のレイテンシーで相互接続する必要のあるアプリケーションが多数存在するため、AWSリージョンへの直接移行は困難でした。移行のリスクを軽減し加速するため、IBM WebSphere MQとWebSphere Application Server上のアプリケーションサーバー層を使用しています。銀行は、プライマリサイトとDRサイトの両方に配置されたEKS on Outpost racksに、VMwareとOpenShiftクラスターからメインフレームシステム周辺のアプリケーションを移行しています。
1500個のコンテナと50個のVM（30個のIBM WebSphereアプリケーションサーバーと20個のメッセージング用IBM MQを含む）をOutpost環境に移行しています。これにより、IBMメインフレームへの一桁ミリ秒のレイテンシー要件を増加させるリスクに対処することなく、これらのアプリケーションを移行することが可能になりました。さらに、CloudWatch、CloudTrail、CloudTower、Amazon Configなどの同じツールをAWS、OpenShift、WebSphere MQ環境全体で標準化することで、運用の優位性を向上させることができました。最後に、AWS上で一貫性のある自動化、ガバナンス、モニタリング、監査モデルを実装することができました。
ここまで、製造業と銀行業のお客様がOutpostを使用してどのように移行とモダナイゼーションを実現したかの事例を見てきました。次は、ヘルスケアとライフサイエンス分野の事例を見てみましょう。ここで、MerckがOutpostでどのようにイノベーションを実現したかについて、Jeffにお話しいただきたいと思います。Janさん、ありがとうございます。本日プレゼンテーションの機会をいただき、感謝いたします。私はMerck and Co Incに所属しています。当社は世界中の人々の命を救い、生活を改善するために最先端の科学を活用しているグローバルヘルスケア企業です。約130年の歴史があり、アメリカとカナダではMerck and Co Inc、その他の国ではMSDとして知られています。
このプレゼンテーションで私の話に関心を持っていただけるよう、簡単に経歴をご紹介させていただきます。私は数年間、AWSのカスタマーアドバイザリーボードのメンバーを務めており、約10年間、AWSグローバルリージョンを担当し、ランディングゾーンの確立、ガバナンスガードレールの設定、そして社内でのクラウドテクノロジーの採用推進に注力してきました。約2年前、私の責任範囲が拡大し、オンプレミス環境も担当することになりました。そこで、クラウドでは当たり前だと思っていたこと、気にする必要がなかったこと、例えば使用しているハイパーバイザーの種類、ハードウェアの健全性、ハードウェアの適切なパッチ適用など、すべてが私の責任となり、オンプレミスでクラウドコンピューティングを活用する際の課題となりました。
まず、私たちは自社の戦略の基盤を固めたいと考えました。私たちの優先事項は、顧客や患者のために生命を救う医薬品を創造できるスピードを上げるため、社内での変革の速度を加速することです。私たちが注力する主要な領域は3つあります。1つ目はシンプリシティです - できる限りシンプルな環境を目指しています。重複を避け、一から作り直すことを避け、構築する投資やソリューション、提供する機能が可能な限り再利用できることを確実にしたいと考えています。
次に、Total Cost of Ownershipです。環境を維持するためのコストを最小限に抑えることを目指しています。AWSの有名なバズワードの1つを使えば、「Undifferentiated Heavy Lifting（差別化されない重労働）」を排除したいのです - 環境の維持に費やす1ドルは、私たちの核となるミッションに使えない1ドルということになります。最後は変革です。世界をリードするヘルスケア企業の1つであり続けるためには、変革が必要です。最新のテクノロジーの進歩を取り入れ、私たちの働き方を近代化する必要があります。私たちには非常に優秀なエンジニアチームがいますが、環境の維持管理や、すでに存在するものを再創造することに注力していては、最大限の価値を得ることができず、私たちにとって最も重要な人々に最高の機能を提供することができません。
これは私たちのホスティング戦略にも表れています。まず、責任の範囲を最小限に抑えるため、可能な限りSoftware as a Serviceを活用します。次に、AWS Global Regionsの活用を検討します。現在、バイオロジクスからハイパフォーマンスコンピューティング環境、Generative AIまで、ほぼすべてをAWS Global Regions内でホストしています - 今日では、SAPもAWS Global Regions内で運用しています。今年は、これらの機能に関する多くの講演があるので、カタログ内のMerkの講演をチェックすることをお勧めします。
クラウド環境で実行できるこれらのワークロードがある一方で、オンプレミスに残さなければならないワークロードもあります。Johnが言及したように、これには主に2つの理由があります：レイテンシーとデータレジデンシーです。アプリケーションがオンプレミスインフラストラクチャに対して高いパフォーマンスを必要とする特定のレイテンシー要件があり、また特定の環境内でデータをローカルに保持する必要があります。私たちのオンプレミス環境は、4つのカテゴリーのアプリケーションで構成されています。皆さんの環境内でも同様の状況があるかもしれません。まず、データセンターのビジネスサポート環境です - これらは重要度の低いアプリケーションで、理想的にはAWS Global Regionsに移行できるものですが、現時点ではオンプレミスに保持しています。例えば、企業向けツールやまだ移行されていない小規模なアプリケーションなどです。
次に、データセンターのクリティカル環境があります。カテゴリーが下がるにつれて要件は厳しくなっています。これらは、エンタープライズバックアップ機能やオンプレミスインフラストラクチャに適用されるエンタープライズセキュリティツールを含む、私たちの壁の中で最も重要なエンタープライズアプリケーションです。残りの2つのカテゴリーは、エッジインフラストラクチャに関連しています。これらは世界中に分散された、より小規模で特定のユースケースに使用されるサイトです。これらは通常、ネットワークに関してより多くの制限があり、主にネットワーク制約が限られています。ここでの例としては、個々のサイトを扱うローカル施設アプリケーションなどがあります。
最後のカテゴリは、Edge Restrictedです。これらは当社で最も重要なアプリケーションで、通常、製造設備や研究機器に接続されています。取り扱うデータや情報の性質上、最も厳しいネットワーク制限が設けられており、例えばMESの実装やPAS-Xの実装などがこれに該当します。すべてのアプリケーションを変革し、可能な限り最新化したいという目標があったため、私たちは強固な基盤を確立する必要がありました。
数年前、私たちはBlue Skyと呼ばれるクラウド変革イニシアチブを開始しました。これは社内のコードネームで、私たちが先に使い始めたと思いますが、働き方を変革し、運用モデルとサポート体制を最新化するためのクラウド変革イニシアチブです。AWS Global Regionsを選択した理由は、その基盤に必要なすべての機能がすぐに利用できたからです。Infrastructure as Code、CloudFormation、そして利用可能になったTerraform、すべてのAPI、パイプライン、そしてすべてがソフトウェア定義されていました。
これにより、スタッフのスキルアップと多くの機能の最新化に注力することができました。このイニシアチブは非常に成功を収めました。前回のre:Inventで、このイニシアチブを通じて社内で達成できた価値について素晴らしい講演がありました。クラウドの機能を活用することで、環境内での変更のスピードを加速することができ、これまでにないスピードで進めることができ、私たちが求めていた価値を本当に実現することができました。しかし、パブリッククラウド環境での成功を収めた今、オンプレミス環境にも目を向けたいと考え、それがBlue Skyイニシアチブの次のステップとなりました。
オンプレミスイニシアチブの一環として、AWS Outpostsを活用し、Global Regionsのクラウド機能を社内に展開するソリューションとして採用しています。これにより、変革イニシアチブに投資してきた成果を社内で再利用することが可能になりました。このソリューションとこの働き方により、多くのメリットを得ることができています。
最初のメリットは再利用性に関するものです。Janも言及していましたが、AWS Outpostsソリューションは、AWS Global Regionsと同じAPIを使用しているため、多くの開発成果を再利用することができます。パブリッククラウドの展開用に作成したInfrastructure as Codeのテンプレートを活用できます。また、ソリューションを展開するために作成した自動化パイプラインも再利用できます。クラウド内の別のアベイラビリティゾーンとして表示されるだけなので、Global Regionsの管理のために投資した自動化されたガバナンスをここでも適用できます。ユーザーの視点からは、単にワークロードをホストできる別の環境として認識されます。
これにより、私たちが行う必要のある作業量を最小限に抑え、これまで以上に投資を有効活用することが可能になりました。これは最小限の管理という点に直結します。Outpostsソリューションは、実質的にハンズオフでサポートできるデバイスです。最初のデバイスを社内に導入した後は、本当にそのまま動作しました。ハードウェアのメンテナンスや監視について心配する必要はありませんでした。AWSがその責任を担ってくれたのです。パッチがリリースされた際も、AWSがサポートして私たちの環境に提供してくれました。私たちはそのことを心配する必要がなく、これは私たちが目指していた総保有コスト削減という目標に沿うものでした。つまり、そうした責任を最小限に抑え、より付加価値の高い活動に注力できるようになったのです。
さらに、モダンなアーキテクチャを活用できるようになりました。これまでは、オンプレミス環境では従来型の仮想マシンしか提供できませんでした。しかしOutpostsデバイスが提供する機能により、グローバルリージョンにも適用可能なモダンなクラウドアーキテクチャを推奨できるようになりました。必要に応じて即座にリソースをスピンアップするAutoスケーリングを使用できるようになり、Blue-Greenデプロイメントにも活用できます。RDSやS3といったマネージドサービス、さらにはEKSのようなコンテナサービスも活用して推奨できるようになりました。これらはすべて、これまでは提供できなかった機能ですが、Outpostsの実装によって可能になったのです。
私たちの次のステップは何でしょうか？現在、Outpostsの機能を非常にうまく活用していますが、さらに使用範囲を拡大できる大きな機会が2つあります。1つ目は接続性に関するものです。AWS Outpostsデバイスは、実行場所で接続され、管理レイヤーとコントロールプレーンのためにリージョンに接続されるよう設計されています。先ほど説明したように、私たちのエッジロケーションの中には、ネットワークの可用性が限られている場所があり、そこで接続が切断されると、一部のワークロードに課題が生じる可能性があります。そのため、異なるネットワーク接続シナリオに対応するための追加オプションについて、AWSからの発表を大変楽しみにしています。
私たちにとって次の領域はフォームファクターです。現在のAWS Outpostsは、社内のラックフォームファクター内に導入されていますが、これらのエッジサイトの中には、スペースが非常に限られており、追加デバイスを導入できる物理的な場所が極めて限定されているところがあります。現在、サーバーフォームファクターも利用可能ですが、ストレージ構成の関係で、期待していたようには採用できませんでした。しかし、ここでもAWSと協力して、デバイスの追加フォームファクターを活用するためのストレージに関する今後の展開を楽しみにしています。
全体として、これは私たちにとって非常に成功した取り組みであり、パブリッククラウドで行った投資のほとんどを社内で再利用し、その変革を目の当たりにできることは非常に exciting です。私たちはAWSとのこの journey を大変楽しみにしています。Jan にお返しします。ありがとうございます、Jeff。あなたがおっしゃったことを少し繰り返させていただくと、すでにリージョンで実施していたことをオンプレミスに展開し、将来的にはいつでもそれらをリージョンに戻せるというオプションがあること、その柔軟性は私たちがお客様に提供したい主要な価値の1つです。オンプレミスで移行を開始し、最適化を始め、その後、移行可能なシステムをリージョンに移行することがシームレスにできるようになるのです。
AWSのデジタル主権とデータレジデンシーへの取り組み
AWSでは、私たちはお客様を第一に考えています。AWSが開発する機能の90%以上が、お客様からの直接のご要望に基づいているということは、よく知られた事実です。先ほどJeffの講演でも、皆様からいただいているご要望をいくつか挙げていました。その中の1つがNetAppのサードパーティストレージシステムでした。多くのお客様から、OutpostsでNetAppなどの既存のストレージソリューションとの統合が可能かというご要望をいただいていました。そこで本日、NetAppとPure Storageとの新しいOutpostsサードパーティ統合の開始を発表できることを大変嬉しく思います。
昨日、AWS Management Consoleから直接、OutpostsのEC2インスタンスにNetAppやPure Storageシステムのブロックデータボリュームをアタッチできる機能を導入しました。これにより、業界をリードするこれらのストレージベンダーが提供する高度なデータ管理機能を引き続き利用しながら、VMをOutpost上のEC2インスタンスに素早く統合・移行することが可能になります。このアプリケーションレイヤーでの機能提供を大変嬉しく思います。
また、Körber PharmaのManufacturing Execution System（MES）であるPAS-Xが、マルチラックまたはマルチOutpostのセットアップでOutpost上での検証を完了したことをお知らせできることを嬉しく思います。同一の論理データセンター内の複数のラック上にPAS-X MESを展開する場合、PAS-XはローカルのKubernetesコントロールプレーンインスタンスを活用して、データベースの管理とシームレスなフェイルオーバーを行い、重要なMESワークロードに対して堅牢な障害対策メカニズムを提供できます。マルチ論理Outpostで展開する場合、PAS-Xは同期RDSレプリケーションを活用してデータの一貫性と高可用性を実現できます。複数のOutpostsにまたがるこのアクティブ-アクティブ構成により、いずれかの拠点で障害が発生した場合のフェイルオーバーが可能になります。これら2つのオプションにより、製薬会社は、データのオンプレミス保持という厳格な規制要件を満たしながら、ミッションクリティカルなアプリケーションや低レイテンシーが要求されるMESワークロードに対して、比類のない信頼性とスケーラビリティを実現できます。
最後に、移行を容易にするために、複数のAWSネイティブおよびサードパーティの移行ツールを使用できます。時間の都合上、詳細には触れませんが、これらのツールを使用したOutpostsへのVMware移行について、ソリューションアーキテクトが詳しく説明するセッションを用意していますので、ぜひご参加ください。
次に、話題を変えて、規制要件やデジタル主権、データレジデンシー要件を満たすために、AWS HybridサービスでRegulated Workloadを実行する方法について説明します。規制環境が進化し続ける中、多くのお客様から、イノベーションや変革の能力を妨げる可能性のある特注のクラウドソリューションを選択せざるを得なくなるのではないかという懸念を伺っています。私たちは、お客様がこのような選択を強いられるべきではないと固く信じています。そのため、AWS Digital Sovereignty Pledgeを導入しました。これは、デジタル主権の4つの柱に沿って、クラウド、ハイブリッド、エッジサービスで利用可能な最先端の主権管理機能と機能を、すべてのAWSのお客様に提供するという私たちのコミットメントです。データの保存場所に関係なく、同じ制御と暗号化機能を持ちながら、データの所在地についてより多くの選択肢をお客様に提供します。
まず、データの所在地に関するコントロールについてお話しします。データレジデンシーは白黒はっきりしたものではないということを理解することが重要です。むしろ、シナリオごとに複雑さの度合いが異なるスペクトラムとして捉えるべきです。対象となるデータを特定することは、お客様の設計や投資ニーズのあらゆる側面に影響を与える重要なステップとなります。このスライドでは、お客様がよく直面する一般的なシナリオをご覧いただけます。私たちは、お客様の国固有の規制やコンプライアンスニーズから逆算し、対象データの特定をサポートし、AWS Region、Local Zone、あるいはOutpostなど、お客様の具体的なニーズに合った適切なインフラストラクチャを推奨します。さらに、AWS Control Tower landing zonesなどのサービスを使用して、リージョンとハイブリッド環境全体で同じツールを使用し、データレジデンシーのガードレールを設定してデータの場所と移動を制御することができます。
第二に、データアクセスの検証可能な制御についてです。2023年には、Dedicated Local Zonesを導入しました。これは、AWSが完全に管理するインフラストラクチャの一種で、お客様またはコミュニティ専用に構築され、機密性の高い、または規制対象の業界ワークロードを実行するために、お客様が指定した場所またはデータセンターに配置されます。AWSはお客様と協力して、規制要件を満たすために必要な機能でDedicated Local Zonesを構成します。これには、データ監視へのアクセス、監査プログラム、お客様アカウントへのインフラストラクチャアクセスの制御、および機器の作業が必要なAWS担当者に対するローカルのセキュリティ基準や承認要件などが含まれます。
しばらく前から、Local Zone専用の2つのS3ストレージクラスが利用可能になっています。1つ目はAmazon S3 Express One Zone、2つ目はDedicated Local ZonesにおけるS3 One Zone-Infrequent Accessです。これらのストレージクラスは、特定のデータ境界内にデータを保存するように設計されており、データの分離とデータレジデンシーのユースケースをサポートします。AWS Identity and Access Managementを使用してデータ境界内のセキュリティを強化し、バケットタグでデータを整理・管理し、AWS CloudTrailのアクセスログで監査要件を満たし、サーバーサイド暗号化のためのAWS Key Management Serviceによる顧客管理キーで暗号化基準を満たすことができます。
第三に、リージョン、Local Zone、Outpostsにまたがるデータアクセスの検証可能な制御についてです。AWS インフラストラクチャはAWS Nitro Systemsによって動作し、お客様データの機密性と完全性を確保します。10年以上にわたり、私たちはセキュリティ、ネットワーク、ストレージ、コンピューティングなどの仮想化機能をNitroシステムと呼ばれる専用のハードウェアとファームウェアに移行することで、仮想化技術を革新してきました。これにより、お客様のワークロードが実行されているホストCPU、メモリ、ディスクでAWSがソフトウェアを実行する必要性がなくなり、強力な物理的・論理的セキュリティ境界を提供しています。Nitroは、AWSの誰も含めて誰もお客様のワークロードにアクセスできないよう制限を強制するように設計されています。
グローバルセキュリティコンサルティング企業のNCC Groupは、Nitroシステムのセキュリティ設計に関する独立した報告書を公開しました。その結論として、NCC Groupは設計上、これらのセキュリティ主張を損なうようなNitroシステムの欠陥は見つからなかったとしています。また、クラウドサービスプロバイダーの従業員がデータを保護するためにNitro上で実行されているホストにアクセスできる兆候はないとも述べています。データセンターからOutpostサーバーを撤去する際には、すべてのOutpostサーバーに搭載されているNitroセキュリティキーを開発し、サーバーがデータセンターを離れる前にすべてのデータを暗号化します。このNitroセキュリティキーはサーバーから取り外され、HECKSキーを使用して暗号化キーを含むセキュリティチップが破壊され、そのサーバー上のすべてのデータが暗号的に消去されます。
これは、データ破壊の問題を解決し、データセンターの運用を簡素化し、機密データが顧客のデータセンターから流出することを防ぐための、非常にシンプルでエレガントかつ厳密な方法となっています。この同じNitro Keyは、Local Zonesでも使用されており、データ破壊の簡便性から、私たちは自社のデータセンター内にも同じキーを導入しています。CTOのDr. Werner Vogelsが「すべてのものは常に故障する」と言ったように、これは特にエッジロケーションで顕著で、光ファイバーの切断や気象現象により一時的なネットワーク切断が発生します。そのため、私たちはハイブリッドおよびエッジサービスのレジリエンシーの強化に継続的に投資しています。
本日は、ハイブリッドおよびエッジサービスにおけるワークロードの可用性と耐久性を向上させるために行った、いくつかの重要な機能強化についてご紹介します。まず一つ目は、複数のOutpostsにまたがるVPC内通信です。これにより、親リージョンを経由することなく、異なる論理Outposts間でローカル接続が可能になります。お客様はこの機能強化を活用して、オンプレミスアプリケーションの高可用性を設計できるとともに、リージョンを横断する必要がなくなることでレイテンシーが削減され、アプリケーションのパフォーマンスを向上させることができます。
政府、防衛、金融、産業などの規制産業のお客様から、地球上で最も遠隔で地理的に分散した環境でもAWSのパワーを活用したいが、現在の地上回線では提供できないレベルのネットワークレジリエンシーが必要だという声をいただいていました。Accenture、Capgemini、Deloitte、Kendrell、TCSなどのパートナーと協力し、AWS Outpostsに衛星通信によるレジリエンシーを構築できるソリューションを開発しました。このソリューションはOutpostsを低軌道衛星に接続し、リージョンへの接続が途絶えた場合、スマートネットワークルーティングを使用して衛星回線経由で親リージョンにトラフィックをルーティングします。現在、このソリューションはOutpost serversの主回線およびバックアップ回線として、またOutpost racksのバックアップ回線として使用できます。
このソリューションにより、お客様はOutpostとリージョン間のネットワーク接続のレジリエンシーを大幅に向上させたり、非常に遠隔地にOutpostを導入したりすることが可能になります。また今年初めには、Local ZonesとOutpostに対するAWS Elastic Disaster Recovery（AWS ERS）のサポートを発表しました。AWS ERSは、OutpostsやLocal Zonesを目的地としたワークロードのディザスタリカバリを簡素化するためのネイティブツールを提供します。re:Inventの直前には、インスタンスストアボリュームによってバックアップされたOutpost上のT2インスタンスの静的安定性も発表しました。これにより、親リージョンへの接続が利用できない場合でも、電源障害やリセットからの自動復旧が可能になります。また、親リージョンへの接続なしで、Outpostを長期間運用し続けることができます。
AWSのグローバル展開と今後の展望
ハイブリッドサービスの機能強化に加えて、クラウド機能を活用し、ワークロードを分散できる場所の拡大も継続しています。AWSは、分散ワークロード向けに、どのプロバイダーよりも大規模なグローバルインフラストラクチャのフットプリントを持っており、このフットプリントは著しいペースで拡大し続けています。これが現時点でのフットプリントのスナップショットです。過去12ヶ月間で、Atlanta、Chicago、Houston、Honolulu、Miamiに5つの新しいLocal Zonesを追加しました。また、世界中でOutpostsの出荷と展開ができるよう、新しい国や地域を追加し続けています。今年は、Turkey、Jordan、Kingdom of Saudi Arabia、Kuwait、SenegalでのOutpostsの利用が可能になりました。
Kuwaitでのアウトポストの展開により、私たちは同国内でクラウドサービスの利用を可能にした初めての主要クラウドプロバイダーとなりました。Yegerは、Outpostを使用してKuwaitでクラウドサービスを活用する最初の顧客の一つです。Yegerは、調達とサプライヤーコラボレーションソリューションを専門とするクラウドベースのビジネス自動化テクノロジーの主要プロバイダーです。これにより、AWSユーザーとして、現地の規制や要件に準拠しながら、Kuwaitの顧客向けにサービスを拡大することが可能になりました。
本日の議論の要点をまとめますと：AWSを使用することで、クラウド、オンプレミス、エッジ環境全体で、同じインフラストラクチャ、API、マネジメントコンソール、自動化ガバナンスポリシー、セキュリティコントロールを活用できます。この一貫したアプローチこそが、類似のソリューションと私たちを差別化する要因であり、開発者の生産性向上、IT効率の改善、そして最終的にお客様へのイノベーティブなソリューションの迅速な提供を可能にします。AWSは、低レイテンシー、ローカルデータ処理、データレジデンシー要件を必要とする幅広いオンプレミスおよびエッジワークロードをサポートしています。これには、以前はクラウドでの実行が不可能と考えられていたワークロードも含まれます。
私たちは、オンプレミスで必要となるVMwareの移行を含め、移行とモダナイゼーションを加速させるためにAWSの経験をオンプレミスにもたらします。AWSは、ハイブリッドクラウドとエッジコンピューティングへの投資とイノベーションを継続することを約束します。Jeffが言及したように、より小型のサーバーと切断機能に取り組んでおり、Static Stabilityに関する発表もありました。そして、必要な場所どこへでもAWSをお届けできるよう、投資を続けていきます。
最後に、re:Inventでのハイブリッドクラウドとエッジコンピューティングに関するブレイクアウトセッションをご確認いただくことをお勧めします。また、エッジでの実践的なアーキテクチャパターンと実装について学べる多くのチョークトークやワークショップもご用意しています。ブースにお立ち寄りいただき、専門家とお話しください。今年は、私たちのコアハードウェアイノベーションの全セットをブースに展示しています - カスタム設計チップ、スイッチ、光学デバイス、光ファイバーケーブルシステム、Outpostラックとデバイス、認定IoTデバイスなどです。また、GenAIの実践をご体験いただきたい方は、ブースでバスケットボールシュートを打ってみてください。Outpost InferentiaとECSを使用して、あなたの動きを捉え、AIによるライブ実況とスポーツハイライトリールを生成する体験ができます。最後に、セッションの改善に役立てるため、アンケートへのご協力をお願いいたします。ご参加ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion