Function Compute の Cookie アフィニティは、同じ Cookie 情報を含むリクエストを同じ Function Compute インスタンスにルーティングします。 サーバーが Cookie アフィニティが有効になっている関数の HTTP リクエストを受信すると、HTTP リクエストヘッダーを解析します。 ヘッダーに Cookie フィールドが含まれていない場合、または Cookie フィールドに指定された Cookie 名が含まれていない場合、サーバーは自動的に SessionID を生成し、それをレスポンスの set-cookie フィールドに追加します。 クライアントからの後続のリクエストには、サーバーによって生成された Cookie 情報が含まれている必要があります。
プロトコル分析
HTTP プロトコルでは、Cookie と Set-Cookie は、クライアントとサーバー間の状態を管理するために使用される 2 つの重要なメカニズムです。
Set-Cookie: Cookie のキーと値のペア、およびプロパティを設定するために、サーバーからクライアントに送信されます。Cookie: クライアントからサーバーに送信され、サーバーによって以前に設定された Cookie 情報が含まれています。
クライアントが Cookie なしで最初のリクエストを開始すると、サーバーはレスポンスヘッダーに Set-Cookie フィールドを追加します。 このフィールドは、後続のリクエストに指定された Cookie 情報を含めるようにクライアントに指示します。
Set-Cookie 形式
Function Compute が HTTP リクエストを受信し、リクエストヘッダーに Cookie フィールドが含まれていない場合、サーバーはレスポンスに Set-Cookie フィールドを追加します。 Set-Cookie の形式は Set-Cookie: <cookie-name>=<cookie-value>; [property] です。 コンポーネントは次のように説明されています。
現在、
Max-Ageプロパティのみがサポートされています。 このプロパティは、Cookie の最大生存時間 ( TTL ) を秒単位で指定します。<cookie-name> は静的フィールドです: x-fc-cookie-session-id。
Set-Cookie: x-fc-cookie-session-id=xxx; Max-Age=3600実装
Cookie ライフサイクル
Function Compute は、Cookie ライフサイクルにデュアルしきい値メカニズムを使用します。 次のいずれかのしきい値に達すると、Cookie は期限切れになります。
セッションライフサイクル: セッションの作成と使用から破棄までのプロセス全体。 セッションがライフサイクルを超えると、Function Compute は自動的にセッションを破棄し、アフィニティを保証しなくなります。
セッションアイドル時間: セッションが指定された期間アクティビティがない場合、アイドル状態になります。 最大アイドル時間は、セッションライフサイクルを超えることはできません。
ビジネスシナリオに基づいて適切な値を設定する必要があります。
継続的なアクティビティ: 頻繁なリクエストはアイドルタイマーをリセットし、非アクティブが原因でセッションが取り消されるのを防ぎます。
アイドル時の取り消し: リクエスト間の間隔が設定されたアイドルタイムアウトを超えると、セッションは取り消されます。
強制的な取り消し: セッションの合計生存時間が設定された最大 TTL を超えると、セッションは取り消されます。
セッション同時実行管理
実際のビジネス要件に基づいて適切な制限を設定する必要があります。
非アフィニティモードでは、必要に応じてインスタンスごとの同時実行数を調整できます。
アフィニティモードでは、インスタンスの最大同時セッション数を制限できます。 単一インスタンスのすべてのセッションの最大同時リクエスト数は 200 です。
同時実行パラメータータイプ | 説明 | 調整可能 | 制限 | 消費ルール | 同時実行取り消しメカニズム |
インスタンスごとの最大同時実行数 | 単一インスタンスが同時に処理できる同時リクエストの最大数。 同時実行制限を超えるリクエストは、他のインスタンスにルーティングされるか、速度制限のために拒否されます。 | 調整不可 | 200 | 各リクエストは 1 つの同時実行ユニットを消費します。 | リクエストが処理された後、非同期的に解放されます。 |
インスタンスごとの同時セッション数 | 単一インスタンスが同時に処理できるセッションの最大数。 複数のセッションからのリクエストは、200 の同時実行数を共有します。 | 調整可能 | [1, 200] | 各 Cookie は、ライフサイクル中に 1 つのセッションを占有します。 | Cookie の期限が切れた後に解放されます。 |
アフィニティスケジューリング動作（アフィニティ/速度制限/新しいインスタンスへのスケジューリング）
シナリオ 1: セッションとインスタンスのバインディングルール、およびセッションによってトリガーされるインスタンススケールアウトメカニズム
Function Compute は、インスタンスごとの同時セッション数を制限するポリシーを提供します。 このポリシーは、各インスタンスにアタッチできるセッションの最大数を制限します。 プロセスは次のとおりです。
関数が 2 つのセッションのアタッチを許可するように設定されているとします。 Client1 が Cookie なしでリクエストを開始すると、システムは set-cookie 値を生成し、インスタンス 1 を割り当て、1 つの同時セッションを消費します。
Client2 が Cookie なしでリクエストを開始すると、スケジューラはインスタンス 1 に使用可能なセッション容量があると判断し、新しいセッションをインスタンス 1 にアタッチします。
Client3 が Cookie なしでリクエストを開始すると、スケジューラはインスタンス 1 のセッション容量がいっぱいであると判断します。 したがって、リクエストは新しいインスタンスであるインスタンス 2 にスケジューリングされます。
シナリオ 2: 単一インスタンスを共有する複数のセッションのリソース速度制限メカニズム
関数が 2 つのセッションのアタッチを許可するように設定されているとします。 Client1 が最初の Cookie リクエストを開始すると、インスタンス 1 が割り当てられます。 インスタンスは
1 つの同時セッション + 1 つのリクエスト同時実行数を消費します。Client2 が最初の Cookie リクエストを開始すると、スケジューラはインスタンス 1 に使用可能なセッション容量があると判断し、新しいセッションをインスタンス 1 にアタッチします。 この時点で、インスタンスは
2 つの同時セッション + 2 つのリクエスト同時実行数を使用しています。Client1 と Client2 は最初のリクエストからの Cookie を含め、さらに 198 の同時リクエストを送信します。 この時点で、インスタンスは
2 つの同時セッション + 200 のリクエスト同時実行数を使用しています。別のリクエストが開始されると、インスタンスのリクエスト同時実行制限である 200 に達します。 その結果、リクエストは調整され、429 エラーが返されます。
スムーズな関数更新
Cookie アフィニティシナリオでは、リクエストはリクエストレベルでステートレスである代わりに、セッションレベルでステートフルになります。 関数が更新された後、既存の Cookie を含むリクエストは、更新前にアタッチされていたインスタンスに引き続きルーティングされます。 新しい Cookie を必要とする新しいリクエストは、更新後に作成された新しいインスタンスにルーティングされます。 次の図はこのプロセスを示しています。
スムーズな移行
Function Compute 関数が更新されると ( UpdateFunction )、システムは自動的にデュアルバージョンメカニズムを有効にして、スムーズな移行を保証します。
既存の Cookie リクエスト: CookieA などの既存の Cookie を含むリクエストは、更新前のインスタンスであるインスタンス V1 に自動的にルーティングされます。
新しい Cookie リクエスト: CookieB などの新しいリクエストは、新しく作成されたインスタンスであるインスタンス V2 にアタッチされます。
破棄タイミング
既存のインスタンス ( インスタンス V1 ): リクエストを処理すると、アイドルタイマーがリセットされます。 次のいずれかの条件が満たされると、インスタンスは取り消されます。
最後のリクエストからの時間が idleTimeout よりも大きい。
インスタンスの合計生存時間が sessionTTL を超えている。
新しいインスタンス ( インスタンス V2 ): 取り消しメカニズムは、既存のインスタンスと同じです。
課金
セッションアフィニティコスト = リクエストを処理するアクティブなエラスティックインスタンスのコスト + キープアライブ期間中のアイドル状態のエラスティックインスタンスのコスト
アクティブおよびアイドル状態のエラスティックインスタンスのコストの計算方法の詳細については、「課金概要」をご参照ください。