手動でインスタンスを管理してトラフィックのピークと谷に対応するのは非効率であり、応答時間の遅延、サービスの過負荷、またはリソースの遊休につながる可能性があります。Elastic Algorithm Service (EAS) の水平オートスケーリングは、リアルタイムの負荷に基づいてサービスインスタンスの数を自動的に調整します。これにより、サービスの安定性を確保しながらリソース使用率を最大化し、コストとパフォーマンスの最適なバランスを実現します。
仕組み
水平オートスケーリングは、設定されたメトリックのしきい値に基づいてインスタンス数を動的に調整します。
目標インスタンス数の計算: システムは、現在のメトリック値 (currentMetricValue) と目標メトリック値 (desiredMetricValue) の比率に、現在のインスタンス数 (currentReplicas) を掛けることで、目標インスタンス数 (desiredReplicas) を決定します。
数式:
desiredReplicas = ceil[currentReplicas × ( currentMetricValue / desiredMetricValue )]例: 現在のインスタンスが 2 つあり、[インスタンスあたりの QPS しきい値] が 10 に設定されていると仮定します。インスタンスあたりの平均 QPS が 23 に上昇すると、目標インスタンス数は
5 = ceil[2 * (23/10)]になります。その後、平均 QPS が 2 に低下すると、目標インスタンス数は1 = ceil[5 * (2/10)]になります。複数のメトリックを設定した場合、システムは各メトリックの目標インスタンス数を計算し、これらの値の最大値を最終的な目標インスタンス数として使用します。
トリガーロジック: 計算された目標インスタンス数が現在の数より大きい場合、システムはスケールアウトをトリガーします。目標が現在の数より小さい場合、スケールインをトリガーします。
重要メトリックの変動による頻繁なスケールアウトおよびスケールイン操作を防ぐため、システムはしきい値に 10% の Toleration 範囲を適用します。例えば、秒間クエリ数 (QPS) のしきい値が 10 に設定されている場合、スケールアウト操作は QPS が一貫して 11 (10 × 1.1) を超えた場合にのみトリガーされます。これは、次のことを意味します:
QPS が 10 から 11 の間で短時間変動しても、システムはスケールアウトしません。
スケールアウト操作は、QPS が 11 以上で安定している場合にのみトリガーされます。
この仕組みにより、不要なリソースの変更が減り、システムの安定性とコスト効率が向上します。
遅延実行: スケーリング操作は、一時的なトラフィックの変動による頻繁な調整を防ぐための遅延メカニズムをサポートしています。
操作手順
PAI コンソールまたは eascmd クライアントを使用して、水平オートスケーリングポリシーを設定します。
水平オートスケーリングの有効化または更新
コンソールの利用
PAI コンソールにログインします。ページ上部でリージョンを選択します。次に、目的のワークスペースを選択し、[Elastic Algorithm Service (EAS)] をクリックします。
サービスリストで、対象サービスのサービス名をクリックしてサービス詳細ページに移動します。
[Auto Scaling] タブの [Auto Scaling] セクションで、[Auto Scaling の有効化] または [更新] をクリックします。


[Auto Scaling 設定] ダイアログボックスで、次のパラメーターを設定します。
パラメーターの説明
基本構成
パラメーター
説明
推奨事項とリスク警告
[インスタンスの最小数]
サービスがスケールインできるインスタンスの最小数です。最小値は 0 です。
本番環境の推奨事項: 継続的な可用性が必要なサービスでは、この値を
1以上に設定することを強く推奨します。重要この値を
0に設定すると、トラフィックがない場合にすべてのサービスインスタンスが削除されます。その場合、新しいリクエストは完全なコールドスタートの遅延 (数十秒から数分かかる場合があります) に直面し、その間サービスは利用できなくなります。また、専用ゲートウェイを使用するサービスでは、この値を0に設定することはサポートされていません。最大インスタンス数
サービスがスケールアウトできるインスタンスの最大数です。最大値は 1000 です。
予期しないトラフィックの急増によるコスト超過を防ぐため、予測されるピークトラフィックとアカウントのリソースクォータに基づいてこの値を設定します。
一般的なスケーリングメトリクス
スケーリングをトリガーするために使用される組み込みのパフォーマンスメトリックです。
[インスタンスあたりの QPS しきい値]: ストレステストの結果に基づいて設定し、通常は単一インスタンスの最適パフォーマンスの 70% から 80% に設定します。
重要単一インスタンスの QPS しきい値を小数値に設定するには、クライアント (eascmd) を使用して
qps1kフィールドを設定します。[CPU 使用率のしきい値]: この値を低く設定しすぎるとリソースの無駄遣いになり、高く設定しすぎるとリクエストのレイテンシーに悪影響を与える可能性があります。応答時間 (RT) メトリックに基づいてこの値を設定します。
[GPU 使用率のしきい値]: RT メトリックに基づいてこの値を設定します。
[非同期キューの長さ]: 非同期サービスにのみ適用されます。平均タスク処理時間と許容可能なレイテンシーに基づいて設定します。詳細については、「非同期推論サービスの水平オートスケーリングの設定」をご参照ください。
カスタムスケーリングメトリクス
カスタムメトリックをレポートし、オートスケーリングに使用できます。詳細については、「カスタムモニタリングとスケーリングメトリック」をご参照ください。
組み込みのメトリックがビジネス要件を満たさない複雑なシナリオに適しています。
高度な構成
パラメーター
説明
推奨事項とリスク警告
[スケールアウト遅延]
スケールアウト決定のための観測ウィンドウです。スケールアウトがトリガーされた後、システムはこの期間中にメトリックを観測します。メトリック値がしきい値を下回った場合、スケールアウトはキャンセルされます。単位は秒です。
デフォルトは
0秒で、即座にスケールアウトが発生することを意味します。一時的なトラフィックの急増による不要なスケーリングを防ぐために、この値を増やします (例:60 秒)。スケールイン遅延
スケールイン決定のための観測ウィンドウで、サービスのジッターを防ぐための重要なパラメーターです。スケールインは、メトリックがこの期間全体でしきい値を下回り続けた後にのみ発生します。単位は秒です。
デフォルトは
300秒です。これは、トラフィックの変動による頻繁なスケールインイベントに対する中心的な保護機能です。サービスの安定性に影響を与える可能性があるため、この値を低く設定しすぎないでください。ゼロへのスケールイン遅延
[インスタンスの最小数] が
0の場合、このパラメーターはインスタンス数が0に減少するまでの待機時間を定義します。サービスの完全なシャットダウンを遅らせ、トラフィックが回復する可能性に備えたバッファーを提供します。
ゼロからの追加インスタンス
サービスが
0インスタンスからスケールアウトする際に追加するインスタンス数です。初期のトラフィックバーストに対応でき、コールドスタート中のサービスの利用不能時間を短縮できる値に設定します。
クライアントの利用
コマンドを実行する前に、クライアントをダウンロードして認証していることを確認してください。有効化と更新の両方で autoscale コマンドを使用します。-D パラメーターまたは JSON 設定ファイルを使用してポリシーを設定します。
パラメーター形式:
# 形式: eascmd autoscale [region]/[service_name] -D[attr_name]=[attr_value] # 例: インスタンスの最小数を 2、最大数を 5、QPS しきい値を 10 に設定します。 eascmd autoscale cn-shanghai/test_autoscaler -Dmin=2 -Dmax=5 -Dstrategies.qps=10 # 例: スケールイン遅延を 100 秒に設定します。 eascmd autoscale cn-shanghai/test_autoscaler -Dbehavior.scaleDown.stabilizationWindowSeconds=100設定ファイル形式:
# ステップ 1: 設定ファイル (例:scaler.json) を作成します。 # ステップ 2: コマンドを実行します: eascmd autoscale [region]/[service_name] -s [desc_json] # 例 eascmd autoscale cn-shanghai/test_autoscaler -s scaler.json
設定例
次の scaler.json の例には、一般的な設定オプションが含まれています:
パラメーターの説明
パラメーター | 説明 |
| インスタンスの最小数。 |
| インスタンスの最大数。 |
| スケーリングメトリックとしきい値。
|
| コンソールの[スケールアウト遅延] に対応します。 |
| コンソールの[スケールイン遅延] に対応します。 |
水平オートスケーリングの無効化
クライアントの利用
コマンド形式
eascmd autoscale rm [region]/[service_name]例
eascmd autoscale rm cn-shanghai/test_autoscaler
本番環境でのベストプラクティス
シナリオ別の設定ガイド
CPU 負荷の高いオンライン推論サービス: [CPU 使用率のしきい値] と [インスタンスあたりの QPS しきい値] の両方を設定します。CPU 使用率はリソースの消費を、QPS はビジネスの負荷を反映します。これらのメトリックを組み合わせることで、より正確なスケーリングが可能になります。
GPU 負荷の高いオンライン推論サービス: 主に [GPU 使用率] のしきい値に注目します。GPU コンピューティングユニットが飽和状態になった場合、迅速にスケールアウトして、サービスがより多くの同時タスクを処理できるようにします。
非同期タスク処理サービス: [非同期キューの長さ] をコアメトリックとして使用します。キュー内のバックログタスク数がしきい値を超えた場合、スケールアウトによって処理能力が向上し、タスクの待機時間が短縮されます。
安定性のためのベストプラクティス
ゼロへのスケールインを避ける: 本番環境の同期サービスでは、継続的な可用性と低レイテンシーを確保するために、常に[インスタンスの最小数] を
1以上に設定します。適切な遅延を設定する: [スケールイン遅延] を使用して、通常のトラフィック変動によるサービスのジッターを防ぎます。デフォルト値の
300秒は、ほとんどのシナリオに適しています。
よくある質問
しきい値に達してもサービスがスケールアウトしないのはなぜですか?
考えられる原因は次のとおりです:
リソースクォータの不足: 現在のリージョンにおけるアカウントの利用可能な vCPU または GPU クォータが枯渇しています。
スケールアウト遅延がアクティブ: [スケールアウト遅延] を設定した場合、システムはこの期間が終了するのを待って、トラフィックの増加が持続的であることを確認しています。
インスタンスのヘルスチェックの失敗: 新しくスケールアウトされたインスタンスがヘルスチェックに失敗し、操作が失敗しました。
インスタンスの最大数に到達: 現在のインスタンス数が、設定された[インスタンスの最大数] の上限に達しています。
サービスが頻繁にスケールイン/スケールアウト (ジッター) するのはなぜですか?
これは通常、スケーリングポリシーが不適切に設定されていることが原因です:
しきい値が敏感すぎる: しきい値が通常の負荷レベルに近すぎると、わずかな変動でもスケーリングイベントがトリガーされます。
スケールイン遅延が短すぎる: 遅延期間が短いと、システムは一時的なトラフィックの減少に過剰反応し、不要なスケールインにつながります。トラフィックが回復すると、すぐに別のスケールアウトがトリガーされます。[スケールイン遅延] を長く設定してください。
関連ドキュメント
スケジュールされた時間にインスタンス数を自動的にスケーリングする方法の詳細については、「スケジュールされたオートスケーリング」をご参照ください。
変化する需要に合わせてリソースを柔軟に割り当てる方法の詳細については、「弾性リソースプール」をご参照ください。
カスタムモニタリングメトリックを使用してオートスケーリングの効果をモニタリングする方法の詳細については、「カスタムモニタリングとスケーリングメトリック」をご参照ください。