re:Invent 2025: Amazon EC2の容量管理と可用性のトレードオフ
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Managing Amazon EC2 capacity and availability (CMP331)
この動画では、Amazon EC2の容量管理と可用性、そしてそれに伴うトレードオフについて、Brian PhillippiとCarlos Manzanedo Ruedaが解説しています。On-Demand Instances、On-Demand Capacity Reservations、Capacity Blocks、Spot Instancesといった異なる使用モデルの特徴と適用方法を詳しく説明し、柔軟性を持つことで容量不足エラーを回避する方法や、Auto Scaling GroupsやEC2 Fleetを活用した実装方法を紹介しています。特に属性ベースのインスタンス選択、Capacity Reservationsの共有機能、中断可能なCapacity Reservations、Spot Placement Scoreなどの具体的な機能に加え、2024年10月にリリースされたEC2 Capacity Managerを使って組織全体の容量を一元管理する方法を実演しています。最大90%の割引が得られるSpot Instancesから、決定論的なパフォーマンスが必要な場合のCapacity Reservationsまで、コストと可用性のバランスを取るための実践的なアプローチが示されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
Amazon EC2の容量管理と可用性：トレードオフの理解
本日は、Amazon EC2 の容量管理と可用性、そしてそれに伴うトレードオフについてお話しします。本日は Brian Phillippi が一緒です。Brian、自己紹介をしていただけますか？もちろんです。皆さん、こんにちは。Brian Phillippi と申します。Amazon EC2 の Principal Product Manager をしています。AWS には約 8 年間います。ちなみに、本日は Cyber Monday なので、Amazon に行ってセールをチェックするのをお忘れなく。AWS に入社した当初は、Cyber Monday の容量計画をしていたので、容量のことは本当に生活の一部です。皆さんとここにいられて本当に嬉しいです。私の場合は、Carlos Manzanedo Rueda です。Compute の Tech Lead をしており、Worldwide Solutions Architect として、組織が特に最適化とそれに伴うトレードオフを見つけるのをお手伝いしています。もちろん、容量と可用性は、価格、パフォーマンス、コストと一緒に、私たちが考慮する必要がある最も重要なことの一つです。
アジェンダを始める前に、いくつかお話ししたいことがあります。まず、FinOps に関わっている方、または FinOps をやったことがある方は手を挙げていただけますか？予想通りですね。Platform engineering チームの一部、または組織やプラットフォームチームの一部として容量を管理している方は何人いますか？素晴らしい。かなりの数の方がいますね。最後に、アプリケーションオーナーまたは開発者で、可用性のようなことを見ている方は？素晴らしい。このトークはこのオーディエンスをかなりよくカバーしていますね。もしかしたら何人かのペルソナを見落としているかもしれませんが、皆さんはこれらのもの間のトレードオフのバランスを取る必要があると確信しており、これがこのトークの内容です。
まず、課題が何かについてお話しします。私たちが設定したフレーミングで、大体何についてのお話しかはご理解いただけると思います。 使用モデルについてお話しします。使用モデルは、異なるタイプのワークロードに対して、アプリケーションに最適なものを定義するのに役立ちます。On-Demand Instances、On-Demand Capacity Reservations、Capacity Blocks、そして Spot Instances から始まります。最後に、過去 2 ヶ月間、あるいは先週さえもリリースされた、おそらく少し新しいいくつかのことを紹介します。
これは 300 レベルのセッションなので、これからお話しするトピックについて、ある程度のハンズオンの習熟度が期待されています。もしかして、私たちがカバーしている新しいことを見つけた方は、これが宿題をするためのポインタを与えてくれて、容量計画と可用性に関する日々の活動の一部としてこれらの概念をどのように適用できるかを学ぶことができます。いくつかの重要なポイントで終わります。まず課題から始めましょう。私たちはこれらのトレードオフについて、そしてそれらのトレードオフをどのように適用するかについて話していました。
クラウド容量は無限だと聞いたことがあると思いますし、それが現実だと知っています。その現実は、私たちが内部でその容量をどのように管理するかの物理的な制限であり、それがここでお話しすることであり、それに伴うトレードオフがあります。利用可能な容量がどのくらいあるか、したがってどのような価格モデルになるのか、そしてそれでどのような低価格を得ることができるのか、そしてどのようにしてその効率を最大化できるのかについてのトレードオフがあります。 例を挙げると、 Spot Instances についてはそのバランスの中で聞いたことがあると思います。Spot Instances は、私たちのデータセンター、アベイラビリティゾーン、リージョンにある予備容量です。その予備容量を最大 90 パーセントの大幅な割引で皆さんにご利用いただけるようにしています。しかし、トレードオフはこれらのインスタンスが中断される可能性があるということです。ですから、ご覧の通り、可用性についてのトレードオフがあります。異なる使用モデルのすべての異なるオプションを探索して、容量対可用性対利用率の目標のそのレベルを理解できるようにします。
On-Demand Instancesの特徴と容量プールの仕組み
まず On-Demand Instances について深掘りしていきましょう。 これはおそらく皆さんがより馴染みのある利用モデルだと思います。 On-Demand Instances は基本的に皆さんの柔軟性のためのもので、必要な時に必要なだけ容量を確保できるというものです。ですから pay-as-you-go モデルで物事がシンプルになります。どの時点で容量が必要で、いつそれを手に入れるのか。現時点では 1000 を超えるインスタンスがあります。私の推奨としては、これらのインスタンスの最新世代を選ぶことです。通常、最高の価格性能比を備えているので、その方法で基本的に管理しやすいインスタンスの選択肢が得られます。そして私たちはこれらのインスタンスを 120 以上のアベイラビリティゾーンと 38 のリージョンで提供しています。
また Local Zones でも提供しているので、レイテンシーが皆さんのお客様にとって重要な場所で容量とアベイラビリティを管理できます。On-Demand Instances は通常、スケーリングパターン、例えば周期的なパターンのようなステートフルなワークロードに使用されます。 または、スポーティックな、あるいは一時的な短期的なワークロードのように、ある期間だけ容量が必要な場合もあります。Savings Plans のような長期的なコミットメントをする準備ができていない時、そしてテストして、そのコミットメントの準備ができるまで待ちたい時のためのものです。On-Demand の容量プールがどのように機能するかを理解することが重要です。
ある時点で特定のインスタンスタイプを選択する時、 そのプールが枯渇する可能性があり、容量不足エラーが発生する可能性があります。私たちはそれが起こらないようにするために、舞台裏で多くのことを行っており、皆さんに対して私たちが話していた柔軟性を提供しています。確実に容量を事前に確保するためのフォーキャスティングを行っています。また、その容量が必要なリージョンへの配置も行っており、ラック構築を可能な限り迅速に行うための障害を取り除いています。舞台裏では、例えば pool balancing のようなことを行っています。特定のインスタンスタイプに対して 16 X large インスタンスの過剰がある場合、ある時点で 4 X large が必要になると、それらのインスタンスを分割して 4 X large インスタンスを 4 つ作成します。供給と需要を作り出しているのですが、それでもある時点で 1 つのインスタンスタイプだけを選択すると、特定のプールが枯渇する可能性があります。
容量についての直感を与えるために、私たちは約 2 ヶ月前に新しい Intel の M8i インスタンスをリリースしました。 約 2 ヶ月前に AMD 版の M8a もリリースしました。これらを確認することをお勧めします。予想通り、私たちが可能な限り迅速にラック構築を行っていても、これらは新しいインスタンスなので、それらの容量は少なくなるでしょう。これらが皆さんの好みのインスタンスであっても、容量の利用可能性という要因を考慮に入れる必要があります。
これに対処する 1 つの方法は柔軟性を持つことです。私たちはビュッフェにいるので、縁日の例えを使いましょう。 ラビオリを選びたいかもしれません。 その時点でビュッフェにラビオリがないかもしれません。それは残念ですね。柔軟性があり、他のパスタも好きなら、それでも正しい食事を得られると確信しています。それだけでなく、残りの食べ物についても柔軟性があれば、それからさらに良い食事が得られます。ですから、異なる容量プールをどのように活用するかを改善する柔軟性というコンセプトがあります。
柔軟性による容量不足への対処：EC2 FleetとAuto Scaling Groups
オンデマンドインスタンスを使用する際に自分自身を効果的に保護することができます。そして、あなたの好みのインスタンスに行くことができますが、少し柔軟性があれば、インスタンスで常に自分自身を保護できることを知っておいてください。その柔軟性を適用する方法は、異なるインスタンスファミリーを使用するか、または x86 の異なる CPU メーカー、Intel と AMD を使用することです。異なる世代または異なるサイズです。特に大規模な組織の中には、インスタンスがあなたが必要とするサービスレベルの目標に合致していることを確認するために、インスタンスの適格性審査を行う人もいることを理解しています。決定論的なワークロードと決定論的なパフォーマンスニーズがある場合、これは非常に理にかなっています。私はあなたにそれらの概念に疑問を持つことをお勧めします。
ほとんどの場合、適格性審査を行う場合でも、あなたが求めているのは決定論的なレベルのパフォーマンスではありません。あなたが求めているのはベースラインであり、そのベースラインの後は他のインスタンスを使用できます。例えば、ベースラインが第 7 世代インスタンスで満たされている場合、おそらく第 8 世代も同様に有効です。ですから、私たちが先ほど述べた柔軟性のレベルについて考えることができます。その柔軟性を適用することは、あなたが考えるより簡単です。私たちは、EC2 Fleet と Auto Scaling Groups の両方で、重い処理を行うすべての方法を組み込んでいます。これらは私たちのサービスの残りの部分と統合されています。例えば、Capacity Manager の背後には、EC2 Fleet があり、ノードプールを通じてその選択を行い、複数のインスタンスを通じてその正確な弾力性と柔軟性を作成することができます。Auto Scaling Groups についても同じことが言えます。これは AWS Batch、ECS などと統合されています。
その使い方は非常にシンプルです。Fleet Auto Scaling Group のセットを定義または作成し、あなたが求める柔軟性を適用し、実質的にその Fleet Auto Scaling Group にインスタンスのライフサイクルを管理させます。私たちは約 2.5 年から 3 年前にこの概念を導入しました：属性ベースのインスタンス選択です。これは、プロパティまたは属性を通じてあなたの柔軟性とインスタンス選択を定義することができる方法です。例えば、特定の数の vCPU を提供するあらゆるタイプのインスタンス、最新世代または第 6 世代以降の特定の量のメモリ、および特定のストレージタイプの EBS が必要であると言うことができます。これがあなたのためにその柔軟性グループを作成するインスタンスのタイプを定義します。インスタンスを手動で定義することもできます。これは完全に問題ありません。
これらのインスタンスを定義する場合、例えば、オンデマンドインスタンスで自分自身を保護するために使用できるパターンを提供するために、優先度付き割り当て戦略で定義を開始できます。あなたはインスタンスのグループを順序付けてリストします。あなたの好みのインスタンスから始まります。しかし、そのインスタンスが得られない場合、あなたは 2 番目の選択肢、3 番目の選択肢、4 番目の選択肢を得ることに問題ありません。主な考え方は、あなたが自分自身を保護し、そのスケーリンググループがあなたの好みのインスタンスを見つけることができない場合、次のインスタンスにジャンプするので、あなたはそれらの問題に苦しむことはないということを確認することです。
これは私が推奨するパターンです。割り当て戦略は、Spot インスタンスの場合にも使用できます。例えば、容量最適化割り当て戦略は、最も深いプールからインスタンスを選択するため、頻繁な終了または終了の頻度の増加を回避します。価格に敏感な場合、価格最適化によって駆動される割り当て戦略があります。すべてのインスタンスをリストして、私たちはあなたのために価格を最適化しているものを選択します。
例えば、このアトリビュートベースのインスタンス選択をどのように適用するかというと、8つの vCPU、8ギガバイトの RAM で Graviton タイプ、そして EBS のみのストレージが欲しいと言うかもしれません。そうすると、自動的に m8g.2xlarge 以上から c7gn.2xlarge までを含む柔軟性グループが作成されます。左隅に見えるように、これらはネットワーク特化型インスタンスで、私たちはそこから選択します。つまり、そのモデルをより簡単に効果的に適用できるわけです。
On-Demand Capacity Reservations：確実な容量確保のための選択肢
決定論的なレベルのパフォーマンスや特定のインスタンスタイプが必要な場合は、オンデマンド キャパシティ リザベーション に移ります。Carlos が言及したように、特定のインスタンスタイプに対して最適化する必要があり、そこにキャパシティがある必要がある場合は、キャパシティ リザベーション を使用できます。これはコストと可用性の観点からスペクトラムの反対側にあるようなものです。キャパシティ リザベーション では、本質的にリザベーション を保持している間、その容量を確保するか、その容量に対して支払います。
キャパシティ リザベーション が何であるかについて、少し説明しましょう。キャパシティ リザベーション の頭字語は、オンデマンド キャパシティ リザベーション 、または ODCR と呼ぶこともあります。本質的に、これらを使用すると、特定のインスタンスタイプとアベイラビリティ ゾーンの組み合わせを予約することになります。キャパシティ可用性の階層を見ると、オンデマンド があり、オンデマンド は私たちが提供できる可用性という点で世界クラスだと言えます。私たちが持つ多くの異なるプールがあります。しかし、Carlos が言及したように、柔軟性を持つことで複数のプールにアクセスすることで、可用性の面で上に行くことができます。最後に、本当にそのキャパシティ保証が必要な場合は、キャパシティ リザベーション を使用する時です。
私たちが保証を提供する理由は、実際にそのキャパシティをあなたのために確保しているからです。しかし、キャパシティをあなたのために確保しているので、他の誰かがそれを使用したり、その上でインスタンスを実行したりすることはできません。したがって、リザベーション を保持している間、ずっと料金が発生します。リザベーション 内でインスタンスを実行している場合、追加の費用はまったくありません。これはコストと使用状況レポートで実行中のインスタンスのように見えます。しかし、インスタンスを実行していない場合は、未使用のリザベーション に対して料金が発生します。これは基本的に実行中のインスタンスと同じ料金です。
キャパシティ リザベーション の良い点は、特に AWS を長く使用している人の場合、ゾーン別の予約インスタンスとは異なり、キャパシティ リザベーション ではコミットメント期間がないということです。いつでもキャンセルできます。1年または3年のコミットメント期間はありません。
では、ODCR をいつ使うべきかというと、まず 1 つ目は、柔軟性がない場合です。Carlos が言及したようなビュッフェにいるときのように、金曜日の夜 6 時に North Las Vegas でどうしてもラビオリが必要な場合、確実に食べ物を手に入れるために電話をして予約を取りますよね。キャパシティ予約も同じことです。特定の時間に特定のアベイラビリティゾーンで特定のインスタンスタイプが本当に必要な場合は、おそらくキャパシティ予約を使う必要があります。
キャパシティ予約の使用をお勧めする別の場合は、ワークロードが非常に重要で、インスタンスをスピンアップできなければ悪いことが起こるという場合です。その場合も、キャパシティ予約を使うことをお勧めします。キャパシティ予約を作成する方法は 2 つあります。オンデマンドで作成することができます。これは、プール内にあるキャパシティに基づいて作成することを意味します。オンデマンドで作成する場合、私たちはキャパシティを取得して、あなたのために確保します。または、実際に将来の日付で作成することもできます。
オンデマンドの場合、スケーリングに時間がかかるワークロードを持つ顧客が予約のオンデマンド部分を作成しているのをよく見かけます。1 つのインスタンスずつ、または数個のインスタンスずつ時間をかけてプロビジョニングする必要があるワークロードがある場合、デプロイメントの 90 パーセントまで進んでからキャパシティが不足するのは本当にイライラしますよね。キャパシティ予約を使えば、実際に同期呼び出しを取得して、キャパシティがあるかどうかを確認できます。基本的には、キャパシティがあるかどうかを「はい」か「いいえ」で答えます。そしてそれがあれば、予約を作成してくれるので、好きな時にインスタンスをスピンアップして、それが成功することを知ることができます。
キャパシティ予約のオンデマンド版を使用する別の場合は、既に実行中のインスタンスがあり、それらの実行中のインスタンスを予約でカバーしたい場合です。先ほど述べたように、実行中のインスタンスを予約でカバーするための追加コストはありませんが、メンテナンスが必要な場合やフリートをバウンスする必要がある場合は、メンテナンスを実行するときにそのキャパシティを確実に取り戻すことができます。
もう 1 つのタイプは、将来の日付のキャパシティ予約です。将来のキャパシティ予約にはいくつかの異なるユースケースがあります。1 つは、Q4 ピークのようなピークイベントで、今は Cyber Monday と Black Friday があるので、大きなイベント用のキャパシティを確保することです。もう 1 つは、大規模なマイグレーションを実行していて、新しいインスタンスタイプに切り替えたい場合です。将来のキャパシティ予約がそれを支援できます。そして最後に、ベースラインを段階的に増やしている場合、将来のキャパシティ予約も役に立ちます。
その仕組みというのは、まさにレストランに注文を入れるのと同じようなものです。私たちが話したように、レストランに電話をするのと同じですね。ですから、必要な日付に対して容量予約をリクエストします。それは必要とする日から5日から120日前のどこかの時点になります。そして、その容量をどのくらいの期間保持する予定なのかを指定します。通常、私たちがあなたのために新しいサーバーをラッキングしてスタッキングしたり、サーバーを脇に置いたりするかもしれないので、予約後の約14日間の使用をお願いしています。ですが、その場で回答を得るか、予約が作成されて、それは評価中の状態になります。その後、約5日以内に、私たちはそれをスケジュール済み状態に変更します。そうすれば、容量が利用可能になるのを待つだけで、インスタンスを起動できます。
ODCRのマッチング原則と利用率向上のための戦略
ODCRが何であるか、どのように使うか、そして何のためにあるのかについて、私たちは多くの話をしてきました。では、私たちがどのようにそれを使うかについて少し話しましょう。ODCRでは、マッチングの原則で動作します。あなたのインスタンスが予約と一致する必要があり、その2つが結婚して、あなたはそれでインスタンスを起動することができるようになります。インスタンス起動と予約でマッチさせる必要がある4つの主要なものがあります。
1つ目はインスタンスタイプです。C6I.xlargeであれ、M7I.xlargeであれ、必要なインスタンスタイプが何であれ、起動するインスタンスは予約と一致する必要があります。また、アベイラビリティゾーン、プラットフォームまたはオペレーティングシステム、そして最後にテナンシーがあります。テナンシーは、シングルテナンシーか共有テナンシーかです。
私たちのほとんどのお客様は共有テナンシーを使用しています。オプションとして、クラスタープレースメントグループと連携した容量予約を使用している場合、そのプレースメントグループIDをODCRと一致させる必要があります。クラスタープレースメントグループは、高性能コンピューティングのようなものに役立ちます。これにより、すべてのインスタンスを本当に密接に同じ場所に配置できるので、インスタンスタイプ間で本当に高速なレイテンシーを得ることができます。
さて、インスタンスの適格性について考える必要があります。おそらく使用例の80～90パーセントでは、インスタンスの適格性は単にデフォルトまたはオープンインスタンス適格性になります。それが行うことは、誰もが利用できる容量のパブリックプールのように機能することです。インスタンスを起動するときのデフォルト、そして容量予約を作成するときのデフォルトは常にオープンになり、ですからそれは常に魔法のように機能します。
ただし、マルチテナントアカウントで、アカウント内の他のユーザーが容量を使用するのを防ぎたい場合は、Targeted を使用したいでしょう。Targeted は基本的に、インスタンスを起動する際に、予約 ID または予約が含まれるリソースグループのいずれかを指定する必要があるということです。こうすることで、OpenNess が提供するパブリックプールではなく、プライベートな容量プールを保護して作成できます。通常、マルチテナントアカウントが Targeted オプションを使用しています。
Carlos が言ったことに戻りますが、柔軟性を考慮して設計した場合でも、特に使用されていない予約容量があるが、別の時間のために保存しておきたい場合は、容量予約を使用したいことがあります。では、オートスケーリンググループではどうするのでしょうか。オートスケーリンググループが予約を選択する際に、例えば m8g.2xlarge を選択したいが、m7g.2xlarge を持っている場合、オートスケーリンググループが容量予約と一致することをどのように確認しますか？
昨年、ASG Capacity Reservation Preference という機能をリリースしました。この機能を使用すると、実際にそのプリファレンスを設定して、容量予約の利用率を向上させることができます。容量予約のみを使用することもできます。これは基本的に、オートスケーリンググループ内の何かと一致する容量予約がある場合、その容量予約を使用してインスタンスを起動するということです。ただし、一致する容量予約がない場合は、インスタンスを起動しないため、エラーが発生します。
また、容量予約を優先的に使用することもできます。これは似ていますが、容量予約がない場合は、実際にオンデマンドを使用しようとします。まず容量予約を探そうとします。容量予約がない場合は、オンデマンドにフォールバックして、Carlos が話していたリストを再度確認し、最も優先度の高いインスタンスを見つけようとします。これにより、効率を改善するのに役立ちます。
コストと可用性について話したい場合、容量予約を使用する際にコストを削減する方法は、それを完全に使用して、その予約から最大限の価値を得ることです。これをどのように実現できるかについて、もう少し詳しく説明しましょう。容量予約からより良い利用率を得る最良の方法の 1 つは、共有を通じることです。
容量予約の共有と中断可能な予約による効率化、そしてSavings Plans
高優先度のワークロードが昼間だけ実行されて、夜間は小さなベースラインがあるけれど、真夜中はあまり使用されないというシナリオを想像してみてください。そのようなギャップを埋めるために、実は容量予約を割り込み可能な低優先度のワークロードと共有することができます。これは特にスパイク状のワークロードで容量保証が必要な場合に、お客様が利用率を高めるための本当に素晴らしい方法です。
予約を共有する場合、実はアカウント間で共有することができます。組織間で共有することもできますし、1対多で共有することもできます。あるいは組織外の別のアカウントと共有することもできます。その方法は Resource Access Manager、つまり RAM を使って共有をセットアップするというものです。
デフォルトでは、予約を所有していて他の人と共有する場合、その人が容量を使用しなければ、予約の所有者であるあなたが料金を請求されます。もし彼らが容量を使用すれば、彼らは消費した使用量に対してのみ料金を請求されます。
しかし、私が中央チームで、未使用の予約に対して何も請求されないけれど、予約を制御・変更する能力を持ちながら Carlos に支払わせたいという場合、昨年立ち上げた方法の1つが請求所有権を割り当てる機能です。Carlos が容量をリクエストした人なので、私は Carlos に請求所有権を割り当てることができます。中央チームとしての私は管理することができますが、それを Carlos に与えて、彼が容量をリクエストした人なので未使用容量に対する料金を彼に支払わせることができます。
余談ですが、今年立ち上げたのは cluster placement groups と On-Demand Capacity Reservations も共有できるようになったということです。過去には、その容量を取り戻すのに少し手作業が必要でした。真夜中の高優先度ワークロードである私が容量を取り戻す必要があることに気付いた場合、過去にやらなければならなかったことは、低優先度ワークロードのオンコール担当者に電話するか呼び出すことです。オンコール担当者は起きます。私もオンコール経験がありますし、皆さんの多くもオンコール経験があると思いますが、真夜中に起きてログインしなければなりません。高優先度ワークロードが容量を取り戻せるように、実行中のインスタンスを終了するアクションを実行するために、多くの時間と手作業が必要になる可能性があります。
でも今、容量を取り戻す必要がある場合は、2分間の通知で中断することができます。私たちがすべての自動化を行い、インスタンスを中断して、適切なリザベーションに返却し、その後インスタンスを起動できるようにします。私はこのように設定して説明するのが好きです。On-Demand Capacity Reservation はほぼ親のリザベーションのようなもので、中断可能な On-Demand Capacity Reservation は子のリザベーションのようなものです。この2つの間には接続があります。親子関係が好きな理由は、私には4人の子どもがいて、子どもたちはいつも私を中断させるからです。その後、RAM share を使用してその中断可能な容量リザベーションを組織全体で共有し、必要な時に取り戻すことができます。
ここで1つ注意点があります。容量リザベーションには生産者と消費者がいます。生産者は明らかに優先度の高いワークロードですが、消費者、つまり優先度の低いワークロードは、インスタンスが中断される可能性があるため、自分たちが何をしようとしているのかを理解する必要があります。低優先度のワークロードがそこに起動するためには、まず私たちが話したようにその容量リザベーションをターゲットにする必要がありますが、その後、市場タイプを interruptible capacity reservation に設定して、中断されても大丈夫だということを私たちに伝える必要があります。
これをローンチテンプレートで設定して、設定したら忘れることができ、すべてが機能します。その後、インスタンスを起動して、中断通知を待つか聞きます。それが来たら、進捗を保存して正常にシャットダウンするだけです。最後に、これら2つのモデルについて少し話しました。On-Demand と On-Demand Capacity Reservations です。実は、この容量のコストを調整してコストを削減する方法があり、それは savings plan と呼ばれるものです。
savings plan を使用する場合、実際にやっていることは、一定期間、何らかの容量を使用することにコミットすることです。基本的には、少なくとも1年または3年間の時間単位のコミットメントであり、その時間単位のコミットメントにより、そのコミットメント内に適合する使用量に対して割引を受けます。当社のトップの3年間の instant savings plans では、最大72パーセント割引を受けることができます。savings plans には2つの異なるフレーバーがあります。compute savings plans と instant savings plans です。compute savings plans は究極の柔軟性を提供していると言えます。
ワークロードを実行する必要があり、Americas で8時間、その後 Europe で8時間、その後 Asia で8時間実行する場合、compute savings plan を使用できます。これにより、任意のリージョン内の任意のインスタンスタイプの任意の使用量に対して割引を受けることができます。これにより、On-Demand 価格から最大66パーセント割引を受けることができます。または、柔軟性が低く、特定のインスタンスタイプを使用したい場合、より大きな割引を受けたいが、リージョン内またはインスタンスファミリー内にとどまりたい場合は、Instant Savings Plans を使用できます。
では、ここからは Carlos に戻して、いくつかの異なるユースケースについて少し詳しく説明してもらいましょう。
Capacity Blocks for ML：GPU訓練ワークロードのための容量確保
ユースケースと異なるトレードオフについて続けていきます。基本的には、決定論的なパフォーマンス、オンデマンド容量予約、そしてオンデマンドをカバーしています。その中でも特に注目すべきなのが Capacity Blocks for ML で、これは GPU インスタンスまたはアクセラレーテッドコンピューティングインスタンス、トレーニングを含むものをターゲットにしています。これらのインスタンスは、まず第一に非常に需要が高く、需要が高いということは、ご想像の通り、場合によっては供給が逼迫することもあります。
第二に、特にトレーニングに関しては、柔軟に対応するのが難しいということです。柔軟性の管理方法については多くの改善が進んでいます。トレーニングライブラリやフレームワークをチェックしてみると、Qutile や JAX など、コンパイル時にドメイン固有言語を最大限に活用して、特定のターゲットプラットフォームに向けてコンパイルされるようにしようとするものがたくさんあります。しかし現実のところ、GPU から得られるパフォーマンスのレベルは非常に高く、そのパフォーマンスレベルは低レベルの部分を最大化して正しく処理することから生まれています。
NVIDIA のような GPU の場合、このトレーニングの多くは CUDA を使って行われており、ボトルネックを最大化して絞り込み、適切な価格対パフォーマンスを得ることで、インスタンス間での柔軟性を得ることがはるかに難しくなっています。これらのインスタンスは高価でもあるため、何か実験をしてみないうちは、Savings Plan に入るのが正しい方法ではないかもしれません。
Capacity Blocks は 1 週間から 26 週間、つまり半年間の予約容量のブロックを確保するのに役立つ契約です。私たちはこれを最近拡張しました。その容量ブロックを適用するとき、容量ブロックをリクエストするとき、その容量ブロックを取得できれば、その上にオンデマンド容量予約が配置されます。ですから、ある時点で自分たちのアカウントでその容量ブロックを使用していない場合、Brian から学んだばかりのテクニックを使って、組織の他の部分に引き継ぎ、それを最大限に活用することができます。
Capacity Blocks をいつ使うかというと、予想通りですが、大きな訓練演習が来ることがわかっている場合は、Capacity Blocks について考えるのに訓練が適切な場所です。その可用性と容量があることを確認してください。また、キャンペーン、季節的なキャンペーン、製品ローンチなどが来ている場合も、同じことです。当然のことながら、ある程度の実験のために、その実験期間中に容量を持ちたいけれど、時間をかけて貯蓄プランにコミットしたくない場合があります。そういった場所で Capacity Blocks について考えるわけです。
最大 64 インスタンス、1 から 64 インスタンスまで取得できます。それを GPU で掛け算すると、例えば 512 個の P6E-P200 GPU になります。それを placement group、cluster placement group と組み合わせることで、必要なすべての帯域幅を得られて、訓練用の本当に大きなクラスタになります。わかりますか？そして当然のことながら、これらのほとんどは Linux システムで実行されます。
ML 用の Capacity Blocks の同じコンセプトは SageMaker にも適用されます。SageMaker training plans がそれに相当します。30 分前に適用できるという方法に違いがあり、その容量があれば、直接あなたのところに来ます。ただし、ほぼ同じ側面で使用されます。SageMaker と HyperPod 内に統合されます。Ultra cluster service も要求できるので、私たちが話していた P6E-P200 も取得できます。
そのエクスペリエンスはダッシュボードと API の両方を通じて公開されるので、それらのいずれかにアクセスできます。予想通り、訓練 1 と訓練 2 を含むアクセラレーテッド コンピュートへの予測可能なアクセスに使用でき、主にデータがある場所にすべての容量があることを確認するためです。私が言っていたように、これらのワークロードのほとんどは、ターゲット アーキテクチャへのコンパイルの理由と、それらの訓練モデルを処理するために必要なデータの量のため、一般的なワークロードよりも柔軟性が低いです。
Spot Instancesの活用：フォールトトレランスと柔軟性の重要性
スペクトラムの反対側に移りましょう。Spot instances が何であるかはおそらくすでに知っていると思います。セッションの最初の部分でこれについて言及しました。これらは私たちのデータセンターにある余剰容量です。最大 90% の大幅な割引で販売されていますが、通常は 60～70% の割引が見つかります。このパスで来ることができます。人々は GPU 上で機会的なワークロードを実行できる場合、Spot instances でも GPU にアクセスできることを忘れています。さて、問題はそれらをどこで見つけるかです。Spot Placement Score について聞いたことがない場合は、すぐにそれについて話します。基本的な Spot instances をカバーさせてください。これらは主に C、M、R タイプ インスタンス、つまり通常のインスタンス タイプで使用されます。
これらのインスタンスを使用するための鍵となるのは2つのことです。1つ目は、2分間の終了通知を管理することで、ある程度のフォールトトレランスが必要になります。2つ目の重要なポイントは、柔軟性を持つことです。多くの異なる次元で柔軟性を持つことができます。インスタンスサイズ、世代、タイプの次元で柔軟性を持つことができますし、時間帯をずらせるワークロードに対しても柔軟に対応できます。 通常、夜間にはスペア容量が多くあるので、基本的にバッチワークロードの一部を夜間に移動させて、より低い価格でそれに必要な容量とスケールを見つけることができます。リージョンに対して柔軟に対応できれば、異なるリージョナルアベイラビリティゾーンに移動したり、Spot Placement Score を使ってそのリージョナルアベイラビリティを見つけたりすることもできます。
まずフォールトトレランスの側面についてお話しします。これらの中断についてお話ししていましたが、相変わらず2分間の中断通知があり、GPU に対しては最大30分まで延長しています。また、balancing recommendation と呼ばれるものも提供しており、これは基本的に私たちが提供する通知です。最悪の場合でも、Spot 終了と同じように2分前の通知ですが、通常は10～15分前に通知を提供する傾向があり、そのインスタンスが終了のリスクにさらされることを伝えます。実際に、Auto Scaling グループや Capacity Reservations 内で、そのインスタンスを同様に見える他のインスタンスに置き換えることを組み込んでいます。
Fault Injection Simulator を使用して、テストモデルの一部として自分のサイトから意図的な終了を作成することもできます。 これにより、アプリケーションが実際にこれらの終了に対してフォールトトレランスを持っているかどうかを検証できます。それがどのように機能するかを検証し、継続的インテグレーションの一部として構築することもできます。重要なのは柔軟性です。そして柔軟性の他に、 どの柔軟性の次元があなたにとって重要かを見つけることが重要です。Spot Placement Score について聞いたことがある人がどのくらいいるか分かりませんが、私たちはそれを約2～2年半前にリリースしました。Spot Placement Score は API であり、ダッシュボードにもあります。
多様化された構成を選択できます。先ほど示した Attribute Based Instance Selection と同様です。また、ターゲット容量を設定することもできます。例えば、私が使用した属性ベースのインスタンス選択の例から、1万インスタンスまたは5万インスタンスが欲しいとします。0から10のスコアが得られます。9は、その容量を見つけることができ、終了のレベルが低いことを意味します。3は反対で、おそらくその容量を見つけることができず、終了の頻度がかなり悪くなることを意味します。基本的に、アクセスしようとしている異なるリージョンと、すべての異なるアベイラビリティゾーンに対して数値を提供します。
Spark ワークロードのように非常にチャッティなもので、アベイラビリティゾーン間の料金を避けようとしている場合、分析ワークロードに適したアベイラビリティゾーンがどれかを教えてくれます。常に、お話しした手動選択を行うことができます。 私たちはすべての異なるユースモデルと、それらをスケールで実装する方法についてカバーしてきました。現実には、ほとんどのお客様はこれらのモデルの組み合わせを持つことになります。私たちは最近、私が本当に誇りに思っているものをリリースしました。Brian のチームと彼らが行うすべてのことについて、これらすべてのものをどのように一緒に持ってきて実装できるかについてです。
EC2 Capacity Managerによる統合管理と主要ポイントのまとめ
Brian、やってもらえますか？もちろんです、ありがとうございます。Carlos が言及したように、私たちは組織全体で使用されているこれらのさまざまな使用モデルを見ており、これらの異なる使用モデルを使用したい理由についてはすでに説明してきました。小規模な場合、単一のリージョンまたは単一のアカウントを見ているだけであれば、容量を管理するのは非常に簡単です。それほど悪くはありません。コンソールを使用して、正確に何が起こっているかを確認できます。しかし、大規模な組織で組織全体の容量を管理しようとしている場合、数千のインスタンスタイプ、潜在的には数千のアカウントを扱う必要があります。
これに加えて、数百のアベイラビリティゾーン、数十のリージョン、そしてこれらのすべての異なる使用モデルの混合があります。 AWS には、Cost and Usage reports、describe API、さらには CloudWatch など、これを支援できるさまざまなツールがあります。しかし、私たちが顧客と話をしたときに分かったことは、彼らが何が起こっているのかを把握するために、これらのすべてのツール間を何度も行き来する必要があったということです。容量がどのようになっているかを把握して管理するために、数時間かかることもありました。
実は 10 月に、EC2 Capacity Manager と呼ばれるものをリリースしました。 これはこれらのツールをすべて 1 つの統一されたビューにまとめるのに役立ちます。これで、On-Demand の使用状況、ODCR の使用状況、容量ブロックの使用状況、さらには Spot データまで、すべてのリージョンとすべての AWS アカウント全体で 1 か所で確認できます。そして、これは完全に無料です。 私たちはこれについて本当に興奮しています。なぜなら、これがあなたにより良い全体像を得るのに役立ち、より効率的になり、容量をより効果的に管理できるようになると思っているからです。
では、ここで少しデモに飛び込みましょう。 これは Capacity Manager ダッシュボードです。Capacity Manager の考え方は、常に非常に高いレベルから始めることです。いわば 1 万フィートまたは 5 万フィートの視点から始めて、その後、データを詳しく調べるためのツールを提供することです。上部にはダッシュボードがあり、その他のすべてのタブは、使用状況を詳しく調べたり、予約または Spot を詳しく調べたりするためのタブです。また、日付フィルターを設定することもできます。数時間前から 90 日前までの日付フィルターを設定でき、毎日の粒度を持つことができます。トレンドを見たい場合は、毎日の粒度を持つことができます。または、本当に細かく見たい場合は、時間単位の粒度で見ることができます。
ダッシュボード内には概要セクションがあり、容量予約でどの程度うまくいっているかをすぐに確認できます。容量予約と言うとき、ODCR と容量ブロックの両方を意味しており、実際にそれらの予約をどの程度効率的に使用しているかを確認できます。効率的に使用していると言うとき、利用率について言及しているのは、インスタンスがオンかオフかということです。CPU 利用率について話しているのではありません。また、十分に活用されていない容量予約のすべての推定コストを確認できるので、最高の価値を得ていないお金を使っている場所を確認できます。
また、使用状況と、その使用状況のうち実際に capacity reservation でカバーされている割合、そして Spot でカバーされている割合も確認できます。通常、ここで補足を入れておきたいのですが、これはテスト用のアカウントなので、通常であれば 44% よりもはるかに良い利用率が見られますし、1 時間の中断時間よりもはるかに少ない中断時間が見られるはずです。これは単にテストを行っているだけです。ただし、どこで中断が発生しているのか、そして Spot をどこで効果的に利用できているのかを確認できるので、希望するランタイムが得られていない場合は、より柔軟性を追加することができます。
また、使用状況メトリクスも提供され、これらのメトリクスを vCPU と vCPU 時間、インスタンスとインスタンス時間、さらには推定コストで分類することができます。On-Demand 使用量のうち capacity reservation でカバーされている割合、capacity reservation でカバーされていない割合、そして Spot で実行されている割合を確認できます。その後、時間経過に伴う使用状況のトレンドを確認して、状況がどのように変化しているかを把握できます。
また、reservation メトリクスを詳しく調べて、使用されている部分と使用されていない部分を確認することもできます。そして、この未使用容量セクションがあります。これは基本的に、未使用の capacity reservation が最も多いトップのインスタンスタイプとアベイラビリティゾーンの組み合わせを示しています。そして最後に、Spot を追跡できます。これらのいずれかを詳しく調べるとどのようになるかを見てみましょう。例えば、組織全体を見ている中で、最も効率的に使用していない reservation を確認したいとします。reservation をクリックして、同じようなことを確認できます。日付フィルター、そして dimension filter やaggregations のような新しいものが表示されます。aggregations は、すべてのデータが存在する場所です。そして今のところ、先ほど言ったように、最初から始めてからより深く掘り下げることができます。
また、capacity reservation に関するさまざまな統計情報とトレンドも表示されます。715 個の reservation がある場合、それは考えるべきことがたくさんあります。これらの reservation を分類したい場合は、instance family やアベイラビリティゾーンのようなものを選択できます。そうすると、すべてが分類されます。これで instance family とアベイラビリティゾーンが表示されるので、US East 1 AZ1 に M5 の reservation が 4 つあることを正確に確認できます。これで各 reservation に詳しく掘り下げるのがはるかに簡単になります。
また、reservation をフィルタリングすることもできるので、M5 だけを確認したい場合は、その小さなプラスボタンをクリックするか、reservation にさらに詳しく掘り下げてそれらのフィルターを適用することができます。その行項目に関する統計情報を確認でき、使用されているか使用されていないかについてのさまざまなトレンドを確認できます。その後、特定の reservation ID にさらに詳しく掘り下げることもできます。必要に応じて、個別の reservation ID をクリックして、実際にそれらの reservation に変更を加えることもできます。
時間が限られているので、指摘しておきたい機能がいくつかあります。1つは Usage です。Usage タブは Reservations タブと非常に似た動作をしており、ここで総使用量のトレンド、Reservation でカバーされている部分、カバーされていない部分、さらには Spot 使用量を確認することができます。 Instance Family、Availability Zone、Account ID、または好きな方法で分類することができます。 その後、Spot タブもあり、ここでランタイムメトリクスを詳しく調べることができるので、Spot Fleet をより柔軟にするためにどこにもっと時間を費やす必要があるかを見つけ出して、より良いランタイムを得ることができます。
必要に応じて、これは Dashboard を通じて、API を通じて、または Data Export を設定することで利用できます。Data Export は基本的には全データの毎時ダンプで、S3 バケットに送信するように設定できます。 Capacity Manager で支払う必要があるのは、S3 のストレージコストだけです。Data Export を毎時間実行するように設定して、すべてのデータを取得し、その後、必要に応じて Athena や AWS Glue などを使用してデータ変換を行うことができます。
すべてをまとめると、Capacity Manager は今日お話しした様々なことをすべて1つのソリューションにまとめるための素晴らしい方法であり、組織がすべてを可能な限り効率的かつ効果的に使用していることを確認できます。Account レベルで設定することもできます。つまり、1つの Account 内のすべてのデータということですが、Payer Account へのアクセス権がある場合や Payer Account の委任管理者である場合は、Organization レベルで設定することができます。本日の呼びかけは、Capacity Manager を Account 内または Organization 内で設定することは完全に無料であるということです。なぜなら、異なるツールをすべて使用して何が起こっているのかを把握する必要なく、より良い全体像を得ることができるからです。
では、すべてをまとめるために、強調しておきたい主要なポイントをいくつか紹介します。1つ目は、EC2 には様々な異なる Usage Model があるということです。 すべての人に最適に機能する万能な単一の Usage Model はありません。多くの場合、ほとんどの組織は異なるワークロードを最適化する必要があるため、すべての異なる Usage Model を使用しています。それらのバランスを取ることが重要であり、そのバランスを見つけることは非常に重要です。
2つ目は、Cost と Availability のようなものを継続的に調整したい場合は、Savings Plans を追加できるということです。 1年または3年の期間でコミットする意思がある場合は、On-Demand 使用量に対して大きな割引を受けることができます。または、ワークロードに柔軟性を追加する場合は、Capacity Availability を改善できます。3つ目は、EC2 インスタンスを大規模に管理したい場合、または EC2 Capacity を大規模に管理したい場合は、Capacity Manager を使用してください。本当に簡単です。
本当にありがとうございます。技術的な問題が色々ありましたが、申し訳ございません。お時間をいただき、本当に感謝しています。Carlos Manzanedo Rueda または私とつながりたい場合は、こちらが私たちの LinkedIn プロフィールです。本当にありがとうございました。皆さん、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion