EC2 スポットを利用するうえでのベストプラクティス

Amazon EC2 スポットインスタンス は、AWS クラウド クラウドに用意された予備の EC2 コンピューティング性能であり、オンデマンド料金に比べて最大 90% の節約が可能です。オンデマンドインスタンス と スポットインスタンス の唯一の違いは、 Amazon EC2 が容量を必要とするときに、Amazon EC2 が スポットインスタンス を中断できることです。この中断の際には、2 分前に通知があります。

スポットインスタンス は、ステートレスかつフォールトトレラントで、柔軟性の高いアプリケーションに適しています。例えば、 スポットインスタンス はビッグデータ、コンテナ化されたワークロード、CI/CD、ステートレスウェブサーバー、ハイパフォーマンスコンピューティング (HPC)、レンダリングワークロードに適しています。

実行中、 スポットインスタンス は オンデマンドインスタンス とまったく同じ動作をします。ただし、スポットは、ワークロードが完了するまで十分な期間、実行中のインスタンスが動作し続けることを保証するものではありません。また、スポットは必要としているインスタンスをすぐに取得できること、またはリクエストした総容量がいつでも取得できることを保証するものではありません。さらに、スポットインスタンスの可用性は需要と供給によって変化し、将来のパフォーマンスが過去の実績により保証されるものではないため、スポットインスタンスの容量や発生する中断は、時間の経過とともに変化する可能性があります。

スポットインスタンス は、柔軟性がない、ステートフル、フォールトイントレラント、またはインスタンスノード間で緊密に結合されているワークロードには適していません。また、ターゲットキャパシティが完全に使用できない期間が時折あることが許容されないワークロードには、スポットインスタンスは推奨されません。スポットのベストプラクティスに従ってインスタンスタイプとアベイラビリティーゾーンに柔軟性を持たせることで、高可用性を実現できますが、オンデマンドインスタンスの需要が急増するとスポットインスタンスのワークロードが中断される可能性があるため、容量が使用可能になる保証はありません。

こうしたワークロードにスポットインスタンスを使用したり、中断や停止期間を処理するためにオンデマンドインスタンスへのフェールオーバーを試みたりしないよう、強く勧告します。オンデマンドインスタンスにフェイルオーバーすると、他のスポットインスタンスの中断が誤って発生する可能性があります。さらに、インスタンスタイプとアベイラビリティーゾーンの組み合わせのスポットインスタンスが中断された場合、同じ組み合わせでオンデマンドインスタンスを取得することが困難になる可能性があります。

スポットの使用に慣れている場合でも、スポットインスタンスを使い始めたばかりの場合でも、スポットインスタンスの中断や可用性に関する問題が発生している場合には、スポットサービスを最大限に活用できるよう、これらのベストプラクティスに従うことをお勧めします。

中断に備えて個々のインスタンスを準備する

スポットインスタンスの中断を適切に処理する最善の方法は、耐障害性のあるアプリケーションを設計することです。これを実現するためには、EC2 インスタンスの再調整に関する推奨事項、ならびにスポットインスタンスの中断通知を利用できます。

EC2 インスタンスの再調整に関するレコメンデーションは、スポットインスタンスで中断のリスクが高まった場合に通知するためのシグナルです。ユーザーは、このシグナルにより、スポットインスタンスの中断 2 分前の通知が届いていない段階で、事前にスポットインスタンスの管理を行えます。ワークロードを、中断のリスクが高くない新規または既存の スポットインスタンス に再調整することができます。このシグナルは、Auto Scaling グループと EC2 フリートの容量の再分散機能を使うことで簡単に利用できます。

スポットインスタンスの中断通知は、Amazon EC2 がスポットインスタンスを中断する 2 分前に発行される警告です。ワークロードに時間の面での柔軟性がある場合は、中断が発生した際にそれを終了するのではなく、停止または休止状態になるようにスポットインスタンスを設定することができます。Amazon EC2 は、中断が発生したスポットインスタンスを自動的に停止または休止状態にし、使用可能な容量が確保できた際にはそのインスタンスを自動的に再開します。

再調整に関する推奨事項と中断通知をキャプチャし、ワークロードの進行状況のチェックポイントをトリガーするか、中断を適切に処理するルールを Amazon EventBridge で作成することをお勧めします。詳細については、再調整に関する推奨事項シグナルのモニタリング を参照してください。イベントルールの作成および使用方法の詳細な例については、「Taking Advantage of Amazon EC2 スポットインスタンスInterruption Notices」を参照してください。

詳細については、「EC2 インスタンスの再調整に関する推奨事項」および「スポットインスタンスの中断。」を参照してください。

インスタンスタイプとアベイラビリティーゾーンについて柔軟に対応する

スポットキャパシティープールは、同じインスタンスタイプ (m5.large など) とアベイラビリティーゾーン (us-east-1a など) を持つ、未使用の EC2 インスタンスのセットです。どのインスタンスタイプをリクエストし、どのアベイラビリティーゾーンでワークロードをデプロイするか柔軟に対応することで、スポットが必要な量のコンピューティング性能を見つけ、割り当てられる可能性が高くなります。例えば、c4、m5、m4 ファミリのラージを使用してもよいのであれば、 c5.large を指定する必要はないということです。

具体的なニーズに応じて、コンピューティング要件を満たすためにどのインスタンスタイプを使用できるか評価できます。ワークロードを垂直にスケーリングできる場合は、より大きいインスタンスタイプ (vCPU とメモリが多い) をリクエストに含めてください。水平にしかスケーリングできない場合は、オンデマンドの顧客からの需要が少ない、旧世代のインスタンスタイプを含めることをお勧めします。

一般的に、ワークロードごとに少なくとも 10 種類のインスタンスタイプに柔軟に対応できれば十分です。さらに、すべてのアベイラビリティーゾーンが VPC で使用するように設定され、ワークロード用に選択されていることを確認してください。

EC2 Auto Scaling グループまたは EC2 フリートを使用して総容量を管理する

スポットを使用すると、個々のインスタンスの観点からではなく、総容量 (vCPUs、メモリ、ストレージ、またはネットワークスループットなどの単位) の観点から検討することが可能になります。Auto Scaling グループと EC2 フリートは、ターゲットキャパシティの起動および維持のために使用できます。これにより、中断されたり手動で終了されたりしたリソースを置き換えるリソースを自動的に要求できます。Auto Scaling グループまたは EC2 フリートを設定する際には、アプリケーションのニーズに基づいてインスタンスタイプとターゲットキャパシティを指定するだけで済みます。詳細については、Amazon EC2 Auto Scaling ユーザーガイド の Auto Scaling グループおよびこのユーザーガイドの EC2 フリートの作成 をご参照ください。

価格と容量を最適化する配分戦略を使用する

Auto Scaling グループの配分戦略を使えば、予備容量を持つスポットキャパシティープールを手動で探す必要なく、ターゲット容量をプロビジョニングできます。最も安い価格で最も利用性の高いスポットキャパシティープールからインスタンスが自動的にプロビジョニングされる、price-capacity-optimized 戦略を使用することをお勧めします。また、EC2 フリートの price-capacity-optimized 配分戦略も活用できます。最適な容量を持つプールからスポットインスタンス容量が供給されるため、使用しているスポットインスタンスが再要求される可能性は低くなります。配分戦略の詳細については、このユーザーガイドの「ワークロードの中断コストが高い場合」および Amazon EC2 Auto Scaling ユーザーガイドの「スポットインスタンス」を参照してください。

統合された AWS のサービスを使用して スポットインスタンス を管理する

他の AWS のサービスは、個々のインスタンスやフリートを管理する必要なく、全体的なコンピューティングコストを削減できるよう、スポットと統合されています。該当するワークロードの場合、Amazon EMR、Amazon Elastic Container Service、AWS Batch、Amazon Elastic Kubernetes Service、Amazon SageMaker、AWS Elastic Beanstalk、Amazon GameLift の各ソリューションを検討することをお勧めします。これらのサービスでのスポットベストプラクティスの詳細については、Amazon EC2 スポットインスタンス Workshops Website を参照してください。

使用すべき最適なスポットリクエスト方法はどれですか?

次の表を使用して、スポットインスタンスをリクエストする際に使用する API を決定します。

API	どのようなときに使うか?	ユースケース	この API を使うべきか?
CreateAutoScalingGroup	単一の構成または混合の構成を持つ、複数のインスタンスが必要です。 構成可能な API を使用してライフサイクル管理を自動化するのがよいでしょう。	必要な数のインスタンスを維持しながら、インスタンスのライフサイクルを管理する Auto Scaling グループを作成します。指定した最小値と最大限度の間の水平スケーリング (インスタンスの追加) をサポートします。	はい
CreateFleet	単一の構成または混合の構成を持つ、複数のインスタンスが必要です。 インスタンスのライフサイクルを自己管理するのがよいでしょう。 オートスケーリングが必要ない場合は、instant タイプフリートの使用をお勧めします。	インスタンスタイプ別、AMI 別、アベイラビリティーゾーン別、またはサブネット別で異なる、複数の起動条件を指定し、オンデマンドインスタンスとスポットインスタンス両方のフリートを 1 回のリクエストで作成します。スポットインスタンスの割り当てストラテジーのデフォルトは、ユニットあたりの lowest-price ですが、price-capacity-optimized、capacity-optimized または diversified に変更可能です。	はい - オートスケーリングを必要としない場合は instant モード。
RunInstances	既に RunInstances API を使用してオンデマンドインスタンスを起動しているので、単一のパラメータを変更することで、スポットインスタンスの起動に変更するとよいでしょう。 異なるインスタンスタイプを持つ複数のインスタンスは、必要ありません。	AMI と 1 つのインスタンスタイプを使用して、指定した数のインスタンスを起動します。	いいえ - RunInstances は、1 回のリクエストで複数のインスタンスタイプを許可しないため。
RequestSpotFleet	RequestSpotFleet API は計画投資のないレガシー API であるため、使用はお勧めしません。 インスタンスのライフサイクルを管理する場合は、CreateFleet API を使用します。 インスタンスのライフサイクルを管理したくない場合は、CreateAutoScalingGroup API を使用します。	使用しません。RequestSpotFleet は、計画投資のないレガシー API です。	いいえ
RequestSpotInstances	RequestSpotInstances API は計画投資のないレガシー API であるため、使用はお勧めしません。	使用しません。RequestSpotInstances は、計画投資のないレガシー API です。	いいえ