Amazon EKS で EC2 スポットインスタンスを使用する際のベストプラクティスにはどのようなものがありますか?

簡単な説明

Amazon EKS で Amazon EC2 スポットインスタンスを使用する際のベストプラクティスを以下に示します。

• 長時間実行されるジョブやステートフルなアプリケーションにはスポットインスタンスを使用しないでください。
• スポットインスタンスでマネージドノードグループを使用する。
• 複数のインスタンスタイプをノードグループに追加します。
• AWS ノード終了ハンドラー (NTH) をセルフマネージドノードグループに使用します。

解決方法

長時間実行されるジョブやステートフルなアプリケーションにはスポットインスタンスを使用しない

スポットインスタンスの寿命が短いと、長時間実行されるジョブで望ましくない終了が発生する可能性があります。ステートフルアプリケーションはシャットダウンを許容できないため、ステートフルアプリケーションにも影響する可能性があります。代わりに、長時間実行されるジョブにはオンデマンドインスタンスを使用してください。

スポットインスタンスでマネージドノードグループを使用する

管理対象ノードグループのキャパシティタイプをスポットとして設定できます。次に、マネージドノードグループは、EC2 Auto Scaling キャパシティリバランスを使用するように Auto Scaling グループを設定します。EC2 Auto Scaling キャパシティリバランスがアクティブ化され、スポットノードがリバランスの推奨を受け取ると、Amazon EKS はスポットノードの置き換えを試みます。

新しいスポットノードの準備が整うと、Amazon EKS は以前のスポットノードを分離してドレインします。これにより、Amazon Elastic Block Store (Amazon EBS) ボリュームが破損したり、データベース接続が中断されたりするリスクを軽減できます。

複数のインスタンスタイプをノードグループに追加する

すべてのスポットインスタンスプールは、特定のアベイラビリティーゾーンの特定のインスタンスタイプに対する未使用の EC2 インスタンス容量で構成されます。ノードグループが新しいノードをプロビジョニングしようとすると、ノードグループはその設定に定義されているインスタンスタイプの 1 つを使用します。どのアベイラビリティーゾーンにもインスタンスタイプにスポットキャパシティーがない場合、ノードグループはスケーリングに失敗し、低下します。

この問題を回避するには、ノードグループ内の類似するインスタンスタイプの数を増やしてください。

たとえば、インスタンスタイプが m5.large (2 vCPU/8 GiB RAM) であるとします。m5a.large、m5n.large、m4.large など、vCPU と RAM の値が同じインスタンスを追加します。

セルフマネージドノードグループには AWS NTH を使用する

GitHub ウェブサイトにある AWS ノード終了ハンドラー (NTH) は、デプロイまたは DaemonSet として Amazon EKS クラスターにデプロイされます。NTH は、セルフマネージドノードグループにはない機能を追加します。ハンドラーは、Amazon EC2 メンテナンスイベント、スポット中断通知、Auto Scaling グループのスケールインイベント、およびアベイラビリティーゾーンのリバランスを検出し、適切に対応するのに役立ちます。[Queue Processor] オプションを使用して、すべての NTH 機能をセルフマネージドノードグループに追加します。

Karpenter を使用してスポットインスタンスを管理する

Karpenter は、スケジュールできないポッドに対応して新しいノードを自動的にプロビジョニングするオープンソースのクラスターオートスケーラです。Karpenter には、ノードをスケールインおよび統合して無駄とコストを削減する機能もあります。EC2 インスタンスのプロビジョニングには、容量を最適化して優先順位を付けた割り当て戦略を使用します。

Karpenter は、Amazon EKS クラスターの AWS リージョンとアベイラビリティーゾーンで利用可能なすべての EC2 インスタンスタイプを使用してスポットインスタンスを最適化します。Karpenter を EC2 インスタンスセレクターツールと組み合わせて使用すると、特定のコンピューティング要件に一致するインスタンスタイプのリストを生成できます。さまざまなインスタンスタイプを使用することで、容量不足によるエラーのリスクを軽減できます。また、インスタンスをさまざまなアベイラビリティーゾーンに分散させてさまざまなスポットプールを使用することもベストプラクティスです。

Karpenter のベストプラクティスと制限の詳細については、GitHub の「Karpenter のベストプラクティス」を参照してください。

重要: 現在のところ、Karpenter には、スポット中断終了通知 (ITN) の 2 分間隔警告を処理する機能がありません。これに対処するため、NTH を設置することで、スポットノードが中断されたときに正常にコードンおよびドレインすることができます。

---