すべてのプロダクト
Search
ドキュメントセンター

Function Compute:自動インスタンススケーリングの制限とルール

最終更新日:Sep 11, 2024

オンデマンドインスタンスとプロビジョニングされたインスタンスの総数、およびインスタンススケーリング速度の制限に基づいて、オートスケーリングルールを設定できます。 プロビジョニングされたインスタンスでは、スケジュールされたスケーリングポリシーと水位スケーリングポリシーを作成して、リソース使用率を向上させることができます。

インスタンススケーリングの動作

Function Computeは既存のインスタンスを優先的に使用してリクエストを処理します。 既存のインスタンスが完全にロードされた場合、Function Computeはリクエストを処理するための新しいインスタンスを作成します。 呼び出し回数が増えると、Function Computeは、リクエストを処理するのに十分なインスタンスが作成されるか、上限に達するまで、新しいインスタンスを作成し続けます。 インスタンスのスケールアウトには、スケーリング速度の制限があります。 詳細については、「異なるリージョンでのインスタンスのスケールアウト速度の制限」をご参照ください。

このセクションでは、オンデマンドおよびプロビジョニング済みインスタンスのインスタンススケーリング動作について説明します。 関数のプロビジョニング済みインスタンスを設定した後、関数の呼び出し前に特定の数のインスタンスが予約され、コールドスタートによってリクエストの実行が遅延しないようにします。

オンデマンドインスタンスのスケーリング

インスタンスの総数またはインスタンスのスケールアウト速度が制限に達すると、Function ComputeHTTPステータスコード429されたスロットリングエラーを報告します。 次の図は、呼び出し回数が急増するシナリオでFunction Computeがスロットリングを実行する方法を示しています。

image

  • ①: Function Computeは、バーストインスタンスの上限に達する前に、リクエスト数が増加するとすぐにインスタンスを作成します。 このプロセス中、コールドスタートが発生しますが、スロットリングエラーは報告されません。

  • ②: バーストインスタンスの制限に達すると、インスタンスの増加は成長率によって制限されます。 一部のリクエストでは、スロットルエラーが報告されます。

  • ③: インスタンスの上限に達すると、一部のリクエストが抑制されます。

プロビジョニング済みインスタンスのスケーリング

突然の呼び出しの数が多い場合、多数のインスタンスの作成が抑制され、リクエストが失敗します。 インスタンスのコールドスタートも、リクエストの遅延を増加させます。 このような問題を防ぐために、Function Computeでプロビジョニングされたインスタンスを使用できます。 プロビジョニングされたインスタンスは、呼び出し前に予約されます。

次の図は、前の図と同じトラフィック量のシナリオでプロビジョニングされたインスタンスのスロットリング動作を示しています。

image

  • ①: プロビジョニングされたインスタンスが完全にロードされる前に、リクエストは直ちに処理されます。 このプロセス中、コールドスタートは発生せず、スロットリングエラーは報告されません。

  • ②: プロビジョニングされたインスタンスが完全にロードされると、Function Computeはバーストインスタンスの上限に達する前にすぐにインスタンスを作成します。 このプロセス中、コールドスタートが発生しますが、スロットリングエラーは報告されません。

異なるリージョンでのインスタンスのスケールアウト速度の制限

リージョン

バーストインスタンスの上限

インスタンスの成長率の上限

中国 (杭州) 、中国 (上海) 、中国 (北京) 、中国 (張家口) 、中国 (深セン)

300

1分あたりの300

他のリージョン

100

100/ 分

  • 同じリージョンでは、プロビジョニング済みインスタンスとオンデマンドインスタンスのインスタンススケールアウト速度の制限は同じです。

  • GPU高速化インスタンスのスケーリング速度は、エラスティックインスタンスのスケーリング速度よりも遅くなります。 GPUアクセラレーションインスタンスをプロビジョニングモードと一緒に使用することを推奨します。

説明

より高速なスケーリングが必要な場合は、DingTalkグループ64970014484に参加してテクニカルサポートを行います。

プロビジョニング済みインスタンスの自動スケーリング

固定数のプロビジョニングされたインスタンスは、リソースの不十分な利用につながり得る。 この問題を解決するために、スケジュールされたスケーリングと水位スケーリングを設定できます。

説明

スケジュールされたスケーリングポリシーと水上レバーのスケーリングポリシーを設定する場合、これらのスケーリングポリシーで指定された最大値がプロビジョニングされたインスタンスの数として使用されます。

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

シナリオ

スケジュールされたインスタンスのスケーリングは、顕著な周期的パターンまたは予測可能なトラフィックピークを持つ関数に適用されます。 同時呼び出しの数がスケジュールされたスケーリングポリシーの同時実行容量よりも大きい場合、過剰なリクエストは処理のためにオンデマンドインスタンスに送信されます。

サンプル設定

2つのスケジュールされたスケーリングポリシーを設定できます。 1つ目は、トラフィックが急増する前にプロビジョニングされたインスタンスの数を増やします。 2番目のポリシーは、トラフィックが減少すると、プロビジョニングされたインスタンスの数を減らします。 詳細は以下の図をご参照ください。

image

次のコードスニペットは、スケジュールされたスケーリングポリシーを作成するために呼び出される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"
    }
  ]

次の表にパラメーターを示します。

パラメーター

説明

name

スケジュールされたスケーリングタスクの名前。

startTime

設定が有効になり始める時刻。 デフォルトでは、タイムゾーンが指定されていない場合、UTC時間が使用されます。

endTime

設定が停止して有効になる時刻。 デフォルトでは、タイムゾーンが指定されていない場合、UTC時間が使用されます。

ターゲット

プロビジョニング対象のインスタンスの数。

scheduleExpression

スケジュール情報。 タイムゾーンが指定されていない場合、UTC時間は自動的に使用されます。

次の形式がサポートされています。

  • At expressions - "at(yyyy-mm-ddThh:mm:ss)": スケジュールされたタスクを1回だけ実行します。

    たとえば、2024年4月1日の20:00 (UTC + 8) にスケジューリングを開始する場合、タイムゾーンをAsia/Shanghaiに設定し、値を (2024-04-01T20:00:00) に設定します。

  • Cron expressions - "cron(0 0 4 * * *)": スケジュールされたタスクを複数回実行します。 crontab式を使用します。

    たとえば、スケジュールされたタスクを毎日20:00 (UTC + 8) に実行する場合。 タイムゾーンをAsia/Shanghaiに設定し、このパラメーターの値をcron(0 0 20 * * *) に設定します。

timeZone

指定されたタイムゾーン。

Cron式

次の表では、cron (秒分時間月の曜日) のフィールドについて説明します。

パラメーター

値の範囲

許可された特殊文字

0から59

非該当

0から59

, - * /

時間

0から23

, - * /

月の日

1から31

, - * ? /

1〜12またはJAN〜DEC

, - * /

曜日

1〜7またはMON〜SUN

, - * ?

次の表に、cron式の特殊文字を示します。

キャラクター

説明

*

anyまたはそれぞれを示します。

[Minutes] フィールドの0は、タスクが毎分0秒で実行されることを指定します。

,

値リストを指定します。

曜日のフィールドでは、MON、WED、FRIは毎週月曜日、水曜日、金曜日を指定します。

-

範囲を指定します。

[時間] フィールドで、10-12はUTCで10:00から12:00までの時間範囲を指定します。

?

不確定な値を指定します。

この特殊文字は、他の指定された値とともに使用されます。 たとえば、日付を指定しても、指定した日付を特定の曜日にする必要がない場合は、[曜日] フィールドでこの文字を使用できます。

/

増分を指定します。 n/mは、nの位置から始まるmの増分を示す。

フィールドの3/5は、3分目から5分ごとに操作が行われることを示します。

水位スケーリング

シナリオ

Function Computeは、プロビジョニングされたインスタンスの同時使用率やプロビジョニングされたインスタンスのリソース使用率など、メトリックの値を定期的に収集します。 プロビジョニングされたインスタンスは、メトリックの値と、指定したプロビジョニングされたインスタンスの最小数と最大数に基づいてスケーリングされます。

サンプル設定

プロビジョニングされたインスタンスの並行使用率のしきい値を指定する水位スケーリングポリシーを設定したとします。 トラフィック量が増加すると、スケールアウトしきい値がトリガーされ、システムはプロビジョニングされたインスタンスのスケールアウトを開始します。 指定された最大値に達すると、スケールアウトは停止します。 過剰なリクエストはオンデマンドインスタンスに送信されます。 トラフィック量が減少すると、スケールインしきい値がトリガーされ、システムはプロビジョニングされたインスタンスのスケールを開始します。 詳細は以下の図をご参照ください。

image

説明
  • リザーブドスケーリングを使用する場合は、インスタンスレベルのメトリクス機能を有効にする必要があります。 それ以外の場合、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"
    }
  ]

次の表にパラメーターを示します。

パラメーター

説明

name

メトリックベースのスケーリングタスクの名前。

startTime

水位スケーリング設定が有効になり始める時刻。 デフォルトでは、タイムゾーンが指定されていない場合、UTC時間が使用されます。

endTime

水位スケーリング設定の有効化が停止した時刻。 デフォルトでは、タイムゾーンが指定されていない場合、UTC時間が使用されます。

metricType

追跡されるメトリックの名前。 この例では、ProvisionedConcurrencyUtilizationメトリックが追跡されます。

metricTarget

メトリックベースのスケーリングのしきい値。

minCapacity

スケールアウト用にプロビジョニングされたインスタンスの最大数。

maxCapacity

スケールイン用にプロビジョニングされたインスタンスの最小数。

timeZone

タイムゾーン。

スケーリングの原則

(0,1) の範囲内の値を有するスケールイン係数を使用することによって、比較的控えめなスケールイン処理が達成される。 スケールイン係数は、スケールイン速度を遅くするために使用されるシステムパラメータである。 スケールイン係数を設定する必要はありません。 スケーリング操作のターゲット値は、次の計算結果以上の最小の整数です。

  • スケールアウト対象=現在プロビジョニングされているインスタンス数 × (現在のメトリック値 /指定された使用率しきい値)

  • スケールインターゲット=現在プロビジョニングされているインスタンス数 × スケーリング係数 × (1-現在のメトリック値 /指定された利用率しきい値)

例:

現在のメトリック値が80% で、指定された使用率のしきい値が40% で、現在プロビジョニングされているインスタンスの数が100の場合、インスタンスのターゲット数は100 × (80%/40%) = 200です。 指定されたプロビジョニング済みインスタンスの最大数が200以上の場合、プロビジョニング済みインスタンスの数は200に増加します。 これは、利用閾値が40% に近いままであることを保証する。

最大同時実行性

次の項目では、さまざまなインスタンスの同時実行値の最大同時呼び出し数を計算する方法について説明します。

  • 単一のインスタンスが一度に単一のリクエストを処理する

    最大同時実行数=インスタンス数。

  • 1つのインスタンスが同時に複数のリクエストを処理する

    最大同時実行数=インスタンス数 × インスタンス同時実行

インスタンス同時実行機能のシナリオ、利点、設定、および影響の詳細については、「インスタンス同時実行の設定」をご参照ください。

関連ドキュメント

  • オンデマンドインスタンスとプロビジョニングされたインスタンスの基本概念と課金方法の詳細については、「インスタンスタイプと使用モード」をご参照ください。

  • プロビジョニング済みインスタンスのリソース使用率を改善する方法の詳細については、「プロビジョニング済みインスタンスの設定」をご参照ください。

  • デフォルトでは、同じリージョンのAlibaba Cloudアカウント内のすべての関数は、前述のスケーリング制限を共有します。 関数のインスタンス数を制限するには、同時インスタンスの上限を指定します。 詳細については、「同時インスタンスの最大数の指定」をご参照ください。 オンデマンドインスタンスの最大数が指定された後、Function Computeは、関数の実行中インスタンスの総数が指定された制限に達すると、スロットリングエラーを返します。