View a markdown version of this page

加權規則的工作階段黏性 - Amazon Bedrock AgentCore
工作階段黏性的運作方式設定傳遞目標的工作階段黏性重要行為

加權規則的工作階段黏性

當您使用加權規則進行 A/B 測試或 Canary 部署時，您希望每個工作階段在多個請求之間獲得一致的體驗。如果沒有工作階段黏性，工作階段可能會收到不同的組態套件或路由到每個請求上的不同目標。路由到不同的目標意味著新的代理程式執行期，沒有先前請求的內容，這會中斷使用者體驗。

為了解決此問題，閘道支援工作階段黏性。當您在請求中包含工作階段 ID 時，閘道會儲存來自第一個請求的路由決策，並重複使用於相同工作階段中的所有後續請求。

工作階段黏性的運作方式

閘道會透過從每個請求擷取工作階段 ID 來識別工作階段。黏性流程的運作方式如下：

  1. 在具有工作階段 ID 的第一個請求上，閘道會根據設定的權重選取變體，並存放決策。

  2. 具有相同工作階段 ID 的後續請求會重複使用預存決策，而無需重新評估權重。

  3. 沒有工作階段 ID 的請求會獨立評估，不會黏性。

閘道如何判斷工作階段 ID 取決於目標類型：

  • AgentCore 執行期目標 – 閘道使用 X-Amzn-Bedrock-AgentCore-Runtime-Session-Id標頭。標頭值必須至少為 33 個字元。您不需要在第一個請求上傳送此標頭。如果 標頭不存在，代理程式執行時間會自動產生工作階段 ID，而且如果您包含該工作階段 ID，閘道會使用該自動產生的工作階段 ID 來確保後續請求的黏性。

  • HTTP 傳遞目標 – 根據預設，閘道會使用 X-Amzn-Bedrock-AgentCore-Runtime-Session-Id標頭。您也可以在目標上設定自訂工作階段識別符和逾時，因此使用自己的工作階段標頭的傳遞用戶端不必採用執行期工作階段標頭。如需詳細資訊，請參閱設定傳遞目標的工作階段黏性。

設定傳遞目標的工作階段黏性

對於 HTTP 傳遞目標，您可以在目標組態stickinessConfiguration中設定選用 ，以控制閘道如何識別工作階段，以及工作階段親和性持續多久。當您的用戶端已經傳送自己的工作階段標頭，而且您不想要求他們也傳送標準執行期工作階段標頭時，這會很有用。

stickinessConfiguration 物件包含：

  • identifier （必要） – 告知閘道在請求中在何處尋找工作階段 ID 的表達式。目前，閘道只能從請求標頭解析工作階段 ID。您可以使用下列其中一種形式指定 標頭：

    • 純 HTTP 標頭名稱，例如 x-session-id。閘道會從該請求標頭讀取工作階段 ID。

    • 形式 的內容路徑表達式$.AMZN_AC_GW_CONTEXT.headers.{header-name}，例如 $.AMZN_AC_GW_CONTEXT.headers.x-session-id。

      目前僅支援headers來源。其他來源 （例如 JWT 宣告） 目前無法使用。

  • 逾時 （選用） – 工作階段親和性逾時，以秒為單位，從 1 到 86400 (24 小時）。在此閒置期間之後，工作階段親和性會過期。視窗會重設每個請求 （滑動視窗）。

當目標具有 時stickinessConfiguration，閘道會從設定的 解析工作階段 IDidentifier。

下列範例會使用 建立傳遞目標stickinessConfiguration，該目標會從自訂x-session-id標頭擷取工作階段 ID，並在 8 小時 (28800 秒） 後使工作階段親和性過期：

aws bedrock-agentcore-control create-gateway-target --cli-input-json '{
    "gatewayIdentifier": "GATEWAY_ID",
    "name": "my-passthrough-target",
    "targetConfiguration": {
        "http": {
            "passthrough": {
                "endpoint": "https://my-service.example.com",
                "protocolType": "CUSTOM",
                "stickinessConfiguration": {
                    "identifier": "$.AMZN_AC_GW_CONTEXT.headers.x-session-id",
                    "timeout": 28800
                }
            }
        }
    },
    "credentialProviderConfigurations": [
        {"credentialProviderType": "GATEWAY_IAM_ROLE"}
    ]
}'

如需傳遞目標的詳細資訊，請參閱 HTTP 傳遞目標。

重要行為

儲存的決策優先於規則變更。如果您更新規則，現有的工作階段會繼續原始決策。這可確保工作階段一致性。若要將新規則套用至工作階段，請使用新的工作階段 ID 啟動新的工作階段。

工作階段會在閒置一段時間後過期。過期時段會重設每個請求 （滑動時段）。對於 AgentCore 執行期目標，工作階段會在閒置 15 天後過期。對於 HTTP 傳遞目標，過期時段是timeout您在目標的 stickinessConfiguration(1 到 86400 秒） 中設定的 ；如果您未設定逾時，則會套用預設值。工作階段過期後，請針對新的工作階段使用新的工作階段 ID，以避免非預期的路由行為。建議您不要重複使用過期IDs。

每個目標的工作階段狀態範圍為 。不同的目標會維持獨立的工作階段狀態。

支援 AgentCore 執行期和 HTTP 傳遞目標。MCP 目標不支援工作階段黏性。