Amazon Web Services ブログ

EC2 Fleet と IBM Spectrum LSF による HPC デプロイの最適化

はじめに

ハイパフォーマンスコンピューティング (HPC) のワークロードは、ビッグデータ、先端プロセスノードのチップ設計を行うための電子設計自動化 (EDA)、および高精度検証の出現により複雑化しています。企業は HPC における絶え間なく増大するコンピューティング需要に対応するため Amazon Web Services (AWS) を採用しています。Hyperion Research の Worldwide HPC in the Cloud Forecast 2020-2026 (2022 年 6 月) によると、今後 5 年間で HPC クラウドへの投資がオンプレミスを上回ると予測されています。
AWS は HPC のお客様のクラウド導入の障壁を下げ続けています。EC2 FleetAmazon Elastic Compute Cloud インスタンスのグループを起動することを可能にし、事実上あらゆるワークロードに対して、安全でサイズ変更可能なコンピュートキャパシティを 1 回の API コールで提供します。人気の高い HPC ワークロードマネージャである IBM Spectrum LSF は EC2 Fleet を Resource Connector モジュールに統合しました。LSF で EC2 Fleet がサポートされたことで、単一のテンプレート構成で柔軟なアーキテクチャを実現できるようになり、運用のオーバーヘッドが削減されました。EC2 Fleet API は数万台の Amazon EC2 インスタンスを備えた HPC クラスタを、数時間ではなく数分でプロビジョニングするのに役立ちます。
この記事では EC2 Fleet を LSF でアクティベートする手順を説明します。以下のクラスタパターンに対する設定を提供します。

  • 複数のアベイラビリティゾーンに異なる種類の Amazon EC2 インスタンスタイプを持つクラスタ
  • AWS クラウドの未使用の Amazon EC2 キャパシティを利用できる Amazon EC2 Spot Instances と、コンピュートキャパシティを時間または秒単位で支払うことができる Amazon EC2 オンデマンドインスタンスを組み合わせたクラスタ
  • インスタンスの優先順位付け機能を備えたクラスタ

EC2 Fleet と LSF 統合前の状態

LSF を使った AWS 上のハイレベルな HPC ワークフローは以下のようなステップで構成されます。

図 1:LSF を用いた AWS 上のハイレベルな HPC ワークフロー

図 1 に示す通り、

  1. ユーザは Amazon EC2 上で動作するリモートワークステーションにログインします。
  2. ユーザがジョブを投入します。LSF 管理ホストはジョブスケジューリング要求を処理します。
  3. LSF 管理ホストは必要な Amazon EC2 インスタンスを起動します。Resource Connector の設定ファイルで指定されたパラメーターに基づいてこれらのインスタンス上でジョブをスケジュールします。

EC2 Fleet が統合される前は、LSF は AWS 上でインスタンスを起動するために Amazon EC2 の RunInstances と Spot Fleet API を呼び出していました。この仕組みには課題がありました。ヘテロジニアスなクラスタでは、Amazon EC2 RunInstances の呼び出しはインスタンスタイプごとに連続的に行われました。その結果、実行時間に大きな影響が出ました。数万コアのクラスタをプロビジョニングするのに何時間も掛かりました。カスタムスクリプトは計算能力を獲得するために指数関数的なバックオフアルゴリズムを実装することが多くありました。これもまた、クラスタのセットアップ時間の増加に繋がりました。異なるインスタンスタイプとアベイラビリティゾーンを構成するために複数のテンプレートが必要でした。その結果、運用上のオーバーヘッドが発生しました。インスタンス購入オプションを組み合わせることができないため、コスト最適化のための柔軟性が低下していました。

LSF による EC2 Fleet 構成

LSF Resource Connector の EC2 Fleet を使用すると、AWS 上で数万個のコンピュートコアを数分で起動できるようになります。複数のアベイラビリティゾーンにまたがるヘテロジニアスクラスターのプロビジョニングが 1 つのテンプレートで構成できます。さらに、Amazon EC2 のオンデマンドインスタンス、スポットインスタンス、リザーブドインスタンス (オンデマンド価格よりも大幅に割引される) の購入オプションを LSF の構成で併用できます。これにより、コスト最適化のためのクラスタ構成がよりシンプルかつ柔軟になります。この統合により、AWS 上でコスト効率、パフォーマンス、耐障害性に優れた HPC 環境を設計できるようになります。

LSF の EC2 Fleet サポートは Fix Pack 13 で利用可能です。こちらのインストール手順に従ってアクティベートできます。インストールが完了したら、EC2 インスタンスを起動するための設定情報を含む EC2 LaunchTemplate を作成する必要があります。LaunchTemplateId に注意してください。これは EC2 Fleet の設定に使用されます。上で説明したアーキテクチャパターンは $LSF_TOP/conf/resource_connector/aws/conf/ec2-fleet-config.jsonにある設定ファイルで設定できます。

(A) 複数のアベイラビリティゾーンに異なる種類の Amazon EC2 インスタンスタイプを持つクラスタ
LSF クラスタは数百から数千のコンピュートコアを持つことができます。AWS 上で大規模なスケールを実現する効果的なメカニズムは異なる Amazon EC2 インスタンスタイプで異種混合の LSF クラスタを構築することです。これにより、コンピュートキャパシティの可用性を最大限に高めることができます。また、LSF クラスタは 1 つの AWS リージョン内で複数のアベイラビリティゾーンにまたがることができるため、より多くのコンピュートキャパシティにアクセスできるだけでなく、耐障害性も向上します。複数のアベイラビリティゾーンにまたがる異種クラスターは ec2-fleet-config.json で以下のように設定できます。

{
   "LaunchTemplateConfigs":[
    {
      "LaunchTemplateSpecification":{
      "LaunchTemplateId": "LauncTemplateId_Created_Earlier",
      "Version":"1"
     },

// instanceType lets you specify multiple instance types within
// a single ec2 fleet configuration. Example below specifies c5
// large and 2xlarge. Subnets in the configuration lets you 
// define subnets in different AWS Availability Zones. 
     "Overrides":[
     {
       "InstanceType":"c5.large",
       "SubnetId":"subnet-0fe69d290ae026155",
       "WeightedCapacity":1
     },
     {
        “InstanceType”:”c5.2xlarge”,
        "SubnetId":"subnet-0dfee843e19bfeb52",
        "WeightedCapacity":1
     },
   ]
  }
],

"TargetCapacitySpecification":{
"TotalTargetCapacity": $LSF_TOTAL_TARGET_CAPACITY, 
"OnDemandTargetCapacity": $LSF_ONDEMAND_TARGET_CAPACITY,
"SpotTargetCapacity": $LSF_SPOT_TARGET_CAPACITY,

// DefaultTargetCapacityType can be ‘on-demand’ or ‘spot’
"DefaultTargetCapacityType": "on-demand"
},

// Type is instant for 'on-demand' and 'request' for Spot
   "Type":"instant
}
Bash

上記のテンプレートは 2 つのインスタンスタイプを定義しています。EC2 Fleet がなければ、この構成を実現するために LSF で 2 つのテンプレートを定義する必要があったでしょう。また、テンプレートの数はインスタンスタイプやアベイラビリティゾーンに応じて直線的に増えていくため、構成にエラーが発生しやすく、メンテナンスも複雑になります。EC2 Fleet を使えば、1 つのテンプレートと 1 つの API コールでこれを実現できます。

(B) スポットインスタンスとオンデマンドインスタンスを組み合わせたクラスタ
スポットインスタンスは AWS 上の未使用の Amazon EC2 キャパシティを利用することができます。オンデマンドに比べて最大 90% 割引で利用できます。LSF で EC2 Fleet がサポートされたことで、スポットインスタンスとオンデマンドインスタンスを組み合わせたり、異なる割り当て戦略を使用することで、コンピュートインスタンスの可用性を最大化できるようになりました。これは ec2-fleet-config.json で以下のように設定できます。

{
   "OnDemandOptions":{
      "AllocationStrategy": "lowest-price"
   },
   "SpotOptions":{
      "AllocationStrategy": "price-capacity-optimized",
      "InstanceInterruptionBehavior": "terminate"
   },
   "LaunchTemplateConfigs":[
      {
         "LaunchTemplateSpecification":{
            "LaunchTemplateId": "LauncTemplateId_Created_Earlier ",
            "Version":"1"
         },
         "Overrides":[
           {
               "InstanceType":"c5.2xlarge",
               "SubnetId":"subnet-06bd452f95ffd6193",
                 "WeightedCapacity":4
            }
         ]
 }
   ],

   "TargetCapacitySpecification":{
      "TotalTargetCapacity": $LSF_TOTAL_TARGET_CAPACITY,
      "OnDemandTargetCapacity": $LSF_ONDEMAND_TARGET_CAPACITY,
      "SpotTargetCapacity": $LSF_SPOT_TARGET_CAPACITY,
      "DefaultTargetCapacityType": "spot"
   },
   "Type":"request"
}
Bash

(C) インスタンスの優先順位付け機能を持つクラスタ
場合によっては、利用者は他のものよりも特定のインスタンスタイプを優先させたいことがあります。例えば、CPU ベースのライセンシングシナリオでよりメモリ量の多いインスタンスを優先したり、特定のインスタンスサイズでより良いジョブをパックする機能などです。EC2 Fleet API と LSF では ec2-fleet-config.json で以下のように起動の優先順位を指定できます。


{
  "OnDemandOptions": 
  // Allocation strategy needs to be set to ‘prioritized’
  “AllocationStrategy” : “prioritized” 
  },
  “SpotOptions”:{ 
  // AllocationStrategy can be specified as below
  “AllocationStrategy”: “price-capacity-optimized”, 
  “InstanceInterruptionBehavior”:“terminate”
},
"LaunchTemplateConfigs":[
      {
         "LaunchTemplateSpecification":{
            "LaunchTemplateId": "LauncTemplateId_Created_Earlier ",
            "Version":"1"
         },
         "Overrides":[
         {
             "InstanceType":"c5.2xlarge",
             "SubnetId":"subnet-hgr84786",
             "WeightedCapacity":1,
             // Lower the number, higher the priority for the instance type
             "Priority": 30. 
         }
       ]
 }
   ],

   "TargetCapacitySpecification":{
   "TotalTargetCapacity": $LSF_TOTAL_TARGET_CAPACITY,
   "OnDemandTargetCapacity": $LSF_ONDEMAND_TARGET_CAPACITY,
   "SpotTargetCapacity": $LSF_SPOT_TARGET_CAPACITY,
    "DefaultTargetCapacityType": "spot"
  },
  "Type":"request"
}
Bash

上記 (B) と (C) で説明した構成の柔軟性は LSF の EC2 Fleet のサポートが無ければ実現できませんでした。

ec2-fleet-config.json でパターンを定義したら、$LSF_TOP/conf/resource_connector/aws/conf/awsprov_templates.json を以下のように ec2-fleet テンプレート定義で更新する必要があります。

{
“templateId” : “ec2-fleet”,
“maxNumber” : 5000,
“attributes”: {
“types”: [“String”, “X86_64”],
“ncores”: [“Numeric”, “1”],
“ncpus”: [“Numeric”, “1”],
“mem”: [“Numeric”, “3750”],
“awshost”:[“Boolean”,“1”]
},
// Specify path to the ec2-fleet-config.json defined above
“ec2FleetConfig” : “/opt/config/ec2-fleet-config.json”, 

// You can specify the ratio for on-demand to spot instances
“OnDemandTargetCapacityRatio” :0.5 
Bash

既知の制限

この記事の公開日時点では以下の機能はサポートされていません。

  • “Maintain” フリートタイプ (EC2 Fleet タイプはこちら)
  • EC2 Fleet 構成の InstanceRequirements 属性と TargetCapacityUnitType 属性
  • スポットフリートリクエストのためのキャパシティの重み付けのサポート
  • その他の次元のターゲット容量ユニットタイプ (メモリ、GPU、その他のリソースなど)

EC2 Fleet API と LSF の AWS 機能の設定は常に開発中です。読者の皆様には、EC2 Fleet と LSF の統合に関する新機能のアナウンスをフォローしていただくことをお勧めします。

まとめ

EC2 Fleet と LSF の統合により、AWS 上での複雑な HPC アーキテクチャパターンの構成が簡単になります。ここではいくつかのパターンを取り上げますが、このブログAWS の EC2 Fleet に関するドキュメントには、さらに多くのパターンが説明されています。また、AWS 上での LSF の構成については、IBM のドキュメントを参照してください。

EC2 Fleet API の統合は、LSF Fix Pack 13 で利用できます。この機能により、クラスタのプロビジョニング時間が短縮され、生産性が大幅に向上する可能性があります。また、運用のオーバーヘッドを削減できるメリットもあります。お客様には、各 AWS アカウントチームと協力して、概念実証を行いながらこの技術を開拓していただきたいと思います。

AWS 上の半導体とエレクトロニクスについてはこちらを、AWS 上の HPC についてはこちらをご覧ください。IBM Spectrum LSF による AWS EDA ワークショップもお試しください。

翻訳はソリューションアーキテクトの 吉廣 理 が担当しました。原文はこちらです。

Kartik Gopal

Kartik Gopal

Kartik Gopal は AWS のシニアソリューションアーキテクトで、半導体のお客様が AWS を導入する際の設計支援を専門としています。Kartik のドメイン知識は、シリコン設計のための EDA ツールのオーサリングと、17 年間の業界経験における企業のクラウド導入支援の組み合わせから来ています。

Bill McMillan

Bill McMillan

Bill McMillan は IBM Spectrum Computing チームのプリンシパルプロダクトマネージャーです。さまざまな業界で 30 年以上の HPC 経験を持つ McMillan は Spectrum Computing の製品管理全般を担当しています。高性能・高スループット・コンピューティングのための GPU、コンテナ、クラウドの活用に関心があります。英国在住です。

Martin Gao

Martin Gao

Martin Gao は IBM スペクトラムコンピューティングチームのソフトウェアエンジニアです。HPC の分野で 10 年以上の経験を持ち、Spectrum Computing 製品とクラウドインフラの統合を専門としています。カナダのトロントを拠点としています。

Mayur Runwal

Mayur Runwal

Mayur Runwal は AWS のシニアソリューションアーキテクトで EDA のスペシャリストです。半導体の顧客と密接に連携し、AWS 上で EDA ソリューションの構築とアーキテクトを行っています。Runwal は半導体企業の IT 組織で 10 年以上仮想デスクトップインフラを構築していました。IT ソリューションのリード、アーキテクト、実装において豊富な経験を持っています。