オンデマンドインスタンスとプロビジョニングされたインスタンスの総数、およびインスタンススケーリング速度の制限に基づいて、オートスケーリングルールを設定できます。 プロビジョニングされたインスタンスでは、スケジュールされたスケーリングポリシーと水位スケーリングポリシーを作成して、リソース使用率を向上させることができます。
インスタンススケーリングの動作
Function Computeは既存のインスタンスを優先的に使用してリクエストを処理します。 既存のインスタンスが完全にロードされた場合、Function Computeはリクエストを処理するための新しいインスタンスを作成します。 呼び出し回数が増えると、Function Computeは、リクエストを処理するのに十分なインスタンスが作成されるか、上限に達するまで、新しいインスタンスを作成し続けます。 インスタンスのスケールアウトには、スケーリング速度の制限があります。 詳細については、「異なるリージョンでのインスタンスのスケールアウト速度の制限」をご参照ください。
このセクションでは、オンデマンドおよびプロビジョニング済みインスタンスのインスタンススケーリング動作について説明します。 関数のプロビジョニング済みインスタンスを設定した後、関数の呼び出し前に特定の数のインスタンスが予約され、コールドスタートによってリクエストの実行が遅延しないようにします。
オンデマンドインスタンスのスケーリング
インスタンスの総数またはインスタンスのスケールアウト速度が制限に達すると、Function ComputeはHTTPステータスコード
が429
されたスロットリングエラーを報告します。 次の図は、呼び出し回数が急増するシナリオでFunction Computeがスロットリングを実行する方法を示しています。
①: Function Computeは、バーストインスタンスの上限に達する前に、リクエスト数が増加するとすぐにインスタンスを作成します。 このプロセス中、コールドスタートが発生しますが、スロットリングエラーは報告されません。
②: バーストインスタンスの制限に達すると、インスタンスの増加は成長率によって制限されます。 一部のリクエストでは、スロットルエラーが報告されます。
③: インスタンスの上限に達すると、一部のリクエストが抑制されます。
プロビジョニング済みインスタンスのスケーリング
突然の呼び出しの数が多い場合、多数のインスタンスの作成が抑制され、リクエストが失敗します。 インスタンスのコールドスタートも、リクエストの遅延を増加させます。 このような問題を防ぐために、Function Computeでプロビジョニングされたインスタンスを使用できます。 プロビジョニングされたインスタンスは、呼び出し前に予約されます。
次の図は、前の図と同じトラフィック量のシナリオでプロビジョニングされたインスタンスのスロットリング動作を示しています。
①: プロビジョニングされたインスタンスが完全にロードされる前に、リクエストは直ちに処理されます。 このプロセス中、コールドスタートは発生せず、スロットリングエラーは報告されません。
②: プロビジョニングされたインスタンスが完全にロードされると、Function Computeはバーストインスタンスの上限に達する前にすぐにインスタンスを作成します。 このプロセス中、コールドスタートが発生しますが、スロットリングエラーは報告されません。
異なるリージョンでのインスタンスのスケールアウト速度の制限
リージョン | バーストインスタンスの上限 | インスタンスの成長率の上限 |
中国 (杭州) 、中国 (上海) 、中国 (北京) 、中国 (張家口) 、中国 (深セン) | 300 | 1分あたりの300 |
他のリージョン | 100 | 100/ 分 |
同じリージョンでは、プロビジョニング済みインスタンスとオンデマンドインスタンスのインスタンススケールアウト速度の制限は同じです。
GPU高速化インスタンスのスケーリング速度は、エラスティックインスタンスのスケーリング速度よりも遅くなります。 GPUアクセラレーションインスタンスをプロビジョニングモードと一緒に使用することを推奨します。
より高速なスケーリングが必要な場合は、DingTalkグループ64970014484に参加してテクニカルサポートを行います。
プロビジョニング済みインスタンスの自動スケーリング
固定数のプロビジョニングされたインスタンスは、リソースの不十分な利用につながり得る。 この問題を解決するために、スケジュールされたスケーリングと水位スケーリングを設定できます。
スケジュールされたスケーリングポリシーと水上レバーのスケーリングポリシーを設定する場合、これらのスケーリングポリシーで指定された最大値がプロビジョニングされたインスタンスの数として使用されます。
スケジュールされたスケーリング
シナリオ
スケジュールされたインスタンスのスケーリングは、顕著な周期的パターンまたは予測可能なトラフィックピークを持つ関数に適用されます。 同時呼び出しの数がスケジュールされたスケーリングポリシーの同時実行容量よりも大きい場合、過剰なリクエストは処理のためにオンデマンドインスタンスに送信されます。
サンプル設定
2つのスケジュールされたスケーリングポリシーを設定できます。 1つ目は、トラフィックが急増する前にプロビジョニングされたインスタンスの数を増やします。 2番目のポリシーは、トラフィックが減少すると、プロビジョニングされたインスタンスの数を減らします。 詳細は以下の図をご参照ください。
次のコードスニペットは、スケジュールされたスケーリングポリシーを作成するために呼び出されるPutProvisionConfigのリクエストパラメーターの例を示しています。 この例では、スケジュールされたスケーリングポリシーがfunction_1に設定されています。 タイムゾーンはAsia/Shanghai (UTC + 8) に設定されています。 このポリシーは、2024年8月1日の10:00:00から2024年8月30日の10:00:00まで有効になります。 このポリシーは、毎日20:00にインスタンスの数を50に増やし、毎日22:00にインスタンスの数を10に減らします。
"scheduledActions": [
{
"name": "scale_up_action",
"startTime": "2024-08-01T10:00:00",
"endTime": "2024-08-30T10:00:00",
"target": 50,
"scheduleExpression": "cron(0 0 20 * * *)",
"timeZone": "Asia/Shanghai"
},
{
"name": "scale_down_action",
"startTime": "2024-08-01T10:00:00",
"endTime": "2024-08-30T10:00:00",
"target": 10,
"scheduleExpression": "cron(0 0 22 * * *)",
"timeZone": "Asia/Shanghai"
}
]
Cron式
水位スケーリング
シナリオ
Function Computeは、プロビジョニングされたインスタンスの同時使用率やプロビジョニングされたインスタンスのリソース使用率など、メトリックの値を定期的に収集します。 プロビジョニングされたインスタンスは、メトリックの値と、指定したプロビジョニングされたインスタンスの最小数と最大数に基づいてスケーリングされます。
サンプル設定
プロビジョニングされたインスタンスの並行使用率のしきい値を指定する水位スケーリングポリシーを設定したとします。 トラフィック量が増加すると、スケールアウトしきい値がトリガーされ、システムはプロビジョニングされたインスタンスのスケールアウトを開始します。 指定された最大値に達すると、スケールアウトは停止します。 過剰なリクエストはオンデマンドインスタンスに送信されます。 トラフィック量が減少すると、スケールインしきい値がトリガーされ、システムはプロビジョニングされたインスタンスのスケールを開始します。 詳細は以下の図をご参照ください。
リザーブドスケーリングを使用する場合は、インスタンスレベルのメトリクス機能を有効にする必要があります。 それ以外の場合、
400 InstanceMetricsRequired
エラーが報告されます。 インスタンスレベルメトリックを有効にする方法の詳細については、「インスタンスレベルメトリックの設定」をご参照ください。同時実行利用率メトリックには、プロビジョニングされたインスタンスの同時実行のみが含まれ、オンデマンドインスタンスの同時実行は含まれません。
プロビジョニングされたインスタンスの同時使用率は、プロビジョニングされたインスタンスが応答する同時実行要求の最大同時実行値に対する比率です。 値の範囲は [0,1] です。
次のコードスニペットは、水位スケーリングポリシーを作成するために呼び出されるPutProvisionConfigのリクエストパラメーターの例を示しています。 この例では、水位スケーリングポリシーがfunction_1に設定されています。 タイムゾーンはAsia/Shanghai (UTC + 8) に設定されています。 このポリシーは、2024年8月1日の10:00:00から2024年8月30日の10:00:00まで有効になります。 ポリシーはProvisionedConcurrencyUtilizationを追跡し、同時実行使用率が60% を超えるとスケールアウトの実行を開始し、同時実行率が60% を下回るとスケールインの実行を開始します。 上限は100であり、下限は10である。
"targetTrackingPolicies": [
{
"name": "action_1",
"startTime": "2024-08-01T10:00:00",
"endTime": "2024-08-30T10:00:00",
"metricType": "ProvisionedConcurrencyUtilization",
"metricTarget": 0.6,
"minCapacity": 10,
"maxCapacity": 100,
"timeZone": "Asia/Shanghai"
}
]
スケーリングの原則
(0,1) の範囲内の値を有するスケールイン係数を使用することによって、比較的控えめなスケールイン処理が達成される。 スケールイン係数は、スケールイン速度を遅くするために使用されるシステムパラメータである。 スケールイン係数を設定する必要はありません。 スケーリング操作のターゲット値は、次の計算結果以上の最小の整数です。
スケールアウト対象=現在プロビジョニングされているインスタンス数 × (現在のメトリック値 /指定された使用率しきい値)
スケールインターゲット=現在プロビジョニングされているインスタンス数 × スケーリング係数 × (1-現在のメトリック値 /指定された利用率しきい値)
例:
現在のメトリック値が80% で、指定された使用率のしきい値が40% で、現在プロビジョニングされているインスタンスの数が100の場合、インスタンスのターゲット数は100 × (80%/40%) = 200です。 指定されたプロビジョニング済みインスタンスの最大数が200以上の場合、プロビジョニング済みインスタンスの数は200に増加します。 これは、利用閾値が40% に近いままであることを保証する。
最大同時実行性
次の項目では、さまざまなインスタンスの同時実行値の最大同時呼び出し数を計算する方法について説明します。
単一のインスタンスが一度に単一のリクエストを処理する
最大同時実行数=インスタンス数。
1つのインスタンスが同時に複数のリクエストを処理する
最大同時実行数=インスタンス数 × インスタンス同時実行
インスタンス同時実行機能のシナリオ、利点、設定、および影響の詳細については、「インスタンス同時実行の設定」をご参照ください。
関連ドキュメント
オンデマンドインスタンスとプロビジョニングされたインスタンスの基本概念と課金方法の詳細については、「インスタンスタイプと使用モード」をご参照ください。
プロビジョニング済みインスタンスのリソース使用率を改善する方法の詳細については、「プロビジョニング済みインスタンスの設定」をご参照ください。
デフォルトでは、同じリージョンのAlibaba Cloudアカウント内のすべての関数は、前述のスケーリング制限を共有します。 関数のインスタンス数を制限するには、同時インスタンスの上限を指定します。 詳細については、「同時インスタンスの最大数の指定」をご参照ください。 オンデマンドインスタンスの最大数が指定された後、Function Computeは、関数の実行中インスタンスの総数が指定された制限に達すると、スロットリングエラーを返します。