Konfiguration von serverseitigem Caching und API Nutzlastkomprimierung in AWS AppSync - AWS AppSync

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Konfiguration von serverseitigem Caching und API Nutzlastkomprimierung in AWS AppSync

AWS AppSync Die serverseitigen Funktionen zum Zwischenspeichern von Daten stellen Daten in einem In-Memory-Cache mit hoher Geschwindigkeit zur Verfügung, wodurch die Leistung verbessert und die Latenz verringert wird. Dies reduziert die Notwendigkeit, direkt auf Datenquellen zuzugreifen. Caching ist sowohl für Unit- als auch für Pipeline-Resolver verfügbar.

AWS AppSync ermöglicht es Ihnen auch, API Antworten zu komprimieren, sodass Nutzdateninhalte schneller geladen und heruntergeladen werden. Dies reduziert potenziell die Belastung Ihrer Anwendungen und senkt möglicherweise auch Ihre Datenübertragungsgebühren. Das Komprimierungsverhalten ist konfigurierbar und kann nach eigenem Ermessen festgelegt werden.

In diesem Abschnitt finden Sie Hilfe bei der Definition des gewünschten Verhaltens von serverseitigem Caching und Komprimierung in Ihrem. AWS AppSync API

Instance-Typen

AWS AppSync hostet Amazon ElastiCache (RedisOSS) -Instances in demselben AWS Konto und derselben AWS Region wie Ihre AWS AppSync API.

Die folgenden Instance-Typen ElastiCache (RedisOSS) sind verfügbar:

small

1 VCPU, 1,5 GiBRAM, geringe bis mäßige Netzwerkleistung

Medium

2 VCPU, 3 GiBRAM, geringe bis mäßige Netzwerkleistung

large

2 VCPU, 12,3 GiBRAM, bis zu 10 Gigabit Netzwerkleistung

xlarge

4 VCPU, 25,05 GiBRAM, bis zu 10 Gigabit Netzwerkleistung

2xlarge

8 VCPU, 50,47 GiBRAM, bis zu 10 Gigabit Netzwerkleistung

4xlarge

16 VCPU, 101,38 GiBRAM, bis zu 10 Gigabit Netzwerkleistung

8xlarge

32 VCPU, 203,26 GiBRAM, 10-Gigabit-Netzwerkleistung (nicht in allen Regionen verfügbar)

12xlarge

48 VCPU, 317,77 GiBRAM, 10 Gigabit Netzwerkleistung

Anmerkung

In der Vergangenheit haben Sie einen bestimmten Instance-Typ angegeben (z. B.). t2.medium Seit Juli 2020 sind diese älteren Instanztypen weiterhin verfügbar, ihre Verwendung ist jedoch veraltet und es wird davon abgeraten. Wir empfehlen, die hier beschriebenen generischen Instanztypen zu verwenden.

Caching-Verhalten

Im Folgenden sind die Verhaltensweisen im Zusammenhang mit dem Caching aufgeführt:

None

Keine serverseitige Zwischenspeicherung.

Vollständige Zwischenspeicherung von Anforderungen

Wenn sich die Daten nicht im Cache befinden, werden sie aus der Datenquelle abgerufen und füllen den Cache bis zum Ablauf von Time to Live (TTL). Alle nachfolgenden Anfragen an Sie API werden aus dem Cache zurückgegeben. Das bedeutet, dass Datenquellen nicht direkt kontaktiert werden, es sei denn, sie TTL laufen ab. In dieser Einstellung verwenden wir den Inhalt der context.arguments und context.identity -Maps als Caching-Schlüssel.

Zwischenspeicherung pro Resolver

Bei dieser Einstellung muss jeder Resolver explizit aktiviert werden, damit er Antworten zwischenspeichern kann. Sie können einen Wert angeben TTL und Schlüssel auf dem Resolver zwischenspeichern. Bei den Caching-Schlüsseln, die Sie angeben können, handelt es sich um die Zuordnungen context.arguments context.sourcecontext.identity, und und/oder Zeichenkettenfelder der obersten Ebene aus diesen Zuordnungen. Der TTL Wert ist obligatorisch, aber die Caching-Schlüssel sind optional. Wenn Sie keine Caching-Schlüssel angeben, sind die Standardwerte der Inhalt der Zuordnungen context.argumentscontext.source, und. context.identity

Sie könnten beispielsweise die folgenden Kombinationen verwenden:

  • context.arguments und context.source

  • context.arguments und context.identity.sub

  • context.arguments.id oder context.arguments. InputType.id

  • context.source.id und context.identity.sub

  • context.identity.claims.username

Wenn Sie nur einen Schlüssel TTL und keine Caching-Schlüssel angeben, verhält sich der Resolver genauso wie beim vollständigen Zwischenspeichern von Anfragen.

Gültigkeitsdauer zwischenspeichern

Diese Einstellung legt fest, wie lange zwischengespeicherte Einträge im Speicher gespeichert werden sollen. Das Maximum TTL ist 3.600 Sekunden (1 Stunde). Danach werden Einträge automatisch gelöscht.

Cache-Verschlüsselung

Die Cache-Verschlüsselung gibt es in den folgenden zwei Varianten. Diese ähneln den Einstellungen, die ElastiCache (RedisOSS) zulässt. Sie können die Verschlüsselungseinstellungen nur aktivieren, wenn Sie das Caching für Ihren zum ersten Mal aktivieren. AWS AppSync API

  • Verschlüsselung bei der Übertragung — Anfragen zwischen AWS AppSync dem Cache und Datenquellen (außer unsicheren HTTP Datenquellen) werden auf Netzwerkebene verschlüsselt. Da zum Verschlüsseln und Entschlüsseln der Daten an den Endpunkten einige Verarbeitungsvorgänge erforderlich sind, kann die Verschlüsselung während der Übertragung die Leistung beeinträchtigen.

  • Verschlüsselung im Ruhezustand — Daten, die während Swap-Vorgängen aus dem Speicher auf der Festplatte gespeichert werden, werden in der Cache-Instance verschlüsselt. Diese Einstellung wirkt sich auch auf die Leistung aus.

Um Cache-Einträge für ungültig zu erklären, können Sie entweder mit der AWS AppSync Konsole oder mit AWS Command Line Interface ()AWS CLI einen API Flush-Cache-Aufruf ausführen.

Weitere Informationen finden Sie in der Referenz zum ApiCacheDatentyp. AWS AppSync API

Räumung des Caches

Wenn Sie AWS AppSync das serverseitige Caching einrichten, können Sie ein Maximum konfigurieren. TTL Dieser Wert definiert die Zeitspanne, für die zwischengespeicherte Einträge im Speicher gespeichert werden. In Situationen, in denen Sie bestimmte Einträge aus Ihrem Cache entfernen müssen, können Sie AWS AppSync das evictFromApiCache Erweiterungsprogramm in der Anfrage oder Antwort Ihres Resolvers verwenden. (Zum Beispiel, wenn sich Ihre Daten in Ihren Datenquellen geändert haben und Ihr Cache-Eintrag jetzt veraltet ist.) Um ein Element aus dem Cache zu entfernen, müssen Sie seinen Schlüssel kennen. Wenn Sie Elemente dynamisch entfernen müssen, empfehlen wir daher, das Zwischenspeichern pro Resolver zu verwenden und explizit einen Schlüssel zu definieren, mit dem Einträge zu Ihrem Cache hinzugefügt werden.

Einen Cache-Eintrag löschen

Verwenden Sie das Erweiterungsprogramm, um ein Element aus dem Cache zu entfernen. evictFromApiCache Geben Sie den Typ- und Feldnamen an und stellen Sie dann ein Objekt mit Schlüsselwertelementen bereit, um den Schlüssel für den Eintrag zu erstellen, den Sie entfernen möchten. Im Objekt steht jeder Schlüssel für einen gültigen Eintrag aus dem context Objekt, das in der Liste des zwischengespeicherten Resolvers verwendet wird. cachingKey Jeder Wert ist der tatsächliche Wert, der verwendet wurde, um den Wert des Schlüssels zu ermitteln. Sie müssen die Elemente im Objekt in derselben Reihenfolge platzieren wie die Caching-Schlüssel in der Liste des zwischengespeicherten Resolvers. cachingKey

Sehen Sie sich zum Beispiel das folgende Schema an:

type Note { id: ID! title: String content: String! } type Query { getNote(id: ID!): Note } type Mutation { updateNote(id: ID!, content: String!): Note }

In diesem Beispiel können Sie das Caching pro Resolver aktivieren und es dann für die Abfrage aktivieren. getNote Anschließend können Sie den Caching-Schlüssel so konfigurieren, dass er aus besteht. [context.arguments.id]

Wenn Sie versuchenNote, einen abzurufen, um den Cache-Schlüssel zu erstellen, AWS AppSync führt er mithilfe des id Arguments der Abfrage eine Suche in seinem serverseitigen Cache durch. getNote

Wenn Sie eine aktualisierenNote, müssen Sie den Eintrag für die spezifische Notiz entfernen, um sicherzustellen, dass sie bei der nächsten Anforderung aus der Backend-Datenquelle abgerufen wird. Dazu müssen Sie einen Request-Handler erstellen.

Das folgende Beispiel zeigt eine Möglichkeit, die Räumung mit dieser Methode zu handhaben:

import { util, Context } from '@aws-appsync/utils'; import { update } from '@aws-appsync/utils/dynamodb'; export function request(ctx) { extensions.evictFromApiCache('Query', 'getNote', { 'ctx.args.id': ctx.args.id }); return update({ key: { id: ctx.args.id }, update: { context: ctx.args.content } }); } export const response = (ctx) => ctx.result;

Alternativ können Sie die Räumung auch im Response-Handler abwickeln.

Wenn die updateNote Mutation verarbeitet ist, wird AWS AppSync versucht, den Eintrag zu entfernen. Wenn ein Eintrag erfolgreich gelöscht wurde, enthält die Antwort einen apiCacheEntriesDeleted Wert im extensions Objekt, der angibt, wie viele Einträge gelöscht wurden:

"extensions": { "apiCacheEntriesDeleted": 1}

Löschen eines Cache-Eintrags auf der Grundlage seiner Identität

Sie können Caching-Schlüssel auf der Grundlage mehrerer Werte aus dem Objekt erstellen. context

Nehmen wir zum Beispiel das folgende Schema, das Amazon Cognito Cognito-Benutzerpools als Standard-Authentifizierungsmodus verwendet und von einer Amazon DynamoDB DynamoDB-Datenquelle unterstützt wird:

type Note { id: ID! # a slug; e.g.: "my-first-note-on-graphql" title: String content: String! } type Query { getNote(id: ID!): Note } type Mutation { updateNote(id: ID!, content: String!): Note }

Die Note Objekttypen werden in einer DynamoDB-Tabelle gespeichert. Die Tabelle hat einen zusammengesetzten Schlüssel, der den Amazon Cognito Cognito-Benutzernamen als Primärschlüssel und den id (einen Slug) von Note als Partitionsschlüssel verwendet. Dies ist ein Mehrmandantensystem, das es mehreren Benutzern ermöglicht, ihre privaten Note Objekte zu hosten und zu aktualisieren, die niemals gemeinsam genutzt werden.

Da es sich um ein leseintensives System handelt, wird die getNote Abfrage per Resolver-Caching zwischengespeichert, wobei sich der Caching-Schlüssel aus folgenden Komponenten zusammensetzt: [context.identity.username, context.arguments.id] Wenn a aktualisiert Note wird, können Sie den entsprechenden Eintrag löschen. Note Sie müssen die Komponenten dem Objekt in derselben Reihenfolge hinzufügen, in der sie in der Liste Ihres Resolvers angegeben sind. cachingKeys

Das folgende Beispiel zeigt dies:

import { util, Context } from '@aws-appsync/utils'; import { update } from '@aws-appsync/utils/dynamodb'; export function request(ctx) { extensions.evictFromApiCache('Query', 'getNote', { 'ctx.identity.username': ctx.identity.username, 'ctx.args.id': ctx.args.id, }); return update({ key: { id: ctx.args.id }, update: { context: ctx.args.content } }); } export const response = (ctx) => ctx.result;

Ein Backend-System kann den Eintrag auch aktualisieren Note und entfernen. Nehmen wir zum Beispiel diese Mutation:

type Mutation { updateNoteFromBackend(id: ID!, content: String!, username: ID!): Note @aws_iam }

Sie können den Eintrag entfernen, aber die Komponenten des Caching-Schlüssels zum Objekt hinzufügen. cachingKeys

Im folgenden Beispiel erfolgt die Räumung in der Antwort des Resolvers:

import { util, Context } from '@aws-appsync/utils'; import { update } from '@aws-appsync/utils/dynamodb'; export function request(ctx) { return update({ key: { id: ctx.args.id }, update: { context: ctx.args.content } }); } export function response(ctx) { extensions.evictFromApiCache('Query', 'getNote', { 'ctx.identity.username': ctx.args.username, 'ctx.args.id': ctx.args.id, }); return ctx.result; }

In Fällen, in denen Ihre Backend-Daten außerhalb von aktualisiert wurden AWS AppSync, können Sie ein Element aus dem Cache entfernen, indem Sie eine Mutation aufrufen, die eine Datenquelle verwendet. NONE

Antworten werden komprimiert API

AWS AppSync ermöglicht es Clients, komprimierte Payloads anzufordern. Auf Anfrage werden API Antworten komprimiert und als Antwort auf Anfragen zurückgegeben, die angeben, dass komprimierter Inhalt bevorzugt wird. Komprimierte API Antworten werden schneller geladen, Inhalte werden schneller heruntergeladen und Ihre Datenübertragungsgebühren können ebenfalls reduziert werden.

Anmerkung

Die Komprimierung ist für alle neuen Versionen verfügbar, die nach dem 1. Juni 2020 APIs erstellt wurden.

AWS AppSync komprimiert Objekte nach bestem Wissen. In seltenen Fällen AWS AppSync kann die Komprimierung aufgrund einer Vielzahl von Faktoren, einschließlich der aktuellen Kapazität, übersprungen werden.

AWS AppSync kann GraphQL-Abfrage-Payloadgrößen zwischen 1.000 und 10.000.000 Byte komprimieren. Um die Komprimierung zu aktivieren, muss ein Client den Accept-Encoding Header mit dem Wert senden. gzip Die Komprimierung kann überprüft werden, indem der Wert des Content-Encoding Headers in der Antwort (gzip) überprüft wird.

Der Abfrage-Explorer in der AWS AppSync Konsole legt standardmäßig automatisch den Header-Wert in der Anfrage fest. Wenn Sie eine Abfrage ausführen, die eine ausreichend große Antwort hat, kann die Komprimierung mithilfe der Entwicklertools Ihres Browsers bestätigt werden.