Platform For AI:PAI-EAS Spot のベストプラクティス

利用シーン

• クリティカルではないワークロード： たまにサービスが中断しても影響が最小限であるアプリケーション。

• フォールトトレラントなアプリケーション： リトライや他のフォールトトレランスメカニズムによって、一時的な利用不可に対応できるアプリケーション。

• コスト重視のプロジェクト： 運用コストの削減が最優先事項であるプロジェクト。

スポットサービスの設定

1. PAI コンソールにログインします。ページ上部でリージョンを選択します。次に、目的のワークスペースを選択し、Elastic Algorithm Service (EAS) をクリックします。

3. 「リソースのデプロイ」セクションで、リソースタイプとして Public Resources を選択し、インスタンスタイプを選択します。L または H シリーズのインスタンスタイプを使用することを推奨します。入札モードをオンにし、入札価格を入力します。過去 48 時間のインスタンスタイプの市場価格の推移を確認するために、過去の価格曲線をクリックして入札の参考にすることができます。

   

   重要

   • 入札価格は、支払う意思のある最大価格であり、最終的に請求される価格ではありません。市場価格が入札価格を下回っている限り、現在の市場価格で請求されます。これにより、市場価格のみを支払いながら、価格変動によるインスタンスの回収を防ぐことができます。

   • 入札価格を定価の 20% に設定することを強く推奨します。例えば、8 コア、シングルカードの L20 インスタンスの従量課金の定価が 14.4 CNY/時間である場合、スポットインスタンスの市場価格が定価の 20% (2.88 CNY/時間) を超えることはほとんどありません。この戦略により、安定したリソースの可用性を維持しながら、大幅なコスト削減の恩恵を受けることができます。詳細については、「スポットインスタンスの選択」をご参照ください。

   • スポットインスタンスの割り当てに失敗した場合のデプロイの失敗を防ぐために、フォールバックとしてオンデマンドインスタンスも設定することを推奨します。

4. サービスがデプロイされた後、EAS のサービス詳細ページで過去 48 時間のインスタンスタイプの価格変動をモニターできます。これにより、コストの変動を把握し、管理することができます。

スポットインスタンスの回収とフォールトトレランス

EAS による回収

EAS は、スポットインスタンスが回収される約 5 分前に警告通知を受け取ります。通知を受け取ると、EAS はグレースフルシャットダウンを開始してインスタンスからトラフィックを移行し、サービスの中断を防ぎます。同時に、EAS は自動的に新しいインスタンスを起動し、設定のインスタンスタイプの順序に基づいてデプロイを試みます。このプロセスにより、回収による中断を最小限に抑え、サービスの継続性を確保します。

スポットインスタンスへの復帰

スポットインスタンスが回収され、オンデマンドインスタンスに置き換えられた場合、「インスタンスの再構築」機能を使用して、スポットインスタンスの在庫が回復した後にインスタンスをスポットインスタンスに戻すことができます。

インスタンスの再構築 機能を使用して、インスタンスリソースを解放し、同じ設定でインスタンスを再作成します：

推奨される設定戦略

スポットインスタンスが回収されそうになると、EAS はグレースフルシャットダウンを開始すると同時に、代替インスタンスを起動します。サービスの安定性と信頼性を向上させ、新しいインスタンスの起動を高速化するために、以下の設定戦略を推奨します。

複数のインスタンスタイプの設定

安定性と信頼性を高めるために、複数のインスタンスタイプを選択することを推奨します。重要なのは、フォールバックとして、設定リストに少なくとも 1 つのオンデマンドインスタンス (入札モードをオフにしたもの) を含めることです。EAS は指定した順序でインスタンスのデプロイを試みるため、安定したデプロイと運用の可能性が高まります。詳細については、「複数のインスタンスタイプの選択」をご参照ください。

ローカルディレクトリのメモリキャッシュの設定

スポットインスタンスが回収された後、新しいインスタンスのモデルファイルの読み込みを高速化するために、ローカルディレクトリのメモリキャッシュを設定します。この機能は、ノードの予備メモリを使用してモデルファイルをキャッシュします。新しいインスタンスは、マウントされたデータソースからではなく、キャッシュからモデルを読み込むことができるため、起動時間が短縮され、スポットインスタンスの回収によるダウンタイムが最小限に抑えられます。

インスタンスのスケールアウト効率を向上させるために、サービス作成時に メモリキャッシュ を有効にすることを推奨します。詳細については、「モデルキャッシュアクセラレーション」をご参照ください。

次の表は、メモリキャッシュ (cachefs) を有効にした後の高速化効果を示しています。Stable Diffusion モデルを例にとると、メモリキャッシュが有効な場合、新しいインスタンスはスケールアウト中にサービス内の他のインスタンスのメモリから直接モデルを読み込むことができます (cachefs リモートヒット)。これにより、マウントされた OSS ディレクトリから直接読み取る場合と比較して、モデルの読み込み時間が大幅に短縮されます。

ACR Enterprise Edition の使用

回収後に新しいインスタンスのイメージのプルを高速化するには、イメージアクセラレーションを有効にした ACR Enterprise Edition を使用します。高速化イメージを使用して EAS サービスをデプロイします。標準のイメージ URL に _accelerated サフィックスを追加して、高速化イメージ URL を作成します。サービスをデプロイする際は、ACR Enterprise Edition インスタンスで使用されている VPC を必ず選択してください。

ACR Enterprise Edition インスタンスで、インスタンスタイプ に Standard を選択します。イメージリポジトリを作成する際に、イメージアクセラレーションを有効にして、新しいインスタンスのスケールアウト効率を向上させます。詳細については、「イメージアクセラレーション」をご参照ください。

次の図は、EAS でのカスタムデプロイのイメージ設定を示しています：

ACR Standard Edition インスタンスタイプを購入します：

イメージリポジトリを作成する際にイメージアクセラレーションを有効にします：

自動スケーリングとの組み合わせ

変動の大きいワークロードには、水平自動スケーリングを有効にすることを推奨します。ベースラインキャパシティのための専用リソースグループ、弾力的なスケーリングのためのスポットインスタンス、フォールバックのためのオンデマンドインスタンス というハイブリッド戦略を採用できます。このアプローチにより、スムーズなサービス運用とコスト効率が確保されます。推奨される戦略は次のとおりです：

1. サブスクリプションまたは従量課金の専用リソースグループを購入して、サービスのベースラインキャパシティを確立します。コンソールで、専用リソースグループの GPU、CPU、およびメモリ要件を設定して、サービスが開始できるようにします。

2. Elastic Resource Pool を有効にし、複数のインスタンスタイプを設定します。リストではスポットインスタンスを優先し、オンデマンドインスタンスを最終手段のフォールバックとします。この戦略により、トラフィックのピーク時にコスト効率の高いスポットインスタンスを使用してサービスをスケールアウトできます。スポットインスタンスが利用できない場合、サービスはシームレスにオンデマンドインスタンスにフェイルオーバーし、コスト効率とサービスの安定性の両方を確保します。

   

3. サービスがデプロイされた後、サービス詳細ページに移動し、ビジネスメトリクスに基づいて水平 Auto Scaling を有効にします。QPS、CPU 使用率、GPU 使用率、キューの長さなどのメトリクスに基づいてスケーリングポリシーを設定できます。カスタムメトリクスを使用して自動スケーリングすることもできます。

   

   また、スケジュールスケーリング を有効にして、予測可能なトラフィックパターンに対応することもできます。

   

インスタンスは、まず専用リソースグループのリソースを使用して作成されます。さらにリソースが必要な場合は、システムは弾性リソースプールのリソースを使用し、指定した順序でインスタンスタイプを巡回します。

• 例えば、専用リソースグループが完全に利用され、弾性リソースプールに複数のインスタンスを作成する必要がある場合、システムはまず ecs.gn8v-8x.48xlarge の在庫を確認します。在庫が不十分な場合は、ecs.gn8is-8x.32large を確認します。両方とも不十分な場合は、ml.gu7i.c8m30.1-gu30 を使用して残りのインスタンスを作成します。

• 例えば、ご利用のサービスが専用リソースグループ内の 2 つのインスタンスで実行されており、さらに 8 つのインスタンスをスケールアウトする必要があるとします。これら 8 つの新しいインスタンスの割り当ては、可用性と設定に基づいて、3 つの ecs.gn8v-8x.48xlarge スポットインスタンス、2 つの ecs.gn8is-8x.32large スポットインスタンス、および 3 つの ml.gu7i.c8m30.1-gu30 オンデマンドインスタンスになる可能性があります。

EAS で弾力的なスケーリングを設定する方法の詳細については、次のトピックをご参照ください：

• 水平自動スケーリング

• スケジュールスケーリング

• 弾性リソースプール