View a markdown version of this page

Einhaltung gewichteter Regeln in der Sitzung - Amazon Grundgestein AgentCore
So funktioniert Session-StickinessKonfigurieren Sie die Sitzungsbindung für Passthrough-ZieleWichtige Verhaltensweisen

Einhaltung gewichteter Regeln in der Sitzung

Wenn Sie gewichtete Regeln für A/B Tests oder kanarische Bereitstellungen verwenden, möchten Sie, dass jede Sitzung über mehrere Anfragen hinweg ein einheitliches Erlebnis bietet. Ohne Sitzungsbindung könnte eine Sitzung bei jeder Anfrage unterschiedliche Konfigurationspakete erhalten oder an unterschiedliche Ziele weitergeleitet werden. Das Routing zu einem anderen Ziel bedeutet eine neue Agentenlaufzeit ohne Kontext aus früheren Anfragen, was die Benutzererfahrung beeinträchtigt.

Um dieses Problem zu lösen, unterstützt das Gateway Session Stickiness. Wenn Sie eine Sitzungs-ID in Ihre Anfragen aufnehmen, speichert das Gateway die Routing-Entscheidung aus der ersten Anfrage und verwendet sie für alle nachfolgenden Anfragen in derselben Sitzung wieder.

So funktioniert Session-Stickiness

Das Gateway identifiziert eine Sitzung, indem es aus jeder Anfrage eine Sitzungs-ID extrahiert. Der Stickiness-Flow funktioniert wie folgt:

  1. Bei der ersten Anfrage mit einer Sitzungs-ID wählt das Gateway anhand der konfigurierten Gewichte eine Variante aus und speichert die Entscheidung.

  2. Nachfolgende Anfragen mit derselben Sitzungs-ID verwenden die gespeicherte Entscheidung wieder, ohne die Gewichte erneut auszuwerten.

  3. Anfragen ohne Sitzungs-ID werden unabhängig voneinander ausgewertet, ohne dass es zu Verzögerungen kommt.

Wie das Gateway die Sitzungs-ID ermittelt, hängt vom Zieltyp ab:

  • AgentCore Laufzeitziele — Das Gateway verwendet den X-Amzn-Bedrock-AgentCore-Runtime-Session-Id Header. Der Header-Wert muss mindestens 33 Zeichen lang sein. Sie müssen diesen Header nicht bei der ersten Anfrage senden. Wenn der Header nicht vorhanden ist, generiert die Agenten-Laufzeit automatisch eine Sitzungs-ID, und das Gateway verwendet diese automatisch generierte Sitzungs-ID, um bei nachfolgenden Anfragen zu bleiben, wenn Sie sie angeben.

  • HTTP-Passthrough-Ziele — Standardmäßig verwendet das Gateway den Header. X-Amzn-Bedrock-AgentCore-Runtime-Session-Id Sie können auch eine benutzerdefinierte Sitzungs-ID und ein Timeout für das Ziel konfigurieren, sodass Passthrough-Clients, die ihren eigenen Sitzungsheader verwenden, den Runtime-Sitzungsheader nicht übernehmen müssen. Weitere Informationen finden Sie unter Sitzungs-Stickiness für Passthrough-Ziele konfigurieren.

Konfigurieren Sie die Sitzungsbindung für Passthrough-Ziele

Für HTTP-Passthrough-Ziele können Sie stickinessConfiguration in der Zielkonfiguration eine Option festlegen, mit der Sie steuern können, wie das Gateway Sitzungen identifiziert und wie lange die Sitzungsaffinität anhält. Dies ist nützlich, wenn Ihre Clients bereits ihren eigenen Sitzungsheader senden und Sie nicht möchten, dass sie auch den standardmäßigen Runtime-Sitzungsheader senden.

Das stickinessConfiguration Objekt enthält:

  • Identifier (erforderlich) — Ein Ausdruck, der dem Gateway mitteilt, wo sich die Sitzungs-ID in der Anfrage befindet. Derzeit kann das Gateway die Sitzungs-ID nur aus einem Anforderungsheader auflösen. Sie können den Header in einer der folgenden Formen angeben:

    • Ein einfacher HTTP-Header-Name, z. x-session-id B. Das Gateway liest die Sitzungs-ID aus diesem Anforderungsheader.

    • Ein Kontextpfadausdruck der Form$.AMZN_AC_GW_CONTEXT.headers.{header-name}, z. $.AMZN_AC_GW_CONTEXT.headers.x-session-id B.

      Heute wird nur die headers Quelle unterstützt. Andere Quellen (z. B. ein JWT-Anspruch) sind derzeit nicht verfügbar.

  • timeout (optional) — Der Timeout für die Sitzungsaffinität in Sekunden von 1 bis 86400 (24 Stunden). Nach dieser Dauer der Inaktivität läuft die Sitzungsaffinität ab. Das Fenster wird bei jeder Anfrage zurückgesetzt (Schiebefenster).

Wenn ein Ziel eine hatstickinessConfiguration, löst das Gateway die Sitzungs-ID aus der konfigurierten auf. identifier

Im folgenden Beispiel wird ein Passthrough-Ziel mit a erstelltstickinessConfiguration, das die Sitzungs-ID aus einem benutzerdefinierten x-session-id Header extrahiert und die Sitzungsaffinität nach 8 Stunden (28800 Sekunden) abläuft:

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"}
    ]
}'

Weitere Informationen zu Passthrough-Zielen finden Sie unter HTTP-Passthrough-Ziele.

Wichtige Verhaltensweisen

Gespeicherte Entscheidungen haben Vorrang vor Regeländerungen. Wenn Sie eine Regel aktualisieren, werden bestehende Sitzungen mit der ursprünglichen Entscheidung fortgesetzt. Dadurch wird die Sitzungskonsistenz gewährleistet. Um neue Regeln auf eine Sitzung anzuwenden, starten Sie eine neue Sitzung mit einer neuen Sitzungs-ID.

Sitzungen laufen nach einer gewissen Zeit der Inaktivität ab. Das Ablauffenster wird bei jeder Anfrage zurückgesetzt (Schiebefenster). Bei AgentCore Runtime-Zielen laufen Sitzungen nach 15 Tagen Inaktivität ab. Für HTTP-Passthrough-Ziele entspricht das Ablauffenster dem, das timeout Sie im Ziel festgelegt haben stickinessConfiguration (1 bis 86400 Sekunden). Wenn Sie kein Timeout festlegen, gilt die Standardeinstellung. Verwenden Sie nach Ablauf einer Sitzung eine neue Sitzungs-ID für neue Sitzungen, um unerwartetes Routing-Verhalten zu vermeiden. Wir empfehlen, abgelaufene Sitzungs-IDs nicht wiederzuverwenden.

Der Sitzungsstatus wird pro Ziel festgelegt. Verschiedene Ziele behalten einen unabhängigen Sitzungsstatus bei.

Wird für AgentCore Runtime- und HTTP-Passthrough-Ziele unterstützt. Session Stickiness wird für MCP-Ziele nicht unterstützt.