**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# EKS オートモードでのコスト最適化
EKS オートモードでは、統合、ビンパッキング、適切なサイジングを通じてクラスターのコンピューティングコストが継続的に最適化されます。ただし、特定のワークロード設定では、これらの最適化を妨げられる場合があります。このトピックでは、コスト最適化の仕組み、コスト最適化を妨げるもの、コスト効率を維持するためにクラスターを設定する方法について説明します。
## EKS オートモードによるコストの最適化方法
EKS オートモードでは、次のメカニズムを通じてコンピューティングコストが削減されます。
+ **ビンパッキング** — ポッドをノードにスケジューリングする場合、EKS オートモードによって集約リソースリクエストに厳密に一致するインスタンスタイプが選択され、未使用のキャパシティが最小限に抑えられます。
+ **統合** — EKS オートモードによって実行中のノードが定期的に評価され、ワークロードをより少ないインスタンスまたはより低コストなインスタンスで実行できる場合、ノードが置き換えられるか削除されます。
+ **適切なサイジング** — ワークロードがスケールダウンすると、EKS オートモードによってポッドが小さなノードに統合され、使用率の低いインスタンスが終了されます。
これらの最適化は、手動操作なしで継続的に実行されます。ただし、特定のポッドアノテーションと NodePool 設定により、統合の有効化が妨げられる場合があります。
## 組み込みノードプールとコストガードレール
組み込みの `general-purpose` ノードプールと `system` ノードプールでは、既にいくつかのコスト保護のためのデフォルトが適用されています。
+ **C、M、R に制限されたインスタンスファミリー** — 高速 (P、G、Inf、Trn) またはエキゾチックのインスタンスタイプは許可されません。
+ **オンデマンドキャパシティのみ** — スポットインスタンスは使用されません。これにより、中断によるチャーンは回避されますが、スポット節約も行われません。
+ **世代 5 以降** — 古い、コスト効率の低いインスタンス世代は除外されます。
組み込みノードプールのみを使用している場合は、既にこれらのガードレールによるメリットを得ています。[インスタンスファミリーの除外](#_exclude_instance_families_for_cost_control)と[インスタンスサイズの制約](#_constrain_instance_sizes)に関するこのトピックのガイダンスは、これらの制限を継承しない**カスタム NodePool** を作成するときに最も関連します。
ただし、組み込みノードプールでも、以下のセクションは適用されます。
+ [統合を防ぐもの](#_what_blocks_consolidation) — `do-not-disrupt` 注釈と制限付き PDB により、ノードをプロビジョニングした NodePool に関係なく、統合がブロックされます。
+ [NodePool の制限をコスト上限として使用する](#_use_nodepool_limits_as_a_cost_ceiling) — 組み込みノードプールにはリソースの `limits` が設定されていません。ワークロードを大幅にスケールできる場合は、無制限の組み込みプールに依存するのではなく、制限付きのカスタム NodePool を作成することを検討してください。
+ [ノードのライフサイクルとコスト](#_node_lifecycle_and_cost) — ノード置換の重複は、組み込みプールによってプロビジョニングされるノードを含むすべてのノードに適用されます。
| ガードレール | 組み込みノードプール | カスタム NodePool |
| --- | --- | --- |
| 高速インスタンスの除外 | 強制 | 設定が必要 |
| インスタンスサイズの制限 | 未設定 | 設定が必要 |
| リソースの `limits` (CPU/メモリの上限) | 未設定 | 設定が必要 |
| オンデマンドのみ | 強制 | (スポット/オンデマンド) を選択 |
| 統合防止 (`do-not-disrupt`/PDB) | お客様の責任 | お客様の責任 |
## 統合を防ぐもの
ノードの中断がワークロードの可用性要件に違反すると EKS オートモードで判断されると、統合が防がれます。次の設定では、統合が妨げられます。
### `do-not-disrupt` 注釈
`karpenter.sh/do-not-disrupt` 注釈により、ノードで注釈付きポッドが実行されている限り、ノードを保持するように EKS オートモードに指示されます。これにより、ノードが十分に活用されていなくても、ノードが統合、置換、または終了されるのを防ぎきます。
```
metadata:
annotations:
karpenter.sh/do-not-disrupt: "true"
```
**重要**
**コストへの影響**: ポッドに `do-not-disrupt` 注釈がある場合、そのポッドが実行されるノードは統合から除外されます。つまり、次のようになります。
ノードは、実際の使用率に関係なく、現在のインスタンスサイズで引き続き実行されます。
ワークロードの需要が減少しても、そのノードの vCPU とメモリの使用量が高止まりすることがあります。
多くのノードにまたがる複数のポッドにこの注釈がある場合、クラスター全体の統合が大幅に削減され、コストが持続的に高くなります。
`do-not-disrupt` 注釈は可用性メカニズムです。コストは考慮されません。チェックポイントなしで長時間実行されるバッチジョブやステートフルプロセスなど、実行中の中断によってデータ損失や大幅な再作業が発生するワークロードにのみ使用してください。
**考慮すべき代替案**:
+ **ポッド中断の予算 (PDB)** — 完全に防がずに中断率を制御するには、PDB を使用します。PDB を使用すると、最小限の数のレプリカを引き続き使用しながら、統合を続行できます。
+ **存続期間の短いワークロード** — CI/CD ランナーとビルドエージェントの場合、中断を許可し、`do-not-disrupt` を使用せずに CI システムの組み込み再試行ロジックを利用します。
+ **時間制限付き注釈** — 重要な操作の期間中のみ `do-not-disrupt` を適用し、操作の完了時にプログラムによって解除します。
### ポッド中断の予算 (PDB)
`maxUnavailable: 0` または `minAvailable` を現在のレプリカ数以上に設定する PDB により、影響を受けるポッドのすべての統合が効果的に防がれます。PDB を確認して、一度に少なくとも 1 つのポッドを中断できることを確認します。
## NodePool の制限をコスト上限として使用する
NodePool の `limits` により、NodePool がプロビジョニングできるコンピューティングリソースの合計に絶対的な上限が設定されます。この制限に達すると、EKS オートモードによってその NodePool の新しいノードの起動が停止されます。これは、ポッドが保留中であっても行われます。
特に、無制限のスケーリングが適切でない非本番稼働、テスト、またはバーストのワークロードを処理する NodePool に対して、コストガードレールとして `limits` を使用します。
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: ci-runners
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m"]
limits:
cpu: "500"
memory: 1000Gi
```
この例では、`ci-runners` NodePool はプロビジョニングするすべてのノードで合計 500 vCPU または 1000 GiB のメモリを超えることはできません。この制限を超えるポッドは、キャパシティが解放されるまで `Pending` 状態のままになります。
**ヒント**
予想される最大バーストサイズにノード置換のバッファを加えた値に基づいて `limits` を設定します。NodePool の使用率を定期的に確認し、ワークロードパターンの変化に応じて制限を調整します。
## コスト管理のためにインスタンスファミリーを除外する
デフォルトの EKS オートモードでは、幅広いインスタンスタイプから選択することでスケジューリングの柔軟性が最大化されます。特殊なハードウェアを必要としないワークロードの場合は、コストの高いインスタンスタイプが起動されないようにインスタンスファミリーを制限します。
### 高速インスタンスを除外する
GPU またはアクセラレーターリソースをリクエストしないワークロードの場合は、高速インスタンスファミリーを NodePool から除外します。これにより、キャパシティの制約中に高速インスタンスが選択されるシナリオを回避できます。
```
spec:
template:
spec:
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
```
コンピューティング最適化、汎用、メモリ最適化のカテゴリのみを指定することで、高速 (P、G、Inf、Trn) やその他の特殊なインスタンスファミリーを選択から除外できます。
### インスタンスの選択がキャパシティの制約とどのように相互作用するか
EKS オートモードでは、通常のインスタンスの選択中は高速およびエキゾチックのインスタンスタイプの優先順位が下がります。ただし、持続的な起動障害が発生すると、EKS オートモードでは残りの使用可能なインスタンスタイプから起動され、ワークロードの可用性が優先されます。これは例えば、すべての優先インスタンスタイプで EC2 のサービスクォータが一時的に使い果たされた場合に発生します。
このフォールバック動作を防ぐには、ワークロードに必要なインスタンスカテゴリのみに NodePool 要件を明示的に制限します。優先タイプが使用できず、NodePool 設定で他のタイプが許可されていない場合、ポッドはコストの高いインスタンスにスケジュールされずに、`Pending` 状態のままになります。
### インスタンスサイズを制約する
インスタンスファミリーの制限に加えて、NodePool 内の最大インスタンスサイズを制限できます。インスタンスサイズの制約により、統合できない単一ノードからのコストエクスポージャーが制限されます。例えば、`do-not-disrupt` 注釈によってブロックされたノードは、ワークロードが小さい場合でも縮小できません。
`eks.amazonaws.com/instance-cpu` ラベルを使用して、NodePool 要件の最大インスタンスサイズを制限します。
```
requirements:
- key: "eks.amazonaws.com/instance-cpu"
operator: Lte
values: ["32"]
```
この設定により、EKS オートモードではこの NodePool で 32 vCPU を超えるインスタンスを起動できなくなります。
既存のクラスターで最適化の機会を特定するには、実行中の最大のインスタンスを確認します。大きなノードの統合が一貫して防がれている場合、そのアイドルキャパシティのノードあたりのコストは比例して高くなります。
## バーストワークロードに推奨されるパターン
CI/CD パイプライン、バッチジョブ、エフェメラルランナーでは、コスト効率を維持するために特定の設定を必要とするバーストとアイドルのパターンが作成されます。
### バーストワークロードに推奨されるデフォルト
| 設定 | 推奨事項 |
| --- | --- |
| `do-not-disrupt` | CI/CD ランナーには使用しないでください。代わりに、CI システムの再試行とキューのメカニズムを利用します。 |
| NodePool の `limits` | 予想される最大同時実行数にノード置換の重複のバッファを加えた値に基づいて CPU/メモリの上限を設定します。 |
| インスタンスカテゴリ | `c` および `m` ファミリーに制限します。GPU 以外のワークロードの高速インスタンスファミリー (P、G、Inf、Trn) を除外します。 |
| インスタンスサイズ | 中程度のサイズ (4～32 個の vCPU など) に制約して、統合が防がれる単一ノードからのコストエクスポージャーを制限することを検討してください。 |
| 統合タイミング | デフォルトの `consolidateAfter` 設定を使用します。ランナーの完了後に、バーストキャパシティをオンラインに保つ長い遅延を設定しないでください。 |
| キャパシティータイプ | 耐障害性ランナーにはスポットインスタンスを使用します。実行中に状態を保持するビルドエージェントでは、オンデマンドと組み合わせます。 |
### 例: CI ランナー NodePool
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: ci-runners
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m"]
- key: "eks.amazonaws.com/instance-cpu"
operator: Lte
values: ["32"]
- key: "karpenter.sh/capacity-type"
operator: In
values: ["spot", "on-demand"]
limits:
cpu: "500"
memory: 1000Gi
disruption:
consolidationPolicy: WhenEmptyOrUnderutilized
consolidateAfter: 30s
```
この設定では、次のようになります。
+ コスト効率の高いインスタンスファミリーに制限
+ NodePool の合計キャパシティは 500 vCPU が上限
+ 積極的な統合を許可 (ポッドが削除されてから 30 秒後)
+ スポットとオンデマンド両方のキャパシティを許可
## ノードのライフサイクルとコスト
EKS オートモードでは、ノードが目的の仕様から逸脱した場合 (新しいオートモード AMI のリリース後など)、またはノードの有効期限が近づいた場合、グレースフルな中断によってノードが置き換えられます。グレースフルな置き換え中に、以下が行われます。
+ 新しい代替ノードが起動し、準備が整います。
+ ポッド中断の予算を考慮して、ポッドが古いノードからドレインされます。
+ 短期間、古いノードと代替ノードの両方が同時に実行されます。
大規模なノードまたは多数のノードがあるクラスターの場合、この重複により定期的にコストが増加する可能性があります。影響を最小限に抑えるには、以下が必要です。
+ **中断の予算の確認** — 中断の予算でタイムリーなドレインが許可されていることを確認します。制限付きの予算では、古いノードと新しいノードの両方が実行されている重複期間が長くなります。
+ **適切なサイズのインスタンス** — インスタンスが小さいほど、重複期間の絶対コストが削減されます。
+ **ノードの最大有効期間の短縮** — 有効期限の値を短くすると (7 日間など)、置き換えイベントの頻度は高くなりますが、置き換えイベントは小規模になります。これにより、コストが集中せずに、時間的に均等に分散されます。
ノードのライフサイクルの詳細については、「[Amazon EKS Auto Mode マネージドインスタンスについての説明](automode-learn-instances.md)」を参照してください。