Function Compute:HeaderField アフィニティの概要

HeaderField セッションのライフサイクル

Function Compute は、HeaderField セッションのライフサイクルに 2 つのしきい値メカニズムを使用します。 次のいずれかの条件が満たされると、セッションは期限切れになります。

1. セッションのライフサイクル: セッションが作成されてから破棄されるまでの合計時間。 セッションが設定されたライフサイクル期間を超えると、Function Compute は自動的にセッションを破棄します。 アフィニティは保証されなくなります。

2. セッションのアイドル時間: セッションが非アクティブになっている期間。 セッションが指定された期間アイドル状態のままになると、期限切れになります。 最大アイドル時間は、セッションの合計ライフサイクル期間を超えることはできません。

シナリオに適した値を設定できます。

• 継続的にアクティブ: 頻繁なリクエストによってアイドルタイマーがリセットされ、非アクティブが原因でセッションが取り消されるのを防ぎます。

• アイドル時の取り消し: リクエスト間のインターバルが設定されたアイドルタイムアウトを超えると、セッションは取り消されます。

• 強制的な取り消し: インスタンスの Time to live がセッションの最大ライフサイクル期間を超えると、セッションは取り消されます。

セッションの同時実行管理

シナリオに応じて、必要に応じて制限を設定できます。

• 非アフィニティモードでは、インスタンスごとの同時実行数を調整できます。

• アフィニティモードでは、1 つのインスタンスあたりの同時セッションの最大数のみを制限できます。 1 つのインスタンス上のすべてのセッションの同時リクエストの最大数は 200 です。

セッションアフィニティの予期される動作 (インスタンスのスケジューリングルール)

シナリオ 1: セッションとインスタンスのアタッチメント、およびセッションによってトリガーされるスケールアウト

Function Compute は、インスタンスごとの同時セッション数を制限するポリシーを使用します。 各インスタンスには、最大 n 個のセッションをアタッチできます。 プロセスは次のとおりです。

1. 関数が 2 つの接続セッションを許可するように設定されているとします。 Client1 が新しいヘッダーでリクエストを送信すると、Instance1 が割り当てられ、1 つの同時セッションスロットを使用します。

2. Client2 が新しいヘッダーでリクエストを送信すると、スケジューラは Instance1 に使用可能なセッションスロットがあることを判断します。 その後、セッションは Instance1 にアタッチされます。

3. Client3 が新しいヘッダーでリクエストを送信すると、スケジューラは Instance1 の両方の同時セッションスロットが使用中であることを検出するため、新しいセッションをアタッチできません。 その後、リクエストは新しいインスタンス Instance2 にスケジュールされ、セッションがそれにアタッチされます。

シナリオ 2: 1 つのインスタンス上の複数のセッションのスロットリング

1. 関数が 2 つの同時セッションを許可するように設定されているとします。 Client1 が HeaderA を使用して最初のリクエストを送信すると、Instance1 が割り当てられます。 インスタンスは 1 つの同時セッションスロット + 1 つの同時リクエストスロット を使用します。

2. Client2 が HeaderB を使用して最初のリクエストを送信すると、スケジューラは Instance1 に使用可能な同時セッションスロットがあることを検出します。 新しいセッションは Instance1 にアタッチされます。 インスタンスは 2 つの同時セッションスロット + 2 つの同時リクエストスロット を使用します。

3. その後、Client1 と Client2 は、それぞれのヘッダーを使用してさらに 198 の同時リクエストを送信します。 インスタンスは 2 つの同時セッションスロット + 200 の同時リクエストスロット を使用します。

4. 別のリクエストが到着すると、インスタンスの 200 の同時リクエストの制限に達します。 リクエストはスロットリングされ、429 エラーが返されます。