Capacity Blocks for ML を使用してセルフマネージドノードを作成する - Amazon EKS
考慮事項セルフマネージド型ノードでキャパシティブロックを使用する

Capacity Blocks for ML を使用してセルフマネージドノードを作成する

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

考慮事項

重要

  • キャパシティブロックは、特定の Amazon EC2 インスタンスタイプおよび AWS リージョンでのみ使用できます。互換性情報については、「Linux インスタンス用 Amazon EC2 ユーザーガイド」の「キャパシティブロックの操作」を参照してください。

  • 現在、キャパシティブロックは Karpenter では使用できません。

  • キャパシティ予約が有効になる前にセルフマネージド型ノードグループを作成する場合は、希望キャパシティを 0 に設定します。

  • ノードを正常にドレインさせるのに十分な時間を確保するために、キャパシティブロックの予約終了時刻の 30 分以上前にスケーリングがゼロになるようにスケーリングをスケジュールすることをお勧めします。

  • Pods が正常にドレインされるように、例の手順の説明に従って AWS ノード終了ハンドラーを設定することをお勧めします。

セルフマネージド型ノードでキャパシティブロックを使用する

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

  1. ワークロードに適用可能な起動テンプレートを作成します。詳細については、「Amazon EC2 Auto Scaling ユーザーガイド」の「Use Capacity Blocks for machine learning workloads」を参照してください。

    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

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

  2. 起動テンプレートを使用して、セルフマネージド型ノードグループを作成します。キャパシティ予約が有効になる前にこれを行う場合は、希望キャパシティを 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

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

  4. Auto Scaling グループに対して、キャパシティブロックの予約時間に合わせて、スケジュールされたスケーリングポリシーを作成することをお勧めします。詳細については、「Amazon EC2 Auto Scaling ユーザーガイド」の「Amazon EC2 Auto Scaling のスケジュールされたスケーリング」を参照してください。

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

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

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

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

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