

 **このページの改善にご協力ください** 

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。

# Capacity Blocks for ML を使用してセルフマネージドノードを作成する
<a name="capacity-blocks"></a>

機械学習 (ML) のキャパシティブロックを使用すると、短期間の機械学習ワークロードをサポートするために、GPU インスタンスを将来の日付で予約できます。詳細については、「Linux インスタンス用 Amazon EC2 ユーザーガイド」の「[機械学習用のキャパシティブロック](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html)」を参照してください。

## 考慮事項
<a name="capacity-blocks-considerations"></a>

**重要**  
キャパシティブロックは、特定の Amazon EC2 インスタンスタイプおよび AWS リージョンでのみ使用できます。互換性情報については、「Linux インスタンス用 Amazon EC2 ユーザーガイド」の「[キャパシティブロックの操作](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-using.html#capacity-blocks-prerequisites)」を参照してください。
キャパシティ予約が有効になる前にセルフマネージド型ノードグループを作成する場合は、希望キャパシティを `0` に設定します。
ノードを正常にドレインさせるのに十分な時間を確保するために、キャパシティブロックの予約終了時刻の 30 分以上前にスケーリングがゼロになるようにスケーリングをスケジュールすることをお勧めします。
Pod が正常にドレインされるように、例の手順の説明に従って AWS ノード終了ハンドラーを設定することをお勧めします。

## セルフマネージド型ノードでキャパシティブロックを使用する
<a name="capacity-blocks-procedure"></a>

Amazon EKS でキャパシティブロックを使用して、セルフマネージド型ノードのプロビジョニングとスケーリングを行うことができます。以下のステップは、一般的な概要の例を示しています。AWS CloudFormation テンプレートの例は、本番ワークロードに必要なすべての側面を網羅しているわけではありません。通常、ブートストラップスクリプトを使用してノードをクラスターに結合し、Amazon EKS 高速 AMI、およびクラスターに参加するための適切なインスタンスプロファイルを指定することも必要になります。詳細については、「[セルフマネージド Amazon Linux ノードを作成する](launch-workers.md)」を参照してください。

1. ワークロードに適用可能な起動テンプレートを作成します。詳細については、「Amazon EC2 Auto Scaling ユーザーガイド」の「[Use Capacity Blocks for machine learning workloads](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-template-capacity-blocks.html)」を参照してください。

   `LaunchTemplateData` に以下が含まれていることを確認します。
   +  `MarketType` が `"capacity-block"` に設定された `InstanceMarketOptions` 
   +  `CapacityReservationId` がキャパシティブロックに設定された `CapacityReservationSpecification: CapacityReservationTarget` (例: `cr-02168da1478b509e0 `)
   +  `Arn` が適切な *iam-instance-profile-arn* に設定された `IamInstanceProfile` 
   +  適切な *image-id* に設定された `ImageId` 
   +  キャパシティブロックをサポートするインスタンスタイプに設定された `InstanceType` (例:*p5.48xlarge* )
   +  適切な ID に設定された `SecurityGroupIds` (例:*sg-05b1d815d1EXAMPLE*)
   +  セルフマネージド型ノードグループの適切な *user-data* に設定された `UserData`

     キャパシティブロックをターゲットとする起動テンプレートを作成する CloudFormation テンプレートの抜粋を以下に示します。

     ```
     NodeLaunchTemplate:
       Type: "aws::EC2::LaunchTemplate"
       Properties:
         LaunchTemplateData:
           InstanceMarketOptions:
             MarketType: "capacity-block"
           CapacityReservationSpecification:
             CapacityReservationTarget:
               CapacityReservationId: "cr-02168da1478b509e0"
           IamInstanceProfile:
             Arn: iam-instance-profile-arn
           ImageId: image-id
           InstanceType: p5.48xlarge
           KeyName: key-name
           SecurityGroupIds:
           - sg-05b1d815d1EXAMPLE
           UserData: user-data
     ```

     キャパシティブロックはゾーン型であるため、予約が行われたアベイラビリティーゾーンのサブネットを渡す必要があります。

1. 起動テンプレートを使用して、セルフマネージド型ノードグループを作成します。キャパシティ予約が有効になる前にこれを行う場合は、希望キャパシティを `0` に設定します。ノードグループを作成する際には、キャパシティが予約されているアベイラビリティーゾーンの当該サブネットのみを指定するようにしてください。

   以下は、ワークロードに適用可能な CloudFormation テンプレートを作成するときに参照できる、サンプル CloudFormation テンプレートです。この例では、前の手順で示した ` AWS::Amazon EC2::LaunchTemplate` リソースの `LaunchTemplateId` と `Version` を取得します。また、同じテンプレートの他の場所で宣言されている `DesiredCapacity`、`MaxSize`、`MinSize`、`VPCZoneIdentifier` の値も取得します。

   ```
   NodeGroup:
     Type: "AWS::AutoScaling::AutoScalingGroup"
     Properties:
       DesiredCapacity: !Ref NodeAutoScalingGroupDesiredCapacity
       LaunchTemplate:
         LaunchTemplateId: !Ref NodeLaunchTemplate
         Version: !GetAtt NodeLaunchTemplate.LatestVersionNumber
       MaxSize: !Ref NodeAutoScalingGroupMaxSize
       MinSize: !Ref NodeAutoScalingGroupMinSize
       VPCZoneIdentifier: !Ref Subnets
       Tags:
         - Key: Name
           PropagateAtLaunch: true
           Value: !Sub ${ClusterName}-${NodeGroupName}-Node
         - Key: !Sub kubernetes.io/cluster/${ClusterName}
           PropagateAtLaunch: true
           Value: owned
   ```

1. ノードグループが正常に作成されたら、作成されたノードグループの `NodeInstanceRole` を必ず記録してください。これは、ノードグループがスケーリングされたときに、新しいノードがクラスターに参加し、Kubernetes がノードを認識できるようにするために必要です。詳細については、「[セルフマネージド Amazon Linux ノードを作成する](launch-workers.md)」の「AWS マネジメントコンソール」の手順を参照してください。

1. Auto Scaling グループに対して、キャパシティブロックの予約時間に合わせて、スケジュールされたスケーリングポリシーを作成することをお勧めします。詳細については、「Amazon EC2 Auto Scaling ユーザーガイド」の「[Amazon EC2 Auto Scaling のスケジュールされたスケーリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html)」を参照してください。

   予約したすべてのインスタンスを使用できるのは、キャパシティブロックの終了時刻の 30 分前までです。その時点でまだ稼働しているインスタンスでは、終了処理が開始されます。ノードを正常にドレインさせるのに十分な時間を確保するために、キャパシティブロックの予約終了時刻の 30 分以上前にスケーリングがゼロになるようにスケーリングをスケジュールすることをお勧めします。

   代わりに、キャパシティ予約が `Active` になるたびに手動でスケールアップを行う場合は、キャパシティブロック予約の開始時に Auto Scaling グループの希望キャパシティを更新する必要があります。その場合は、キャパシティブロック予約の終了時刻の 30 分以上前に手動でスケールダウンを行う必要もあります。

1. これで、ノードグループではワークロードと Pod をスケジュールする準備が整いました。

1. Pod が正常にドレインされるように、AWS ノード終了ハンドラーを設定することをお勧めします。このハンドラーは、EventBridge を使用して Amazon EC2 Auto Scaling からの「ASG スケールイン」ライフサイクルイベントを監視し、インスタンスが使用できなくなる前に Kubernetes コントロールプレーンが必要なアクションを実行できるようにします。そうしないと、Pod と Kubernetes のオブジェクトが保留状態でスタックします。詳細については、GitHub の「[AWS ノード終了ハンドラー](https://github.com/aws/aws-node-termination-handler)」を参照してください。

   ノード終了ハンドラーを設定しない場合は、正常にドレインさせる時間を十分に確保できるように、30 分のウィンドウに入る前に Pod のドレインを手動で開始することをお勧めします。