Amazon Web Services ブログ
新機能 — EC2 Auto Scaling と EC2 フリートの属性ベースのインスタンスタイプの選択
10 年以上前に私が最初に使用した AWS のサービスは、 Amazon Elastic Compute Cloud (Amazon EC2) でした。時間が経つにつれて、EC2 はさまざまなユースケースに合わせて最適化されたインスタンスタイプを幅広く追加しました。CPU/GPU、メモリ、ストレージ、ネットワーク容量のさまざまな組み合わせにより、アプリケーションに適したリソースの組み合わせを柔軟に選択できます。
クラウドの主な利点の 1 つは伸縮性です。EC2 フリートを使用すると、オンデマンド、リザーブド、スポットインスタンスを一緒に使用して、複数のインスタンスタイプと購入オプションにわたって容量を同期的にリクエストし、複数のアベイラビリティーゾーンでインスタンスを起動できます。Amazon EC2 Auto Scaling を使用すると、定義した条件に応じて EC2 インスタンスを自動的に追加または削除し、ウォームプール、インスタンスの更新、ヘルスチェックなどの高度なインスタンス管理機能を追加できます。これらのツールでは、最新の EC2 インスタンスを活用するために、設定を手動で更新する必要があります。また、EC2 スポットインスタンスを使用してコストを最適化する場合、最大のスポット容量にアクセスするために複数のインスタンスタイプを選択することが重要です。これまでは、インスタンスタイプの設定を柔軟に構築して維持する簡単な方法はありませんでした。
2021 年 10 月 27 日、属性ベースのインスタンスタイプ選択 (ABS) を導入することをお知らせします。ABS は、インスタンス要件を vCPU、メモリ、ストレージなどの属性のセットとして表現できる新機能です。要件は ABS によって一致するすべてのインスタンスタイプに変換され、インスタンスタイプ設定の作成とメンテナンスが簡素化されます。これにより、新しい世代のインスタンスタイプがリリースされたときに自動的に使用され、EC2 スポットインスタンスを介してより広い範囲の容量にアクセスできるようになります。EC2 フリートと EC2 Auto Scaling は、指定された属性に適合するインスタンスを選択して起動するため、インスタンスタイプを手動で選択する必要がなくなります。
ABS は、コンテナーや ウェブフリートの実行、ビッグデータの処理、継続的インテグレーションとデプロイ (CI/CD) ツールの実装など、柔軟なワークロードとフレームワークに最適です。スポットインスタンスを使用する場合、数十のインスタンスタイプとサイズを選択して入力する代わりに、単純な属性設定を使用してすべてをカバーし、新しいインスタンスが出てくるときに含めることができるようになりました。
属性ベースのインスタンスタイプ選択の仕組み
ABS では、インスタンスタイプのリストをインスタンス要件に置き換えます。インスタンス要件は、起動テンプレート内、あるいは EC2 フリートまたは EC2 Auto Scaling リクエストで、起動テンプレートのオーバーライドとして指定できます。
ABS は 2 つのステップで動作します。
- まず、ABS は、指定された属性、AWS リージョン、アベイラビリティーゾーン、および価格に基づいてインスタンスタイプのリストを決定します。
- 次に、EC2 Auto Scaling または EC2 フリートは、選択した配分戦略をこのリストに適用します。
スポットインスタンスの場合、ABS は容量最適化および最低価格の配分戦略をサポートします。
オンデマンドインスタンスの場合、ABS は最低価格の配分戦略をサポートします。EC2 Auto Scaling または EC2 フリートは ABS 属性をインスタンスタイプのリストに転換させ、容量要求のオンデマンド部分を満たすために最低価格のインスタンスを最初に起動し、必要に応じて次に価格の低いインスタンスに移動します。
デフォルトでは、ABSは価格保護を有効にして、支出をコントロールします。価格保護により、ABS は、選択した属性にたまたま適合するインスタンスタイプであっても、過度に高価なインスタンスタイプのプロビジョニングを回避し、プロビジョニングされたインスタンスの価格を特定の境界内に維持します。価格保護を有効にすると、ABS は、価格が価格保護のしきい値を上回るインスタンスタイプを選択しません。スポットインスタンスとオンデマンドインスタンスには 2 つの異なるしきい値があり、オプションでカスタマイズできます。
ABSが実際にどのように機能するかを、いくつかの例で見てみましょう。
EC2 Auto Scaling での属性ベースのインスタンスタイプの選択の使用
AWS コマンドラインインターフェイス（CLI）を --generate-cli-skeleton パラメータとともに使用して、CreateAutoScalingGroup API で受け入れられるすべてのパラメータを含む YAML 形式のファイルを生成します。
YAML ファイルには、起動テンプレートの設定をオーバーライドするために使用できる新しい instanceRequriments セクションがあります。これらはすべて、いくつかのサンプル値で選択できる属性です。
InstanceRequirements:
VCpuCount: # [REQUIRED]
Min: 0
Max: 0
MemoryMiB: # [REQUIRED]
Min: 0
Max: 0
CpuManufacturers:
- amd
MemoryGiBPerVCpu:
Min: 0.0
Max: 0.0
ExcludedInstanceTypes:
- ''
InstanceGenerations:
- previous
SpotMaxPricePercentageOverLowestPrice: 0
OnDemandMaxPricePercentageOverLowestPrice: 0
BareMetal: 必須 # 有効な値は、含まれる、除外される、必須です。
BurstablePerformance: 除外 # 有効な値は、含まれる、除外される、必須です。
RequireHibernateSupport: true
NetworkInterfaceCount:
Min: 0
Max: 0
localStorage: 必須 # 有効な値は、含まれる、除外される、必須です。
LocalStorageTypes:
-ssd
TotalLocalStorageGB:
Min: 0.0
Max: 0.0
BaselineEbsBandwidthMbps:
Min: 0
Max: 0
AcceleratorTypes:
- inference
AcceleratorCount:
Min: 0
Max: 0
AcceleratorManufacturers:
- amazon-web-services
AcceleratorNames:
-a100
AcceleratorTotalMemoryMiB:
Min: 0
Max: 0オーバーライドのリストを提供し、それぞれが単一のインスタンスタイプを選択した InstanceType 属性を持つ代わりに、要件に基づいてインスタンスタイプを選択できるようになりました。vCPUs の最小量と最大量、およびメモリの範囲を指定できます。オプションで、vCPUs ごとに最低限のメモリ容量を要求できます。
選択できる属性は他にもたくさんあります。たとえば、ベアメタルインスタンスまたはバースタブルインスタンスの使用を含める、除外する、または要求することができます。ネットワーク要件またはストレージ要件を追加できます。必要に応じて GPU とか FPGA アクセラレーターなどを要求できます。
この場合、2 つから 4 つの vCPUs と少なくとも 2048 MiB のメモリを持つインスタンスを要求します。以前は、これらの要件を満たすインスタンスタイプごとに 1 つずつ、約 40 のオーバーライドが必要でしたが、ABS では、instanceRequiments セクションで 3 つのパラメータを指定するだけで済みます。これは、Auto Scaling グループの作成に使用する完全な設定ファイルです。
Auto Scaling グループを作成し、 --cli-input-yaml パラメータで設定ファイルを渡します。
数分後、4 つの EC2 インスタンス (自分の DesiredCapacity に対応する) が EC2 コンソールで実行されています。リストには、C3 と C5a の両方のインスタンスがあり、時間と CPU メーカーの両方にまたがっています。
これらのインスタンスのうち、50% はオンデマンドです ([InstancesDistribution] セクションの [onDemandPercentageAboveBaseCapacity] オプションに基づく)。EC2 コンソールの [Spot Request] タブに、2 つのリクエストが表示されます。
予想通り、すべてのインスタンスタイプは私の要件に従い、サイズは大きくなります。しかし、アプリケーションには各インスタンスでより多くのコンピューティング性能が必要であることをすぐに認識します。Auto Scaling グループを新しい要件で更新し、追加の vCPUs (4～6) 個を要求します。
次に、Auto Scaling グループのインスタンスの更新を開始します。
EC2 Auto Scaling は、新しい要件に基づいてインスタンスのローリング置換を実行します。数分後、すべてのインスタンスはサイズが xlarge の新しいインスタンスに置き換えられ、C5、C5a、M3 のインスタンスが混在して実行されています。以前のインスタンスはすべて終了しました。
前と同様に、新しいインスタンスのうち 2 つはスポットリクエストを使用して起動されます。以前のスポットリクエストはクローズされています。
一致するインスタンスを起動せずにプレビューする方法
新しい ABS の仕組みをよりよく理解するために、新しい EC2 GetInstanceTypesFroMInstanceRequiments API を使用します。この API は、要件に一致するインスタンスタイプのリストを返します。
まず、YAML パラメータファイルを作成します。
Auto Scaling グループの更新に使用したのと同じ要件でファイルを編集します。今回は、現行世代のインスタンスも使用するように依頼します。
ArchitectureTypes: # [REQUIRED]
-x86_64
VirtualizationTypes: # [REQUIRED]
-hvm
InstanceRequirements: # [REQUIRED]
VCpuCount:
Min: 4
Max: 6
MemoryMiB:
Min: 2048
InstanceGenerations:
- currentここでアーキテクチャの種類 (x86_64) と仮想化 (hvm) を指定しなければならなかったことに注意してください。Auto Scaling グループの作成時に、この情報は、起動テンプレートで使用される Amazon マシンイメージ (AMI) によって提供されました。
では、次の要件によって選択されたすべてのインスタンスタイプをプレビューしてみましょう。
この新しい EC2 API を使用して、さまざまな要件をすばやくテストし、インスタンスタイプにマッピングする方法を確認できます。新しいインスタンスタイプがリリースされた場合、要件に合致すると自動的にリストに追加されます。
利用可能なリージョンと料金
現在、 EC2 Auto Scaling と EC2 フリートで、属性ベースのインスタンスタイプの選択 (ABS) をすべてのパブリックリージョンと GovCloud AWS リージョンで使用できます。ただし、より多くの時間が必要な中国に拠点を置くリージョンを除きます。AWS コマンドラインインターフェイス (CLI)、AWS SDK、 AWS マネジメントコンソール、およびAWS CloudFormationを使用して ABS を設定できます。ABS の使用には追加料金はかかりません。プロビジョニングされたインスタンスの標準の EC2 料金のみをお支払いいただきます。価格保護の詳細については、EC2 Auto Scaling のドキュメントを参照してください。
この新機能により、インスタンスタイプの長いリストではなく、柔軟なインスタンスタイプ設定を簡単に使用できます。このようにして、新しい世代のインスタンスタイプがリージョンでリリースされたときに自動的に使用できます。また、スポットリクエストでより多くの容量に簡単にアクセスできます。
属性ベースのインスタンスタイプの選択により、EC2 インスタンスタイプの設定を簡素化します。
– Danilo
原文はこちらです。