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

シナリオ

• 非クリティカルビジネス: 時折のサービスの中断が最小限の影響を与えるアプリケーション。

• フォールトトレラント処理: 再試行メカニズムまたはその他のフォールトトレランス方法を使用して、一時的なサービスの中断を管理できます。

• コスト最適化に対する高い需要: より手頃で柔軟なコンピューティングリソースを使用して運用コストを削減することを目的とした企業やプロジェクト。

スポットサービスの作成

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

2. [モデルオンラインサービス (EAS)] ページで、[サービスのデプロイ] をクリックします。 [カスタムモデルのデプロイ] セクションで、[カスタムデプロイ] をクリックします。

3. [リソースのデプロイ] セクションで、リソースタイプとして [パブリックリソース] を選択します。 リソース仕様 (LまたはH仕様を推奨) を選択します。

   入札スイッチをオンにして、入札を設定します。 入札を通知するには、過去48時間のモデルの市場価格の傾向を示す過去の価格曲線を表示できます。

   

   重要

   • 入札価格は、市場価格である実際の価格ではありません。 入札価格は、あなたが支払う意思のある最大価格を表します。 市場価格が入札価格よりも低い場合、リソースはユーザーに割り当てられたままであり、リリースされません。 あなたは実際に入札価格ではなく市場価格を請求されます。

   • 入札価格を元の価格の20% に設定することを強くお勧めします。 たとえば、インスタンスの従量課金価格が1時間あたり2.58ドルの場合、市場価格が元の価格である1時間あたり0.516ドルの20% を超える可能性はほとんどありません。 この戦略により、安定したリソース可用性を確保しながら大幅なコスト削減が可能になります。 詳細は、「プリエンプティブルインスタンスの指定」をご参照ください。

   • インスタンスのプリエンプションが発生した場合にサービスのデプロイが失敗しないように、プリエンプティブルインスタンスと一緒に通常のインスタンスを設定することを推奨します。

4. サービスのデプロイ後、サービスの詳細ページで過去48時間のモデルの価格変動を監視できます。 この洞察は、コスト変動の理解と管理に役立ちます。

リサイクルとフォールトトレランスメカニズム

EAS側のリサイクルメカニズム

EASは通常、スポットインスタンスのリサイクル予定の約5分前に通知を受け取ります。 通知を受けると、EASは正常なシャットダウンを開始して、リサイクルが予定されているインスタンスからトラフィックをスムーズに迂回させ、サービスの中断を防ぎます。 同時に、EASは新しいインスタンスを自動的に起動し、リソース構成で指定された順序でデプロイして、リサイクルの影響を最小限に抑え、中断のないカスタマーサービスを維持します。

リサイクル後にスポットインスタンスに戻す

通常のリソースがリサイクルされたスポットインスタンスを置き換え、インベントリが復元されたらスポットインスタンスに切り替える場合は、[インスタンスの再構築] 機能を使用します。

[インスタンスの再構築] をクリックしてリソースをリリースし、同じ構成のインスタンスを再作成します。

推奨設定戦略

サービスの安定性と信頼性を高め、新しいインスタンスの起動を高速化するには、次の設定戦略をお勧めします。

複数の仕様のインスタンスの設定

サービスの安定性と信頼性のために、さまざまな仕様を選択してリソース構成を多様化します。 少なくとも1つの通常リソースをバックアップとして構成に含めます。 EASサービスはサービス操作の安定性を最大にする指定順序に基づいて指定を順次使用できます。 詳細は、「複数のインスタンスタイプの指定」をご参照ください。

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

リサイクル後に新しいインスタンスを起動するときにモデルファイルを取得するプロセスを高速化するには、ローカルディレクトリのメモリキャッシュを設定します。 これにより、アイドルメモリを使用してモデルファイルをキャッシュし、スケールアウト時にモデルファイルを読み取るために必要な時間を短縮し、スポットリサイクルによるサービスのダウンタイムを軽減します。

EASサービスの作成時にメモリキャッシュを有効にして、インスタンスのスケールアウト効率を高めます。 詳細については、「ローカルディレクトリのメモリキャッシュの有効化」をご参照ください。

次の表に、安定拡散モデルを例として使用したメモリキャッシュ (cachefs) の利点を示します。 cachefsを有効にすると、スケールアウト中にサービス内の他のインスタンスのメモリからモデルを読み取ることができ (cachefsリモートヒット) 、マウントされたOSSディレクトリから直接読み取る場合と比較して、モデルの読み込み時間が大幅に短縮されます。

ACR Enterprise Editionの使用

リサイクル後に新しいインスタンスを起動するときのイメージプル効率を向上させるには、イメージアクセラレーションを有効にしたContainer Registry (ACR) Enterprise Editionを使用します。 _acceleratedサフィックス付きの高速化イメージを使用してEASサービスを展開します。 また、EASサービスをデプロイするときは、ACRインスタンスに関連付けられた同じVPCを選択します。

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

以下は、EASカスタム展開中のイメージ構成の例です。

ACRインスタンスを購入する:

イメージリポジトリの作成時にAccelerated Imageを有効にします。

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

負荷変動が大きいビジネスでは、水平自動スケールアウトとスケールインを有効にすることを推奨します。 専用リソースグループ、スポットリソーススケーリング、および通常リソースの組み合わせを使用して、スムーズなサービス運用とコスト効率を確保します。 設定戦略:

1. EASサブスクリプション /従量課金制の専用リソースグループを購入することで、サービストラフィックの基本レベルを保護します。 コンソールで専用リソースグループを設定して、サービス起動のGPU、CPU、およびメモリ要件を満たします。

2. Elastic Resource Poolを有効にし、複数のリソース仕様を設定します。 スポットリソースを優先し、フォールバックリソースを最後に使用します。 このアプローチにより、ピーク時に十分な在庫を持つリソースをスポットするための拡張が可能になります。 スポットリソースが不十分な場合は、通常のリソースを使用して、ビジネスのピーク時のスムーズなスケールアウトを保証します。

   

3. サービスのデプロイ後、サービスの詳細ページでビジネスメトリックに基づいてAuto Scalingを有効にします。 QPS、CPU使用率、GPU使用率などの一般的なスケーリングメトリックを使用できます。

   または、ニーズに合わせてメトリックをカスタマイズできます。

   

   スケジュールされたスケーリングを有効にして、予測可能な時間のトラフィック変動に合わせることもできます。

   

サービスを作成するとき、専用のリソースグループリソースが最初に使用され、その後、設定されたソートに基づいてエラスティックリソースプールから利用可能なリソースが順次割り当てられます。

• たとえば、専用リソースグループが完全に使用されていて、パブリックリソースプールへのスケーリングが必要な場合、システムは、現在のecs.gn61-c16g1.4xlargeのインベントリで作成できるインスタンスの数を評価します。 それでもリソースが不十分な場合は、ecs.gn61-c24g1.6xlargeを検討し、最後に残りのインスタンスについては通常のecs.gn6i-c16g1.4xlargeを検討します。

• 専用リソースグループ以外に8つのインスタンスが必要な場合、割り当ては専用リソースグループから2つ、ecs.gn61-c16g1.4xlargeから3つ、ecs.gn61-c24g1.6xlargeから2つ、通常のecs.gn61-c16g1.4xlargeから1つです。

EASスケーリングの詳細については、以下を参照してください。

• 自動スケーリング

• スケジュールされたスケーリング

• Elasticリソースプール