re:Invent 2024: AWSのEC2キャパシティ管理 - 4つのモデルを解説
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Managing Amazon EC2 capacity and availability (CMP319)
この動画では、AWSのEC2キャパシティに関する4つの異なるモデルについて詳しく解説しています。On-Demand、On-Demand Capacity Reservations、Capacity Blocks、Spotという各モデルの特徴や使い分けについて、具体的なユースケースとともに説明されています。特にOn-Demand Capacity Reservationsについては、Future-Dated ODCRsの導入により最大120日前からの予約が可能になったことや、請求の柔軟性向上など、最新の機能強化について詳しく紹介されています。また、Capacity Blocksでは、Machine Learning向けのP5、P4D、TRN1などのインスタンスタイプを2のべき乗単位でプロビジョニングできる特徴や、最大6ヶ月までの期間延長が可能になった点など、具体的な活用方法が解説されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
EC2キャパシティ管理の概要と本日のアジェンダ
みなさん、こんにちは。お元気ですか？ありがとうございます。本日は Mandalay Bay までお越しいただき、ありがとうございます。ストリップの端にあるので少し遠かったと思いますが、本日ご参加いただけて嬉しく思います。私は Dave Ward です。Amazon EC2 のキャパシティを統括しています。Auto Scaling や Spot Capacity Blocks、そして EC2 自体のキャパシティプランニングなどのサービスを担当しています。本日は、On-Demand Capacity Reservations のプロダクトマネージャーである Brian Phillippi と一緒に発表させていただきます。
今日は素晴らしいアジェンダをご用意しています。使用モデルが盛りだくさんです。ここでの課題は、これらを使用してキャパシティの可用性を向上させる方法、またはコスト効率を改善する方法についてです。それぞれのモデルについて詳しく説明し、ベストプラクティスをご紹介するとともに、この1年間のチームの取り組みについてもお話しさせていただきます。
AWSの4つのキャパシティモデルとその特徴
お客様との会話を振り返ると、私は AWS に長く携わってきましたが、当初の会話は、必要なときにキャパシティを確保できる弾力性について、とても興奮した内容でした。しかし、お客様との対話を深めていくと、価格とコストを抑えることも重要な関心事であることがわかりました。 つまり、コストを適切に管理するためには、コストと可用性のバランスを取る必要があるということです。
そこで私たちは、本日ご紹介する4つの異なるキャパシティモデルを導入しました。1つ目は On-Demand で、これは誰もが知っている、長年親しまれているキャパシティモデルです。使用した分だけ1分単位で支払い、インスタンスの起動と停止が自由にできます。2つ目は On-Demand Capacity Reservations で、必要なときにキャパシティを確実に確保したいお客様向けのモデルです。ただし、キャパシティを確保してコストを適切に管理するため、24時間365日の課金となります。
次のモデルは Capacity Blocks で、機械学習用のコンピュートにアクセスする機能を提供します。特定の期間を指定し、その期間が終了すると、そのキャパシティを他のユーザーに提供するために回収します。社内では、需要の高い生成AI向けキャパシティへのアクセスを民主化するような取り組みだと考えています。最後のモデルは、私の心に近いものです。以前から携わってきて、また今も関わっている Spot です。これは EC2 の余剰キャパシティを大幅な割引価格で提供するものです。このモデルのトレードオフは、On-Demand Capacity Reservations などの他のキャパシティモデルにキャパシティを提供する必要が生じた場合に、使用中に中断される可能性があることです。
On-Demandモデルの詳細と柔軟性の重要性
それでは、On-Demandそのものについて詳しく見ていきましょう。先ほど申し上げたように、これはキャパシティを柔軟に拡大縮小できる機能です。850種類以上のインスタンスタイプから選択できるだけでなく、データセンターと考えていただける108のAvailability Zone、そして34のリージョンなど、世界中の様々な地域にアクセスすることができます。
ここ数年で、Local Zonesをリリースしました。ご存じない方のために説明しますと、これは特定の都市圏内に地理的な拠点を設けるというものです。ハワイまでアクセスできるようになりました。今この時期にいたら素敵ですよね。さらに14の拠点が追加される予定です。例えば、ハリウッドにある素晴らしいデータセンターのように、レンダリング作業向けに特化した計算処理が必要な場合に最適です。各ゾーンで利用可能なインスタンスの種類が異なりますが、これはその地域で想定される用途に合わせて調整されているためです。
On-Demandの使用例としては、日中の周期的な使用パターンがあります。9時から17時といった時間帯に応じて、スケールアップやダウンを行います。短期的なワークロードや通常の定常状態の運用にも対応できます。これが、お客様が一般的にキャパシティを利用する際のデフォルトの方法となっています。
On-Demandの最も基本的な利点の一つは、エラスティシティです。私たちは、無限のキャパシティがあるかのような印象を提供するために、舞台裏で懸命に働いています。それを実現するために、キャパシティプランニングに力を入れ、それぞれのキャパシティプールに必要な容量を事前に検討しています。インスタンスを実行する際の配置を最適化するなど、他の取り組みも行っています。ハードウェアの再構築も行います。インスタンスタイプ間や異なるインスタンスファミリー間で需要が変化していることに気付いた場合、内部の需要も調整します。特に人気の高いインスタンスタイプがある場合、内部のワークロードに移動を指示することもあります。
そして最後に、私たちは利用率を非常に重視しています。コストを低く抑えるためだけだと思われるかもしれませんが、それは確かにその通りで、最もコスト効率の良いソリューションを提供したいと考えています。しかし、それと同時に、導入した全てのハードウェアをお客様の手元に届けることも重要なのです。
On-Demand Capacity Reservationsの進化と新機能
新世代のインスタンスをリリースする際のキャパシティには物理的な制約があります。よく「なぜ新世代のインスタンスは初日から無制限のキャパシティを提供できないのか」という質問を受けます。実際には、データセンターへの導入時にはスループットの制約があり、それは徐々に拡大していきます。私たちの目標は、最新世代のインスタンスに対して、幅広く深いキャパシティプールを提供することです。これは今後1〜2年の重要な焦点となっています。
私たちは無限のキャパシティという幻想を提供するために懸命に努力していますが、実際にはOn-Demandインスタンスは共有キャパシティプール上に構築されています。つまり、他のお客様も同じキャパシティを必要とする場合、そのキャパシティを確保される可能性があります。お客様との会話の中でよく出る質問は、必要な時にキャパシティを確実に確保するにはどうすればよいかということです。
結局のところ、柔軟性が重要で、現在私たちは多くのキャパシティを提供しています。柔軟に対応できれば、新しい可能性が開けます。これはラスベガスのビュッフェに例えることができます。カニの足が食べたくても、みんなが取りに行けば品切れになるかもしれません。でも、スパゲッティやステーキなど他のメニューでも良いと考えれば、きっと満足できる食事にありつけるはずです。
柔軟性を考える際には、通常4つの次元について話し合います。1つ目はインスタンスファミリーです。C、M、Rなどの異なる特性を持つインスタンスファミリーは、時として互いに代替可能です。2つ目はサイズで、ワークロードをスケールアップできる可能性があります。3つ目の世代は実は大きなレバレッジの1つで、必要に応じて第7世代から第6世代に切り替えることができます。最後に、現在データセンターに導入しているインスタンスの約50%がGravitonなので、異なるチップアーキテクチャに対応できれば、追加のキャパシティを確保できる機会が多くあります。
この話をすると、お客様からよく「第7世代であれ第8世代であれ、新しいインスタンスを使用する前に徹底的な検証が必要だ」という声を聞きます。私たちは、お客様のインスタンス検証プロセスや、その背後で行われている具体的な作業について、多くの時間を費やして確認します。しばしば、多くのお客様がこれらの検証から実際には何も利点を得ていないことがわかります。AWSでの17年の経験の中で、世代間で問題や違いが見つかったのは、スケールで実行した時に発見された1つのユースケースだけでした。
アプリケーションに柔軟性を組み込むためのツールを用意しています。必要な柔軟性を分析する際、キャパシティプールの規模や、どこをターゲットにするかなど、様々な要因を考慮し始めます。私たちは2つの基本的な機能を構築しました：新しいインスタンスを起動する際の需要の柔軟性を伝えやすくすることを目的としたEC2 Fleetと、15-16年の歴史を持ち、様々なメトリクスに基づいて自動的にスケールアップ・ダウンを行うAuto Scalingです。 Auto ScalingとFleetを活用する際は、3つの簡単なステップで実現できます：Auto Scaling groupまたはFleetのセットアップ、柔軟性の定義、そして必要に応じてAuto Scalingが自動的にFleetを起動または使用します。
異なるインスタンスタイプの必要量を計画する際、実際の使用状況を確認します。より柔軟性が高いと想定される場合もありますが、最新世代や特定の仕様など、フリートに関する情報が多ければ多いほど、ユーザーのニーズをより良く理解できます。これにより、通常のOn-Demandプールを深化させる方法を理解できるだけでなく、より高いキャパシティの可用性を確保することにも役立ちます。
2つの異なるモデルがあります。1つ目はAttribute-Based Instance Selection（ABIS）で、特定のvCPU数、メモリ量、EBS-onlyかどうか、そして2週間前にリリースしたPerformance Protectionなどを指定できます。これにより最小世代を設定でき、多くの可能性が広がります。なぜなら、多くのユーザーは何年も前のM1インスタンスを使用できないからです。もう1つのオプションは、利用可能な特定のインスタンスを指定することです。多くの場合、お客様は手動選択から始めて、その後Attribute-Based Instance Selectionに移行できます。あるお客様の場合、新しいインスタンスタイプをリリースした際、ABISを使用していたため、すでにトラフィックが発生していたことに感銘を受けました。
CPUとメモリを指定するだけでは十分ではありません。 何を起動するかの優先順位付けの方法を知る必要があります。2つの方法があります：1つ目はコストベースで、最もコスト効率の良いソリューションを起動しようとします。もう1つは可用性ベースで、より多くのキャパシティが利用可能な場所での起動に焦点を当てます。このアプリケーションと一緒に動作する他のアプリケーションがある場合、これらのアプリケーションを成功に導く良い方法となります。
簡単な例として、vCPUとメモリ、そしてEBS-onlyを指定できます。 これにより、予想以上に多くのインスタンスが選択され、目的の起動を実現します。最終的に、この柔軟性を持つことで、より高い可用性の実現に焦点を当てています。私たちは引き続きお客様のニーズに応えることに注力しますが、これによって追加の確実性が得られます。
ODCRsの使用方法と最新の改善点
そういうわけで、次のモデルとして、さらに高度な容量保証を提供するOn-Demand Capacity Reservationsについてお話しします。そしてBrianがこれについて説明してくれます。ありがとう、Dave。私はEC2のProduct Managerを務めています。Daveの17年には及びませんが、Amazonで7年以上働いており、その間ずっと容量管理に携わってきました。実は2日前に開催したCyber MondayやPrime Dayの計画立案から私のキャリアは始まり、それらのイベントに十分な容量を確保することが私の仕事でした。容量管理は私にとって非常に身近なテーマであり、現在はOn-Demand Capacity Reservationsのプロダクトマネージャーを務めています。
Daveのたとえに戻りますと、On-Demand Capacity Reservationsは、バランスという観点から見ると、可用性により重点を置いています。 しかし、その話に入る前に、17年の経験を持つDaveは、実は私たちのお客様に容量保証を提供する最初のツールの立ち上げに携わった人物なので、まずはZonal Reserved Instances（ZRI）についてお話ししたいと思います。これによって、私たちがお客様のワークロードの容量保証をどのように改善してきたかがわかると思います。重要なワークロードを実行する際には、容量保証が必要不可欠だからです。2009年にZonal Reserved Instances（略してZRI）を立ち上げた時、実際にはこれは2つの異なる製品を1つにまとめたものでした。一方では容量予約があり、これは誰も触れない容量を確保して、お客様だけが使用できるようにするものです。そして他方では、1年または3年の期間を約束することで、その予約に対するすべての使用量に割引が適用される課金割引がありました。
しかし、お客様とともにこれを運用していく中で、この2つを組み合わせることで管理が非常に難しくなることがわかりました。 例えば、エンジニアリングチームは容量予約機能を気に入っていて、それだけを重視していました - 容量が確保され、実行できるかどうかだけが関心事でした。一方、財務チームは割引に関心がありました。割引が適用されているか、それをどう管理するかが重要だったのです。
そこで私たちはこれらを分離しました。ここで素晴らしいアニメーションをお見せしましょう。このアニメーションはDaveが作ったもので、彼はとても誇りに思っています。もしよろしければ、このアニメーションに対してDaveに拍手をお願いします。私たちはこれらを分離し、ありがとうございます。一方にOn-Demand Capacity Reservations、もう一方にSavings Plansを置きました。
On-Demand Capacity Reservationsの説明に入る前に、Savings Plansについて少し詳しくお話ししましょう。Savings Plansは本当に素晴らしい仕組みです。実質的に、1時間あたりの特定の金額を支払うことを約束するものです。支払う金額を選択でき、その見返りとして使用量に対する割引を受けられます。これらを分離したことで、より柔軟性の高い2種類のSavings Plansを作ることができました。Compute Savings PlanとInstance Savings Planです。Compute Savings Planでは、EC2の使用量全般に対して割引が適用されます。特定のタイプや特定のAvailability Zoneに限定されず、世界中のどのEC2使用量にも適用されます。これにより非常に高い柔軟性が得られ、最大66%の割引を受けることができます。さらに深い割引を得るために少し柔軟性を犠牲にしたい場合は、Instance Savings Planがあります。これはリージョンとインスタンスファミリーに限定されますが、そのリージョンとインスタンスファミリー内であれば、サイズやAvailability Zoneを自由に組み合わせることができます。
Capacity Reservationsについて少しお話しさせていただきます。Capacity ReservationsはEC2が提供する製品の中で最高の可用性を実現します。先ほどDaveが説明したように、On-Demandでは、On-Demandプールの弾力性を確保するために私たちが裏側で多くの作業を行っており、柔軟性を持たせることでさらに向上させることができます。しかし、Capacity Reservationsでは、実際にキャパシティを確保して取り置きするため、他のユーザーがそのキャパシティに触れたり、そこにインスタンスを起動したりすることはできません。これにより、確実なキャパシティを保証します。デメリットとしては、キャパシティを取り置きするため、他のユーザーに販売できない分、予約を保持している間ずっと料金を支払う必要があるという点です。
これらを組み合わせると、非常に強力なツールになることがお分かりいただけると思います。例えば、Savings PlanやCompute Savings Planを持っていて、最新のGravitonインスタンス、C7gで運用しているとします。そこにAmazonが得意とするイノベーションを行い、新しいインスタンスC8gをリリースしたとします。1年や3年の契約期間が終わるまで待つ必要はありません。Capacity Reservationはいつでもキャンセルできるため、コミットメントの必要がないのです。C7gのCapacity Reservationをキャンセルして、C8gの新しいCapacity Reservationを作成すれば、すべてがスムーズに動作します。割引を受けることができ、Capacity Reservationを使用したくない場合でも、Savings Planをサンに従って移動させることもできます。本当に強力なツールなのです。
では、ODCRsをどのように使用するのでしょうか？ODCRsは「マッチング」という概念で動作します。インスタンスがODCRで実行されるためには、インスタンスとODCRが5つのパラメータで一致している必要があります。最初の4つはキャパシティ自体に固有のものです：インスタンスタイプ、キャパシティが配置されているAvailability Zone、プラットフォームまたはオペレーティングシステム、そして共有インスタンスか専用インスタンスかという点です。 5つ目は「インスタンスの適格性」と呼ばれるもので、予約とインスタンスの両方で設定できるパラメータで、両者が確実にマッチするようにするものです。
インスタンスの適格性には2つのタイプがあります。1つ目は「オープンインスタンス適格性」で、これは公共プールのようなもので、他の4つのパラメータが一致する起動は自動的にあなたのCapacity Reservationで実行されます。これは魔法のように動作し、使いやすく効果的なため、約70%のお客様がこのオープン適格性を使用しています。残りの30%のお客様は「ターゲットインスタンス適格性」を使用しており、これによってアカウント内にプライベートプールを作成し、他のユーザーがアクセスできないようにすることができます。これにより、重要度の高いワークロードのみがキャパシティを使用できるように設定することができます。
予約のターゲティングには2つのアプローチがあり、一方が明らかに推奨されています。1つ目の方法は予約IDによるターゲティングで、インスタンスを起動する際に予約IDを指定します。Capacity Reservationにキャパシティがある場合、インスタンスは起動しますが、ない場合はインスタンスは起動せず、On-Demandにも移行しません。2つ目のアプローチはリソースグループIDによるターゲティングで、同様に機能しますが、リソースグループをターゲットにし、より柔軟にリソースグループ内外にものを移動できる点が異なります。
Capacity Blocksによる機械学習向けキャパシティ管理の革新
これらのアプローチを比較すると、Reservation IDによるターゲティングは少数のインスタンスに対する小規模な運用では上手く機能します。しかし、大規模に運用したい場合は、おそらくReservation Groupによるターゲティングを使用することをお勧めします。なぜなら、インスタンスの出し入れが可能で、キャパシティが不足した場合は自動的にOn-Demandでの実行にフォールバックするため、より柔軟な運用が可能だからです。 DaveがAttribute Based Instance Selection（ABIS）について説明しましたが、私はこれがCapacity Reservationとどのように連携するのかについてお話ししたいと思います。これは非常に強力なツールで、Auto Scaling Groupが最適な価格性能のインスタンスを自動的に選択することを可能にします。
嬉しいお知らせですが、先週、ASG Capacity Reservation Preferenceという新機能をリリースしました。これにより、ASGでキャパシティを実行し、ABISを使用してインスタンスを選択し、そのインスタンスを直接ODCRで実行することができます。利用可能な設定には2種類あります。1つ目は「Capacity Reservations Only」で、ASGはReservation内でインスタンスを起動しようとし、見つからない場合は何も起動しません。2つ目は「Capacity Reservations First」で、インスタンスを起動する際にまずCapacity Reservationでの起動を試み、キャパシティが利用できない場合はOn-Demandでの起動を試みます。
これにより、Capacity Reservationの効率が大幅に向上します。なぜなら、ABISは単に利用可能な任意のインスタンスや最も低コストなインスタンスを選択するだけでなく、あなたのCapacity Reservation内のインスタンスを選択するからです。Capacity Reservationの使用を忘れたり、未使用のキャパシティが残っていることを心配する必要はありません。ABISが自動的にそのキャパシティを見つけ、インスタンスを起動してくれます。
ODCRの最後の主要機能は、Capacity Reservation Sharingです。この機能を使用すると、Capacity ReservationをAWS Resource Access Manager（RAM）を通じて、組織全体や他のアカウントと共有することができます。デフォルトでは、Capacity Reservationを共有した場合、誰かがそれを使用すれば、その使用分は彼らが支払うことになります。誰も使用しない場合は、Reservationの所有者である私が支払うことになります。これがOn-Demand Capacity Reservations（ODCRs）の基本的な機能です。
私たちのイノベーションはまだ終わっていません。Zonal Reserved Instancesについて、お客様からより多くのコントロールと柔軟性を求める声が続いていました。これは今でもお客様が求めていることです - 大規模なキャパシティをより集中的に管理したいと考えています。お客様は、Reservationの管理、課金、メトリクスやダッシュボードの表示方法について、より多くのコントロールを求めていることがわかりました。
数週間前に発表された新機能についてご説明できることを嬉しく思います。 現在、ODCRのサイズ変更、分割、ODCR間でのキャパシティの移動、さらにはオープン構成とターゲット構成の切り替えが可能になりました。 これは、お客様がODCRをより簡単かつ効果的に管理できるようになる大きな進歩です。
お客様から要望の多かったもう一つの重要な機能は、請求の柔軟性でした。数週間前に、 別のアカウントに請求を割り当てる機能をリリースしました。例えば、私がDaveさんとODCRを共有する場合、そのODCRの請求をDaveさんに割り当てることができます。Daveさんが使用しない場合は、支払いの責任は彼にあります。第三のステップは承認です。相手の承認なしに、未使用のODCRを単純に転送することはできません。
これらをどのように統合するのでしょうか？大規模なお客様は、いくつかの理由から、一元的なキャパシティ管理モデルに移行する傾向にあります。第一に、すべてのキャパシティを一箇所で管理することで、より高い可視性が得られます。第二に、未使用のキャパシティをより効果的に制御でき、キャパシティ予約の削減やキャンセルをすぐに実行できます。第三に、どのアカウントがキャパシティを受け取るかをより細かく制御できます。あるアカウントで緊急事態が発生した場合、すぐにキャパシティを別のアカウントに移動できます。
これらの機能がリリースされる前は、問題がありました。サイズ100のODCRを複数のアカウントと共有した場合、各アカウントがODCRに完全にアクセスできてしまい、一つのアカウントが悪影響を及ぼしたり、過剰に消費したりする可能性がありました。現在は分割機能により、 ODCRを分割して個々のチームやサービスと共有できます。これにより、一元管理アカウントが キャパシティの配分をより簡単に制御できるようになりました。
Daveさんをアカウント2として考えてみましょう。Daveさんが一元的なキャパシティ管理者である私にODCRを要求した場合、私は彼のためにODCR Aを取得します。しかし、使用しない場合の支払い責任が私にあるため、Daveさんにはキャパシティ予約を効率的に使用するインセンティブがありませんでした。私が支払うか、全員でコストを分散するか、複雑な会計処理で彼にコストを再配分する必要がありました。現在は、請求所有権を割り当てる機能により、 中央アカウントとしてキャパシティを管理しながらも、使用しない場合の支払い責任はDaveさんにあると伝えることができます。これにより、Daveさんが効率的なキャパシティ使用を確実にするようインセンティブが整います。
Capacity Blocksの新機能とSageMakerとの統合
また、最近いくつかの新機能をリリースしました。 CloudWatchで、Capacity Reservationのメトリクスを表示・集計するためのより詳細な制御が可能になりました。個々のODCRを個別に確認する代わりに、インスタンスタイプやAvailability Zone全体、あるいはすべてのODCRを横断して集計できるようになりました。 EC2 Global Viewを通じて、ODCRのグローバルな視点での確認が可能です。各リージョンのエンドポイントを個別にチェックする必要がなくなり、すべてのODCRを一箇所で確認して、より迅速に意思決定を行うことができます。
しかし、これだけではありません。お客様からは、さらなる改善を求める声がありました。 私は以前、amazon.comのキャパシティプランニングに携わり、Prime DayやCyber Mondayを問題なく実施できるよう取り組んでいました。キャパシティプランニングは難しい課題であり、お客様からもこの問題の解決を求められていました。
なぜこれほど難しいのでしょうか？お客様は将来のイベントに向けたプランニングにおいて、ジレンマに直面します。早めに計画を立ててキャパシティを確保し、イベントに備える一方で、その早期確保のためのコストを支払うべきか？それとも、最後の瞬間までキャパシティの確保を待ち、希望通りのキャパシティが得られないリスクを取るべきか？キャパシティ自体は確保できるものの、必ずしも希望通りのものが得られない可能性があります。
そこで、先週Future-Dated ODCRsをリリースしたことを嬉しくお知らせします。 Future-Dated ODCRsを使用することで、最大120日前からCapacity Reservationを予約でき、開始日にEC2が確実にキャパシティを提供することを確信を持って期待できます。 通常のODCRと同様の設定に加えて、開始日を指定するだけです。また、キャパシティ提供後の2週間の利用コミットメントが必要です。設定後は、ステータスを監視して承認されたことを確認します。承認されれば、EC2が確実に提供することが分かり、あとは開始日にキャパシティが利用可能になるのを待つだけです。利用可能になり次第、簡単にインスタンスを起動できます。
これらの新機能について皆様にお話しできることを大変嬉しく思います。ここで、Capacity Blocksという別のキャパシティ製品についてお話しするため、Daveにバトンを渡したいと思います。 今日、Machine Learningを使用している方はどれくらいいらっしゃいますか？通常なら「この5秒間Machine Learningについて話していなかった」というジョークを言うところですが、今日はそれを始めましょう。Capacity Blocksは、Machine Learningインスタンスを利用する主要な方法の1つです。私がこれについて話し始めたとき、それは本当に生成AIのキャパシティへのアクセスを民主化する方法についてでした。
私たちが直面していた課題の1つは、これらが非常に人気があるということです。新発売のXbox Xを手に入れようとするような感じですね。私はゲーマーというか、子供たちと一緒にゲームをするのが言い訳なんですが。そういったシステムを手に入れようとすると、Webページを更新し続けて待たなければなりませんでした。Generative AIのキャパシティも同じような状況でした。そこで疑問となったのは、これをどうやって民主化するか、つまり誰もが使えるようにするかということです。そのために私たちはCapacity Blocksを構築しました。
今では、実際に必要な時間だけプロビジョニングすればよくなりました。これを開発したきっかけの1つは、Amazon社内でGenerative AIを使用している多くのチームが、実際には使用していないキャパシティを確保したままにしていたことです。私たちはCPU使用率などを確認して回っていました。これにより、キャパシティに対して過剰な支払いをする必要がなくなりました。ただし注意点として、その期間が終了すると、そのキャパシティは回収されます。
これは実験やテストを行い、プロビジョニングして実際に使ってみるのに最適なモデルです。 トレーニングにも最適です。トレーニングは通常1〜3ヶ月の期間で行われるからです。 また、その期間中は予約されたキャパシティとなり、好きなように使用できます。そのため、ローンチ直前であれば、潜在的に必要となる量以上をプロビジョニングすることも可能です。
セットアップする際には、P5、P4D、TRN1など、複数のインスタンスタイプをサポートしています。2のべき乗単位でプロビジョニングできます。これは機械学習の使用方法に起因しており、2のべき乗単位で必要となる傾向があるためです。最近まで、予約期間は1日から1ヶ月までで、複数の異なるオペレーティングシステムで利用可能でした。 この2週間以内に、私たちは多くの新機能をリリースしました。これらの目的は、Capacity Blocksの利点を維持しながら、よりOn-Demandに近い体験を提供することです。まず、お客様から聞いた声として、トレーニングワークロードの所要時間を見積もっていても、実際にはもっと長くかかることがあるということがありました。そこで、Capacity Block自体を延長できる機能を導入しました。また、Capacity Blockの期間を最大6ヶ月まで延長できるようにしました。
すでに1ヶ月のCapacity Blockのうち2週間を使用している場合でも、6ヶ月まで延長できるようになりました。また、OhioとTokyoリージョンにもCapacity Blocksを展開しました。以前は、フラグメンテーションを防ぐためにCapacity Blocksの取得に最大1日かかることがありましたが、現在は数分で利用可能になり、この1年間で見られたものよりもはるかにOn-Demandに近い体験となっています。
MattやPeterのキーノートをご覧になった方は、M2やUltraサーバーのトレーニングについて耳にされたかもしれません。これらのサーバーは最大83.2 FP8のPETAフロップスを提供し、推論とトレーニングの両方で素晴らしい性能を発揮します。これは、AWSが機械学習に関連する独自のシリコンを開発し続けているイノベーションを示しています。私たちは、これをベースに素晴らしい製品群を開発するため、最適化とパートナーとの協力を継続していきます。また、Trn2に関連するCapacity Blocksも提供していることは注目に値します。
トレーニングは、Capacity Blocksに関連する主要なワークロードの1つです。トレーニングを実行する方法の1つがSageMakerです。これは事前にお知らせできることですが、ちょうど発表しようとしているところです - というより、1時間ほど前に発表されたばかりです。SageMakerに関連するトレーニングプランについて、トレーニングワークロードの設定と必要な容量の予約を非常に簡単に行えるようにしたいと考えています。必要な容量を正確に指定し、そのトレーニングワークロードにかかるコストを理解し、SageMakerジョブに関連する他の設定をすべて1つのシームレスな統合ワークフローで設定できます。
複数のメリットがあり、大きく2つの領域に分かれます。1つ目はCapacity Blocks側で、予測可能なコンピュートへのアクセスを提供します。必要なトレーニングクラスターへのアクセスが得られ、事前にコストを把握できます。2つ目は、SageMakerとの深い統合です。適切な場所でのデータとコンピュートの調整、すべての適切なパラメータの設定など、多大な作業が必要です。これら2つを連携させることで、ジョブに関連して必要な容量をすべて1か所で確保できます。これにより、実行しようとしているトレーニングがはるかに容易になることを期待しています。
EC2 Spotの活用とキャパシティ管理の今後の展望
Capacity Blocksには多くのイノベーションが見られ、来年も引き続き注力していく分野だと考えています。では次に、EC2 Spotについてお話ししましょう。冒頭で触れたように - そしてBrianはこのアイコンが大好きで、なぜ画面にタイヤがあるのかと聞いてきました。Spotは予備容量に関するもので、オンデマンド価格から最大90%オフという大幅な割引を受けることができます。ただし、通知後に容量が回収される可能性があるというトレードオフがあります。
Spot価格に注目していない方のために補足すると、この1年で大幅な価格下落がありました。私たちは、これらの価格をさらに下げる方法を検討し続けており、Spotの活用をより魅力的なものにしています。Spotには適している多くのワークロードがありますが、すべてのワークロードがSpotに適しているわけではありません。何年も前のことですが、本番環境のデータベースにSpotを使用しているお客様と話をしたことがありました - これは絶対にお勧めできません。Spotは突然利用できなくなる可能性があり、適切に設定していないとデータを失う可能性があります。しかし、後で一時停止して再開できるバッチジョブのような非同期の中断可能なワークロードがある場合は、これは理想的です。2つ目は、スケールアウト型のワークロードです。従来であれば、5年間ずっと1つのインスタンスを実行し続けていたかもしれません。
その代わりに、大規模な並列処理により、余剰キャパシティを活用して短時間で処理を実行することができます。私が聞いた素晴らしいユースケースの一つは、がん研究を行っているお客様の例です。以前は少数のインスタンスでの研究に約5年かかり、オンプレミスのセットアップだけで数百万ドルのコストがかかっていました。Spot instancesを使用することで、未使用の余剰キャパシティを最大限に活用し、大幅なコスト削減と共に研究期間を5年から約2日間に短縮することができました。その結果、1つではなく複数の薬剤化合物を発見することができたのです。適切なユースケースを見つけることができれば、このような技術によって作業を大幅に加速することができます。
最後に、私が「タイムシフトワークロード」と呼んでいるものについてお話しします。このSpotに関する話で一つだけ覚えておいていただきたいのは、これは私たちの余剰キャパシティだということです。多くの組織と同様に、私たちには9時から17時の間に実行されるワークロードが多くあります。17時から翌朝9時の間は、より多くのキャパシティがあり、Spotを使用する際に2つの重要な意味を持ちます。1つ目は、オフピーク時の中断が5分の1のレベルになることです。2つ目は、オフピーク時にはプールによって10-20%のさらなる追加の節約が見込めることです。タイムシフトワークロード、つまりその地域やロケーションで実行する必要があるワークロードがある場合、夜間に実行できるのであれば素晴らしいことです。多くの場合、夜間にバッチワークロードを実行したり、実行を夜間まで遅らせたりします。
これは現地時間に基づいているため、米国で実行していて地理的な制約にこだわらない場合は、例えば東京で実行することもできます。この機会を活用できる時間帯があるのです。私は長い間Spotに携わってきましたが、これほどまでに成長したことは驚くべきことです。しかし、これは革新の余地が大いにある分野の一つであり、皆さんにとって本当に素晴らしい機会だと思います。
さて、Spotのアーキテクチャに関して、これまでの年月をかけて、Spotをより使いやすくするための多くの機能を開発してきました。まず第一に、中断する前に通知を行うため、必要なワークフロー、ジョブ、またはスクリプトを実行することができます。第二に、再開に必要なデータを確実に保持するためのチェックポイントがあります。ステートレスアプリケーションも非常にうまく機能します。Spotの初期の頃は、インスタンスを強制終了していたため、ほとんどの人がステートレスアプリケーションを実行していました。しかし、その後、中断動作を導入し、インスタンスの停止または休止を可能にしたことで、ローカルディスク上のすべてのデータを保持できるようになり、休止機能によってメモリの扱いもより柔軟になりました。
Spotを使用する際、アーキテクチャを適切に設計することは重要ですが、テストしなければ本当に準備ができているかどうかはわかりません。そのため、AWS Fault Injection Simulatorを使用することで、実際にSpotの中断をテストし、アーキテクチャが適切に機能するかどうかを確認することができます。Spotを使用する際、多くのユースケースは未使用のキャパシティへのバーストに焦点を当てています。最初に話した柔軟性は非常に重要です。なぜなら、異なるプール間でより多くのリソースを使用できるほど、より多くバーストでき、より速く移動できるからです。私たちはSpot Placement Scoreというものを提供しており、これは各プールにどれだけのキャパシティがあるかを示します。これは絶対的な指標ではなく相対的な指標ですが、どこでインスタンスを起動すべきかの目安を提供します。次に、Attribute Based Instance Selection（ABIS）を使用できます。そして最後に、起動可能なインスタンスを指定することができます。ABISでは、Fleetを使用できます - FleetはSpotと連携して動作し、実際にはもともとSpot向けに設計されましたが、その後、一般的にも有用であることがわかりました。
本日は多くの内容をカバーしました。 このプレゼンテーションから覚えていただきたい重要なポイントをお伝えします。まず、様々な利用モデルが存在するということです。私たちは可用性とコストのバランスを取るために、これらの分野で革新を続けています。これは皆様との協力が不可欠な分野の一つであり、お客様とのミーティングでいただくフィードバックは、私たちが提供するサービスを改善する上で重要な要素となっています。Reserved Instancesから始まり、On-Demand Capacity ReservationsやSavings Plansへと進化してきました。キャパシティ管理を成功させるためのレバーとプリミティブを皆様に提供したいと考えているため、この分野での革新を続けています。
二つ目のポイントは、これらのレバーに注目することです。 Savings Plansを活用し、ワークロードに応じて柔軟性を調整する方法を検討してください。また、Cost Optimizerなどの他のツールも、保有するキャパシティを最も効果的に使用するために活用できます。そして最後に、私たちが提供するキャパシティ管理ツールについての継続的な革新についてです。この分野は来年も引き続き注力していく予定ですので、今後の展開にご期待ください。
今後のCapacity Reservationsや、Capacity Blocksなどへの投資について考える際、これらの管理が複雑で手間のかかるものではなく、必要な作業が簡単に行えるようにすることを重視しています。もしこのトピックに興味をお持ちでしたら、明日午後2時からOn-Demand Capacity Reservationsについての別のセッションが予定されています。
以上で本日のセッションを終了させていただきます。質問がございましたら、Brianと私が前方でお待ちしております。アンケートへのご協力をお願いいたします。皆様からのフィードバックは、今後のプレゼンテーションをより効果的なものにするために、私たちは真摯に受け止めています。ご参加いただき、ありがとうございました。素晴らしい一日を、そして素晴らしいイベントをお過ごしください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion