re:Invent 2025: AWS OutpostsとLocal Zonesを活用したVMwareワークロードの段階的移行戦略
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Migrating your VMware workloads with on-premises dependencies (HMC309)
この動画では、AWSがVMwareワークロードのクラウド移行を支援するサービス群について解説しています。オンプレミスインフラのTCO把握の困難さ、データ主権要件、ライセンスコスト増加といった課題に対し、AWS OutpostsやLocal Zonesを活用した段階的移行戦略を提示。特にCaesars Entertainmentの事例では、Kubernetesベースのアーキテクチャを活用し、34以上の管轄区域で7ヶ月間に20ラック以上を展開、カットオーバー時間を2時間まで短縮した実績を紹介。AWS Transformによる評価・最適化の自動化、スロッティング計画の重要性、1対1のCPU比率による4倍のパフォーマンス向上など、具体的な技術的知見と教訓が共有されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
オンプレミスインフラストラクチャの課題：TCO、データ主権、Generative AIへの対応
皆さん、ようこそ。こちらはセッションAMC 309、オンプレミスの依存関係を持つVMwareワークロードの移行についてです。もし皆さんが今日ここに、AWSがどのようにして、皆さんが自分のペースでVMwareからクラウドへ移行し、モダナイズするのを支援するための一連のサービスを設計したかを学びに来られたのであれば、正しい場所にいらっしゃいます。本日は、私の良き友人であるScott Roseと、Caesars EntertainmentからゲストのTravis McVeyと一緒にステージを共有させていただきます。
さて、こちらが本日のアジェンダです。それでは、これ以上前置きなしに、本題に入っていきましょう。
私は以前、このような状況に置かれたことがあります。もし皆さんが従来のオンプレミスインフラストラクチャに携わっているプロフェッショナルであれば、おそらくこれらの課題に共感できるのではないでしょうか。もしそうであれば、皆さんの痛みがわかります。私は何年もの間、何度もそこにいましたし、オンプレミスインフラストラクチャの管理と運用について話すときは、非常に、非常に困難で大変なことだとお伝えできます。
皆さんに質問させてください。オンプレミスインフラストラクチャを運用することに、まだ価値はあるのでしょうか？それはまだ良いことなのでしょうか？まだ有効なアプローチなのでしょうか？実は、 オンプレミスインフラストラクチャを運用するTCOを正確に把握することは非常に、非常に難しいのです。特に人件費、インフラストラクチャの運用コスト、施設のコスト、そして時間とともに蓄積される技術的負債といった側面においてです。正確な見積もりを得ることは非常に難しく、実際にどれだけコストがかかっているかわからなければ、オンプレミスインフラストラクチャを運用することがまだ価値があるのか、それとも別の道を選ぶべきなのかについて、情報に基づいた意思決定を行うことは非常に困難です。
時間の経過とともに、ビジネスドライバーと技術的ドライバーの複合的な効果により、実際にインフラストラクチャをクラウドへ移行するというアイデアが推進されます。そして、その複合的な力によって、実際に情報に基づいた意思決定を行うことができるのです。つまり、行くべきか行かないべきか、それは価値があるのか、すべてを投入すべきか、実際にこの旅を始めるための最適な戦略は何か、といったことです。
このことを考えるとき、もちろん、いくつかの課題に直面することになりますし、当然それが頭に浮かんでくると思います。まず最初は、移行にどれくらいの時間がかかるのか、ということです。それは簡単なのか？速いペースで行うべきなのか、それともゆっくり進めるべきなのか？そしてもしゆっくり進める場合、そこから価値を生み出していることをどのように示せばいいのか？リーダーシップに対して、私たちはすでに手の届きやすい成果を上げていて、順調に進んでいて、これは良いことなんだということをどのように示せばいいのか、ということです。
次の課題は、最近、主権に関するプレッシャーがますます高まっているということです。データをオンプレミスに保持しなければなりません。規制要件があります。政府の義務があり、彼らは自分のデータが存在する施設を管理したいと言っています。これはもう一つの論点です。なぜなら、近くにリージョンがない可能性が非常に高く、リージョンが自分の国にあるとか、あるいは自分の国にローカルゾーンがあるとは言えないからです。ですから、これらの政府機関の一つから監査を受ける際には、戦略が必要になります。
その戦略とは、「私のデータ主権要件をどのように扱っているのか？」と言うことです。言うまでもなく、この数日間、Generative AIについて多くのことを耳にされたと思います。私が対応している多くのお客様は、常に私たちに、Gen AI拡張アプリケーションをオンプレミスでどのように実行できるのか、と尋ねています。自分たちのデータセットからオンプレミスで推論をどのように実行でき、それでいてデータ主権要件を満たすことができるのか、ということです。これらの課題は、オンプレミスからクラウドへの移行の動きに大きなプレッシャーを与えています。
AWS Where You Need It戦略：Outposts、Local Zones、リージョンへの段階的移行パス
そして今、皆さんはおそらく、AWSはその意図に対してどのように支援してくれるのか、と考えていることでしょう。AWSは、お客様が自分のペースでオンプレミスから、理想的にはクラウドリージョンへ移行できるよう支援する戦略を設計しました。しかし、最初は不可能な場合でも、途中でステップを提供することができます。移行し、要件を満たし、先ほど見た課題に取り組めるように、ジャーニーを提供することができます。従来の世界から離れて、クラウドに足を踏み入れていることを迅速に示すことができます。この戦略が、私たちがAWS Where You Need Itと呼んでいるもので、オンプレミス環境から、皆さんに非常に近いAWS Outpostsへ移行できるようにするサービスのセットです。
AWS Outpostsは、皆さんのデータセンターまたは選択したコロケーション施設に配置することができ、これがAWSサービスで最も近づける方法です。あるいは、Local Zoneへの移行というステップを踏むこともできます。Local Zoneは、選ばれた大都市圏に配置された私たちのインフラストラクチャであり、主権要件に対応するための有効な道でもあります。AWSは、私たちのインフラストラクチャがその大都市圏で稼働していることを保証することができ、これはデータレジデンシーを要求する多くの政府や団体にとって十分である可能性があります。
それでは、ジャーニーを作成することができます。可能な限りリージョンに到達することを常に目指すべきですが、もしそうでない場合でも、途中のステップをご提供できます。そこでは、将来性のあるクラウドアセットを使用して、AWSのクラウドインフラストラクチャ上で効果的に実行することができ、最終的にオンプレミス環境からクラウドへできるだけ多くを移行するための道を開くことができます。このジャーニーに実際に乗り出すために、いくつかの方法、いくつかのパスがあります。
もちろん、最も一般的なのはリフトアンドシフトアプローチです。これは、お客様が非常に迅速な結果を示したいと考える場合で、ワークロードをそのままOutpostsまたはLocal Zonesに移行するだけです。これは全く問題ありません。絶対に問題ありません。その過程でできることは、マネージドデータベースやマネージドコンテナなどのマネージドサービスを体験して、モダナイズを試み、少しギアを変えることです。
もうEC2の上にデータベースをインストールする必要はありません。KubernetesやDockerを管理する必要もありません。私たちの提供するサービスを活用することで、差別化されない重労働と呼ばれるもの、つまり基本的ではあるものの、あまり付加価値をもたらさない活動を確実に軽減できます。どのルートを選択するかを決める際には、移行のタイムラインを考慮することが重要です。どのような要件がありますか？施設との契約が切れる場合、古いハードウェアがある場合、契約や保証が期限切れになる場合、これらはどちらを選択するかを決定する上で本当に重要です。しかし、最善の行動方針は、今すぐ行動を起こすことです。待たないでください。それが私たちがここにいる理由です。最終的にその決断を下すお手伝いをするため、そしてそれを実現するお手伝いをするためです。
移行の商業的側面：ライセンスコストの重複を回避する資金提供プログラム
では、私の良き友人であるScottに引き継ぎます。はい、ありがとうございます、Frankie。皆さん、こんにちは。私の名前はScott Roseです。Frankieの同僚です。AWSに5年ちょっと在籍しており、皆さんのようなお客様が、ワークロードをAWSに評価、最適化、移行するのをどのように支援してきたか、特にオンプレミスのハイブリッドエッジポートフォリオ、OutpostsとLocal Zonesにそれを行う方法についてお話しできることを本当に嬉しく思います。Outpostsが最初にローンチされて以来、ほぼ5年間これを行ってきました。そして、CaesarsのTravisがここに来て彼のジャーニーについて話してくれることを本当に嬉しく思います。Caesarsは、Outpostsを導入した最初のお客様の1社でしたので、彼からも素晴らしい文脈が得られるでしょう。
さて、ここAWSでは、皆さんも多くのセッションに参加されていますが、私たちは多くの技術を皆さんに提供しています。そして、これからもそうします。しかし、商業的な側面についても話したいと思います。なぜなら、移行の状況を扱う際、私たちは通常、10年、20年、時には30年前の環境を扱っているからです。興味深いライセンスコストの変化が見られ始めています。明らかにVMwareはその1つですが、メインフレーム環境のような非常に古いレガシー環境を運用・維持するコストも、これらの組織が資金を提供し続け、基本的に数十年前に設計された運用の予算を組み続けることが非常に困難になっています。それに加えて、これらのワークロード自体の専門知識のほとんどが、現在の製品やアプリケーションの要件に対してまったく最適化されていないことは言うまでもありません。ですから、もちろん技術的な考慮事項に加えて、コスト要素が非常に重要な検討事項になっているのを目にしています。
さて、そういうことで、AWSはこの6ヶ月から9ヶ月の間、資金面の状況、つまり移行に対する補償の状況と呼んでいますが、これを支援するために本当に多くの時間を費やしてきました。これを分析する際には、ライセンスコストの重複や、いわゆるダブルバブルのような状況について心配する必要はありません。私たちには移行プログラムと適切な資金提供プログラムがあり、これらのコストのほとんど、あるいはすべてを軽減するお手伝いをいたします。Frankieもそうですし私自身も、かなり大規模なお客様に関わってきましたが、これらの資金提供プログラムの規模を計算してみると、非常に大きなものになります。ですから、こうした商業的な懸念事項については、技術的な分析やアーキテクチャの分析が並行して行われることになりますが、それよりもずっと前の段階で、遠慮なく私たちにお持ちいただければと思います。移行アセスメントのためにですね。
財務的な観点からこれにアプローチする方法はたくさんあります。私たちのProServe組織に対するクレジットという形で行うこともできますし、これらのプロジェクトを順序立てて、そして適切な金額でスコープを決めていく作業を行います。また、これに関わるパートナーも数多くいます。私たちのお客様のほとんどは、複数のシステムインテグレーターと関わっており、彼らは長年にわたってアプリケーション管理や運用を契約して行ってきました。ですから、私たちの資金提供プログラムは、商業的な観点から、これらのパートナー自身に対しても直接機能するように設計されています。そして、今後を見据えた観点から見ると、明らかにAWSはクラウドコンピューティングです。消費モデルに基づいています。お客様のオンプレミスインフラの多くは、まだ資本支出の観点から購入され、予算化されているかもしれませんので、私たちはその二つの橋渡しをしようとしています。
最終的な結果として、AWSで移行プログラムを実施する場合、私たちはその環境がクラウドネイティブなインフラストラクチャ上で稼働する様子を見据えています。この場合、OutpostsやLocal Zonesのような、オンプレミスのクラウドネイティブなインフラストラクチャですね。そして、お客様が計算されているかもしれない重複コストを相殺します。
移行のステージング：リフト&シフトからサーバーレスまでの段階的モダナイゼーション
ですから、安心して前に進んでいただけます。複数のレイヤーのコストではなく、単一レイヤーのコストです。なぜなら、VMwareや古いインフラのセットといった一つのプラットフォームから、AWSへと移行するわけですから。さて、進めていきますと、Frankieが少し複雑な、 まあ、テキストが多めのスライドを用意していましたが、様々な移行ステップについてですね、これは実際にはこのように集約されます。かなりシンプルなステージングまたはシーケンスです。お客様の状態をどのように見ていくか、レガシーアプリケーションやレガシーVMを適切なAWSフットプリント上に移行するという観点から何をしたいかということです。
明らかに、一番下のレイヤーは非常に高速でありながら非常に有用なEC2のリフトアンドシフトです。そして、単純にスケールを上げていきます。一部のお客様は、これらの仮想アプリケーション、仮想マシンをコンテナにモダナイズしたいと考えています。もう一歩進んで、RDSのようなマネージドデータベースサービスを追加したいかもしれません。あるいは、最終的な飛躍として、これらのアプリケーションの一部を完全にリファクタリングして、例えば完全にサーバーレスなデプロイメントにするということもあります。もちろん、これらすべてを行うことができます。私たちはかなり長い間、これらすべてを行ってきました。
私が移行のお客様と関わってきた経験から申し上げますと、過去3年から4年にわたって多くの移行を実施してきましたが、そのスピードは加速しており、これは決してワンストップショップではありません。私たちが取り組んでいる多くの環境では、まず環境全体をリフト&シフトでキャンバス化し、その後、一部をコンテナ化し、さらにその一部でデータベースマネージドサービスをデプロイしています。つまり、これは単一の塊ではなく、このケーキには複数の異なる層があるということです。そして、オンプレミスと地域的な要素について強調しておきますと、OutpostsやLocal Zonesを使えば、通常はマネージドデータベースサービスまで持っていくことができます。そしてリージョンはもちろん、Lambdaのようなスケーラブルなサーバーレスプラットフォームが提供されている場所です。
AWS Outposts Gen 2：大規模VMware移行を支える高密度コンピュートとGPUインスタンス
ということで、改めて少し文脈を整理しますと、先ほどFrankieが少し前に見せたスライドの観点からお話しします。さて、昨年の初めに第2世代のOutpostsをローンチしましたが、これについてお話しするのは、私たちのVMware移行の機会の多くが、オンプレミスに留まらなければならないという厳しい要件を伴ってやってくるからです。お客様はクラウドネイティブなインフラストラクチャでデプロイしたいと考えており、明らかにAWSを活用したいのですが、リージョンではなく、オンプレミスに留める必要があるのです。その理由は様々です。データレジデンシー、レイテンシー、他のオンプレミス資産、例えば他のストレージや他のコンピュート資産への近接性などです。そのため、私たちのインフラストラクチャは基本的にこれらの既存ソリューションに隣接して配置される必要があります。
それがまさにOutpostsが特別に構築された目的です。第2世代のOutpostsは昨年、2024年の年初から中頃に登場し、過去6ヶ月から9ヶ月にわたってスケールアップしてきました。そしてこれは、私たちの移行の機会、移行ユースケースを持つお客様にとって驚くほどうまく機能しています。なぜでしょうか？私たちが分析しているこれらの環境の多くで、何万、何万ものCPU、数百テラバイト、時にはペタバイト規模のストレージ範囲を目にしているからです。つまり、これらのワークロードをAWS Outpostsのフットプリントに移行するために必要なスケールは、かなり大規模になる可能性があるのです。
そこで、Outposts Gen 2でローンチされた新しい高コンピュート密度のEC2インスタンス、私たちの並列ネットワーキングサブストラクチャは、高I/Oデータセンターアプリケーションやデータベースを支援するだけでなく、お客様の中には他のワークロード、ネットワーク集約型のワークロードを多重化したいという方もいらっしゃいます。Outposts Gen 2は、VMwareから移行してくる標準的なITアプリケーションだけでなく、おそらく高性能データベースや他の適切なアプリケーション、アプリケーションのカテゴリーにとっても非常に堅固なフットプリントとして機能し、これらすべてを同じラックインフラストラクチャ上で多重化できます。
そして、ここでお話ししているのは、非常に大規模なレガシーインフラストラクチャのフリートを撤去しているお客様のことです。その多くはVMwareを実行しており、その多くは複数のサイトにわたって稼働しており、それらの多くをOutpostsラックのフットプリントに統合しています。時には数十、時には数百のラック規模になります。しかし、そのフットプリントは、プロジェクト自体に着手する前のレガシーインフラストラクチャのフットプリントと比べて、はるかに小さく、はるかに効率的であることがわかります。
さて、先ほど申し上げたように、Outposts 2に搭載された新しいインスタンスは、特にCPUとメモリ密度の観点から、非常に優れたメトリクスを提供してくれました。これにより、以前のエッジインフラで展開されていたものよりも、はるかに高密度な構成を計算して作成することができるようになりました。また、このOutpostsには、ベアメタルなど他のインスタンスセットもあります。これは、金融サービス部門や通信事業者部門など、非常に高性能なアプリケーションを必要とするお客様向けに設計されたものです。そして近日中に、次世代のGPUインスタンスが登場します。もちろん、単なるグラフィックスインスタンスではありません。
これは、エッジでの推論、そしてモデルの設定方法によってはトレーニングにも特化して設計されたGPUインスタンスになります。つまり、このラックは、お客様が今後数年間に必要とするワークロードのタイプという観点から、将来を見据えて構築されており、これらの一部はまだ設計段階にあります。ですから、オンプレミス要件の観点から、パックが向かう先を見据えて滑っていけるようにしたいと考えています。
そして、このセッションで特にお話ししているマイグレーションの状況は、これらのOutpostsに搭載された次世代の密度の限界を本当に押し広げてきました。そして、ここに示されていないのは、約2ヶ月後にAWSがさらに新しい、さらに高性能なインスタンスの新しいウェーブを投入する予定だということです。詳細については、ぜひご期待ください。
AWS Transform：AIベースの評価・最適化ツールによる移行の加速化
マイグレーションの話に戻りますが、そして少しVMwareのストーリーに戻ると、現在これを積極的に行っているお客様で見られることは、私たちは皆、キャリアを通じてかなり長い間、こうしたエンタープライズIT環境に携わってきましたし、理解していると思っています。評価には数週間程度かかるだろうと思うかもしれません。しかし、そうではありません。これには数ヶ月かかっています。一部のお客様では数年かかっています。なぜなら、これらの環境の多くが基本的にそこに置かれたまま、最適化されていないことがわかってきたからです。オペレーティングシステムやファームウェア以外は実際には更新されていないため、アーキテクチャが意味をなしていないのです。
具体的な例を挙げると、VMディスクマニフェストを見ると、1つのCPUと700ギガバイト、760ギガバイトのメモリという、非常に非対称なVMが見つかることがあります。そして、それが何に使われていたのか、それを収容するのに適したEC2インスタンスを見つける必要があるのかを調べようとしても、組織内の誰もそれがどこから来たのか知らないようなのです。これを大規模に行い、何百、何千、何万ものVMでこれを実行すると、実際にそのすべてにかかる時間が本当に増えていくのです。
では、どのようにしてこれを解決しているのでしょうか？どのように修正しているのでしょうか？どのようにして、より良い評価と最適化の計画を作成しているのでしょうか？もちろん、私たちはこれを分析してきました。そして私たちのソリューションは、エージェントベースの最適化および評価ツールのセットとなります。これにより環境に入り込んで分析し、既存の環境にどれだけのCPU、どれだけのメモリ、どれだけのストレージがあるかを大まかに把握するだけではありません。それはおそらく皆さんもすでにご存知でしょう。実際に入り込んで、これらのVMの使用状況に基づいて判断します。私たちは、このクラスのVMは、何ヶ月も使用されておらずアイドル状態にある他のVMと比較して、より高い優先度、または評価の優先スケジュールに値すると考えています。これが、私たちのAIベースのツールで実現できる、かなり簡単な最適化の道筋の一つです。
もう一つの重要なポイントは、ネットワーク要素をどのように分析するかということです。多くのお客様が、コンピュートとストレージだけでなく、これらのVMware環境の周りに存在するかなりカスタマイズされたネットワークシェルを持っているのを目にします。それをどうするのか？非常にフラットなレイヤー2環境を、よりスケーラブルでルーティング可能なレイヤー3に変換するにはどうすればよいのか？私たちのAIツールは、アグリゲーションレイヤーだけでなく、EC2インスタンスと相互作用するVVCレイヤーまで、ネットワークの側面を分析し評価するのに役立ちます。
そして最も重要なのは、繰り返しになりますが、数十台、あるいは数百台のVMがある環境であれば、すべてかなり手動で、昔ながらのスプレッドシートで対応できます。しかし、複数のサイトにまたがる数万、数万台のVMを扱う場合、それは一度にすべて実行できるものではありません。そこで本当に便利になるのが、適切なウェーブ分析をどのように行うかということです。どのように分析し、VMからEC2への移行、あるいは同時にコンテナ化される可能性のあるアプリケーションの重要度の観点から意味のあるウェーブで、環境にリロードする方法を決定するのか。
つまり、これらすべては基本的にAWS Transformによって行われています。これは今年の初めにローンチした新しいツールで、 特に、VMware、メインフレーム、また仮想化されているがVMwareベースではないレガシー仮想化アプリケーションなど、さまざまな移行ワークロードを分析し、インフラストラクチャのパスだけでなく、アプリケーション自体のコーディングを提案し最適化することも目的として設計されています。例えば、メインフレームのレガシーCOBOLアプリケーションを、モダンなJavaアプリケーションに変換するといったことです。つまり、AWS Transformは、インフラストラクチャのアナライザーでありモデラーであると同時に、個別の アプリケーション最適化ツールでもあります。
そして、Transformが対応するモジュールや機能がいくつかあります。繰り返しになりますが、特にVMwareについて話しているのか、あるいは私たちのところに来るほとんどのお客様にとって、まず最初にVMwareの問題なのか。
しかし、その後、レガシーな非仮想化データベース、メインフレームアプリケーション、非常に古いJavaアプリケーションなどを含む、マルチアプリケーションの問題へと変化していきます。ですので、Transformが支援する複数のインターフェースがあり、これについては専用のブレイクアウトセッションで詳しく説明できます。Travisのセクションに進みたいと思いますが、一例として、ネットワーク変換と移行に関するこの一つのセグメントだけを見てみましょう。
これは、Transformがどのように処理するかという詳細です。仮想NSXスイッチのソースを分析する観点から、もちろんVMDKファイルの分析、そしてサードパーティのファイアウォールやロードバランサー、またはCiscoのようなアプリケーション中心のインフラストラクチャも分析します。今後の適切な新しいトポロジーを決定し、変換されたAWSネットワークエンティティを作成します。この場合は、AWSネットワークエンティティです。繰り返しになりますが、これはネットワークの側面だけです。同様のコンピュートとストレージの側面もあります。これにはウェーブ分析も含まれますので、数ヶ月かかる移行の問題を、少なくとも2桁、場合によっては3桁の規模で加速させるのに役立つ、かなり包括的なAIツールとなっています。
移行のメリット：コスト削減、セキュリティ強化、大規模イノベーションの実現
明らかに、これから実現できる主なメリットは、まずコストと時間の観点からです。環境を統合の観点だけでなく、今後の最適化の観点から分析します。さらに、これをオンプレミスで行うという変数も加わります。リージョンでこれができることは分かっています。皆さんの多くはおそらくリージョンのリソースを活用されていると思いますが、ここで話しているのは、これらすべてをOutpostsやLocal Zonesのようなオンプレミスのクラウドネイティブインフラストラクチャ上で行うということです。これらは、その物理インフラストラクチャが皆さんの環境内に設置されているため、若干異なるニュアンスがあります。
ですので、既存のインフラストラクチャ、既存のライセンスの観点からコストを分析し、現在の状態からAWSを使った状態まで、単一レイヤーのコスト構造になるように、これらすべてをどのように相殺するかを考えます。並行コスト、冗長コスト、二重コストは発生させません。移行をできるだけ迅速に進めたいと考えています。AIは素晴らしいですが、決して完璧ではありません。分析時間の多くを短縮するのに役立ちますが、それでも明らかに多くの手動介入が必要になります。しかし、ゼロから行ったり、かなり古い方法で行ったりするよりも、桁違いに速くなるでしょう。
これを行う際、AWSのセキュリティ原則も取り入れていきます。セキュリティが最優先事項であるということを何度も耳にされていると思います。ですので、当社のインフラストラクチャと皆さんのインフラストラクチャへのインターフェース方法を検討する際、明らかな移行活動自体に加えて、これらのセキュリティプリミティブと原則を導入していきます。ですので、セキュリティは無料で付いてくるようなものですが、現代的で、実績があり、Well-Architectedな移行プロジェクトすべてにおいて、非常に重要な工業化されたコンポーネントなのです。
そして、大規模にイノベーションを起こします。もちろん私たちは大規模に取り組んでいます。つまり、もちろん小規模な環境でもこれを実現できますが、私たちはすでに数百、数千、数十万台のVMにわたって動作するようにこれを設計しており、これが通常、複数のサイト、時には大陸規模で私たちのもとに来る中規模から大規模のお客様のほとんどで見られる運用規模です。これはAWSが明らかに非常に得意としていることであり、私たちはこれらの小規模なPOCから大規模な本番環境へと移行するパターンを学んできました。
さて、これで私たちがどのように行うか、どのようにアプローチするか、そして何のためにそれを使用するかについて、少し興味を持っていただけたのではないかと思います。それでは、プレゼンテーションをTravisに引き継ぎ、CaesarsのOutpostsでの取り組みについて聞かせていただきたいと思います。Travis、よろしくお願いします。
Caesars Entertainment事例：Wire Actとデータレジデンシー要件への対応
お招きいただきありがとうございます。私の名前はTravis McVeyです。8月でCaesars Entertainmentに勤めて4年になります。実際、私はスポーツブックやレースブック、iGaming部門を運営するビジネスのデジタル部門に所属しており、ここに映っているホテルや宮殿を担当しているわけではありません。しかし、スポーツブックに入って、賭けをしたい場合に使うすべてのキオスクは、私のチームが管理しています。
それでは、まずCaesars Entertainmentとは何かについて、少し背景をお話ししましょう。Caesars Palaceが何であるかは皆さんご存知だと思いますが、私たちは宮殿だけではないんです。私たちは米国最大のカジノエンターテインメント企業であり、世界で最も多様化したカジノエンターテインメントプロバイダーの1つです。実は1937年にネバダ州リノで始まり、新しいリゾートの開発、拡張、買収を通じて成長してきました。ご存知かもしれませんし、ご存知ないかもしれませんが、実際に私たちはここラスベガスや他の場所でHorseshoe、Linq、Flamingo、そしてEldoradoのような他の主要施設、そしてもちろんCaesarsとHarrah'sといったいくつかのブランドを運営しています。
私たちは、業界をリードするCaesars Rewardsロイヤルティプログラムに結びついた、モバイルおよびオンラインゲーミングとスポーツベッティング体験の完全なスイートを提供しています。私たちは、これらのサービスのユニークな組み合わせを通じてお客様との価値構築に注力しており、People Planet Playフレームワークを通じて、従業員、サプライヤー、コミュニティ、そして環境に対してコミットしています。
それでは、いくつかの統計データをご紹介します。はい、私たちは実際に50,000人以上の従業員を抱えています。繰り返しになりますが、私たちが管理しているさまざまな象徴的なブランドや、Caesarsが何をしているのか、特にここラスベガスの地元で何をしているのかについて説明してきました。しかし、私の担当する事業領域、つまりオンラインギャンブルについて掘り下げていきましょう。2018年にPASPAが廃止されて以来、これはまさにロケットのような、金鉱のような、何と呼んでもいいですが、そんな成長を遂げてきました。以前は存在しなかったものが、今では年間200億ドル以上の産業になっています。私たちは2018年以来10倍に成長し、米国のほぼ60パーセント、半分以上の州でギャンブルが認められるようになりました。月曜日にサービスを開始したばかりのミズーリ州も含めてです。
しかし、それが皆さんがここにいる理由ではありません。私たちがここにいるのはマイグレーションについてです。VMwareからOutpostsへ、なぜそれを行ったのか、何が関係しているのか、ですよね。それでは、私たちが運用していたものの良い点に入る前に、悪い点についてお話ししましょう。私たちには複雑性がありました。皆さんがどうかはわかりませんが、私たちの開発環境と本番環境は完全には一致していませんでした。AWSでアプリをスケールして構築するのは非常に簡単ですが、私たちには非常に興味深い問題があり、それを解決しなければなりません。それは多くの業界が解決する必要のない問題で、それがWire Actです。
米国で賭けを受け付けるためには、その賭けは実際にその州内で行われなければなりません。皆さんは、どうやってそれをするのかと思うでしょう。まあ、それは法的なルールによって決まるのですが、実質的にトランザクションはオンプレミスで発生しなければなりません。ですから、私は賭けエンジンをオンプレミスから移動させることは決してできません。それは州内に留まらなければならないのです。そして本当に面白いのは、時にはカジノの裏側にあることもあるということです。なぜなら、それが実際に許可されている唯一の場所だからです。
そのため、私はそこにVMwareワークロードがあり、開発者たちはAWSでテストしていて、そうするとコンテナが実行すらされないといった奇妙なことが起こります。なぜなら、これらのいくつかでEVCを実行していて、アプリが実際に実行するために必要なプロセッサオプション、CPUオプションが利用できず、それを修正しなければならないからです。他のすべての場所では動作しているのに、この1つの州でデプロイメントが失敗するのです。ですから、データレジデンシーと環境の不一致に関して多くの複雑性があります。
また、コストの問題もあります。ここにはHPのソフトウェアがあり、ここにはDellがあり、ここにはこのベンダーXYZがあります。VMwareは抽象化レイヤーを提供してくれますが、それでもこれらのファームウェアをアップグレードする必要があります。すべてが正常に動作していることを確認する必要がありますし、VMwareビルド自体を管理するソフトウェアがある場合、それが独自のバブルの中にあるようなもので、これらすべての環境のパッチ適用をどのように管理するかという問題もあります。私たちはこれらの環境がある30以上の管轄区域を持っており、これらすべてのvCenterをアップグレードすることは困難です。もう1つの問題は、これらすべての環境にゴールデンイメージをどのように配布するかということです。それは簡単ではありません。
ユーザーエクスペリエンスについてです。もしあなたがCaesars PalaceやLINQでベットをする場合、それがOutpostsで動いているのか、VMwareで動いているのか分かりますか？気にしませんよね。ただベットが通ることを確認したいだけです。これは私たちが理解しなければならなかった大きなポイントでした。私たちはこれだけの複雑性を抱えていて、これら全てを管理しようとしているわけですが、結局のところ、この頭痛の種に対して実際にどんな顧客価値を追加しているのでしょうか？これは良い質問で、私たち自身に問いかけなければなりませんでした。自分たちで構築してベアメタルでやりたいのか？VMwareを継続したいのか？それともOutpostsを実行して、そういったものを全て抽象化して、より高い顧客価値のある項目に集中できるようにしたいのか？
そして最後のポイントはパフォーマンスです。確かに、VMware環境をパフォーマンスの高いものにすることはできますが、挙手をお願いします。データベースを速くするために60個のCPUを載せようとする人を見たことがある方はどれくらいいますか？ええ、それはうまくいきませんよね。Outpostsで実際に起こることは、デプロイメント戦略を再考することを強いられるということです。これについては後ほど少し詳しく説明します。
CAPIからEKS on Outpostsへ：Kubernetesベースのアーキテクチャ移行とパフォーマンス向上
では、私たちのVMwareアーキテクチャは実質的にどのようなものだったのか、そしてなぜ移行が簡単になるのか？これから私たちがどれだけ速くこれらを実行するかを説明しますが、皆さんは嘘だと思うでしょうから、先に言っておきます。嘘ではありません。
これからお話しすることは全て真実です。私たちが実行していたのはCAPIで、これはVMware上のKubernetesのオープンソース版です。ほぼ全てのワークロードはKubernetesで動作するコンテナ化されたものでした。その外にあったのはデータベースのVMだけで、これは単にKubernetesでは必要なリカバリータイムとリカバリーポイント目標を達成できないからです。もう少しで達成できそうです。本当にそれらをKubernetesに入れたいのですが、まだ完全にはそこまで到達していません。それから、規制要件を満たすためにバックアップを管理してオフサイトに保存できるようにストレージゲートウェイがあります。
ですから、私たちにとってはかなりシンプルなスタックでしたが、ハードウェアが異なっていても開発者のエクスペリエンスが同じになるように、この方向性を推進し続けました。開発者がコンテナを作成し、アプリを作成して、それがAWS内であろうとVMware内であろうと、デプロイできるようにしたかったのです。そしてKubernetesの話は全て本当です。私のチームがそのインフラを管理している限り、それは同じでした。しかし繰り返しになりますが、違いについて話すとき、私のチームはその違い全てに対処しなければなりませんでした。CAPIを管理しなければなりませんでした。アップグレードを管理しなければなりませんでした。ゴールデンイメージが存在して起動することを確認しなければなりませんでした。全ての通信が機能するように全てのファイアウォールルールを管理しなければなりませんでした。そして、Kubernetesが常に行っている全てのCSIボリュームのために、vCenterを酷使するのが大好きでした。試したことがあるか分かりませんが、アップグレードを行う際に、いわゆるクラウドネイティブディスクを1つのVMから別のVMに移動するのには、かなり時間がかかることがあります。
では、現在AWS Outpostsラック上で何が稼働しているのでしょうか？ 私たちが行ったのは、異なるアプリケーション用のEC2ノードとマネージドノードを配置する構成への移行です。ここにはデータベース用のEC2ノードがあります。前のスライドを見ていただくと、VMデータベースをEC2ノードのVMに移行しただけなんです。そして、EKS on Outpostsがあります。これにより、もうCAPIのアップグレードをする必要もなく、CAPIのテストをする必要もなく、それらすべてが正常に動作しているか確認する必要もなくなりました。そして、開発環境にある単一のVMwareインスタンスを、一人のエンジニアがゆっくりと反復作業するという状況もなくなりました。今ではAWSとEKSがあり、すべてのdaemon setやHelmチャートなどが正常に動作していることを迅速に確認できるようになりました。
いくつか追加のリソースを用意していますが、それは今、Route 53などのよりクラウドネイティブなサービスを使いたいと考えているからです。ただし、少し違った考え方をする必要があります。Outpostsはリージョンに紐づいています。では、そのリージョンへの接続が切れたらどうなるでしょうか？これは真剣に考えなければならない非常に重要な問題です。インスタンスはそこにあるにもかかわらず、リージョンに依存しているため、従来とは異なる考え方が必要になります。そこで、できる限りの回復力を持たせたいと考え、障害が発生した際には古いキャッシュを提供できるようにしました。なぜなら、私たちのIPは実際にはあまり変わらないからです。かなり静的なものなんです。ingressがクラスターに入ることさえ確保できれば、すべてが機能します。だからこそRoute 53を導入しているんです。
マネージドEC2インスタンスには依然としてストレージゲートウェイがあります。ですから、私たちのアプローチはリフト&シフトと言えるかもしれませんが、私たちにとってリフト&シフトを可能にしたのは、実質的にKubernetesでした。アプリケーションを使って簡単にクラウド間を移動できるようにしたいという話がありましたが、私たちはその理論を実際にテストして前進することができました。このケースではプライベートクラウドからOutpostsへの移行ですが、本当にうまくいきました。「ちょっと待って、S3が見当たらないけど。私はS3が大好きなんだけど」と思われるかもしれません。 その通りです。S3はOutpostsラックに大量のノードを追加することになります。また、コストも増加しますので、本当にそれをやりたいのかよく考える必要があります。そして先ほど申し上げたように、私たちは34以上の管轄区域で展開していますので、コストを追加するたびに、それを30倍しなければならず、数字が非常に大きくなることがお分かりいただけると思います。ですから、必要なものに適応しつつ、CFOのためにコストを意識する必要があるんです。
また、私たちが取り組んできたのは、単一のOutpostsへの依存性についてです。それはアベイラビリティゾーンに紐づいているということです。Outpostsラックはアベイラビリティゾーンとして考える必要があります。リージョンではなく、ゾーンなんです。追加のSLAはありません。追加のフェイルオーバーもありません。はい、サーバーが故障した場合は、冗長性が組み込まれています。ネットワークスイッチが故障した場合も、冗長性が組み込まれています。しかし、ラック全体がダウンしたり、サービスリンクがダウンしたりすると、そのアベイラビリティゾーンに縛られてしまいます。皆さんの中には、US East Oneリージョンの障害の影響を受けましたか、という質問をされる方もいらっしゃるでしょう。はい、影響を受けました。ただ、幸いなことに、ローカルゲートウェイ経由でルーティングするために共有VPCをほとんどのサービスで利用するという設計のおかげで、影響を軽減することができました。Frankieの以前のスライドを見ていただくと、ローカルゲートウェイ経由のネットワーキングという小さな箇条書きが一つあったと思いますが、私たちはそのインフラストラクチャ上でサービスエンドポイントを動作させるために、それを本当に推し進めてきました。
こうすることで、単一障害点であるサービスリンクがダウンしても、依然として外部にルーティングして賭けを受け付けることができます。なぜなら、それが私たちのトランザクションであり、賭けを受け付けられるようにしたいからです。そして、他のアベイラビリティゾーンにマネージドノードを配置して、それらのゾーンで実行されているあらゆる種類のサービスが運用可能な状態を維持できるようにしました。そのため、そのアベイラビリティゾーンがダウンしても、Route 53などのサービスのトラフィックが流れ続け、更新され続けることを確保できます。
私たちがやっているのは、Outpostを分割することです。これにより、もしアベイラビリティゾーンが1つ障害を起こした場合、影響を受けることになりますが、アベイラビリティゾーンが影響を受けても、すべてのサイトが影響を受けるわけではありません。つまり、これは設計上の決定なんです。皆さんのビジネスモデルによっては異なる選択になるかもしれません。これが私たちが決めたことです。アカウントマネージャーやソリューションアーキテクトと協力して、皆さんにとって何が最適かを本当によく考えてみてください。なぜなら、これは万能な解決策ではないからです。皆さんのビジネスに何が合うのか、レジリエンシー要件は何か、そして何を許容できるのかを見極める必要があります。
スロッティング、スロッティングが何か知っている人はいますか?はい、1人手が挙がりましたね。では、VMwareがこれをとてもシンプルにしてくれましたよね?VMware以前のことを考えてみてください。何をしなければならなかったでしょうか?ラックに何台のサーバーを収められるか計算して、どれだけの電力があるか、私のキャリア初期に電力に関するガイダンスをいただきありがとうございました、Brad、そしてラックに収められる量には限りがありました。つまり、そのラックに収められるアプリの数にも限りがあったわけです。Outpostでは少しそこに戻ることになり、本当に考え直さなければなりません。なぜなら、私がVMwareリソースでできたことは、オーバーコミットすることだったからです。VMが欲しいですか?ええ、もちろん、6対1の比率を守り、クリティカルなアプリが適切にサイジングされている限り、問題ありません。
それは素晴らしいことですが、今や私はこれらすべてのVMを抱えていて、それらはすべて膨大なリソース要件を持っていますが、おそらくそれは実際には必要ないものです。もう1つ考えなければならないのは、私たちの場合Kubernetesがあったということです。つまり、スケジューラーの数を考えてみてください。CPUを持つベースホストがあり、VMwareスケジューラーがあり、次にCPUをスケジューリングする仮想マシンがあり、そしてKubernetesがあり、さらにコンテナがあります。すごいですよね。
今やVMwareのオーケストレーションレイヤーがなく、Outpostサーバー上で直接実行しているので、1対1のCPUを得られます。つまり、もうCPUスワップがなく、CPU待機時間がなくなったんです。CPUウェイト、CPUレディ、皆さんがずっとグラフを見ながら「なぜ私のVMは遅いんだろう?」と思っていたあれです。それが存在しなくなりましたが、事前に作業を行う必要があります。時間をかけて適切にサイジングしてください。そうしないと、あまりにも多くのハードウェアを購入することになり、この余分なハードウェアをどうしようかと悩むことになります。
データベースノードでスワッピングがなくなったため、4倍のパフォーマンスが出ています。データベースノードは、繰り返しになりますが、ベットはオンプレミスで行われなければなりませんでした。それは何を意味するのでしょうか?トランザクションが発生する必要があるということです。トランザクションがデータベースにヒットします。もしそれがレプリケーションを試み、高可用性を保とうとしている間にスワップインとスワップアウトを繰り返していたら、そして今やそのスワッピングが一切必要なくなりました。私たちが気づいたのは、ノードをそこまで大きくする必要がないということでした。そこで今、分散させるために、これらの余分なスロットを得て、今やCPUに非常に最適化された追加のコンピュートKubernetesノードがあり、以前はKubernetesに入れるのがとても怖かった異なるデータベーステクノロジーを入れることができるようになり、準備万端です。
それでは最後に、先ほど申し上げたように、他のデータベースノードをこれらの専用インスタンススロットから移行する必要があります。それらをKubernetesに移行することができますし、実際にDRSやHAアイテムのように環境をフローさせることができるようになります。ただし、Kubernetesを使って管理することで、料金を支払っているVMwareの基盤となるすべてのものは不要になります。
移行の実践：7ヶ月で34州以上への展開とダウンタイム2時間への短縮
では、私たちの旅はどのようなものだったのでしょうか?私のチームは動きますし、そして速く動きます。ですから、できる限りのことを把握しようとしました。設計を行い、事前に時間をかけてスロットを割り当て、適切なサイジングを行いました。アカウントチームと協力してテスト環境を立ち上げ、それが機能することを確認してから、アクセルを全開にしました。7月には4ラックを設置し、2つの州を移行しました。8月にはさらに1ラック設置し、2つの州を移行しました。9月には5ラックを追加設置し、毎週1つの州を移行しました。
顧客にサービスを提供できないダウンタイムを2時間まで短縮しました。その後、論理ゲートウェイを介してデータベース移行を行う新しい方法を見つけ出し、レプリケーションができるようにしたことで、カットオーバーが発生した際にはほぼ瞬時に完了するようになりました。そして、anti-affinityルールに精通している方ならご存知かと思いますが、一部のサービスがどのように機能するかを考える必要があります。私たちにとっては、
単一障害点は好ましくありませんし、どのサービスを使用したいかを特定する必要がありました。重要なポイントの1つは、AWS Outpostsではハイパープレーンがなくなるということです。つまり、ラック内でネットワークロードバランサーを使用することはできません。リージョン内で使用して転送することはできますし、ALBオプションも提供されています。スロッティングによっては、ALBが非常にうまく機能する場合もあります。しかし私たちには合いませんでした。アップグレードとALBのマネージドサービスのために非常に多くのキャパシティが必要でした。なぜなら、それはリージョンで実行されるように設計されており、AWS Outpostではないからです。
繰り返しになりますが、ソリューション次第ですが、私たちは単一ラックを持っているため、それは私たちには機能しないと判断しました。私が言いたいポイントは、移行を行っている間、私たちは学習し、改善しているということです。そして、ウェーブを実行する際にそれを行うことが重要なのです。私たちは州単位で行っています。なぜなら、同じアプリを何度も繰り返しているからです。しかし、ほとんどのアプリケーションを見てみると、Webティア、アプリティア、データベースのいずれであっても、依存関係があります。うまくいくようになり、依存関係が何であるかを把握できたら、あとはすすぎと繰り返しです。そのローテーションに乗ることができます。そして、それが本当に認識すべき重要なことなのです。
タイムラインを続けていきますね。10月にはさらに6つのラックを設置しました。11月、残念ながら、12月には20になることを期待していたんですが。そのバックアップを再開することを期待していますが、DR設計を改善することができました。これには本当に興奮しています。実質的に、リージョナルアベイラビリティゾーン設計を使用して、それをAWS Outpostsに複製できるようになったんです。繰り返しになりますが、クラウドネイティブで考えていて、マルチアベイラビリティやマルチリージョナルについて考えているなら、それは全体的なAWS Outpostsの設計に役立つことになります。
では、私たちが話した課題に戻りましょう。何だったかというと、経験と複雑性がありました。今では単一のAMIがあり、同じアカウント内にあるので、すべてのAWS Outpostsと共有でき、高速にデプロイできます。1対1のCPUについて話しましたね。アプリの設定方法によっては、3倍のパフォーマンスを得られることもあります。先ほど4倍と言ったのは知っていますが、常に調整して改善しようとしているんです。でも繰り返しになりますが、6対1の比率を持つ必要がないので、1対1の比率で本当に考えることができます。私のデータベースは実際に24個のCPUが必要なのか？ベアメタルで動作していたら、何個のCPUを与えますか？おそらく24個ではないでしょう。12個から始めて、それがどう機能するか見てみます。
ですから、それについて本当に考えて、何が機能するかを考え、そしてスロッティングについて考えてください。なぜなら、繰り返しになりますが、すべてのスロットがそれを消費することになりますし、新しいgen twosではより多くのスケール、はるかに多くのスケールが得られます。これらはまだgen onesですが、考えることが重要です。そして私たちにとっては、価格保証でした。皆さんの中でBroadcomとやり取りしている方がどれくらいいるかわかりませんが、その会話が始まったとき、私たちは非常に不安でした。方程式で変更する項目の数は関係ないようでした。最終的に数字は常に同じになってしまうんです。どうしてそうなるのかわかりませんが、価格が保証されていることを確認したかったんです。そうすれば、ビジネスに対して、これが年々のコストになり、新しい州を追加するコストがこれになると約束できます。それは本当に重要でした。
そして最後に本当に重要なのは、VMwareだけではないということです。ストレージベンダーもあります。皆さんの中で何人が、ストレージが気に入って、すべてが気に入って、それが別の会社に買収されて、突然価格が急騰したり、廃止されて移行しなければならなくなったりした経験がありますか？チームがストレージデバイスを移動するのにどれだけの労力、どれだけの時間を費やしていますか、そしてそれが顧客にもたらした価値は何ですか？ゼロです。つまり、すべてのエンジニアリング時間を費やし、すべての資本を費やし、すべての運用コストを費やし、ダウンタイムがゼロになるようにすべての計画を立てて移行し、祝福し、素晴らしかったのに、顧客が見た価値はそれだけです。それが重要なポイントです。これをC-suiteが理解できる言葉でどう表現するか？それが売り込みのポイントであり、それが私たちが本当にやりたかったことでした。
そして最後はハードウェアです。ハードウェアベンダーに入り込みます。サポート方法を完全に理解します。すべてのファームウェアアップグレードを処理するために管理ソフトウェアを購入し、そして買収されたり、サポートされなくなったりします。そして今度はバージョン2に移行することになり、アップグレードパスがありません。これは継続的なコストであり、繰り返しになりますが、FrankとScottが話していた隠れたコストで、一歩下がって「ちょっと待って、実際に顧客に何を提供しているんだ？」と考えない限り、本当に考えないものなんです。
私の顧客は開発者なのか？私の顧客は実際のエンドユーザーなのか？これが、私たちがこれらすべてを実行する前に本当に座って考えたことです。ベアメタルKubernetesを構築することもできました。私は自分のチームを完全に信頼しています。非常にうまくできたでしょうし、紙の上では安く見えたでしょう。しかし、すべてのベンダー交換などを考えると、それは本当にどんな価値を提供するのでしょうか？
学んだ教訓：スロッティング計画、バックアップ電源、障害テストの重要性
それで、これらのいくつかに触れてきましたが、少し早く進みすぎている気がしますが、学んだ教訓です。デプロイメントのスロッティングを計画してください。これを何度も取り上げていることは分かっていますが、スロッティングは非常に重要です。これは全く新しいパラダイムシフトであり、必要とするすべてのマネージドサービスもスロットを消費します。EC2に移行して、その後マネージドRDSに移行できるという素晴らしいスライドがありました。しかし、マネージドRDSは依然としてスロットを消費します。無料では手に入りません。それが使用されます。そして冗長化したい場合、それは2つのスロットを使用することになります。ALBが必要な場合、それもスロットを消費します。
アップグレードも必要です。ダウンタイムなしでアップグレードするには、3つ目をデプロイして、他の1つを廃止する必要がありますよね？つまり、その余裕、必ずしもそこにあるわけではない弾力的な容量が必要なのです。そしてストレージゲートウェイも、すべてスロットを消費します。最初にそこに入ったとき、私たちはそれについて考えていませんでした。ただ行って、ええ、これが必要だと言っていました。幸運なことに、追加容量を提供してくれるパフォーマンス向上を得ることができました。しかし、そこまで幸運でない場合、セットアップしようとしているときに本当に悪い状況に陥る可能性があります。そして、最初のものが失敗するのは決して望まないですよね？ですから、どうかその教訓を学んでください。スロッティングに取り組み、チームと協力して、必要なものを本当にテストし、それが適合することを確認してください。
バックアップ電源、これは非常にシンプルだと思いますよね？私たちに起こったことの1つは、先ほど言ったように、カジノの奥に物を置くことがあります。そこにVMwareラックがあり、停電が起きた場合、カジノには必ずしも本番データセンターグレードのUPSが自動的に切り替わるわけではないので、時々起こるのですが、電源を入れ直します。VMwareが起動し、右クリックして、はい、読み取り専用ファイルシステムではありません、すべて問題ありません、次へ、次へ、次へ、そして復旧しますよね？そして15分ほどかかります。
これはブートしなければならないクラウド全体です。リージョンに接続しなければなりません。プロビジョニングしなければなりません。すべてのセキュリティチェックを実行することを確認しなければなりません。私たちが当たり前だと思っているすべてのメタデータサービスをセットアップしなければなりません。ご存知のように、それが誰であるか、そのIPなどを送信するメタデータサービス、これらすべてが起動してオンラインになる必要があり、それには数時間かかります。数分ではありません。ですから、個別の冗長電源があるか、UPSを購入してそこに設置し、ラックの電源を維持できるようにしてください。私が経験して説明しなければならなかったこの教訓を、どうか学んでいただき、皆さんがそうする必要がないようにしてください。
私たちが行った最も大きなことは、私のチームが、先ほどお話ししたようなService Linkの単一障害点をいくつか特定したことだと思います。そこで私たちがやったのは、アカウントチームと協力して、「ねえ、これは私たちにとって全く新しいことだから、私たちが知らない障害の可能性は何だろう?みんなで頭を寄せ合って、起こりうるすべての障害について考えてみよう。サーバーが故障したらどうなる?Service Linkが故障したらどうなる?Route 53がダウンしたらどうなる?これらすべてが何を引き起こす可能性があるか考えて、ランブックを作成して、アプリが動作し続けられるようにしよう」と言ったんです。そして実際にやりました。すべてテストしました。ランブックも用意して、すべて素晴らしかったです。
一つお伝えしておきたいのは、Service Linkの障害をテストするなら、2時間以上テストしてください。それが役に立ちます。それから、VMware HA DRSについてはかなり話してきたので、あまり時間をかけたくないんですが、これはスロッティングの話に戻ります。でも繰り返しになりますが、本当に実行する必要があるものは何かということです。とてもシンプルなんです。リージョン内で実行するなら、実行したいバージョンを選んで、それでガンガンやればいいんです。もしできないなら、下位環境があるはずなので、そこにシフトして、テストして、M5で何が得られるか確認すればいいんです。リージョン内のM5は、Outpostsで動作しているものと同じなので、期待しているのと同じCPUメモリパフォーマンスが得られるはずです。C7やM7も同様です。でも本当にテストしてください。時間をかけてやってください。
以上です。はい、ありがとう、Travis、ありがとうございました。本当にありがとうございました。終わる前にいくつか締めくくりの言葉を。ぜひAWS villageにお越しください。そこにはマイグレーションとモダナイゼーションについて話すキオスクがあります。実物のOutpostsラックを見ることができますし、Local Zonesのキオスクもあります。イベント後のセッションアンケートへの記入をお忘れなく。セッション後方で質問をお受けします。皆さん、お越しいただきありがとうございました。ありがとうございました、ありがとうございました。ありがとうございました、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion