AWS Batchのコンピューティング環境を整理してみた

# 背景・目的
以前、下記の記事でAWS Batchについて基本的な知識を整理しました。

https://qiita.com/zumax/items/4d426da81e38e7f8a040

今回は、コンピューティング環境について整理します。

# まとめ
下記に特徴を整理します。

|特徴|説明|
|:--|:--|
|コンピューティング環境|ジョブキューは、一つ以上のコンピューティング環境にマッピングされる<BR><BR>コンピューティング環境には優先順位がある<BR><BR>コンピューティング環境はリソースや、使用可能な状態により適切にアサインされる|
|マネージドコンピューティング環境|AWS Batch で環境内のコンピューティングリソースの容量とインスタンスタイプを管理が可能<BR><BR>コンピューティング環境の作成時に定義したコンピューティングリソースの仕様に基づく|
|マネージドコンピューティング環境のNW|VPCとサブネットを指定する<BR><BR>指定した VPC およびサブネットに EC2 インスタンスが起動され、ECS クラスターに登録される<BR><BR>EC2 インスタンスは、ECS サービスエンドポイントと通信するために外部ネットワークアクセスを必要とする<BR><BR>通信するためには、NATが必要|
|マネージドコンピューティング環境のAMI|ECS に最適化された AMI の最新の承認済みバージョンが使用される<BR><BR>AWS Batch は、コンピューティング環境の作成後に AMI を自動的にアップグレードしない<BR><BR>ECS に最適化された AMI の新しいバージョンがリリースされても、コンピューティング環境の AMI は更新されない。利用者の責任で更新する|
|マルチノード並列ジョブを作成する際の考慮事項|マルチノード並列 (MNP) ジョブと非 MNP ジョブを実行するための専用のコンピューティング環境を分けて作成することを推奨している|
|起動テンプレート|AWS Batchでは、EC2 コンピューティング環境での Amazon EC2 起動テンプレートの使用をサポートしている<BR><BR>起動テンプレートを使用すると、カスタマイズされた AMI を作成しなくても、AWS Batch コンピューティングリソースのデフォルト設定を変更できる<BR><BR>起動テンプレートをコンピューティング環境に関連付ける前に、起動テンプレートを作成する必要がある<BR><BR>マネコン、CLI、SDKで作成できる|<BR><BR>EC2 ユーザーデータを、インスタンス起動時にcloud-initで提供できる|
|コンピューティング環境のパラメータ|いくつかの基本コンポーネントに分かれる<BR>・Compute environment name<BR>・Type<BR>・State<BR>・Compute resources<BR>・Amazon EKS configuration<BR>・Service role|
|コンピューティングリソースメモリ管理|プラットフォームのメモリオーバーヘッドとシステムカーネルが占めるメモリがあるので、インスタンスのすべてのメモリを使用することはできない|



# 概要
下記を基に整理します。

https://docs.aws.amazon.com/batch/latest/userguide/compute_environments.html

> ジョブキューは、1 つ以上のコンピューティング環境にマッピングされます。コンピューティング環境には、コンテナ化されたバッチジョブを実行するために使用される Amazon ECS コンテナインスタンスが含まれます。特定のコンピューティング環境を 1 つ以上のジョブキューにマッピングすることもできます。ジョブキュー内では、関連付けられたコンピューティング環境ごとに順序があり、スケジューラはこれを使用して、実行準備が整ったジョブをどこで実行するかを決定します。最初のコンピューティング環境のステータスが で VALID、使用可能なリソースがある場合、ジョブはそのコンピューティング環境内のコンテナインスタンスにスケジュールされます。最初のコンピューティング環境のステータスが であるINVALIDか、適切なコンピューティングリソースを提供できない場合、スケジューラは次のコンピューティング環境でジョブを実行しようとします。

- ジョブキューは、一つ以上のコンピューティング環境にマッピングされる
    - コンピューティング環境には、コンテナ化されたバッチジョブを実行するために使用される Amazon ECS コンテナインスタンスが含まれる
    - 特定のコンピューティング環境を 1 つ以上のジョブキューにマッピングすることもできる
- コンピューティング環境には優先順位がある
    - ジョブキュー内では、関連付けられたコンピューティング環境ごとに順序がある
    - スケジューラはこの優先順位を使用して、実行準備が整ったジョブをどこで実行するかを決定する
- コンピューティング環境はリソースや、使用可能な状態により適切にアサイン
    - 最初のコンピューティング環境のステータスが VALIDで 、使用可能なリソースがある場合、ジョブはそのコンピューティング環境内のコンテナインスタンスにスケジュールされる
    - 最初のコンピューティング環境のステータスが INVALIDであるか、適切なコンピューティングリソースを提供できない場合、スケジューラは次のコンピューティング環境でジョブを実行しようとする

## Managed compute environments
> マネージドコンピューティング環境を使用すると、AWS Batch で環境内のコンピューティングリソースの容量とインスタンスタイプを管理できます。これは、コンピューティング環境の作成時に定義したコンピューティングリソースの仕様に基づきます。Amazon EC2 オンデマンドインスタンスと Amazon EC2 スポットインスタンスのどちらかを選択できます。または、マネージドコンピューティング環境で Fargate と Fargate スポット容量を使用することもできます。スポットインスタンスを使用する場合は、オプションで最大価格を設定できます。これにより、スポットインスタンスは、スポットインスタンスの価格がオンデマンド価格の指定されたパーセンテージを下回った場合にのみ起動します。

- マネージドコンピューティング環境：AWS Batchは、マネージド環境を使用することで、コンピューティングリソースの容量とインスタンスタイプを自動的に管理します。

リソースの種類：Amazon EC2のオンデマンドインスタンスとスポットインスタンス、またはFargateとFargateスポットを選択して利用可能です。

スポットインスタンスの価格設定：スポットインスタンスを使用する場合、オプションで最大価格を設定することができます。スポットインスタンスの価格がオンデマンド価格の指定パーセンテージを下回った時にのみインスタンスが起動されます。


- マネージドコンピューティング環境
    - AWS Batch で環境内のコンピューティングリソースの容量とインスタンスタイプを管理が可能
    - コンピューティング環境の作成時に定義したコンピューティングリソースの仕様に基づく
- リソースは下記が選択可能
    - 下記のEC2インスタンスが選択可能
        - オンデマンドインスタンス
        - スポットインスタンス
    - マネージドコンピューティング環境では、下記が選択可能
        - Fargate
        - Fargate スポット容量
- スポットインスタンスを使用する場合は、オプションで最大価格を設定できる
    - 下記の条件の場合、起動する
    - スポットインスタンスの価格 < オンデマンド価格 * 指定されたパーセンテージ


> マネージドコンピューティング環境では、指定した VPC およびサブネットに Amazon EC2 インスタンスが起動され、Amazon ECS クラスターに登録されます。Amazon EC2 インスタンスは、Amazon ECS サービスエンドポイントと通信するために外部ネットワークアクセスを必要とします。一部のサブネットでは、Amazon EC2 インスタンスにパブリック IP アドレスが提供されません。Amazon EC2 インスタンスにパブリック IP アドレスがない場合は、ネットワークアドレス変換 (NAT) を使用してこのアクセスを取得する必要があります。

- マネージドコンピューティング環境のNW
    - VPCとサブネットを指定する
    - 指定した VPC およびサブネットに EC2 インスタンスが起動され、ECS クラスターに登録される
    - EC2 インスタンスは、ECS サービスエンドポイントと通信するために外部ネットワークアクセスを必要とする
    - 通信するためには、NATが必要

> デフォルトでは、AWS Batch マネージドコンピューティング環境では、コンピューティングリソース用に Amazon ECS に最適化された AMI の最新の承認済みバージョンが使用されます。ただし、さまざまな理由から、マネージドコンピューティング環境で使用する独自の AMI を作成する必要がある場合があります。詳細については、「コンピューティングリソース AMI」を参照してください。

※ 注釈も踏まえて下記に整理しています。

- マネージドコンピューティング環境のAMI
    - ECS に最適化された AMI の最新の承認済みバージョンが使用される
    - AWS Batch は、コンピューティング環境の作成後に AMI を自動的にアップグレードしない
    - ECS に最適化された AMI の新しいバージョンがリリースされても、コンピューティング環境の AMI は更新されない。利用者の責任で更新する
- AMIを更新する方法
    - 手動でジョブキューに紐づけるコンピューティング環境を付け替える
    - コンピューティング環境の拡張更新を使用してAMIを更新する（いくつかの設定が必要）

### マルチノード並列ジョブを作成する際の考慮事項
> AWS Batch では、マルチノード並列 (MNP) ジョブと非 MNP ジョブを実行するための専用のコンピューティング環境を作成することを推奨しています。これは、マネージドコンピューティング環境でコンピューティング容量が作成される方法によるものです。新しいマネージドコンピューティング環境を作成するときに、minvCpuゼロより大きい値を指定すると、AWS Batch は非 MNP ジョブでのみ使用するインスタンスプールを作成します。マルチノード並列ジョブが送信されると、AWS Batch はマルチノード並列ジョブを実行するための新しいインスタンス容量を作成します。 または の値が設定されている同じコンピューティング環境で単一ノード並列ジョブとマルチノード並列ジョブの両方が実行されている場合minvCpus、maxvCpus 必要なコンピューティングリソースが利用できないと、AWS Batch は現在のジョブが終了するまで待機してから、新しいジョブを実行するために必要なコンピューティングリソースを作成します。

- マルチノード並列 (MNP) ジョブと非 MNP ジョブを実行するためのコンピューティング環境
    - マルチノード並列 (MNP) ジョブと非 MNP ジョブを実行するための専用のコンピューティング環境を分けて作成することを推奨している
    - 理由
        - 新しいマネージドコンピューティング環境を作成するときに、 ゼロより大きい最小vCpu値を指定すると、非 MNP ジョブでのみ使用するインスタンスプールを作成する
        - MNPジョブが送信されると、MNP並列ジョブを実行するための新しいインスタンス容量を作成する
        - minvCpus または maxvCpus のいずれかの値が設定されている同じコンピューティング環境で、単一ノードと複数ノードの並列ジョブの両方が実行されている場合、必要なコンピューティングリソースが利用できないと、AWS Batch は現在のジョブが終了するまで待機してから、新しいジョブを実行するために必要なコンピューティングリソースを作成する

## Unmanaged compute environments
> 管理されていないコンピューティング環境では、独自のコンピューティングリソースを管理します。コンピューティングリソースに使用する AMI が Amazon ECS コンテナインスタンス AMI 仕様を満たしていることを確認する必要があります。詳細については、「コンピューティングリソース AMI 仕様」および「コンピューティングリソース AMI の作成」を参照してください。

- 独自のコンピュートリソースを管理する
- AMI が Amazon ECS コンテナインスタンス AMI 仕様を満たしていることを確認する必要がある

## 起動テンプレートのサポート
下記を基に整理します。

https://docs.aws.amazon.com/batch/latest/userguide/launch-templates.html

> AWS Batch は、EC2 コンピューティング環境での Amazon EC2 起動テンプレートの使用をサポートしています。起動テンプレートを使用すると、カスタマイズされた AMI を作成しなくても、AWS Batch コンピューティングリソースのデフォルト設定を変更できます。

- EC2 コンピューティング環境での Amazon EC2 起動テンプレートの使用をサポートしている
- 起動テンプレートを使用すると、カスタマイズされた AMI を作成しなくても、AWS Batch コンピューティングリソースのデフォルト設定を変更できる

> 起動テンプレートをコンピューティング環境に関連付ける前に、起動テンプレートを作成する必要があります。起動テンプレートは、Amazon EC2 コンソールで作成できます。または、AWS CLI または AWS SDK を使用することもできます。たとえば、次の JSON ファイルは、デフォルトの AWS Batch コンピューティングリソース AMI の Docker データボリュームのサイズを変更し、暗号化するように設定する起動テンプレートを表しています。

```json
{
    "LaunchTemplateName": "increase-container-volume-encrypt",
    "LaunchTemplateData": {
        "BlockDeviceMappings": [
            {
                "DeviceName": "/dev/xvda",
                "Ebs": {
                    "Encrypted": true,
                    "VolumeSize": 100,
                    "VolumeType": "gp2"
                }
            }
        ]
    }
}
```

- EC2 コンピューティング環境での Amazon EC2 起動テンプレートの使用をサポートしている
- 起動テンプレートを使用すると、カスタマイズされた AMI を作成しなくても、AWS Batch コンピューティングリソースのデフォルト設定を変更できる
- 起動テンプレートをコンピューティング環境に関連付ける前に、起動テンプレートを作成する必要がある
- マネコン、CLI、SDKで作成できる

> 起動テンプレートを使用してコンピューティング環境を作成する場合は、次の既存のコンピューティング環境パラメータを起動テンプレートに移動できます。

> - Amazon EC2 キーペア
> - Amazon EC2 AMI ID
> - セキュリティグループID
> - Amazon EC2 タグ


> 注記
これらのパラメータのいずれか (Amazon EC2 タグを除く) が起動テンプレートとコンピューティング環境設定の両方で指定されているとします。その場合、コンピューティング環境パラメータが優先されます。Amazon EC2 タグは、起動テンプレートとコンピューティング環境設定の間でマージされます。タグのキーに競合がある場合は、コンピューティング環境設定の値が優先されます。

- 同一パラメータが設定されていた場合、起動テンプレートよりも、コンピューティング環境が優先される

> 次の起動テンプレートパラメータはAWS Batch によって無視されます。
> - インスタンスタイプ（コンピューティング環境を作成するときに、希望するインスタンスタイプを指定します）
> - インスタンス ロール (コンピューティング環境を作成するときに、必要なインスタンス ロールを指定します)
> - ネットワーク インターフェイス サブネット (コンピューティング環境を作成するときに必要なサブネットを指定します)
> - インスタンス市場のオプション (AWS Batch はスポットインスタンスの構成を制御する必要があります)
> - API 終了を無効にする (AWS Batch はインスタンスのライフサイクルを制御する必要があります)

|パラメータ|起動テンプレートでの利用可否|
|:--|:--|
|Amazon EC2 key pair|◯|
|Amazon EC2 AMI ID|◯|
|Security group IDs|◯|
|Amazon EC2 tags|◯|
|Instance type|✕|
|Instance role|✕|
|Network interface subnets|✕|
|Instance market options|✕|
|Disable API termination|✕|

### 起動テンプレートの Amazon EC2 ユーザーデータ
> 起動テンプレート内の Amazon EC2 ユーザーデータを、cloud-init をインスタンス起動時に提供できます。ユーザーデータは、以下を含む一般的な設定シナリオを実行できます。ただし、これらに限定されるものではありません。

- Amazon EC2 ユーザーデータを、インスタンス起動時にcloud-initで提供できる

## コンピューティング環境のパラメータ
> コンピューティング環境は、コンピューティング環境の名前、タイプ、状態、コンピューティングリソース定義 (マネージドコンピューティング環境の場合）、Amazon EKS 設定 (Amazon EKS リソースを使用する場合）、 への IAM アクセス許可の提供に使用するサービスロール AWS Batch、コンピューティング環境のタグなど、いくつかの基本コンポーネントに分割されます。

- コンピューティング環境は、いくつかに基本コンポーネントに分割される

### Compute environment name
- コンピューティング環境の名前

### Type
- コンピューティング環境のタイプ
- EC2 または Fargate コンピューティング リソースを AWS Batch で管理するには、MANAGEDを選択する
- 設定可能な値
    - MANAGED | UNMANAGED

### State
- コンピューティング環境の状態
- 状態が ENABLED の場合、AWS Batch スケジューラは環境内にジョブを配置する
    - コンピューティング環境がMANAGEDの場合、インスタンスはジョブ キューの需要に基づいて自動的にスケールアウトまたはスケールインする
- 状態が DISABLED の場合、AWS Batch スケジューラは環境内にジョブを配置しようとしない
    - STARTING または RUNNING 状態にあるジョブは、引き続き通常どおりに進行する
    - DISABLED 状態にあるマネージド コンピューティング環境はスケールアウトされない
    - DISABLED 状態のコンピューティング環境では、引き続き料金が発生する可能性がある
    - 追加料金が発生しないようにするには、コンピューティング環境をオフにしてから削除する
- インスタンスがアイドル状態の場合、インスタンスは minvCpus 値までスケールダウンする
- 設定可能な値
    - ENABLED | DISABLED


### Compute resources
- コンピューティング環境によって管理されるコンピューティング リソースの詳細
#### type
- コンピューティング環境のタイプ
- 設定可能な値
    - EC2：EC2 オンデマンドインスタンス
    - SPOT：EC2 スポットインスタンス
    - FARGATE：Fargate
    - FARGATE_SPOT：Fargate Spot capacity
#### allocationStrategy
- 最適な EC2 インスタンス タイプのインスタンスを十分に割り当てられない場合の割り当ての戦略
- 下記が原因で、トリガーが発動する
    - AWS リージョンでのインスタンス タイプの可用性
    - Amazon EC2 サービスクォーター
- Fargateリソースで実行されるジョブには関係ない
- allocationStrategyの戦略は次の通り
    - BEST_FIT
    - BEST_FIT_PROGRESSIVE
    - SPOT_CAPACITY_OPTIMIZED
    - SPOT_PRICE_CAPACITY_OPTIMIZED
- スポットインスタンスを使用する各戦略では、容量要件を満たすために、max vCPUを超える必要がある
##### BEST_FIT (default)
- ジョブのニーズに最も適したインスタンス タイプを選択し、コストが最も低いインスタンス タイプを優先
- 選択したインスタンスタイプの追加インスタンスが利用できない場合、AWS Batch は追加インスタンスが利用可能になるまで待機する
- 使用可能なインスタンスが十分にない場合、または Amazon EC2 サービスの制限に達している場合は、現在実行中のジョブが**完了するまで追加のジョブは実行されない**
- この割り当て戦略によりコストは低く抑えられますが、スケーリングが制限される可能性がある
- BEST_FIT でスポット フリートを使用している場合は、スポット フリート IAM ロールを指定する必要がある
- **BEST_FIT 割り当て戦略を使用するコンピューティング リソースはインフラストラクチャの更新をサポートしておらず、一部のパラメーターを更新できない**
- EKSリソースを使用する環境では利用できない

##### BEST_FIT_PROGRESSIVE
- キュー内のジョブの要件を満たすのに十分な大きさの追加のインスタンス タイプを使用する
- 各ユニット vCPU のコストが低いインスタンス タイプを優先する
- 以前に選択したインスタンス タイプの追加インスタンスが利用できない場合、AWS Batch は新しいインスタンス タイプを選択する

##### SPOT_CAPACITY_OPTIMIZED
- スポット インスタンスのコンピューティング リソースでのみ利用可能
- キュー内のジョブの要件を満たすのに十分な大きさの追加のインスタンス タイプを使用する
- 中断される可能性が低いインスタンス タイプを優先する

##### SPOT_PRICE_CAPACITY_OPTIMIZED
- スポット インスタンスのコンピューティング リソースでのみ利用可能
- 価格と容量の両方を検討して、中断される可能性が最も低く、価格が可能な限り低いスポット インスタンス プールを選択
- **ほとんどの場合、SPOT_CAPACITY_OPTIMIZED ではなく SPOT_PRICE_CAPACITY_OPTIMIZED を使用することを推奨**

#### minvCpus
- コンピューティング環境が無効になっている場合でも環境が維持する vCPU の最小数
- Fargateリソースでは適用されない

#### maxvCpus
- AWS Batch コンピューティング環境がサポートできる vCPU の最大数
- 下記では、AWS Batch は容量要件を満たすために maxvCpus を超える必要がある場合がある
    - オンデマンドまたはスポットインスタンスを使用する
        - BEST_FIT_PROGRESSIVE
        - SPOT_CAPACITY_OPTIMIZED
        - SPOT_PRICE_CAPACITY_OPTIMIZED
    - スポットインスタンスを使用する 
        - BEST_FIT
- ただし、AWS Batch は maxvCpus を 1 インスタンス以上超えることはない
    - たとえば、AWS Batch はコンピューティング環境で指定されたインスタンスの中から 1 つのインスタンスのみを使用する

:::note info
つまり、インスタンス単位で確保する都合上、maxvCPU 以上、インスタンスのvCPU以下確保する。と言っていると思われる。
:::

#### desiredvCpus
- コンピューティング環境内の必要な vCPU の数
- AWS Batch は、ジョブキューの需要に基づいて、この値を最小値と最大値の間で変更する
- Fargateリソースでは適用されない

#### instanceTypes
- 起動できるインスタンスのタイプ
- 指定方法は下記のどちらか
    - インスタンスタイプファミリー
        - ただし、metalインスタンスタイプは含まれない
    - インスタンスタイプ
    - Optimal
        - ジョブ キューの需要に一致するインスタンス タイプ (C4、M4、および R4 インスタンス ファミリーから) を選択するために最適なものを選択することもできる
        - 現在、C4、M4、R4を使用しているが、存在しないリージョンの場合、C5、M5、R5から選択される
- コンピューティング環境を作成する場合、コンピューティング環境用に選択するインスタンス タイプは、同じアーキテクチャを共有する必要がある
    - たとえば、同じコンピューティング環境内に x86 インスタンスと ARM インスタンスを混在させることはできない
- Fargateリソースでは適用されない

#### imageId
- deprecatedのようです

#### subnets
- コンピューティング リソースが起動される VPC サブネット
- これらのサブネットは同じ VPC 内に存在する必要がある
- Fargate コンピューティング リソースには、最大 16 個のサブネットを含めることが可能
- Amazon EC2 の AWS Batch と Amazon EKS の AWS Batch は、ローカルゾーンをサポート
- コンピューティング環境を更新するときに、VPC サブネットの空のリストを指定すると、Fargate と EC2 コンピューティング リソースの間で結果の動作が異なる
    - Fargate コンピューティング リソースの場合
        - 空のリストを指定すると、このパラメーターが指定されていないかのように処理され、変更は行われない
    - EC2 コンピューティング リソースの場合
        - 空のリストを指定すると、コンピューティング リソースから VPC サブネットが削除される
    - VPC サブネットを変更する場合は、コンピューティング環境のインフラストラクチャの更新が必要

#### securityGroupIds
- コンピューティング環境で起動されたインスタンスに関連付けられた Amazon EC2 セキュリティ グループ
- 1つ以上のセキュリティグループを指定する必要がある
- Fargate リソース上で実行されるジョブで必須
- EC2 コンピューティング リソース。空のリストを指定すると、コンピューティング リソースからセキュリティ グループが削除される

#### ec2KeyPair
- コンピューティング環境で起動されるインスタンスに使用される EC2 キーペア
- SSH でインスタンスにログインできる
- EC2 キー ペアを変更すると、コンピューティング環境のインフラストラクチャの更新が必要

#### instanceRole
- コンピューティング環境内の Amazon EC2 インスタンスにアタッチする Amazon ECS インスタンス プロファイル
- Fargateリソースでは適用されない

#### tags
- コンピューティング環境で起動される EC2 インスタンスに適用されるキーと値のペアのタグ
- Fargateリソースでは適用されない

#### placementGroup
- コンピューティング リソースに関連付ける Amazon EC2 配置グループ
- マルチノードの並列ジョブをコンピューティング環境に送信する場合は、クラスター配置グループを作成し、それをコンピューティング リソースに関連付けることを検討する
- これにより、ネットワーク フローの可能性が高い単一のアベイラビリティーゾーン内のインスタンスの論理グループ上でマルチノードの並列ジョブが維持される
- Fargateリソースでは適用されない

#### bidPercentage
- インスタンスが起動される前に、そのインスタンス タイプのオンデマンド価格と比較した場合の EC2 スポット インスタンス価格の最大パーセンテージ
- たとえば、最大割合が 20% の場合、スポット価格は、その EC2 インスタンスの現在のオンデマンド価格の 20% 未満である必要がある
- 常に最低（市場）価格を支払い、最大パーセンテージを超えることはない
- このフィールドを空のままにすると、デフォルト値はオンデマンド価格の 100% になる
- **ほとんどの使用例では、このフィールドを空のままにすることを推奨**
- Fargateリソースでは適用されない

#### spotIamFleetRole
- SPOT コンピューティング環境に適用される Amazon EC2 スポット フリート IAM ロールの Amazon リソースネーム (ARN)
- このロールは、割り当て戦略が BEST_FIT に設定されている場合、または割り当て戦略が指定されていない場合に必要
- Fargateリソースでは適用されない

#### launchTemplate
- コンピューティング リソースに関連付けるオプションの起動テンプレート
- CreateComputeEnvironment または UpdateComputeEnvironment API オペレーションで指定する他のコンピューティング リソース パラメーターは、起動テンプレート内の同じパラメーターをオーバーライドする
- Fargateリソースでは適用されない
- コンピューティング環境を更新するときに、カスタム起動テンプレートを削除してデフォルトの起動テンプレートを使用するには、起動テンプレート仕様の launchTemplateId または launchTemplateName メンバーを空の文字列に設定する
    - **コンピューティング環境から起動テンプレートを削除しても、起動テンプレートで指定された AMI が使用されていた場合、その AMI は削除されない**
    - 起動テンプレートから選択した AMI を更新するには、updateTolatestImageVersion パラメーターを true に設定する必要がある
    - コンピューティング環境を更新する場合、起動テンプレートを変更すると、コンピューティング環境のインフラストラクチャの更新が必要になる

#### ec2Configuration
- EC2 コンピューティング環境でインスタンスの Amazon Machine Images (AMI) を選択するために使用される情報を提供する
- Ec2Configuration が指定されていない場合、デフォルトは Amazon Linux 2 (ECS_AL2) 
- このパラメータを変更する場合は、コンピューティング環境のインフラストラクチャの更新が必要


### Amazon EKS configuration
- AWS Batch コンピューティング環境をサポートする Amazon EKS クラスターの構成
- コンピューティング環境を作成するには、クラスターが存在している必要がある
- eksClusterArn
    - EKS ClusterのARN
- kubernetesNamespace
    - Amazon EKS クラスターの名前空間
    - AWS Batch は、こ​​の名前空間でポッドを管理する

### Service role
- AWS Batch がユーザーに代わって他の AWS サービスを呼び出すことを許可する IAM ロールのARN
- サービスロールを指定しないことを推奨
    - AWS Batch は AWSServiceRoleForBatch サービスにリンクされたロールを使用する
    - アカウントで AWS Batch サービスにリンクされたロール (AWSServiceRoleForBatch) がすでに作成されている場合は、ここでロールを指定しない限り、そのロールがコンピューティング環境にデフォルトで使用される
    - AWS Batch サービスにリンクされたロールがアカウントに存在せず、ここでロールが指定されていない場合、サービスはアカウントに AWS Batch サービスにリンクされたロールを作成しようとする
    - AWSServiceRoleForBatch サービスにリンクされたロールを使用してコンピューティング環境が作成されている場合、通常の IAM ロールを使用するように変更することはできない
    - 同様に、コンピューティング環境が通常の IAM ロールで作成されている場合、AWSServiceRoleForBatch サービスにリンクされたロールを使用するように変更することはできない
    - インフラストラクチャの更新を変更する必要があるコンピューティング環境のパラメータを更新するには、AWSServiceRoleForBatch サービスにリンクされたロールを使用する必要がある

## コンピューティングリソースメモリ管理

> Amazon ECSコンテナエージェントが、コンテナインスタンスコンピュートリソースをクラスターコンピューティング環境に登録する場合、エージェントはタスクジョブの実行のために、コンテナインスタンスコンピューティングリソースが使用できるメモリ容量を決定する必要があります。プラットフォームのメモリオーバーヘッドとシステムカーネルが占めるメモリのため、この数値は、Amazon EC2 インスタンスとして公開されているインストール済みメモリ量とは異なります。例えば、m4.
インスタンスには 8 GiB のメモリがインストールされています。しかし、これはコンピューティングが登録されたときに、 ジョブに厳密に8192 MiBのメモリに常に変換されるとは限りません。

> ジョブに8192 MiB を指定した場合、この要件を満たす使用可能なメモリが 8192 MiB以上のメモリがないとします。その場合、そのジョブをコンピューティング環境に置くことができなくなります。マネージド型コンピューティング環境を使用している場合、リクエストに対応するためには、AWS Batchはより大きなインスタンスタイプを起動する必要があります。

- プラットフォームのメモリオーバーヘッドとシステムカーネルが占めるメモリがある
- オーバヘッドがあるということ
- ジョブに8192 MiB を指定した場合、この要件を満たす使用可能なメモリが 8192 MiB以上のメモリがないとする。その場合、そのジョブをコンピューティング環境に置くことができなくなる
- マネージド型コンピューティング環境を使用している場合、リクエストに対応するためには、AWS Batchはより大きなインスタンスタイプを起動する必要がある

> デフォルト AWS Batch コンピューティングリソースAMIも、Amazon ECS コンテナエージェントやその他の重要なシステムプロセス用に32 MiBのメモリを予約します。このメモリはジョブの割り当てには使用できません。詳細については、システムメモリの予約を参照してください。

- デフォルト AWS Batch コンピューティングリソースAMIも、Amazon ECS コンテナエージェントやその他の重要なシステムプロセス用に32 MiBのメモリを予約する

> Amazon ECS コンテナエージェントは、Docker ReadMemInfo()関数を使用してオペレーティングシステムで使用可能な合計メモリのクエリを実行します。Linuxは、合計メモリを判断するためにコマンドラインユーティリティを提供します。

### システムメモリの予約
> タスクジョブでコンピューティングリソース上の全メモリを占有している場合、タスクジョブがメモリを必要とする重要なシステムプロセスと競い、システム障害の引き金となる可能性があります。Amazon ECS コンテナエージェントは、ECS_RESERVED_MEMORY と呼ばれる設定変数を提供します。この変数を使用して、タスクジョブに割り当てられたプールから特定のMiBメモリを削減できます。これにより、重要なシステムプロセスのメモリを効果的に確保することができます。

- ジョブで全メモリを占有しているとき、タスクジョブがメモリを必要とする重要なシステムプロセスと競い、システム障害の引き金となる可能性がある
- Amazon ECS コンテナエージェントは、ECS_RESERVED_MEMORY と呼ばれる設定変数を提供する。この変数を使用して、タスクジョブに割り当てられたプールから特定のMiBメモリを削減可能

> デフォルトのAWS BatchコンピューティングリソースAMI は、Amazon ECS コンテナエージェントやその他の重要なシステムプロセス用に、32MiBのメモリを予約します。

- AWS BatchコンピューティングリソースAMI は、Amazon ECS コンテナエージェントやその他の重要なシステムプロセス用に、32MiBのメモリを予約している

### コンピューティングリソース メモリを表示
> Amazon ECS コンソール または DescribeContainerInstances API操作で、コンテナインスタンスコンピューティングリソースが登録されているメモリ量を表示できます。特定のインスタンスタイプに対して、可能な限り大きなメモリをタスクジョブに割り当てて、リソース使用率を最大化しようとする場合は、そのコンピューティングリソースに使用可能なメモリを観察でき、その後にタスクジョブに可能な限り多くのメモリを割り当てることができます。


- コンテナインスタンスコンピューティングリソースが登録されているメモリ量を表示できる
- コンピューティングリソースに使用可能なメモリを観察でき、その後にタスクジョブに可能な限り多くのメモリを割り当てる事が可能

## スケジューリングポリシー
下記を基に整理します。

https://docs.aws.amazon.com/ja_jp/batch/latest/userguide/scheduling-policies.html

- スケジュール ポリシーを使用して、ジョブ キュー内のコンピューティング リソースをユーザーまたはワークロード間で割り当てる方法を構成できる
- スケジューリング ポリシーを使用すると、さまざまなフェアシェア識別子をワークロードまたはユーザーに割り当てることができる
- AWS Batch は、各フェアシェア識別子に、一定期間内に利用可能な総リソースの割合を割り当てる

- 公平なシェアの割合は、shareDecaySeconds と shareDistribution の値を使用して計算される
- ポリシーにシェア減衰時間を割り当てることで、フェアシェア分析に時間を追加できる
- 時間を追加すると、時間の重みが増し、定義された重みが減る
- コンピューティングの予約を指定することで、アクティブではないフェア シェア識別子用にコンピューティング リソースを予約しておくことができる

### Scheduling policy parameters
- スケジューリング ポリシーは、名前、フェア シェア ポリシー、およびスケジューリング ポリシーのタグという 3 つの基本コンポーネントに分割される
- ここでは、Fair share policyにフォーカスする

#### Fair share policy
- スケジューリングポリシーのFair share policy
- 例
    ```json
    "fairsharePolicy": {
       "computeReservation": number,
       "shareDecaySeconds": number,
       "shareDistribution": [
          {
             "shareIdentifier": "string",
             "weightFactor": number
          }
       ]
    }
    ```
##### computeReservation
- 使用されていないFair share 識別子に利用可能な最大 vCPU の一部を予約するために使用される値
- 予約比率
    - (computeReservation/100)^ActiveFairShares
    - ActiveFairShare は、アクティブなFair share 識別子の数
- 例：computeReservationが50のとき
    - アクティブなFair shar識別子が 1 つしかない場合、AWS Batch は、使用可能な最大 VCPU の 50% を確保
    - アクティブなFair shar識別子が 2つの場合、25%を確保
    - アクティブなFair shar識別子が 3つの場合、12.5%を確保
- 例：computeReservationが25のとき
    - アクティブなFair shar識別子が 1 つしかない場合、AWS Batch は、使用可能な最大 VCPU の 25% を確保
    - アクティブなFair shar識別子が 2つの場合、6.25%を確保
    - アクティブなFair shar識別子が 3つの場合、1.56%を確保


##### shareDecaySeconds
- 使用中の各フェア シェア識別子のフェア シェア パーセンテージを計算するために使用する期間
- 値がゼロ (0) の場合、現在の使用状況のみが測定される
- 減衰により、最近実行されたジョブの重みが、以前に実行されたジョブの重みよりも大きくなる

##### shareDistribution
- フェア シェア ポリシーのFair share 識別子の重みを含むオブジェクトの配列
- 含まれていないフェア シェア識別子のデフォルトの重みは 1.0

# 考察
今回は、AWS Batchのコンピューティング環境について整理しました。
vCPU周りの知識が整理できたので、目的が達成できました。
次回は、ジョブキューについて整理する予定です。

# 参考
https://qiita.com/zumax/items/4d426da81e38e7f8a040

https://data-engineer-tech.com/aws-batch-step-functions-batch-simple/