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

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

インスタンス数またはスケーリング速度が制限を超えた場合、Function ComputeはHTTP 429のステータスコードを返し、スロットリングエラーが発生したことを示します。 次の図は、呼び出しが急増したときにFunction Computeがスロットリングを適用する方法を示しています。

• ①: Function Computeは、リクエストの急増に対応するインスタンスを即座に作成します。 このプロセス中にコールドスタートが発生します。 バースト可能インスタンスの数が上限に達していないため、スロットリングエラーは報告されません。

• ②: インスタンス数の増加は、バースト可能なインスタンスの上限に達したため、インスタンスの増加率によって制限されるようになりました。 一部のリクエストでは、スロットルエラーが報告されます。

• ③: インスタンス数が上限に達したため、一部のリクエストでスロットリングエラーが発生しました。

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

突然の呼び出しの数が多すぎると、スロットリングエラーが避けられなくなります。 さらに、新しいインスタンスの作成によりコールドスタートが発生します。 どちらもリクエスト処理のレイテンシを増加させます。 遅延を軽減するために、事前にFunction Computeでインスタンスを予約できます。 これらのリザーブドインスタンスは、プロビジョニング済みインスタンスと呼ばれます。

次の図は、プロビジョニングされたインスタンスが設定され、オンデマンドモードの場合と同様に呼び出しが急増した場合に、Function Computeがどのようにスロットリングを適用するかを示しています。

• ①: すべての受信リクエストは、プロビジョニングされたインスタンスが全容量に達するまですぐに処理されます。 このプロセス中、コールドスタートは発生せず、スロットリングエラーは報告されません。

• ②: プロビジョニングされたインスタンスが完全に活用されました。 Function Computeは、バースト可能なインスタンスの数が上限に達するまで、後続のリクエストを処理するオンデマンドインスタンスの作成を開始します。 このプロセス中、コールドスタートが発生しますが、スロットリングエラーは報告されません。

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

シナリオ

関数で明確な周期パターンや予測可能なトラフィックピークが発生した場合は、スケジュールスケーリングを選択します。 同時呼び出しの数がスケジュールされたスケーリングポリシーで定義された容量を超えると、すべての過剰なリクエストは処理のためにオンデマンドインスタンスに送信されます。

サンプル設定

次の図は、インスタンスのスケーリングの2つのスケジュールされたアクションを示しています。最初のアクションは、トラフィックのピーク前にプロビジョニングされたインスタンスをスケールアウトし、2番目のアクションはその後にインスタンスをスケールアウトします。

次のコードスニペットは、PutProvisionConfig操作を呼び出して、スケジュールされたスケーリングポリシーを設定する方法を示しています。 この例では、function_1という名前の関数は、タイムゾーンをAsia/Shanghai (UTC + 8) に設定して、自動的にスケールインおよびスケールアウトするように設定されています。 設定は、2024年8月1日の10:00:00から2024年8月30日の10:00:00 (UTC + 8) まで有効になります。 この期間中、プロビジョニングされたインスタンスの数は、毎日20:00 (UTC + 8) に50に増加し、22:00 (UTC + 8) に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はプロビジョニングされたインスタンスの同時実行性またはリソース使用率のメトリクスを定期的に収集します。 これらのメトリックと、指定したプロビジョニング済みインスタンスの最小数と最大数を使用して、インスタンスのスケーリングを制御し、インスタンスの数が実際のリソース使用量とより密接に一致するようにします。

サンプル設定

次の図は、インスタンス同時実行の使用率に基づくオートスケーリングの例を示しています。 トラフィック量が増加すると、スケールアウトしきい値がトリガーされ、Function Computeはプロビジョニングされたインスタンスの数を増やし始めます。 スケールアウトは、数値が設定した上限に達すると停止します。 過剰なリクエストは、処理のためにオンデマンドインスタンスに送信されます。

次のコードスニペットは、PutProvisionConfig操作を呼び出してしきい値ベースのスケーリングポリシーを設定する方法を示しています。 この例では、function_1という名前の関数は、プロビジョニングされたインスタンスの同時使用率を追跡するProvisionedConcurrencyUtilizationメトリックに基づいて自動的にスケールインおよびスケールアウトするように構成されています。 タイムゾーンはAsia/Shanghai (UTC + 8) に設定されています。 設定は、2024年8月1日の10:00:00から2024年8月30日の10:00:00 (UTC + 8) まで有効になります。 この期間中、同時実行使用率が60% を超えると、プロビジョニングされたインスタンスの数は最大100まで増加します。 逆に、同時実行使用率が60% を下回ると、プロビジョニングされたインスタンスの数は最小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"
    }
  ]

スケーリングの原則

インスタンスのスケールインがトリガーされると、Function Computeは、0 (除外) から1までのスケールイン係数に基づいて、プロビジョニングされたインスタンスの数を徐々に減らします。 スケールイン係数は、スケールイン速度を遅くするために使用されるシステムパラメータである。 手動設定は必要ありません。 スケーリングタスクのターゲット値は、次の計算結果以上の最小の整数です。

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

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

次の例は、スケールアウトターゲットの計算方法を示しています。 同様に、スケールインターゲットは、前述の原理および式を使用して決定することができる。

現在のメトリック値が80% であり、指定された利用しきい値が40% であり、プロビジョニングされたインスタンスの現在の数が100である場合、インスタンスのターゲット数は次のように計算されます。100 × (80%/40%) = 200。 プロビジョニングされたインスタンスの数が200に増加します (これが許容される最大値を超えない限り) 。これにより、使用率が約40% に維持されます。