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.
# In-Memory-Beschleunigung mit DynamoDB Accelerator (DAX)
Amazon DynamoDB ist für die Skalierbarkeit und Leistung entwickelt. In den meisten Fällen sind die DynamoDB-Reaktionszeiten im einstelligen Millisekundenbereich. Allerdings gibt es gewisse Anwendungsfälle, die Reaktionszeiten in Mikrosekunden erfordern. Für diese Anwendungsfälle bietet DynamoDB Accelerator (DAX) schnelle Reaktionszeiten für den Zugriff auf Eventually-Consistent-Daten.
DAX ist ein DynamoDB-kompatibler Caching-Service, der es Ihnen ermöglicht, von schneller In-Memory-Leistung für anspruchsvolle Anwendungen zu profitieren. DAX befasst sich mit drei Kernszenarien:
1. Als In-Memory-Cache reduziert DAX die Reaktionszeiten der Workloads von Eventually-Consistent-Lesevorgängen um eine Zehnerpotenz von einstelligen Millisekunden zu Mikrosekunden.
1. DAX verringert die operative und Anwendungskomplexität, indem ein verwalteter Service, der API-kompatibel mit DynamoDB ist, bereitgestellt wird. Daher sind nur minimale funktionale Änderungen für die Nutzung mit einer vorhandenen Anwendung erforderlich.
1. Für leseintensive oder stoßweise auftretende Workloads bietet DAX einen erhöhten Durchsatz und potenzielle Kosteneinsparungen, indem weniger überdimensionierte Lesekapazitätseinheiten bereitgestellt werden. Dies ist besonders vorteilhaft für Anwendungen, die wiederholte Lesevorgänge für einzelne Schlüssel benötigen.
DAX unterstützt serverseitige Verschlüsselung. Wenn die Verschlüsselung im Ruhezustand ist, werden die Daten, die von DAX auf der Festplatte gespeichert sind, verschlüsselt. DAX schreibt Daten auf den Datenträger als Teil der Weitergabe von Änderungen vom primären Knoten an Read Replicas. Weitere Informationen finden Sie unter [DAX-Verschlüsselung im Ruhezustand](DAXEncryptionAtRest.md).
DAX unterstützt auch die Verschlüsselung bei der Übertragung. Dadurch wird sichergestellt, dass alle Anforderungen und Antworten zwischen Ihrer Anwendung und dem Cluster durch TLS (Transport Level Security) verschlüsselt werden und Verbindungen zum Cluster durch Überprüfung eines x509-Cluster-Zertifikats authentifiziert werden können. Weitere Informationen finden Sie unter [DAX-Verschlüsselung während der Übertragung](DAXEncryptionInTransit.md).
**Topics**
+ [Anwendungsfälle für DAX](#DAX.use-cases)
+ [Nutzungshinweise für DAX](#DAX.usage-notes)
+ [DAX: So funktioniert es](DAX.concepts.md)
+ [DAX-Cluster-Komponenten](DAX.concepts.cluster.md)
+ [Erstellen eines DAX-Clusters](DAX.create-cluster.md)
+ [DAX- und DynamoDB-Konsistenzmodelle](DAX.consistency.md)
+ [Entwickeln mit dem DynamoDB-Accelerator-(DAX)-Client](DAX.client.md)
+ [Verwalten von DAX-Clustern](DAX.cluster-management.md)
+ [Überwachen von DynamoDB Accelerator](DAX.Monitoring.md)
+ [DAX-T3/T2-Instances mit Spitzenlastleistung](DAX.Burstable.md)
+ [DAX-Zugriffskontrolle](DAX.access-control.md)
+ [DAX-Verschlüsselung im Ruhezustand](DAXEncryptionAtRest.md)
+ [DAX-Verschlüsselung während der Übertragung](DAXEncryptionInTransit.md)
+ [Verwendung von serviceverknüpften IAM-Rollen für DAX](using-service-linked-roles.md)
+ [AWS Kontenübergreifender Zugriff auf DAX](DAX.cross-account-access.md)
+ [DAX-Clustergrößenleitfaden](DAX.sizing-guide.md)
## Anwendungsfälle für DAX
DAX bietet Zugriff auf Eventually-Consistent-Daten aus DynamoDB-Tabellen mit einer Latenz von Mikrosekunden. Ein Multi-AZ-DAX-Cluster kann Millionen von Abfragen pro Sekunde verarbeiten.
DAX eignet sich für folgende Anwendungsarten:
+ Anwendungen, die eine schnellstmögliche Reaktionszeit für Lesevorgänge benötigen. Einige Beispiele sind Real Time Bidding, Social Gaming und Trading-Anwendungen. DAX liefert schnelle In-Memory-Leseleistung für diese Anwendungsfälle.
+ Anwendungen, die eine geringe Anzahl von Elementen häufiger lesen als andere. Stellen Sie sich zum Beispiel ein E-Commerce-System vor, das einen eintägigen Verkauf eines beliebten Produkts anbietet. Während des Verkaufs würde die Nachfrage für dieses Produkt (und seiner Daten in DynamoDB) im Vergleich zu allen anderen Produkten drastisch steigen Um die Auswirkungen eines aktiven Schlüssels und einer nicht-einheitlichen Datenverteilung zu vermeiden, könnten Sie die Leseaktivität in einen DAX-Cache verlagern bis der eintägige Verkauf vorbei ist.
+ Anwendungen, die leseintensiv, aber auch kostensensibel sind. Mit DynamoDB stellen Sie die Anzahl der Lesevorgänge pro Sekunde bereit, die Ihre Anwendung benötigt. Wenn die Leseaktivität steigt, können Sie den bereitgestellten Lesedurchsatz Ihrer Tabelle erhöhen (gegen Aufpreis). Sie können auch die Aktivitäten Ihrer Anwendung in einen DAX-Cluster verlagern und die Menge an Lesekapazitätseinheiten, die Sie sonst erwerben müssten, verringern.
+ Anwendungen, die wiederholte Lesevorgänge für große Datensätze benötigen. Solch eine Anwendung könnte möglicherweise Datenbankressourcen von anderen Anwendungen umleiten. Beispielsweise könnte eine lang andauernde Analyse von regionalen Wetterdaten zeitweise die gesamte Lesekapazität in einer DynamoDB-Tabelle verbrauchen. Dies hätte negative Auswirkungen auf andere Anwendungen, die auf dieselben Daten zugreifen müssen. Mit DAX könnte die Wetteranalyse stattdessen gegen zwischengespeicherte Daten durchgeführt werden.
DAX ist für folgende Anwendungsarten *nicht* geeignet:
+ Anwendungen, die Strongly Consistent-Lesevorgänge erfordern (oder keine Eventually Consistent-Lesevorgänge akzeptieren können).
+ Anwendungen, die keine Reaktionszeiten im Mikrosekundenbereich für Lesevorgänge benötigen oder die keine wiederholte Leseaktivitäten von zugrunde liegenden Tabellen auslagern müssen.
+ Anwendungen, die schreibintensiv sind. Ein hohes Schreibvolumen führt zu einer erhöhten Replikation zwischen DAX-Knoten in einem Cluster. Dies führt wiederum zu einem erhöhten Ressourcenverbrauch und dem Risiko von Verfügbarkeitsproblemen.
+ Anwendungen ohne viele wiederholte Lesevorgänge. DAX bietet die beste Leistung, wenn die Cache-Trefferraten 90 % überschreiten. Niedrigere Cache-Trefferraten erhöhen die Anzahl der Cache-Fehler, wodurch mehr Ressourcen im DAX-Cluster verbraucht werden.
## Nutzungshinweise für DAX
+ Eine Liste der AWS Regionen, in denen DAX verfügbar ist, finden Sie unter [Amazon DynamoDB DynamoDB-Preise](https://aws.amazon.com/dynamodb/pricing).
+ DAX unterstützt Anwendungen, die in Go, Java, Node.js, Python und .NET geschrieben wurden, und verwendet AWS dafür bereitgestellte Clients für diese Programmiersprachen.
+ DAX ist ausschließlich für die EC2-VPC-Plattform verfügbar.
+ Die DAX-Cluster-Service-Rolle-Richtlinie muss die Aktion `dynamodb:DescribeTable` zulassen, damit Metadaten über die DynamoDB-Tabelle beibehalten werden.
+ DAX-Cluster halten Metadaten zu den Attributnamen der von ihnen gespeicherten Elemente bei. Diese Metadaten werden unbegrenzt gespeichert (und zwar sogar, nachdem das Element abgelaufen ist oder aus dem Cache entfernt wurde). Anwendungen, die eine unbegrenzte Anzahl von Attributnamen verwenden, können im Laufe der Zeit zu einer Erschöpfung des Speichers im DAX-Cluster führen. Diese Einschränkung gilt nur für Attributnamen auf oberster Ebene und nicht für verschachtelte Attributnamen. Beispiele für problematische Attributnamen der obersten Ebene sind Zeitstempel und Sitzung UUIDs. IDs
Diese Einschränkung gilt nur für Attributnamen und nicht für deren Werte. Elemente wie die Folgenden stellen kein Problem dar.
```
{
"Id": 123,
"Title": "Bicycle 123",
"CreationDate": "2017-10-24T01:02:03+00:00"
}
```
Bei Elementen wie den folgenden ist dies jedoch der Fall, wenn sie in entsprechender Anzahl vorhanden sind und jedes von ihnen über einen anderen Zeitstempel verfügt:
```
{
"Id": 123,
"Title": "Bicycle 123",
"2017-10-24T01:02:03+00:00": "created"
}
```
# DAX: So funktioniert es
Amazon DynamoDB Accelerator (DAX) wurde für die Ausführung in einer Amazon-Virtual-Private-Cloud-(Amazon-VPC)-Umgebung entwickelt. Der Amazon-VPC-Service definiert ein virtuelles Netzwerk, das einem herkömmlichen Rechenzentrum sehr ähnlich ist. Mit einer VPC können Sie den zugehörigen IP-Adressbereich, die Subnetze, Routing-Tabellen, Netzwerk-Gateways und Sicherheitseinstellungen steuern. Sie können einen DAX-Cluster in Ihrem virtuellen Netzwerk starten und den Zugriff auf den Cluster über Amazon-VPC-Sicherheitsgruppen steuern.
**Anmerkung**
Wenn Sie Ihr AWS Konto nach dem 4. Dezember 2013 erstellt haben, haben Sie in jeder AWS Region bereits eine Standard-VPC. Die VPC kann sofort verwendet werden – ohne zusätzliche Konfigurationsschritte ausführen zu müssen.
Weitere Informationen finden Sie unter [Standard-VPC und Standard-Subnetze](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html) im *Amazon-VPC-Benutzerhandbuch*.
Das folgende Diagramm zeigt einen allgemeinen Überblick über DAX.
![\[Workflow-Diagramm, dass die Interaktion von Anwendung, DAX-Client und DAX-Cluster in einer VPC zeigt.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/dax_high_level.png)
Für die Erstellung eines DAX-Clusters verwenden Sie AWS-Managementkonsole. Sofern nicht anders von Ihnen festgelegt, wird Ihr DAX-Cluster in Ihrer Standard-VPC ausgeführt. Um Ihre Anwendung auszuführen, starten Sie eine Amazon-EC2-Instance in Ihrer Amazon VPC. Anschließend stellen Sie Ihre Anwendung (mit dem bereitstellen-Client) auf der EC2-Instance bereit.
Der DAX-Client leitet zur Laufzeit alle DynamoDB-API-Anforderungen der Anwendung an den DAX-Cluster weiter. Wenn DAX eine dieser API-Anforderungen direkt verarbeiten kann, erfolgt die Verarbeitung auch direkt. Andernfalls wird die Anforderung an DynamoDB übergeben.
Schließlich gibt der DAX-Cluster die Ergebnisse an Ihre Anwendung zurück.
**Topics**
+ [Wie DAX-Anforderungen verarbeitet](#DAX.concepts.request-processing)
+ [Element-Cache](#DAX.concepts.item-cache)
+ [Abfrage-Cache](#DAX.concepts.query-cache)
## Wie DAX-Anforderungen verarbeitet
Ein DAX-Cluster besteht aus einem oder mehreren Knoten. Auf jedem Knoten wird eine eigene Instance der DAX-Caching-Software ausgeführt. Einer der Knoten dient als primärer Knoten für den Cluster. Weitere Knoten (sofern vorhanden) dienen als Read Replicas. Weitere Informationen finden Sie unter [Knoten](DAX.concepts.cluster.md#DAX.concepts.nodes).
Ihre Anwendung kann auf DAX zugreifen, wenn der Endpunkt für den DAX-Cluster angegeben wird. Die DAX-Client-Software arbeitet mit dem Cluster-Endpunkt zusammen, um einen intelligenten Lastausgleich und intelligentes Routing zu erreichen.
### Lesevorgänge
DAX kann auf die folgenden API-Aufrufe antworten:
+ `GetItem`
+ `BatchGetItem`
+ `Query`
+ `Scan`
Wenn die Anforderung *Eventually-Consistent-Lesevorgänge* (Standardverhalten) angibt, versucht sie, das Element in DAX zu lesen:
+ Wenn DAX das Element verfügbar hat (*Cache-Treffer*), gibt DAX das Element an die Anwendung ohne Zugriff auf DynamoDB zurück.
+ Wenn DAX nicht über das Element verfügt (*Cache-Fehlschlag*), leitet DAX die Anforderung an DynamoDB weiter. Wenn die Antwort von DynamoDB eingeht, gibt DAX die Ergebnisse an die Anwendung zurück. Die Ergebnisse werden jedoch auch in den Cache auf dem primären Knoten geschrieben.
**Anmerkung**
Wenn im Cluster Lesereplikate vorhanden sind, sorgt DAX automatisch dafür, dass die Replikate mit dem primären Knoten synchron sind. Weitere Informationen finden Sie unter [Cluster](DAX.concepts.cluster.md#DAX.concepts.clusters).
Wenn die Anforderung *Strongly-Consistent-Lesevorgänge* angibt, leitet DAX die Anforderung an DynamoDB weiter. Die Ergebnisse von DynamoDB werden nicht im Cache von DAX gespeichert. Sie werden lediglich an die Anwendung zurückgegeben.
### Schreibvorgänge
Die folgenden DAX-API-Operationen werden als „Write-Through“ bezeichnet:
+ `BatchWriteItem`
+ `UpdateItem`
+ `DeleteItem`
+ `PutItem`
Mit diesen Operationen werden die Daten zuerst in die DynamoDB-Tabelle geschrieben und anschließend in den DAX-Cluster. Die Operation ist nur erfolgreich, wenn die Daten erfolgreich in die Tabelle *und* in DAX geschrieben werden.
### Andere Operationen
DAX erkennt keine DynamoDB-Operationen für die Verwaltung von Tabellen (z. B. `CreateTable`, `UpdateTable` und usw.). Wenn die Anwendung diese Operationen ausführen muss, muss sie direkt auf DynamoDB zugreifen, anstatt DAX zu verwenden.
Ausführliche Informationen zu DAX und DynamoDB-Konsistenz finden Sie unter [DAX- und DynamoDB-Konsistenzmodelle](DAX.consistency.md).
Hinweise zur Funktionsweise von Transaktionen in DAX finden Sie unter [Verwenden von Transactional APIs in DynamoDB Accelerator (DAX)](transaction-apis.md#transaction-apis-dax).
### Anforderungsratenbegrenzung
Wenn die Anzahl der an DAX gesendeten Anfragen die Kapazität eines Knotens übersteigt, begrenzt DAX die Rate, mit der zusätzliche Anfragen akzeptiert werden, indem es a [ThrottlingException](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/CommonErrors.html#CommonErrors-ThrottlingException)zurückgibt. Zur Bestimmung der Menge der Anforderungen, die verarbeitet werden können, wertet DAX Ihre CPU-Auslastung kontinuierlich aus, während ein fehlerfreier Clusterstatus beibehalten wird.
Sie können die [ThrottledRequestCount Metrik](dax-metrics-dimensions-dax.md) überwachen, die DAX auf Amazon veröffentlicht CloudWatch. Wenn diese Ausnahmen regelmäßig angezeigt werden, sollten Sie die [Skalierung des Clusters](DAX.cluster-management.md#DAX.cluster-management.scaling) in Erwägung ziehen.
## Element-Cache
DAX pflegt einen *Element-Cache*, um die Ergebnisse von `GetItem`- und `BatchGetItem`-Operationen zu speichern. Die Elemente im Cache stellen letztlich konsistente Daten von DynamoDB dar. Sie werden anhand ihrer Primärschlüsselwerte gespeichert.
Wenn eine Anwendung eine `GetItem`- oder `BatchGetItem`-Anforderung sendet, versucht DAX, die Elemente unter Verwendung der angegebenen Schlüsselwerte direkt aus dem Element-Cache zu lesen. Werden die Elemente gefunden (Cache-Treffer), gibt DAX sie umgehend an die Anwendung zurück. Wenn die Elemente nicht gefunden werden (Cache-Fehler), sendet DAX die Anforderung an DynamoDB. DynamoDB verarbeitet die Anforderungen mithilfe von Eventually-Consistent-Lesevorgängen und gibt die Elemente an DAX zurück. DAX speichert sie im Element-Cache und gibt sie dann an die Anwendung zurück.
Der Element-Cache verfügt über eine Time-to-Live-Einstellung (TTL), die standardmäßig auf 5 Minuten festgelegt ist. DAX weist jedem Element einen Zeitstempel zu, das in den Element-Cache geschrieben wird. Ein Element läuft ab, wenn es im Cache länger als wie in der TTL-Einstellung angegeben vorhanden ist. Wenn Sie eine `GetItem`-Anforderung für ein abgelaufenes Element ausgeben, wird dies als Cache-Fehler betrachtet und DAX sendet die `GetItem`-Anforderung an DynamoDB.
**Anmerkung**
Sie können die TTL-Einstellung für den Element-Cache beim Erstellen des neuen DAX-Clusters festlegen. Weitere Informationen finden Sie unter [Verwalten von DAX-Clustern](DAX.cluster-management.md).
DAX verwaltet auch eine LRU-Liste (Least Recently Used) für den Element-Cache. Mit der LRU-Liste wird verfolgt, wann ein Element zuerst in den Cache geschrieben und wann es zuletzt aus dem Cache gelesen wurde. Wenn der Element-Cache voll wird, bereinigt DAX ältere Elemente (auch wenn sie noch nicht abgelaufen sind), um Platz für neue Elemente zu schaffen. Der LRU-Algorithmus ist für den Element-Cache immer aktiviert. Er ist vom Benutzer nicht konfigurierbar.
Wenn Sie Null als *Element-Cache*-TTL-Einstellung angeben, werden Elemente im Element-Cache nur aufgrund einer LRU-Bereinigung oder einer [„Write-Through“](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.concepts.html#DAX.concepts.request-processing-write)-Operation aktualisiert.
Ausführliche Hinweise zur Konsistenz des Element-Caches in DAX finden Sie unter [Verhalten des DAX-Element-Caches](DAX.consistency.md#DAX.consistency.item-cache).
## Abfrage-Cache
DAX pflegt auch einen *Abfrage-Cache*, um die Ergebnisse von `Query`- und `Scan`-Operationen zu speichern. Die Elemente in diesem Cache stellen die Ergebnissätze von Abfragen und Scans auf DynamoDB-Tabellen dar. Diese Ergebnissätze werden anhand ihrer Parameterwerte gespeichert.
Wenn eine Anwendung eine `Query`- oder `Scan`-Anforderung sendet, versucht DAX unter Verwendung der angegebenen Parameterwerte, einen übereinstimmenden Ergebnissatz aus dem Abfrage-Cache zu lesen. Wird der Ergebnissatz gefunden (Cache Hit), gibt DAX ihn umgehend an die Anwendung zurück. Wenn der Ergebnissatz nicht gefunden wird (Cache-Fehler), sendet DAX die Anforderung an DynamoDB. DynamoDB verarbeitet die Anforderungen mit Eventually-Consistent-Lesevorgängen und gibt den Ergebnissatz an DAX zurück. DAX speichert ihn im Abfrage-Cache und gibt ihn dann an die Anwendung zurück.
**Anmerkung**
Sie können die TTL-Einstellung für den Abfrage-Cache beim Erstellen eines neuen DAX-Clusters festlegen. Weitere Informationen finden Sie unter [Verwalten von DAX-Clustern](DAX.cluster-management.md).
DAX verwaltet auch eine LRU-Liste (Least Recently Used) für den Abfrage-Cache. Mit der LRU-Liste wird verfolgt, wann ein Ergebnissatz zuerst in den Cache geschrieben und wann das Ergebnis zuletzt aus dem Cache gelesen wurde. Wenn der Abfrage-Cache voll wird, bereinigt DAX ältere Ergebnissätze (auch wenn sie noch nicht abgelaufen sind), um Platz für neue Ergebnissätze zu schaffen. Der LRU-Algorithmus ist für den Abfrage-Cache immer aktiviert. Er ist vom Benutzer nicht konfigurierbar.
Wenn Sie Null als *Abfrage-Cache* TTL-Einstellung, wird die Abfrageantwort nicht zwischengespeichert.
Ausführliche Hinweise zur Konsistenz des Abfrage-Caches in DAX finden Sie unter [Verhalten des DAX-Abfrage-Caches](DAX.consistency.md#DAX.consistency.query-cache).
# DAX-Cluster-Komponenten
Ein Amazon-DynamoDB-Accelerator-(DAX)-Cluster besteht aus AWS-Infrastrukturkomponenten. In diesem Abschnitt werden diese Komponenten und ihre Zusammenarbeit beschrieben.
**Topics**
+ [Knoten](#DAX.concepts.nodes)
+ [Cluster](#DAX.concepts.clusters)
+ [Regionen und Availability Zones](#DAX.concepts.regions-and-azs)
+ [Parametergruppen](#DAX.concepts.parameter-groups)
+ [Sicherheitsgruppen](#DAX.concepts.security-groups)
+ [Cluster-ARN](#DAX.concepts.cluster-arn)
+ [Cluster-Endpunkt](#DAX.concepts.cluster-endpoint)
+ [Knotenendpunkte](#DAX.concepts.node-endpoints)
+ [Subnetzgruppen](#DAX.concepts.cluster.security)
+ [--Ereignisse](#DAX.concepts.events)
+ [Wartungsfenster](#DAX.concepts.maintenance-window)
## Knoten
Ein *Knoten* ist der kleinste Baustein eines DAX-Clusters. Jeder Knoten führt eine Instance der DAX-Software aus und unterhält ein einzelnes Replikat der zwischengespeicherten Daten.
Sie können Ihren DAX-Cluster auf zwei Arten skalieren:
+ Durch Hinzufügen weiterer Knoten im Cluster. Dies erhöht den Gesamt-Lesedurchsatz des Clusters.
+ Durch das Verwenden eines größeren Knotentyps. Größere Knotentypen bieten mehr Kapazität und können den Durchsatz erhöhen. (Sie müssen einen neuen Cluster mit dem neuen Knotentyp erstellen.)
Jeder Knoten in einem Cluster hat denselben Knotentyp und führt dieselbe DAX-Caching-Software aus. Eine Liste der verfügbaren Knotentypen finden Sie unter [Amazon-DynamoDB-Preise](https://aws.amazon.com/dynamodb/pricing).
## Cluster
Ein *Cluster* ist eine logische Gruppierung von einem oder mehreren Knoten, die DAX als eine Einheit verwaltet. Einer der Knoten im Cluster wird als *primärer* Knoten ausgewiesen und die anderen Knoten (falls vorhanden) sind *Read Replicas*.
Der primäre Knoten ist für Folgendes verantwortlich:
+ Erfüllen der Anwendungsanforderungen für zwischengespeicherte Daten.
+ Handhaben der Schreibvorgänge in DynamoDB.
+ Bereinigen von Daten aus dem Cache, entsprechend der Bereinigungsrichtlinie des Clusters.
Wenn Änderungen an zwischengespeicherten Daten auf dem Primärknoten vorgenommen werden, verteilt DAX die Änderungen unter Verwendung von Replikationsprotokollen auf alle Lesereplikat-Knoten. Nachdem die Bestätigung von allen Lesereplikaten eingegangen ist, löscht DynamoDB die Replikationsprotokolle vom Primärknoten.
Ein DAX-Cluster unterstützt bis zu elf Knoten pro Cluster (den primären Knoten, plus maximal zehn Lesereplikate).
Read Replicas sind verantwortlich für Folgendes:
+ Erfüllen der Anwendungsanforderungen für zwischengespeicherte Daten.
+ Bereinigen von Daten aus dem Cache, entsprechend der Bereinigungsrichtlinie des Clusters.
Im Gegensatz zu dem primären Knoten schreiben Lesereplikate jedoch nicht in DynamoDB.
Read Replicas dienen zwei zusätzlichen Zwecken:
+ **Skalierbarkeit**. Wenn Sie über eine große Anzahl von Anwendungs-Clients verfügen, die gleichzeitig auf DAX zugreifen müssen, können Sie weitere Replikate für die Leseskalierung hinzufügen. DAX verteilt die Last gleichmäßig auf alle Knoten im Cluster. (Eine weitere Möglichkeit zur Erhöhung des Durchsatzes ist die Verwendung größerer Cache-Knoten-Typen.)
+ **Hohe Verfügbarkeit**. Beim Ausfall eines primären Knotens, schaltet DAX automatisch auf ein Lesereplikat um und bestimmt es zum neuen primären Knoten. Wenn ein Replikat-Knoten ausfällt, können andere Instances im DAX-Cluster nach wie vor für die Bearbeitung von Anfragen verwendet werden, bis der ausgefallene Knoten wiederhergestellt werden kann. Für maximale Fehlertoleranz sollten Sie Read Replicas in separaten Availability Zones (Verfügbarkeitszonen) bereitstellen. Diese Konfiguration stellt sicher, dass Ihr DAX-Cluster weiterhin ausgeführt werden kann, auch wenn die gesamte Availability Zone nicht mehr verfügbar ist.
**Wichtig**
Für die Produktionsnutzung empfehlen wir dringend, DAX mit mindestens drei Knoten zu verwenden, in dem die Knoten in verschiedene Availability Zones platziert werden. Drei Knoten sind aus Gründen der Fehlertoleranz für einen DAX-Cluster erforderlich.
Ein DAX-Cluster kann für Bereitstellungs- oder Test-Workloads mit nur einem oder zwei Knoten bereitgestellt werden. Cluster mit einem oder zwei Knoten sind jedoch nicht fehlertolerant. Für die Produktionsnutzung empfehlen wir daher die Nutzung von mindestens drei Knoten. Wenn bei Clustern mit einem oder zwei Knoten Software- oder Hardwarefehler auftreten, ist der Cluster möglicherweise nicht mehr verfügbar oder es gehen zwischengespeicherte Daten verloren.
**Wichtig**
Ein DAX-Cluster unterstützt maximal 500 DynamoDB-Tabellen. Wenn Sie mehr als 500 Tabellen verwenden, kann es bei Ihrem Cluster zu einer Verschlechterung der Verfügbarkeit und Leistung kommen.
## Regionen und Availability Zones
Ein DAX-Cluster in einer AWS-Region kann nur mit DynamoDB-Tabellen interagieren, die sich in derselben Region befinden. Stellen Sie daher sicher, dass Sie Ihren DAX-Cluster in der richtigen Region starten. Wenn Sie über DynamoDB-Tabellen in anderen Regionen verfügen, müssen Sie die DAX-Cluster in diesen Regionen ebenfalls starten.
Jede -Region ist darauf ausgelegt, vollständig von den anderen -Regionen getrennt zu sein. Innerhalb jeder Region gibt es mehrere Availability Zones. Durch das Starten Ihrer Knoten in verschiedenen Availability Zones können Sie eine größtmögliche Fehlertoleranz zu erreichen.
**Wichtig**
Platzieren Sie nicht alle Ihre Cluster-Knoten in eine einzige Availability Zone. Bei dieser Konfiguration ist Ihr DAX-Cluster bei einem Ausfall einer Availability Zone nicht mehr verfügbar.
Für die Produktionsnutzung empfehlen wir dringend, DAX mit mindestens drei Knoten zu verwenden, in dem die Knoten in verschiedene Availability Zones platziert werden. Drei Knoten sind aus Gründen der Fehlertoleranz für einen DAX-Cluster erforderlich.
Ein DAX-Cluster kann für Bereitstellungs- oder Test-Workloads mit nur einem oder zwei Knoten bereitgestellt werden. Cluster mit einem oder zwei Knoten sind jedoch nicht fehlertolerant. Für die Produktionsnutzung empfehlen wir daher die Nutzung von mindestens drei Knoten. Wenn bei Clustern mit einem oder zwei Knoten Software- oder Hardwarefehler auftreten, ist der Cluster möglicherweise nicht mehr verfügbar oder es gehen zwischengespeicherte Daten verloren.
## Parametergruppen
*Parametergruppen* werden verwendet, um Laufzeiteinstellungen für DAX-Clusters zu verwalten. DAX verfügt über mehrere Parameter, die Sie verwenden können, um die Leistung zu optimieren (z. B. Definieren einer TTL-Richtlinie für zwischengespeicherte Daten). Eine Parametergruppe ist eine benannte Sammlung von Parametern, die Sie einem Cluster zuweisen können. Dadurch stellen Sie sicher, dass alle Knoten in diesem Cluster identisch konfiguriert werden.
## Sicherheitsgruppen
Ein DAX-Cluster wird in einer Amazon-Virtual-Private-Cloud-Umgebung (Amazon VPC) ausgeführt. Bei dieser Umgebung handelt es sich um ein virtuelles Netzwerk, das für das betreffende AWS-Konto spezifisch und zugleich von anderen VPCs isoliert ist. Eine *Sicherheitsgruppe* dient als virtuelle Firewall für die VPC und ermöglicht das Steuern des ein- und ausgehenden Netzwerkdatenverkehrs.
Wenn Sie einen Cluster in Ihrer VPC starten, fügen Sie Ihrer Sicherheitsgruppe eine *Zugangsregel* hinzu, um eingehenden Netzwerkverkehr zu erlauben. Die Zugangsregel legt das Protokoll (TCP) und die Portnummer (8111) für den Cluster fest. Nachdem Sie diese Zugangsregel Ihrer Sicherheitsgruppe hinzugefügt haben, können Ihre Anwendungen, die innerhalb Ihrer VPC ausgeführt werden, auf den DAX-Cluster zugreifen.
## Cluster-ARN
Jedem DAX-Cluster wird ein *Amazon-Ressourcenname* (ARN) zugewiesen. Das ARN-Format lautet folgendermaßen.
```
arn:aws:dax:region:accountID:cache/clusterName
```
Sie verwenden den Cluster-ARN in einer IAM-Richtlinie, um Berechtigungen für DAX-API-Operationen zu definieren. Weitere Informationen finden Sie unter [DAX-Zugriffskontrolle](DAX.access-control.md).
## Cluster-Endpunkt
Jeder DAX-Cluster bietet einen *Cluster-Endpunkt* für Ihre Anwendung. Durch den Zugriff auf den Cluster mithilfe des Endpunkts muss Ihre Anwendung die Hostnamen und Portnummern einzelner Knoten im Cluster nicht kennen. Ihre Anwendung "kennt" automatisch alle Knoten im Cluster, auch wenn Sie Read Replicas hinzufügen oder entfernen.
Das folgende Beispiel zeigt einen Cluster-Endpunkt in der Region us-east-1, der nicht für die Verwendung der Verschlüsselung beim Transit konfiguriert ist.
`dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com`
Das folgende Beispiel zeigt einen Cluster-Endpunkt in derselben Region, der für die Verwendung der Verschlüsselung beim Transit konfiguriert ist.
`daxs://my-encrypted-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com`
## Knotenendpunkte
Jeder der einzelnen Knoten in einem DAX-Cluster hat seinen eigenen Hostnamen und seine eigene Portnummer. Das folgende Beispiel zeigt einen *Knotenendpunkt*.
`myDAXcluster-a.2cmrwl.clustercfg.dax.use1.cache.amazonaws.com:8111 `
Ihre Anwendung kann direkt auf einen Knoten zugreifen, indem sie seinen Endpunkt nutzt. Allerdings empfehlen wir, dass Sie den DAX-Cluster als Einzeleinheit behandeln und stattdessen mithilfe des Cluster-Endpunkts darauf zugreifen. Der Cluster-Endpunkt schützt Ihre Anwendung davor, eine Liste von Knoten pflegen zu müssen und diese Liste auf dem neuesten Stand zu halten, wenn Sie dem Cluster Knoten hinzufügen oder entfernen.
## Subnetzgruppen
Der Zugriff auf DAX-Cluster-Knoten ist auf Anwendungen beschränkt, die auf Amazon-EC2-Instances in einer Amazon-VPC-Umgebung ausgeführt werden. Sie können *Subnetzgruppen* verwenden, um Clusters Zugriff von Amazon-EC2-Instances zu gewähren, die auf bestimmten Subnetzen ausgeführt werden. Eine Subnetzgruppe ist eine Sammlung von Subnetzen (in der Regel private Subnetze), die Sie für Ihre in einer Amazon-VPC-Umgebung ausgeführten Cluster festlegen können.
Wenn Sie einen DAX-Cluster erstellen, müssen Sie eine Subnetzgruppe angeben. DAX verwendet diese Subnetzgruppe, um ein Subnetz und IP-Adressen innerhalb dieses Subnetzes auszuwählen und diese mit Ihrem Knoten zu verknüpfen.
## --Ereignisse
DAX zeichnet wichtige Ereignisse innerhalb Ihres Clusters auf, wie beispielsweise einen Fehlschlag beim Hinzufügen eines Knotens, einem erfolgreich hinzugefügten Knoten oder Änderungen an Sicherheitsgruppen. Durch die Überwachung wichtiger Schlüsselereignisse, können Sie den aktuellen Status Ihrer Clusters erfahren und, je nach Ereignis, in der Lage sein, Abhilfemaßnahmen zu ergreifen. Sie können auf diese Ereignisse mit AWS-Managementkonsole oder der `DescribeEvents`-Aktion in der DAX-Verwaltungs-API zugreifen.
Sie können auch anfordern, dass Benachrichtigungen an ein bestimmtes Amazon-SNS-Thema (Amazon Simple Notification Service) gesendet werden. So erfahren Sie es sofort, wenn ein Ereignis im DAX-Cluster auftritt.
## Wartungsfenster
Jeder Cluster verfügt über ein wöchentliches Wartungsfenster, in dem Systemänderungen angewendet werden. Die Änderungen werden nacheinander angewendet. Dabei wird ein vorhandener Knoten ersetzt und ein neuer Knoten mit den angewendeten Änderungen wird dem Cluster hinzugefügt. Während dieses Zeitraums kann es in Ihrer Anwendung zu vorübergehenden Fehlern oder Drosselungen kommen. Daher empfehlen wir, dass Sie das Wartungsfenster auf die Zeiten mit der geringsten Nutzung legen und diesen Zeitplan bei Bedarf regelmäßig anpassen. Sie können einen Zeitraum mit einer Dauer von bis zu 24 Stunden festlegen, in dem alle angeforderten Wartungsaktivitäten durchgeführt werden sollten.
Falls Sie bei der Erstellung oder Änderung eines Cache-Clusters kein bevorzugtes Wartungsfenster angegeben, weist DAX ein 60-minütiges Wartungsfenster an einem zufällig ausgewählten Wochentag zu. Das 60-Minuten-Wartungsfenster wird zufällig aus einem 8-Stunden-Zeitraum für jede AWS-Region ausgewählt. Die folgende Tabelle listet die Blöcke für jede Region auf, von denen die Standard-Wartungsfenster zugewiesen werden.
****
| Regionscode | Name der Region | Wartungsfenster |
| --- | --- | --- |
| ap-northeast-1 | Region Asien-Pazifik (Tokio) | 13:00 - 21:00 UHR UTC |
| ap-southeast-1 | Region Asien-Pazifik (Singapur) | 14:00 - 22:00 UHR UTC |
| ap-southeast-2 | Region Asien-Pazifik (Sydney) | 12:00 - 20:00 UHR UTC |
| ap-south-1 | Region Asien-Pazifik (Mumbai) | 17:30 - 1:30 UHR UTC |
| cn-northwest-1 | Region China (Ningxia) | 23:00 - 07:00 UHR UTC |
| cn-north-1 | Region China (Peking) | 14:00 - 22:00 UHR UTC |
| eu-central-1 | Region Europa (Frankfurt) | 23:00 - 07:00 UTC |
| eu-north-1 | Region Europa (Stockholm) | 01:00 - 09:00 UHR UTC |
| eu-south-2 | Region Europa (Spanien) | 21:00 - 05:00 UTC |
| eu-west-1 | Region Europa (Irland) | 22:00 - 06:00 UHR UTC |
| eu-west-2 | Region Europa (London) | 23:00 - 07:00 UHR UTC |
| eu-west-3 | Region Europa (Paris) | 23:00 - 07:00 UHR UTC |
| sa-east-1 | Region Südamerika (São Paulo) | 01:00 - 09:00 UHR UTC |
| us-east-1 | Region USA Ost (Nord-Virginia) | 03:00 - 11:00 UHR UTC |
| us-east-2 | Region USA Ost (Ohio) | 23:00 - 07:00 UHR UTC |
| us-west-1 | Region USA West (Nordkalifornien) | 06:00 - 14:00 UHR UTC |
| us-west-2 | Region USA West (Oregon) | 06:00 bis 14:00 Uhr UTC |
# Erstellen eines DAX-Clusters
In diesem Abschnitt werden die Ersteinrichtung und Verwendung von Amazon DynamoDB Accelerator (DAX) in Ihrer Amazon-Virtual-Private-Cloud-(Amazon-VPC)-Standardumgebung beschrieben. Sie können Ihren ersten DAX-Cluster entweder mit AWS Command Line Interface (AWS CLI) oder dem erstellen AWS-Managementkonsole.
Nachdem Sie den DAX-Cluster erstellt haben, können Sie darauf von einer Amazon-EC2-Instance zugreifen, die in der gleichen VPC ausgeführt wird. Sie können dann Ihren DAX-Cluster mit einem Anwendungsprogramm verwenden. Weitere Informationen finden Sie unter [Entwickeln mit dem DynamoDB-Accelerator-(DAX)-Client](DAX.client.md).
**Topics**
+ [Erstellen einer IAM-Servicerolle für DAX für den Zugriff auf DynamoDB](#DAX.create-cluster.iam-permissions)
+ [DAX und IPv6](DAX.create-cluster.DAX_and_IPV6.md)
+ [Erstellen eines DAX-Clusters mit dem AWS CLI](DAX.create-cluster.cli.md)
+ [Erstellen eines DAX-Clusters mit dem AWS-Managementkonsole](DAX.create-cluster.console.md)
## Erstellen einer IAM-Servicerolle für DAX für den Zugriff auf DynamoDB
Damit der DAX-Cluster in Ihrem Namen auf DynamoDB-Tabellen zugreifen kann, müssen Sie eine *Servicerolle* erstellen. Eine Servicerolle ist eine AWS Identity and Access Management (IAM-) Rolle, die einen AWS Dienst autorisiert, in Ihrem Namen zu handeln. Die Servicerolle ermöglicht DAX den Zugriff auf Ihre DynamoDB-Tabellen, als ob Sie selbst auf diese Tabellen zugreifen würden. Sie müssen die Servicerolle erstellen, bevor Sie den DAX-Cluster erstellen können.
Wenn Sie die Konsole verwenden, überprüft der Workflow für die Cluster-Erstellung, ob bereits eine DAX-Servicerolle vorhanden ist. Wenn keine gefunden wird, erstellt die Konsole eine neue Servicerolle für Sie. Weitere Informationen finden Sie unter [Schritt 2: Erstellen Sie einen DAX-Cluster mit dem AWS-Managementkonsole](DAX.create-cluster.console.md#DAX.create-cluster.console.create-cluster).
Wenn Sie die verwenden AWS CLI, müssen Sie eine DAX-Servicerolle angeben, die Sie zuvor erstellt haben. Gegebenenfalls müssen Sie vorab eine neue Servicerolle erstellen. Weitere Informationen finden Sie unter [Schritt 1: Erstellen Sie eine IAM-Servicerolle für DAX für den Zugriff auf DynamoDB mithilfe der AWS CLI](DAX.create-cluster.cli.md#DAX.create-cluster.cli.create-service-role).
### Erforderliche Berechtigungen zum Erstellen einer Service-Rolle
Die von AWS verwaltete `AdministratorAccess`-Richtlinie enthält alle Berechtigungen, die erforderlich sind, um einen DAX-Cluster und eine Servicerolle zu erstellen. Wenn dem Benutzer die `AdministratorAccess`-Richtlinie angefügt wurde, ist keine weitere Aktion erforderlich.
Andernfalls müssen Sie der IAM-Richtlinie die folgenden Berechtigungen hinzufügen, damit der Benutzer die Servicerolle erstellen kann:
+ `iam:CreateRole`
+ `iam:CreatePolicy`
+ `iam:AttachRolePolicy`
+ `iam:PassRole`
Fügen Sie diese Berechtigungen dem Benutzer an, der die Aktion ausführen möchte.
**Anmerkung**
Die `iam:PassRole` Berechtigungen `iam:CreateRole``iam:CreatePolicy`,`iam:AttachRolePolicy`, und sind nicht in den AWS verwalteten Richtlinien für DynamoDB enthalten. Dies ist beabsichtigt, da diese Berechtigungen die Möglichkeit der Berechtigungseskalation bieten. Ein Benutzer könnte diese Berechtigungen nutzen, um eine neue Administratorrichtlinie zu erstellen und diese dann einer vorhandenen Rolle zuzuweisen. Deshalb müssen Sie (als Administrator Ihres DAX-Clusters) diese Berechtigungen explizit zu Ihrer Richtlinie hinzufügen.
### Fehlerbehebung
Wenn in Ihrer Benutzerrichtlinie die Berechtigungen `iam:CreateRole`, `iam:CreatePolicy` und `iam:AttachPolicy` fehlen, erhalten Sie Fehlermeldungen. In der folgenden Tabelle sind diese Fehlermeldungen mit den zugehörigen Lösungen aufgeführt.
****
| Fehlermeldung | Gehen Sie wie folgt vor: |
| --- | --- |
| User: arn:aws:iam::accountID:user/userName is not authorized to perform: iam:CreateRole on resource: arn:aws:iam::accountID:role/service-role/roleName | Fügen Sie iam:CreateRole zu Ihrer Benutzerrichtlinie hinzu. |
| User: arn:aws:iam::accountID:user/userName is not authorized to perform: iam:CreatePolicy on resource: policy policyName | Fügen Sie iam:CreatePolicy zu Ihrer Benutzerrichtlinie hinzu. |
| User: arn:aws:iam::accountID:user/userName is not authorized to perform: iam:AttachRolePolicy on resource: role daxServiceRole | Fügen Sie iam:AttachRolePolicy zu Ihrer Benutzerrichtlinie hinzu. |
Weitere Informationen zu den IAM-Richtlinien, die für die Verwaltung von DAX-Clustern erforderlich sind, finden Sie unter [DAX-Zugriffskontrolle](DAX.access-control.md).
# DAX und IPv6
DynamoDB DAX unterstützt jetzt IPv6 Adressierung, sodass Sie Cluster erstellen können, die im Nur-Only-, IPv4 -only- oder IPv6 Dual-Stack-Netzwerkmodus betrieben werden. Dies hilft bei der Verbesserung der Netzwerkkapazitäten, um den sich ändernden Infrastrukturanforderungen gerecht zu werden.
**Netzwerktypen:**
Sie können Cluster mit den folgenden Netzwerktypen erstellen:
+ IPv4-nur
+ IPv6-nur
+ Dual-Stack (unterstützt sowohl als auch IPv4 ) IPv6
**Die wichtigsten Funktionen:**
Mit IPv6 Support können Sie Folgendes tun:
+ **Optionen für die Netzwerkkonfiguration:**
+ IPv4-only und Dual-Stack-Cluster aktiviert. `dual_stack subnets`
+ IPv6-Nur-Cluster in Nur-Subnetzen. IPv6
+ **Verwaltung von Subnetzgruppen:**
+ Erstellen Sie Subnetzgruppen mit Nur-Unterstützung, IPv4 -Nur-Unterstützung oder IPv6 Dual-Stack-Unterstützung
+ Ändern Sie bestehende Subnetzgruppen mit zusätzlichen VPC-Subnetzen
+ Fügen Sie IPv6 -only Subnetze zu -konfigurierten Subnetzgruppen hinzu IPv6
+ Fügen Sie zu konfigurierten Gruppen IPv4 Subnetze hinzu oder stapeln Sie sie in zwei Gruppen IPv4
+ **Client-Konfiguration:**
+ Bei Aufrufen auf der Datenebene können Sie das bevorzugte IP-Protokoll für Dual\$1Stack-Cluster wie folgt festlegen:
+ `ip_discovery`Parameter im Python-SDK
+ `ipDiscovery`Parameter in anderen SDKs
+ Standard: IPv4 wenn keine Protokollpräferenz angegeben ist
Vor der Implementierung IPv6 in Ihren DAX-Clustern müssen Sie Folgendes berücksichtigen:
+ Der Netzwerktyp kann nach der Clustererstellung nicht geändert werden
+ Bei Dual-Stack-Clustern bestimmt der `ip_discovery/ipDiscovery` Parameter in der Client-Konfiguration, welches IP-Protokoll verwendet werden soll (IPv4 oder IPv6)
+ Verschiedene Anwendungen können je nach Konfiguration über unterschiedliche IP-Protokolle eine Verbindung zu demselben Dual-Stack-Cluster herstellen
**Example Beispiel für die Clientkonfiguration**
```
DynamoDbAsyncClient client = ClusterDaxAsyncClient.builder()
.overrideConfiguration(Configuration.builder()
.url(endpoint) // DAX cluster endpoint
.ipDiscovery(ipDiscovery) // IP discovery type (IPv4 or IPv6)
.build())
.build();
```
**Wichtig**
Wenn Sie ressourcenbasierte IAM-Richtlinien verwenden, um IP-Adressen für DynamoDB-Tabellen in IPv6 reinen DAX-Umgebungen einzuschränken, müssen Sie eine Ausnahme für die IAM-Rolle Ihres DAX-Clusters erstellen, wenn Sie den Adressraum blockieren (). IPv4 `0.0.0.0/0` Fügen Sie Ihrer Richtlinie eine `ArnNotEquals` Bedingung hinzu, die speziell den Zugriff für die IAM-Rolle des DAX-Clusters ermöglicht und gleichzeitig IP-basierte Einschränkungen für andere Zugriffspfade beibehält. Ohne diese Ausnahme kann DAX nicht auf Ihre DynamoDB-Tabelle zugreifen.
Beispiel:
**Example**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": "*",
"Action": "dynamodb:PutItem",
"Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MusicCollection",
"Condition": {
"ArnNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/DAXServiceRoleForDynamoDBAccess"
},
"IpAddress": {
"aws:SourceIp": "0.0.0.0/0"
}
}
}
]
}
```
# Erstellen eines DAX-Clusters mit dem AWS CLI
In diesem Abschnitt wird beschrieben, wie Sie einen Amazon-DynamoDB-Accelerator-(DAX)-Cluster mit der AWS Command Line Interface (AWS CLI) erstellen. Wenn Sie es noch nicht getan haben, müssen Sie AWS CLI installieren und konfigurieren. Eine Anleitung finden Sie unter den folgenden Themen im *AWS Command Line Interface -Benutzerhandbuch*:
+ [Installation des AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/installing.html)
+ [Konfigurieren von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)
**Wichtig**
Um DAX-Cluster mit dem zu verwalten AWS CLI, installieren Sie Version 1.11.110 oder höher oder führen Sie ein Upgrade auf Version 1.11.110 durch.
In allen AWS CLI Beispielen werden die `us-west-2` Region und das fiktive Konto verwendet. IDs
**Topics**
+ [Schritt 1: Erstellen einer Servicerolle](#DAX.create-cluster.cli.create-service-role)
+ [Schritt 2: Erstellung einer Subnetzgruppe](#DAX.create-cluster.cli.create-subnet-group)
+ [Schritt 3: Erstellen eines DAX-Clusters](#DAX.create-cluster.cli.create-cluster)
+ [Schritt 4: Konfigurieren der Regeln für eingehenden Datenverkehr für Sicherheitsgruppen](#DAX.create-cluster.cli.configure-inbound-rules)
## Schritt 1: Erstellen Sie eine IAM-Servicerolle für DAX für den Zugriff auf DynamoDB mithilfe der AWS CLI
Bevor Sie einen Amazon-DynamoDB-Accelerator-(DAX)-Cluster erstellen können, müssen Sie eine Servicerolle dafür erstellen. Eine *Servicerolle* ist eine AWS Identity and Access Management (IAM-) Rolle, die einen AWS Dienst autorisiert, in Ihrem Namen zu handeln. Die Servicerolle ermöglicht DAX den Zugriff auf Ihre DynamoDB-Tabellen, als würden Sie selbst darauf zugreifen.
In diesem Schritt erstellen Sie eine IAM-Richtlinie und fügen diese dann einer IAM-Rolle hinzu. So können Sie die Rolle einem DAX-Cluster zuweisen, sodass er DynamoDB-Operationen in Ihrem Namen durchführen kann.
**So erstellen Sie eine IAM-Service-Rolle für DAX**
1. Erstellen Sie eine Datei mit dem Namen `service-trust-relationship.json` und dem folgenden Inhalt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "dax.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
1. Erstellen Sie die Servicerolle.
```
aws iam create-role \
--role-name DAXServiceRoleForDynamoDBAccess \
--assume-role-policy-document file://service-trust-relationship.json
```
1. Erstellen Sie eine Datei mit dem Namen `service-role-policy.json` und dem folgenden Inhalt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"dynamodb:DescribeTable",
"dynamodb:PutItem",
"dynamodb:GetItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:Query",
"dynamodb:Scan",
"dynamodb:BatchGetItem",
"dynamodb:BatchWriteItem",
"dynamodb:ConditionCheckItem"
],
"Effect": "Allow",
"Resource": [
"arn:aws:dynamodb:us-west-2:111122223333:*"
]
}
]
}
```
------
Ersetzen Sie es *accountID* durch Ihre AWS Konto-ID. Um Ihre AWS Konto-ID zu finden, wählen Sie in der oberen rechten Ecke der Konsole Ihre Login-ID aus. Ihre AWS Konto-ID wird im Drop-down-Menü angezeigt.
Im Beispiel *accountID* muss der Amazon-Ressourcenname (ARN) eine 12-stellige Zahl sein. Verwenden Sie keine Bindestriche oder anderen Satzzeichen.
1. Erstellen Sie eine IAM-Richtlinie für die Servicerolle:
```
aws iam create-policy \
--policy-name DAXServicePolicyForDynamoDBAccess \
--policy-document file://service-role-policy.json
```
Beachten Sie in der Ausgabe den ARN für die Richtlinie, die Sie erstellt haben.
`arn:aws:iam::123456789012:policy/DAXServicePolicyForDynamoDBAccess`
1. Fügen Sie die Richtlinie der Servicerolle an. Ersetzen Sie *arn* im folgenden Code durch den tatsächlichen Rollen-ARN aus dem vorherigen Schritt.
```
aws iam attach-role-policy \
--role-name DAXServiceRoleForDynamoDBAccess \
--policy-arn arn
```
Als Nächstes geben Sie eine Subnetzgruppe für Ihre Standard-VPC an. Eine *Subnetzgruppe* ist eine Sammlung eines oder mehrerer Subnetze innerhalb der VPC. Siehe [Schritt 2: Erstellung einer Subnetzgruppe](#DAX.create-cluster.cli.create-subnet-group).
## Schritt 2: Erstellung einer Subnetzgruppe
Gehen Sie wie folgt vor, um mithilfe von () eine Subnetzgruppe für Ihren Amazon DynamoDB Accelerator (DAX) -Cluster zu erstellen. AWS Command Line Interface AWS CLI
**Anmerkung**
Wenn Sie bereits eine Subnetzgruppe für die Standard-VPC erstellt haben, können Sie diesen Schritt überspringen.
DAX wurde für die Ausführung in einer Amazon-Virtual-Private-Cloud-Umgebung (Amazon VPC) entwickelt. Wenn Sie Ihr AWS -Konto nach dem 4. Dezember 2013 erstellt haben, verfügen Sie bereits in jeder AWS -Region über eine Standard-VPC. Weitere Informationen finden Sie unter [Standard-VPC und Standard-Subnetze](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html) im *Amazon-VPC-Benutzerhandbuch*.
**So erstellen Sie eine Subnetzgruppe**
1. Um die ID des Standard-VPCs zu bestimmen, geben Sie den folgenden Befehl ein.
```
aws ec2 describe-vpcs
```
Beachten Sie in der Ausgabe die ID der Standard-VPC, wie im folgenden Beispiel dargestellt.
`vpc-12345678`
1. Ermitteln Sie das Subnetz, das Ihrer Standard-VPC IDs zugeordnet ist. *vpcID*Ersetzen Sie durch Ihre tatsächliche VPC-ID, z. B. `vpc-12345678`
```
aws ec2 describe-subnets \
--filters "Name=vpc-id,Values=vpcID" \
--query "Subnets[*].SubnetId"
```
Notieren Sie sich in der Ausgabe die Subnetz-IDs – z. B. `subnet-11111111`.
1. Erstellen Sie die Subnetzgruppe. Stellen Sie sicher, dass Sie mindestens eine Subnetz-ID im Parameter `--subnet-ids` angeben.
```
aws dax create-subnet-group \
--subnet-group-name my-subnet-group \
--subnet-ids subnet-11111111 subnet-22222222 subnet-33333333 subnet-44444444
```
Informationen zum Erstellen des Clusters finden Sie unter [Schritt 3: Erstellen Sie einen DAX-Cluster mit dem AWS CLI](#DAX.create-cluster.cli.create-cluster).
## Schritt 3: Erstellen Sie einen DAX-Cluster mit dem AWS CLI
Gehen Sie wie folgt vor, um mit AWS Command Line Interface (AWS CLI) einen Amazon DynamoDB Accelerator (DAX) -Cluster in Ihrer Standard-Amazon-VPC zu erstellen.
**So erstellen Sie einen DAX-Cluster**
1. Rufen Sie den Amazon-Ressourcennamen (ARN) für die Servicerolle ab.
```
aws iam get-role \
--role-name DAXServiceRoleForDynamoDBAccess \
--query "Role.Arn" --output text
```
Beachten Sie in der Ausgabe den Servicerollen-ARN, wie im folgenden Beispiel dargestellt.
`arn:aws:iam::123456789012:role/DAXServiceRoleForDynamoDBAccess`
1. DAX-Cluster erstellen. Ersetzen Sie `roleARN` mit der ARN aus dem vorherigen Schritt.
```
aws dax create-cluster \
--cluster-name mydaxcluster \
--node-type dax.r4.large \
--replication-factor 3 \
--iam-role-arn roleARN \
--subnet-group my-subnet-group \
--sse-specification Enabled=true \
--region us-west-2
```
Alle Knoten in dem Cluster sind vom Typ `dax.r4.large` (`--node-type`). Es gibt drei Knoten (`--replication-factor`) – einen primären Knoten und zwei Replikate.
**Anmerkung**
Da `sudo` und `grep`-reservierte Schlüsselwörter sind, können Sie keinen DAX-Cluster mit diesen Wörtern im Cluster-Namen erstellen. Beispiel: `sudo` und `sudocluster` sind ungültige Cluster-Namen.
Zum Anzeigen des Cluster-Status geben Sie den folgenden Befehl ein:
```
aws dax describe-clusters
```
Der Status wird in der Ausgabe angezeigt - z. B. `"Status": "creating"`.
**Anmerkung**
Das Erstellen des Clusters kann einige Minuten dauern. Sobald der Cluster bereit ist, ändert sich sein Status zu `available`. Fahren Sie in der Zwischenzeit mit [Schritt 4: Konfigurieren Sie Regeln für eingehende Sicherheitsgruppen mithilfe der AWS CLI](#DAX.create-cluster.cli.configure-inbound-rules) fort und folgen Sie den Anweisungen.
## Schritt 4: Konfigurieren Sie Regeln für eingehende Sicherheitsgruppen mithilfe der AWS CLI
Die Knoten in dem Amazon-DynamoDB-Accelerator-(DAX)-Cluster verwenden die Standardsicherheitsgruppe für Ihre Amazon VPC. Für die Standardsicherheitsgruppe müssen Sie eingehenden Datenverkehr auf TCP-Port 8111 für unverschlüsselte Cluster oder Port 9111 für verschlüsselte Cluster autorisieren. Auf diese Weise können Amazon-EC2-Instances in der Amazon VPC auf den DAX-Cluster zugreifen.
**Anmerkung**
Wenn Sie den DAX-Cluster mit einer anderen Sicherheitsgruppe (einer anderen als `default`) gestartet haben, müssen Sie stattdessen den hier beschriebenen Prozess für diese Gruppe durchführen.
**So konfigurieren Sie Regeln für eingehenden Datenverkehr für Sicherheitsgruppen**
1. Um die Standard-Sicherheitsgruppen-ID zu bestimmen, geben Sie den folgenden Befehl ein. Ersetzen Sie `vpcID` mit der tatsächlichen VPC-ID (aus [Schritt 2: Erstellung einer Subnetzgruppe](#DAX.create-cluster.cli.create-subnet-group)).
```
aws ec2 describe-security-groups \
--filters Name=vpc-id,Values=vpcID Name=group-name,Values=default \
--query "SecurityGroups[*].{GroupName:GroupName,GroupId:GroupId}"
```
Beachten Sie in der Ausgabe die Sicherheitsgruppen-ID - z. B. `sg-01234567`.
1. Geben Sie dann Folgendes ein. Ersetzen Sie `sgID` mit der tatsächlichen Sicherheitsgruppen-ID. Verwenden Sie Port `8111` für unverschlüsselte Cluster und `9111` für verschlüsselte Cluster.
```
aws ec2 authorize-security-group-ingress \
--group-id sgID --protocol tcp --port 8111
```
# Erstellen eines DAX-Clusters mit dem AWS-Managementkonsole
In diesem Abschnitt wird beschrieben, wie Sie einen Amazon-DynamoDB-Accelerator-(DAX)-Cluster mit AWS-Managementkonsole.
**Topics**
+ [Schritt 1: Erstellung einer Subnetzgruppe](#DAX.create-cluster.console.create-subnet-group)
+ [Schritt 2: Erstellen eines DAX-Clusters](#DAX.create-cluster.console.create-cluster)
+ [Schritt 3: Konfigurieren der Regeln für eingehenden Datenverkehr für Sicherheitsgruppen](#DAX.create-cluster.console.configure-inbound-rules)
## Schritt 1: Erstellen Sie eine Subnetzgruppe mit dem AWS-Managementkonsole
Gehen Sie folgendermaßen vor, um mithilfe AWS-Managementkonsole eine Subnetzgruppe für Ihren Amazon-DynamoDB-Accelerator-(DAX)-Cluster zu erstellen.
**Anmerkung**
Wenn Sie bereits eine Subnetzgruppe für die Standard-VPC erstellt haben, können Sie diesen Schritt überspringen.
DAX wurde für die Ausführung in einer Amazon-Virtual-Private-Cloud-Umgebung (Amazon VPC) entwickelt. Wenn Sie Ihr AWS -Konto nach dem 4. Dezember 2013 erstellt haben, verfügen Sie bereits in jeder AWS -Region über eine Standard-VPC. Weitere Informationen finden Sie unter [Standard-VPC und Standard-Subnetze](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html) im *Amazon-VPC-Benutzerhandbuch*.
Im Rahmen des Erstellungsprozesses eines DAX-Clusters müssen Sie eine *Subnetzgruppe* angeben. Eine Subnetzgruppe ist eine Sammlung eines oder mehrerer Subnetze innerhalb der VPC. Beim Erstellen Ihres DAX-Clusters werden die Knoten für die Subnetze innerhalb der Subnetzgruppen bereitgestellt.
**Anmerkung**
Die VPC mit diesem DAX-Cluster kann andere Ressourcen und sogar VPC-Endpunkte für die anderen Dienste mit Ausnahme des VPC-Endpunkts für enthalten ElastiCache und kann zu Fehlern bei den DAX-Clustervorgängen führen.
**So erstellen Sie eine Subnetzgruppe**
1. Öffnen Sie die DynamoDB-Konsole unter. [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)
1. Klicken Sie im Navigationsbereich unter **DAX** auf **Subnet groups** (Subnetz-Gruppen).
1. Wählen Sie **Create subnet group** (Subnetz-Grupp erstellen) aus.
1. Führen Sie im Fenster **Create subnet group** Folgendes aus:
1. **Name** – Geben Sie eine Kurzbezeichnung für die Subnetzgruppe ein.
1. **Beschreibung** – Geben Sie eine Beschreibung für die Subnetzgruppe ein.
1. **VPC-ID** – Wählen Sie den Bezeichner für Ihre Amazon-VPC-Umgebung aus.
1. **Subnets** (Subnetze)—Wählen Sie ein oder mehrere Subnetze aus der Liste aus.
**Anmerkung**
Die Subnetze sind über mehrere Availability Zones verteilt. Wenn Sie planen, einen DAX-Cluster mit mehreren Knoten (einen Primärknoten und eine oder mehrere Read Replicas) zu erstellen, empfehlen wir Ihnen, mehrere Subnetze zu wählen. IDs DAX kann dann die Cluster-Knoten in mehreren Availability Zones bereitstellen. Wenn eine Availability Zone ausfällt, nimmt DAX automatisch einen Failover zu einer aktiven Availability Zone vor. Der DAX-Cluster funktioniert ohne Unterbrechung weiter.
Wenn Sie die gewünschten Einstellungen vorgenommen haben, klicken Sie auf **Create subnet group** (Subnetzgruppe erstellen).
Informationen zum Erstellen des Clusters finden Sie unter [Schritt 2: Erstellen Sie einen DAX-Cluster mit dem AWS-Managementkonsole](#DAX.create-cluster.console.create-cluster).
## Schritt 2: Erstellen Sie einen DAX-Cluster mit dem AWS-Managementkonsole
Befolgen Sie dieses Verfahren zum Erstellen eines Amazon-DynamoDB-Accelerator-(DAX)-Clusters in der Standard-Amazon VPC.
**So erstellen Sie einen DAX-Cluster**
1. Öffnen Sie die DynamoDB-Konsole unter. [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)
1. Klicken Sie im Navigationsbereich unter **DAX** auf **Cluster**.
1. Wählen Sie **Create cluster** (Cluster erstellen).
1. Führen Sie im Fenster **Create cluster** Folgendes aus:
1. **Cluster-Name** – Geben Sie unter einen Kurznamen für den DAX-Cluster ein.
**Anmerkung**
Da `sudo` und `grep` reservierte Schlüsselwörter sind, können Sie keinen DAX-Cluster mit diesen Wörtern im Cluster-Namen erstellen. Zum Beispiel sind `sudo` und `sudocluster` sind ungültige Cluster-Namen.
1. **Cluster-Bescheibung** – Geben Sie eine Beschreibung für den Cluster ein.
1. **Node types** (Knotentypen)—Wählen Sie den Knotentyp für alle Knoten im Cluster.
1. **Cluster size** (Cluster-Größe)—Wählen Sie die Anzahl der Knoten im Cluster. Ein Cluster besteht aus einem Primärknoten und bis zu neun Read Replicas.
**Anmerkung**
Wenn Sie einen Einzelknoten-Cluster erstellen möchten, wählen Sie **1** aus. Ihr Cluster besteht aus einem primären Knoten.
Wenn Sie einen Cluster mit mehreren Knoten erstellen möchten, wählen Sie eine Zahl zwischen **3** (ein Primärknoten und zwei Read Replicas) und **10** (ein Primärknoten und neun Read Replicas) aus.
Für die Produktionsnutzung empfehlen wir dringend, DAX mit mindestens drei Knoten zu verwenden, wobei die Knoten in verschiedene Availability Zonen platziert werden. Drei Knoten sind aus Gründen der Fehlertoleranz für einen DAX-Cluster erforderlich.
Ein DAX-Cluster kann für Bereitstellungs- oder Test-Workloads mit nur einem oder zwei Knoten bereitgestellt werden. Cluster mit einem oder zwei Knoten sind jedoch nicht fehlertolerant. Für die Produktionsnutzung empfehlen wir daher die Nutzung von mindestens drei Knoten. Wenn bei Clustern mit einem oder zwei Knoten Software- oder Hardwarefehler auftreten, ist der Cluster möglicherweise nicht mehr verfügbar oder es gehen zwischengespeicherte Daten verloren.
1. Wählen Sie **Next** (Weiter).
1. **Subnet group** (Subnetz-Gruppe)—Auswählen **Wählen Sie existierende** und wählen Sie die Subnetzgruppe, die Sie in [Schritt 1: Erstellen Sie eine Subnetzgruppe mit dem AWS-Managementkonsole](#DAX.create-cluster.console.create-subnet-group) erstellt haben aus.
1. **Access control** (Zugriffskontrolle)—Wählen Sie die Sicherheitsgruppe **default** (Standard).
1. **Availability Zones (AZ)**—Wählen Sie **Automatic** (Automatisch) aus.
1. Wählen Sie Next (Weiter) aus.
1. **IAM service role for DynamoDB access** (IAM-Servicerolle für DynamoDB-Zugriff)—Wählen Sie **Create new** (Neu erstellen) aus und geben Sie die folgenden Informationen ein:
+ **IAM-Rollenname** – Geben Sie unter Rollenname einen Namen für Ihre IAM-Rolle ein, z. B `DAXServiceRole`. In der Konsole wird eine neue IAM-Rolle erstellt und der DAX-Cluster übernimmt diese Rolle zur Laufzeit.
+ Wählen Sie das Feld neben **Create policy** (Richtlinie erstellen) aus.
+ **IAM role policy** (IAM-Rollenrichtlinie)—Wählen Sie **Read/Write** (Lesen/Schreiben) aus. Der DAX-Cluster kann so Lese- und Schreibvorgänge in DynamoDB ausführen.
+ **New IAM policy name** (Neuer Name der IAM-Richtlinie) – Dieses Feld wird aufgefüllt, wenn Sie den Namen der IAM-Rolle eingeben. Sie können auch einen Namen für eine IAM-Richtlinie eingeben, z. B. `DAXServicePolicy`. In der Konsole wird eine neue IAM-Richtlinie erstellt und die Richtlinie der IAM-Rolle zugeordnet.
+ **Access to DynamoDB tables** (Zugriff auf DynamoDB-Tabellen) – Wählen Sie **All tables** (Alle Tabellen).
1. **Encryption** (Verschlüsselung) – Wählen Sie **Turn on encryption at rest** (Verschlüsselung im Ruhezustand aktivieren) und **Turn on encryption in transit** (Verschlüsselung während der Übertragung aktivieren) aus. Weitere Informationen finden Sie unter [DAX-Verschlüsselung im Ruhezustand](DAXEncryptionAtRest.md) und [DAX-Verschlüsselung während der Übertragung](DAXEncryptionInTransit.md).
Eine separate Service-Rolle für DAX für den Zugriff auf Amazon EC2 ist ebenfalls erforderlich. DAX erstellt diese Servicerolle automatisch für Sie. Weitere Informationen finden Sie unter [Verwenden von serviceverknüpften Rollen für DAX](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/using-service-linked-roles.html).
1. Wenn Sie die gewünschten Einstellungen vorgenommen haben, wählen Sie **Next** (Weiter).
1. **Parameter group** (Gruppe „Parameter“) – Wählen Sie **Choose existing** (Vorhandene wählen).
1. **Maintenance window** (Wartungsfenster) – Wählen Sie **No Preference ** (Keine Präferenz), falls Sie für Software-Upgrades keine Präferenz haben, oder wählen Sie **Specify time window** (Zeitfenster angeben) und legen Sie die Optionen **Weekday** (Wochentag),**Time (UTC)** (Uhrzeit (UTC)) und **Start within (hours)** (In (Stunden) anfangen) fest, um Ihr Wartungsfenster zu planen.
1. **Tags** — Wählen Sie **Neues Tag hinzufügen, um ein key/value Paar für Tagging-Zwecke** einzugeben.
1. Wählen Sie **Weiter** aus.
Auf dem Bildschirm **Überprüfen und erstellen** können Sie alle Einstellungen überprüfen. Wenn Sie bereit sind, den Cluster zu erstellen, wählen Sie **Cluster erstellen**.
Auf dem Bildschirm **Clusters** wird Ihr DAX-Cluster mit dem Status **Wird erstellt** aufgeführt.
**Anmerkung**
Das Erstellen des Clusters kann einige Minuten dauern. Sobald der Cluster bereit ist, ändert sich sein Status in **Available (Verfügbar)**.
Fahren Sie in der Zwischenzeit mit [Schritt 3: Konfigurieren Sie Regeln für eingehende Sicherheitsgruppen mithilfe der AWS-Managementkonsole](#DAX.create-cluster.console.configure-inbound-rules) fort und folgen Sie den Anweisungen.
## Schritt 3: Konfigurieren Sie Regeln für eingehende Sicherheitsgruppen mithilfe der AWS-Managementkonsole
Ihr Amazon-DynamoDB-Accelerator-(DAX)-Cluster kommuniziert über TCP-Port 8111 (für unverschlüsselte Cluster) oder 9111 (für verschlüsselte Cluster), sodass Sie eingehenden Datenverkehr auf diesem Port autorisieren müssen. Auf diese Weise können Amazon-EC2-Instances in der Amazon VPC auf den DAX-Cluster zugreifen.
**Anmerkung**
Wenn Sie den DAX-Cluster mit einer anderen Sicherheitsgruppe (einer anderen als `default`) gestartet haben, müssen Sie stattdessen den hier beschriebenen Prozess für diese Gruppe durchführen.
**So konfigurieren Sie Regeln für eingehenden Datenverkehr für Sicherheitsgruppen**
1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Wählen Sie im Navigationsbereich **Security Groups (Sicherheitsgruppen)** aus.
1. Wählen Sie die Sicherheitsgruppe **default** (Standard) aus. Wählen Sie im Menü **Actions** (Aktionen) die Option **Edit inbound rules** (Regeln für eingehenden Datenverkehr bearbeiten) aus.
1. Wählen Sie **Add Rule** (Regel hinzufügen) aus und geben Sie die folgenden Informationen ein:
+ **Portbereich** – Geben Sie **8111** (wenn Ihr Cluster unverschlüsselt ist) oder **9111** (wenn Ihr Cluster verschlüsselt ist) ein.
+ **Quelle** – Lassen Sie den Wert unverändert auf **Custom** (Benutzerdefiniert), und wählen Sie das Suchfeld auf der rechten Seite aus. Ein Dropdown-Menü wird angezeigt. Wählen Sie die ID für Ihre Standardsicherheitsgruppe aus.
1. Wählen Sie **Save rules** (Regeln speichern), um Ihre Änderungen zu speichern.
1. Um den Namen in der Konsole zu aktualisieren, rufen Sie die Eigenschaft **Name** auf und wählen Sie die Option **Edit** (Bearbeiten), die angezeigt wird.
# DAX- und DynamoDB-Konsistenzmodelle
Amazon DynamoDB Accelerator (DAX) ist ein Write-Through-Cache-Service, der das Hinzufügen eines Caches zu DynamoDB-Tabellen vereinfachen soll. Da DAX getrennt von DynamoDB arbeitet, ist es wichtig, dass Sie die Konsistenzmodelle von DAX und DynamoDB verstehen, um sicherzustellen, dass sich Ihre Anwendungen wie erwartet verhalten.
In vielen Anwendungsfällen wirkt sich die Art und Weise, wie Ihre Anwendung verwendet, auf die Konsistenz der Daten im DAX-Cluster sowie auf die Konsistenz der Daten zwischen DAX und DynamoDB aus.
**Topics**
+ [Konsistenz zwischen DAX-Cluster-Knoten](#DAX.consistency.nodes)
+ [Verhalten des DAX-Element-Caches](#DAX.consistency.item-cache)
+ [Verhalten des DAX-Abfrage-Caches](#DAX.consistency.query-cache)
+ [Strongly Consistent- und Transactional-Lesevorgänge](#DAX.consistency.strongly-consistent-reads)
+ [Negative Cache-Speicherung](#DAX.consistency.negative-caching)
+ [Strategien für Schreibvorgänge](#DAX.consistency.strategies-for-writes)
## Konsistenz zwischen DAX-Cluster-Knoten
Um eine hohe Verfügbarkeit für Ihre Anwendung zu erreichen, empfehlen wir, dass Sie mindestens drei Knoten für Ihren DAX-Cluster bereitstellen. Platzieren Sie diese Knoten dann in mehrere Availability Zones einer Region.
Wenn Ihr DAX-Cluster ausgeführt wird, repliziert er die Daten zwischen allen Knoten im Cluster (unter der Annahme, dass Sie mehr als einen Knoten bereitgestellt haben). Erwägen Sie eine Anwendung, die eine erfolgreiche `UpdateItem`-Operation mit DAX ausführt. Mit dieser Aktion wird der Element-Cache im primären Knoten mit dem neuen Wert geändert. Dieser Wert wird dann auf alle anderen Knoten im Cluster repliziert. Diese Replikation ist ein Eventually Consistent-Vorgang und dauert in der Regel weniger als eine Sekunde.
In diesem Szenario ist es möglich, dass zwei Clients denselben Schlüssel aus demselben DAX-Cluster lesen, jedoch abhängig von dem Knoten, auf den jeder Client zugegriffen hat, verschiedene Werte erhalten. Die Knoten sind alle konsistent, wenn die Aktualisierung vollständig auf alle Knoten im Cluster repliziert wurde. (Dieses Verhalten ähnelt dem Eventually-Consistent-Verhalten von DynamoDB.)
Wenn Sie eine Anwendung erstellen, die DAX verwendet, sollten Sie diese so konzipieren, dass sie Eventually-Consistent-Daten tolerieren kann.
## Verhalten des DAX-Element-Caches
Jeder DAX-Cluster hat zwei getrennte Caches – einen *Element*- und einen *Abfrage*-Cache. Weitere Informationen finden Sie unter [DAX: So funktioniert es](DAX.concepts.md).
In diesem Abschnitt werden die Konsistenzimplikationen für das Lesen aus dem und Schreiben in den DAX-Element-Cache beschrieben.
### Konsistente Lesezugriffe
Mit DynamoDB führt die `GetItem`-Operation standardmäßig einen Eventually-Consistent-Lesevorgang aus. Angenommen, Sie verwenden `UpdateItem` mit dem DynamoDB-Client. Wenn Sie versuchen, dasselbe Element anschließend sofort zu lesen, kann es sein, dass die Daten so wie vor der Aktualisierung erscheinen. Der Grund hierfür ist die Verzögerung bei der Verbreitung auf alle DynamoDB-Speicherorte. Die Konsistenz wird in der Regel innerhalb von Sekunden erzielt. Wenn Sie den Lesevorgang erneut versuchen, sehen Sie wahrscheinlich das aktualisierte Element.
Wenn Sie `GetItem` mit dem DAX-Client verwenden, erfolgt die Operation (in diesem Fall ein Eventually-Consistent-Lesevorgang) wie folgt:
![\[Workflow-Diagramm mit den nummerierten Schritten zum Aktualisieren eines Elements.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/dax-item-cache.png)
1. Der DAX-Client erstellt eine `GetItem`-Anforderung. DAX versucht, das angeforderte Element aus dem Element-Cache zu lesen. Wenn sich das Element im Cache befindet (*Cache-Treffer*) gibt DAX es an die Anwendung zurück.
1. Wenn das Element nicht verfügbar ist (*Cache-Fehler*), führt DAX eine `GetItem`-Operation für DynamoDB aus.
1. DynamoDB gibt das angeforderte Element zurück und DAX speichert es im Element-Cache.
1. DAX gibt das Element an die Anwendung zurück.
1. (nicht dargestellt) Wenn der DAX-Cluster mehr als einen Knoten enthält, wird das Element auf alle anderen Knoten im Cluster repliziert.
Das Element bleibt im Element-Cache von DAX, abhängig von der (TTL)-Einstellung und vom LRU-Algorithmus des Caches. Weitere Informationen finden Sie unter [DAX: So funktioniert es](DAX.concepts.md).
Während dieses Zeitraums liest DAX das Element nicht erneut aus DynamoDB. Wenn das Element von einem anderen Benutzer mit einem DynamoDB-Client unter Umgehung von DAX aktualisiert wird, liefert eine `GetItem`-Anforderung, die den DAX-Client verwendet, andere Ergebnisse als eine `GetItem`-Anforderung, die den DynamoDB-Client verwendet. In diesem Szenario enthalten DAX und DynamoDB inkonsistente Werte für denselben Schlüssel, bis die TTL für das DAX-Element abgelaufen ist.
Wenn eine Anwendung Daten in einer zugrunde liegenden DynamoDB-Tabelle unter Umgehung von DAX ändert, muss die Anwendung etwaige Dateninkonsistenzen vorhersehen und tolerieren.
**Anmerkung**
Neben `GetItem` unterstützt der DAX-Client auch `BatchGetItem`-Anforderungen. `BatchGetItem` ist in erster Linie ein Wrapper für einzelne oder mehrere `GetItem`-Anforderungen, sodass DAX diese als individuelle `GetItem`-Operationen behandelt.
### Konsistente Schreibzugriffe
DAX ist ein Write-Through-Cache-Service, der die Konsistenz des DAX-Element-Caches mit den zugrunde liegenden DynamoDB-Tabellen vereinfachen soll.
Der DAX-Client unterstützt dieselben API-Operationen wie DynamoDB (`PutItem`, `UpdateItem`, `DeleteItem`, `BatchWriteItem` und `TransactWriteItems`). Wenn Sie diese Operationen mit dem DAX-Client verwenden, werden die Elemente sowohl in DAX als auch DynamoDB geändert. DAX aktualisiert die Elemente in seinem Element-Cache, und zwar unabhängig vom TTL-Wert für diese Elemente.
Beispiel: Sie erstellen eine `GetItem`-Anforderung vom DAX-Client zum Lesen eines Elements in der `ProductCatalog` Tabelle. (Der Partitionsschlüssel ist `Id`. Ein Sortierschlüssel ist nicht vorhanden.) Sie rufen das Element mit der `Id` `101` ab. Der `QuantityOnHand`-Wert für dieses Element ist `42`. DAX speichert das Element im Element-Cache mit einem bestimmten TTL-Format. In diesem Beispiel ist der TTL-Wert zehn Minuten. Drei Minuten später verwendet eine andere Anwendung den DAX-Client, um dasselbe Element zu aktualisieren, sodass der `QuantityOnHand`-Wert jetzt `41` lautet. Vorausgesetzt, das Element wird nicht erneut aktualisiert, geben alle nachfolgenden Lesevorgänge für dasselbe Element während der nächsten zehn Minuten den im Cache gespeicherten Wert für `QuantityOnHand` (`41`) zurück.
#### Wie DAX Schreibzugriffe verarbeitet
DAX ist für Anwendungen konzipiert, die Lesevorgänge mit hoher Leistung erfordern. Als Write-Through-Cache übergibt DAX Ihre Schreibvorgänge synchron an DynamoDB und repliziert dann automatisch und asynchron resultierende Aktualisierungen in den Elementcache über alle Knoten im Cluster. Sie brauchen keine Cache-Invalidierungslogik verwalten, da DAX diesen Vorgang für Sie übernimmt.
DAX unterstützt die folgenden Schreibvorgänge: `PutItem`, `UpdateItem`, `DeleteItem`, `BatchWriteItem` und `TransactWriteItems`.
Wenn Sie eine `PutItem`-, `UpdateItem`-, `DeleteItem`- oder `BatchWriteItem`-Anforderung an DAX senden, werden die folgenden Vorgänge ausgeführt:
+ DAX sendet die Anforderung an DynamoDB.
+ DynamoDB antwortet DAX und bestätigt den erfolgreichen Schreibvorgang.
+ DAX schreibt das Element in den Element-Cache.
+ DAX gibt eine Erfolgsmeldung an den Anforderer zurück.
Wenn Sie eine `TransactWriteItems`-Anforderung an DAX senden, werden die folgenden Vorgänge ausgeführt:
+ DAX sendet die Anforderung an DynamoDB.
+ DynamoDB antwortet DAX und bestätigt, dass die Transaktion abgeschlossen ist.
+ DAX gibt eine Erfolgsmeldung an den Anforderer zurück.
+ DAX stellt im Hintergrund eine `TransactGetItems`-Anforderung für jedes Element in der `TransactWriteItems`-Anforderung, um das Element im Element-Cache zu speichern. `TransactGetItems` wird verwendet, um die [serialisierbare Isolierung](transaction-apis.md#transaction-isolation-serializable) sicherzustellen.
Wenn bei einem Schreibvorgang für DynamoDB ein Fehler auftritt, einschließlich Drosselung, wird das Element in DAX nicht im Cache gespeichert. Die Ausnahme für den Fehler wird an den Anforderer zurückgegeben. So wird sichergestellt, dass keine Daten in den DAX-Cache geschrieben werden, es sei denn, sie wurden vorher erfolgreich in DynamoDB geschrieben.
**Anmerkung**
Mit jedem Schreibvorgang in DAX wird der Status des Element-Caches geändert. Schreibvorgänge in den Element-Cache wirken sich nicht auf den Abfrage-Cache aus. (Der DAX-Element-Cache und Abfrage-Cache werden für unterschiedliche Zwecke verwendet und arbeiten unabhängig voneinander.)
## Verhalten des DAX-Abfrage-Caches
DAX speichert die Ergebnisse von `Query` und `Scan`-Anforderungen im Abfrage-Cache. Diese Ergebnisse wirken sich jedoch nicht auf den Element-Cache aus. Wenn Ihre Anwendung eine `Query`- oder `Scan`- Anforderung mit DAX erstellt, wird der Ergebnissatz im Abfrage-Cache und nicht im Element-Cache gespeichert. Sie können den Element-Cache nicht "warmlaufen" lassen, indem Sie eine `Scan`-Operation ausführen, da der Element-Cache und der Abfrage-Cache zwei verschiedene Entitäten sind.
### Kohärenz von query-update-query
Durch Aktualisierungen des Element-Caches oder der zugrunde liegenden DynamoDB-Tabelle werden die im Abfrage-Cache gespeicherten Ergebnisse nicht ungültig oder geändert.
Berücksichtigen Sie zur Veranschaulichung das folgende Szenario. Eine Anwendung arbeitet mit der `DocumentRevisions`-Tabelle, deren Partitionsschlüssel `DocId` und Sortierschlüssel `RevisionNumber` lautet.
1. Ein Client erstellt eine `Query` für `DocId``101`, für alle Elemente mit `RevisionNumber` größer als oder gleich `5`. DAX speichert den Ergebnissatz im Abfrage-Cache und gibt ihn an den Benutzer zurück.
1. Der Client gibt eine `PutItem`-Anforderung für die `DocId` `101` mit dem `RevisionNumber`-Wert `20` aus.
1. Der Client erstellt dieselbe `Query` wie in Schritt 1 beschrieben (`DocId` `101` und `RevisionNumber` >= `5`).
In diesem Szenario ist der zwischengespeicherte Ergebnissatz für die in Schritt 3 erstellte `Query` mit dem Ergebnissatz identisch, der in Schritt 1 zwischengespeichert wurde. Der Grund ist, dass DAX `Query` - oder `Scan`-Ergebnissätze basierend auf Aktualisierungen einzelner Elemente nicht ungültig macht. Die `PutItem`-Operation aus Schritt 2 wirkt sich nur auf den DAX-Abfrage-Cache aus, wenn die TTL für die `Query` abläuft.
Ihre Anwendung sollte den TTL-Wert für den Abfrage-Cache und die Dauer berücksichtigen, wie lange Ihre Anwendung inkonsistente Ergebnisse zwischen dem Abfrage- und dem Element-Cache tolerieren kann.
## Strongly Consistent- und Transactional-Lesevorgänge
Zum Ausführen einer Strongly-Consistent- `GetItem`, `BatchGetItem`, `Query`, oder `Scan`Anforderung, legen Sie den `ConsistentRead` Parameter auf „true“ fest. DAX übergibt Strongly-Consistent-Leseanforderungen an DynamoDB. Wenn eine Antwort von DynamoDB eingeht, gibt DAX die Ergebnisse an den Client zurück, speichert sie jedoch nicht im Cache. DAX kann selbst keine Strongly-Consistent-Lesevorgänge ausführen, da keine enge Kopplung an DynamoDB besteht. Aus diesem Grund müssen alle nachfolgenden Lesevorgänge aus DAX vom Typ Eventually Consistent sein. Nachfolgende Strongly-Consistent-Lesevorgänge müssen an DynamoDB übergeben werden
DAX verarbeitet `TransactGetItems`-Anforderungen genauso wie Strongly Consistent-Lesevorgänge. DAX übergibt alle `TransactGetItems`-Anforderungen an DynamoDB. Wenn eine Antwort von DynamoDB eingeht, gibt DAX die Ergebnisse an den Client zurück, speichert sie jedoch nicht im Cache.
## Negative Cache-Speicherung
DAX unterstützt negative Cache-Einträge, und zwar sowohl im Element- als auch im Abfrage-Cache. Ein *negativer Cache-Eintrag* tritt auf, wenn DAX in einer zugrunde liegenden DynamoDB-Tabelle keine angeforderten Elemente finden kann. Statt einen Fehler zu melden, legt DAX ein leeres Ergebnis im Cache ab und gibt dieses Ergebnis an den Benutzer zurück.
Angenommen, eine Anwendung sendet eine `GetItem`-Anforderung an einen DAX-Cluster und es befindet sich kein übereinstimmendes Element im DAX-Element-Cache. Dies führt dazu, dass DAX das entsprechende Element aus der zugrunde liegenden DynamoDB-Tabelle liest. Wenn das Element in DynamoDB nicht existiert, speichert DAX ein leeres Element im Element-Cache und gibt dieses leere Element an die Anwendung zurück. Angenommen, die Anwendung sendet eine andere `GetItem`-Anforderung für das gleiche Element. DAX findet das leere Element im Element-Cache und gibt es sofort an die Anwendung zurück. Auf DynamoDB wird dabei nicht zurückgegriffen.
Ein negativer Cache-Eintrag bleibt im DAX-Element-Cache, bis die Element-TTL abgelaufen ist, LRU aufgerufen oder das Element mit `PutItem`, `UpdateItem`, oder `DeleteItem` geändert wird.
Der DAX-Abfrage-Cache verarbeitet negative Cache-Ergebnisse ähnlich. Wenn eine Anwendung eine `Query`- oder `Scan`-Operation ausführt und der DAX-Abfrage-Cache kein Ergebnis enthält, sendet DAX die Anforderung an DynamoDB. Wenn keine übereinstimmenden Elemente im Ergebnissatz vorhanden sind, speichert DAX einen leeren Ergebnissatz im Abfrage-Cache und gibt den leeren Ergebnissatz an die Anwendung zurück. Bei nachfolgenden `Query`- oder `Scan`-Anforderungen ergibt sich derselbe (leere) Ergebnissatz, bis die TTL für diesen Ergebnissatz abgelaufen ist.
## Strategien für Schreibvorgänge
Das Write-Through-Verhalten von DAX eignet sich für viele Anwendungsmuster. Für einige Anwendungsmuster ist ein Write-Through-Modell allerdings nicht geeignet.
Bei Anwendungen, die latenzempfindlich sind, führt die Write-Through-Methode für DAX zu einem zusätzlichen Netzwerk-Hop. Ein Schreibvorgang in DAX ist daher etwas langsamer als ein Schreibvorgang, der direkt in DynamoDB ausgeführt wird. Wenn Ihre Anwendung schreiblatzenzempfindlich ist, können Sie die Latenz reduzieren, indem Sie stattdessen direkt in DynamoDB schreiben. Weitere Informationen finden Sie unter [Write-Around](#DAX.consistency.strategies-for-writes.write-around).
Für schreibintensive Anwendungen (z. B. Anwendungen, die ein Massenladen von Daten ausführen) empfiehlt es sich nicht, alle Daten über DAX zu schreiben, da nur ein kleiner Anteil der Daten von der Anwendung gelesen wird. Wenn Sie große Datenmengen über DAX schreiben, muss der entsprechende LRU-Algorithmus aufgerufen werden, um Platz im Cache für die neuen, zu lesenden Elemente zu schaffen. Hierdurch wird die Effektivität von DAX als Lese-Cache beeinträchtigt.
Wenn Sie ein Element in DAX schreiben, wird der Status des Element-Caches für das neue Element geändert. (DAX muss z. B. ältere Daten aus dem Element-Cache entfernen, um Platz für das neue Element bereitzustellen.) Das neue Element bleibt im Element-Cache, abhängig vom LRU-Algorithmus des Caches und von der TTL-Einstellung für den Cache. Solange das Element im Element-Cache gespeichert bleibt, liest DAX das Element nicht erneut aus DynamoDB.
### Write-Through
Der DAX-Element-Cache implementiert eine Write-Through-Richtlinie. Weitere Informationen finden Sie unter [Wie DAX Schreibzugriffe verarbeitet](#DAX.consistency.item-cache.write-consistency.processing-writes).
Wenn Sie ein Element schreiben, stellt DAX sicher, dass das zwischengespeicherte Element mit dem Element so synchronisiert wird, wie es in DynamoDB vorhanden ist. Dies ist hilfreich für Anwendungen, die ein Element erneut lesen müssen, unmittelbar nachdem sie es geschrieben haben. Wenn andere Anwendungen jedoch direkt in eine DynamoDB-Tabelle schreiben, ist das Element im DAX-Element-Cache nicht mehr mit DynamoDB synchronisiert.
Nehmen wir folgendes Beispiel zur Veranschaulichung. Angenommen, zwei Benutzer (Alice und Bob) arbeiten mit der Tabelle `ProductCatalog`. Alice greift mit DAX auf die Tabelle zu, während Bob DAX umgeht und direkt in DynamoDB auf die Tabelle zugreift.
![\[Workflow-Diagramm mit den nummerierten Schritten, mit denen die Benutzer Alice und Bob mithilfe von DAX und DynamoDB auf eine Tabelle zugreifen.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/dax-consistency-alice-bob.png)
1. Alice aktualisiert ein Element in der `ProductCatalog`-Tabelle. DAX leitet die Anforderung an DynamoDB weiter und die Aktualisierung wird erfolgreich ausgeführt. Anschließend schreibt DAX das Element in den Element-Cache und gibt die Antwort, dass der Vorgang erfolgreich ausgeführt wurde, an Alice zurück. Von diesem Zeitpunkt an sieht jeder Benutzer, der das Element aus DAX liest, das Element mit der Aktualisierung von Alice, bis das Element letztendlich aus dem Cache entfernt wird.
1. Kurze Zeit später aktualisiert Bob dasselbe `ProductCatalog`-Element, das Alice geschrieben hat. Bob aktualisiert das Element jedoch direkt in DynamoDB. DAX aktualisiert den Element-Cache nicht automatisch als Reaktion auf Aktualisierungen über DynamoDB. Daher sehen DAX-Benutzer Bobs Aktualisierung nicht.
1. Alice liest das Element erneut aus DAX. Das Element befindet sich im Element-Cache, sodass DAX es an Alice zurückgibt, ohne auf die DynamoDB-Tabelle zuzugreifen.
In diesem Szenario sehen Alice und Bob unterschiedliche Darstellungen desselben `ProductCatalog`-Elements. Dies ist der Fall, bis DAX das Element letztendlich aus dem Element-Cache entfernt oder bis ein anderer Benutzer dasselbe Element mit DAX erneut aktualisiert.
### Write-Around
Wenn die Anwendung große Datenmengen (z. B. ein Massenladen von Daten) schreiben muss, kann es sinnvoll sein, DAX zu umgehen und die Daten direkt in DynamoDB zu schreiben. Diese *Write-Around*-Strategie reduziert die Schreiblatenz. Der Element-Cache bleibt allerdings nicht mit den Daten in DynamoDB synchronisiert.
Wenn Sie eine Write-Around-Strategie verwenden möchten, denken Sie daran, dass DAX den Element-Cache füllt, sobald Anwendungen den DAX-Client zum Lesen von Daten verwenden. Dies kann in einigen Fällen von Vorteil sind, da sichergestellt wird, dass nur die am häufigsten gelesenen Daten zwischengespeichert werden (im Gegensatz zu den am häufigsten geschriebenen Daten).
Beispiel: Ein Benutzer (Charlie) möchte unter Verwendung von mit einer anderen Tabelle arbeiten, und zwar mit der `GameScores`Tabelle, die DAX nutzt. Der Partitionsschlüssel für `GameScores` ist `UserId`, sodass alle Punktzahlen von Charlie dieselbe `UserId` hätten.
![\[Workflow-Diagramm mit den nummerierten Schritten, in denen Charlie in DAX mit einer DynamoDB-Tabelle arbeitet.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/dax-consistency-charlie.png)
1. Charlie möchte seine gesamten Ergebnisse abrufen und sendet eine `Query` an DAX. Unter der Annahme, dass diese Abfrage noch nicht erstellt wurde, leitet DAX die Abfrage zur Verarbeitung an DynamoDB weiter. Die Ergebnisse werden im DAX-Abfrage-Cache gespeichert und an Charlie zurückgegeben. Der Ergebnissatz bleibt im Abfrage-Cache verfügbar, bis er entfernt wird.
1. Angenommen, Charlie spielt das Spiel Meteor Blaster und erzielt eine hohe Punktzahl. Charlie sendet eine `UpdateItem`-Anforderung an DynamoDB und ändert ein Element in der `GameScores` Tabelle.
1. Schließlich beschließt Charlie, seine frühere `Query` erneut auszuführen, um alle seine Daten aus `GameScores` abzurufen. In den Ergebnissen ist die hohe Punktzahl für Meteor Blaster nicht enthalten. Der Grund hierfür ist, dass die Abfrageergebnisse aus dem Abfrage-Cache und nicht aus dem Element-Cache stammen. Die beiden Caches sind unabhängig voneinander, sodass sich eine Änderung des einen Caches nicht auf den anderen auswirkt.
DAX aktualisiert keine Ergebnissätze im Abfrage-Cache mit den neuesten Daten aus DynamoDB. Jeder Ergebnissatz im Abfrage-Cache entspricht dem Zeitpunkt, an dem die `Query`- oder `Scan`-Operation durchgeführt wurde. Daher werden Charlies `Query`-Ergebnisse nicht in seiner `PutItem`-Operation berücksichtigt. Dies ist so lange der Fall, bis DAX den Ergebnissatz aus dem Abfrage-Cache entfernt.
# Entwickeln mit dem DynamoDB-Accelerator-(DAX)-Client
Um DAX von einer Anwendung aus zu nutzen, verwenden Sie den DAX-Client für Ihre Programmiersprache. Der DAX-Client ist so konzipiert, dass Ihre vorhandenen Amazon-DynamoDB-Anwendungen nur minimal unterbrochen werden. Sie müssen nur einige einfache Änderungen am Code vornehmen.
**Anmerkung**
DAX-Clients für verschiedene Programmiersprachen stehen auf der folgenden Website zur Verfügung:
[http://dax-sdk.s3 - website-us-west -2.amazonaws.com](http://dax-sdk.s3-website-us-west-2.amazonaws.com)
In diesem Abschnitt wird gezeigt, wie Sie eine Amazon-EC2-Instance in der Standard-Amazon-VPC starten, eine Verbindung mit der Instance herstellen und eine Beispielanwendung ausführen. Außerdem enthalten sind Informationen dazu, wie Sie Ihre bestehende Anwendung so ändern, dass sie Ihren DAX-Cluster verwenden kann.
**Topics**
+ [Tutorial: Ausführen einer Beispielanwendung mit DynamoDB Accelerator (DAX)](DAX.client.sample-app.md)
+ [Ändern einer vorhandenen Anwendung für die Verwendung von DAX](DAX.client.modify-your-app.md)
# Tutorial: Ausführen einer Beispielanwendung mit DynamoDB Accelerator (DAX)
In dieser Anleitung wird dargestellt, wie Sie eine Amazon-EC2-Instance in der standardmäßigen Virtual Private Cloud (VPC) starten, eine Verbindung mit der Instance herstellen und eine Beispielanwendung ausführen, die Amazon DynamoDB Accelerator (DAX) nutzt.
**Anmerkung**
Um diese Anleitung abzuschließen, müssen Sie über einen DAX-Cluster verfügen, der in Ihrer Standard-VPC ausgeführt wird. Wenn Sie noch keinen DAX-Cluster eingerichtet haben, finden Sie unter [Erstellen eines DAX-Clusters](DAX.create-cluster.md) eine Anleitung.
**Topics**
+ [Schritt 1: Starten einer Amazon-EC2-Instance](DAX.client.launch-ec2-instance.md)
+ [Schritt 2: Erstellen eines Benutzers und einer Richtlinie](DAX.client.create-user-policy.md)
+ [Schritt 3: Konfigurieren einer Amazon-EC2-Instance](DAX.client.configure-ec2-instance.md)
+ [Schritt 4: Ausführen einer Beispielanwendung](DAX.client.run-application.md)
# Schritt 1: Starten einer Amazon-EC2-Instance
Wenn der Amazon-DynamoDB-Accelerator-(DAX)-Cluster verfügbar ist, können Sie eine Amazon-EC2-Instance in Ihrer standardmäßigen Amazon Virtual Private Cloud (Amazon VPC) starten. Damit können Sie DAX-Client-Software auf dieser Instance installieren und ausführen.
**Starten Sie EC2-Instances wie folgt:**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon EC2 EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Wählen Sie **Launch Instance (Instance starten)** aus und gehen Sie folgendermaßen vor:
** Schritt 1: Auswählen eines Amazon Machine Images (AMI)**
1. Suchen Sie in der Liste von AMIs nach dem **Amazon Linux AMI** und wählen Sie **Select aus**.
**Schritt 2: Auswählen eines Instance-Typs**
1. Wählen Sie in der Liste der Instance-Typen **t2.micro** aus.
1. Wählen Sie **Next: Configure Instance Details** aus.
**Schritt 3: Konfigurieren der Instance-Details**
1. Wählen Sie bei **Network (Netzwerk)** Ihre Standard-VPC aus.
1. Wählen Sie **Next: Add Storage** aus.
**Schritt 4: Hinzufügen von Speicher**
1. Überspringen Sie diesen Schritt, indem Sie **Next: Add tags (Weiter: Tags hinzufügen)** auswählen.
**Schritt 5: Hinzufügen von Tags**
1. Überspringen Sie diesen Schritt, indem Sie **Next: Configure Security Group** auswählen.
**Schritt 6: Konfigurieren einer Sicherheitsgruppe**
1. Wählen Sie **Bestehende Sicherheitsgruppe auswählen** aus.
1. Wählen Sie in der Liste der Sicherheitsgruppen **default** aus. Dies ist die Standard-Sicherheitsgruppe für Ihre VPC.
1. Wählen Sie **Next: Review and Launch** aus.
**Schritt 7: Prüfen eines Starts einer Instance**
1. Wählen Sie **Launch** (Starten) aus.
1. Führen Sie im Fenster **Select an existing key pair or create a new key pair** einen der folgenden Schritte aus:
+ Wenn Sie nicht über ein Amazon-EC2-Schlüsselpaar verfügen, wählen Sie **Neues Schlüsselpaar erstellen** aus und befolgen Sie die Anweisungen. Sie werden dazu aufgefordert, eine private Schlüsseldatei (`.pem`-Datei) herunterzuladen. Sie benötigen diese Datei später, wenn Sie sich bei Ihrer Amazon-EC2-Instance anmelden.
+ Wenn Sie bereits über ein Amazon-EC2-Schlüsselpaar verfügen, wechseln Sie zu **Schlüsselpaar auswählen** und wählen Sie Ihr Schlüsselpaar aus der Liste aus. Beachten Sie, dass Sie bereits über die private Schlüsseldatei (`.pem`-Datei) verfügen müssen, um sich bei Ihrer Amazon-EC2-Instance anmelden zu können.
1. Nachdem Sie Ihr Schlüsselpaar konfiguriert haben, wählen Sie **Launch Instances (Instances starten)** aus.
1. Wählen Sie im Navigationsbereich der Konsole zuerst **EC2 Dashboard** und anschließend die gestartete Instance aus. Suchen Sie im unteren Bereich der Registerkarte **Description (Beschreibung)** das **Public DNS (Öffentliches DNS)** für Ihre Instance, beispielsweise: `ec2-11-22-33-44.us-west-2.compute.amazonaws.com`. Notieren Sie sich diesen öffentlichen DNS-Namen, da Sie ihn für [Schritt 3: Konfigurieren einer Amazon-EC2-Instance](DAX.client.configure-ec2-instance.md) benötigen.
**Anmerkung**
Es dauert einige Minuten, bis Ihre Amazon-EC2-Instance verfügbar ist. Fahren Sie in der Zwischenzeit mit [Schritt 2: Erstellen eines Benutzers und einer Richtlinie](DAX.client.create-user-policy.md) fort und folgen Sie den Anweisungen.
# Schritt 2: Erstellen eines Benutzers und einer Richtlinie
In diesem Schritt erstellen Sie einen Benutzer mit einer Richtlinie, die Zugriff auf Ihren Amazon DynamoDB Accelerator (DAX) -Cluster und auf DynamoDB unter Verwendung gewährt. AWS Identity and Access Management Sie können dann Anwendungen verwenden, die mit dem DAX-Cluster interagieren.
## Melden Sie sich an für ein AWS-Konto
Wenn Sie noch keine haben AWS-Konto, führen Sie die folgenden Schritte aus, um eine zu erstellen.
**Um sich für eine anzumelden AWS-Konto**
1. Öffnen Sie [https://portal.aws.amazon.com/billing/die Anmeldung.](https://portal.aws.amazon.com/billing/signup)
1. Folgen Sie den Online-Anweisungen.
Während der Anmeldung erhalten Sie einen Telefonanruf oder eine Textnachricht und müssen einen Verifizierungscode über die Telefontasten eingeben.
Wenn Sie sich für eine anmelden AWS-Konto, *Root-Benutzer des AWS-Kontos*wird eine erstellt. Der Root-Benutzer hat Zugriff auf alle AWS-Services und Ressourcen des Kontos. Als bewährte Sicherheitsmethode weisen Sie einem Benutzer Administratorzugriff zu und verwenden Sie nur den Root-Benutzer, um [Aufgaben auszuführen, die Root-Benutzerzugriff erfordern](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks).
AWS sendet Ihnen nach Abschluss des Anmeldevorgangs eine Bestätigungs-E-Mail. Du kannst jederzeit deine aktuellen Kontoaktivitäten einsehen und dein Konto verwalten, indem du zu [https://aws.amazon.com/](https://aws.amazon.com/)gehst und **Mein Konto** auswählst.
## Erstellen eines Benutzers mit Administratorzugriff
Nachdem Sie sich für einen angemeldet haben AWS-Konto, sichern Sie Ihren Root-Benutzer des AWS-Kontos AWS IAM Identity Center, aktivieren und erstellen Sie einen Administratorbenutzer, sodass Sie den Root-Benutzer nicht für alltägliche Aufgaben verwenden.
**Sichern Sie Ihre Root-Benutzer des AWS-Kontos**
1. Melden Sie sich [AWS-Managementkonsole](https://console.aws.amazon.com/)als Kontoinhaber an, indem Sie **Root-Benutzer** auswählen und Ihre AWS-Konto E-Mail-Adresse eingeben. Geben Sie auf der nächsten Seite Ihr Passwort ein.
Hilfe bei der Anmeldung mit dem Root-Benutzer finden Sie unter [Anmelden als Root-Benutzer](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial) im *AWS-Anmeldung -Benutzerhandbuch* zu.
1. Aktivieren Sie die Multi-Faktor-Authentifizierung (MFA) für den Root-Benutzer.
Anweisungen finden Sie unter [Aktivieren eines virtuellen MFA-Geräts für Ihren AWS-Konto Root-Benutzer (Konsole)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html) im *IAM-Benutzerhandbuch*.
**Erstellen eines Benutzers mit Administratorzugriff**
1. Aktivieren Sie das IAM Identity Center.
Anweisungen finden Sie unter [Aktivieren AWS IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html) im *AWS IAM Identity Center -Benutzerhandbuch*.
1. Gewähren Sie einem Administratorbenutzer im IAM Identity Center Benutzerzugriff.
*Ein Tutorial zur Verwendung von IAM-Identity-Center-Verzeichnis als Identitätsquelle finden Sie IAM-Identity-Center-Verzeichnis im Benutzerhandbuch unter [Benutzerzugriff mit der Standardeinstellung konfigurieren](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html).AWS IAM Identity Center *
**Anmelden als Administratorbenutzer**
+ Um sich mit Ihrem IAM-Identity-Center-Benutzer anzumelden, verwenden Sie die Anmelde-URL, die an Ihre E-Mail-Adresse gesendet wurde, als Sie den IAM-Identity-Center-Benutzer erstellt haben.
Hilfe bei der Anmeldung mit einem IAM Identity Center-Benutzer finden Sie [im *AWS-Anmeldung Benutzerhandbuch* unter Anmeldung beim AWS Access-Portal](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html).
**Weiteren Benutzern Zugriff zuweisen**
1. Erstellen Sie im IAM-Identity-Center einen Berechtigungssatz, der den bewährten Vorgehensweisen für die Anwendung von geringsten Berechtigungen folgt.
Anweisungen hierzu finden Sie unter [ Berechtigungssatz erstellen](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html) im *AWS IAM Identity Center -Benutzerhandbuch*.
1. Weisen Sie Benutzer einer Gruppe zu und weisen Sie der Gruppe dann Single Sign-On-Zugriff zu.
Eine genaue Anleitung finden Sie unter [ Gruppen hinzufügen](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html) im *AWS IAM Identity Center -Benutzerhandbuch*.
Um Zugriff zu gewähren, fügen Sie Ihren Benutzern, Gruppen oder Rollen Berechtigungen hinzu:
+ Benutzer und Gruppen in AWS IAM Identity Center:
Erstellen Sie einen Berechtigungssatz. Befolgen Sie die Anweisungen unter [Erstellen eines Berechtigungssatzes](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) im *AWS IAM Identity Center -Benutzerhandbuch*.
+ Benutzer, die in IAM über einen Identitätsanbieter verwaltet werden:
Erstellen Sie eine Rolle für den Identitätsverbund. Befolgen Sie die Anleitung unter [Eine Rolle für einen externen Identitätsanbieter (Verbund) erstellen](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) im *IAM-Benutzerhandbuch*.
+ IAM-Benutzer:
+ Erstellen Sie eine Rolle, die Ihr Benutzer annehmen kann. Befolgen Sie die Anleitung unter [Eine Rolle für einen IAM-Benutzer erstellen](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) im *IAM-Benutzerhandbuch*.
+ (Nicht empfohlen) Weisen Sie einem Benutzer eine Richtlinie direkt zu oder fügen Sie einen Benutzer zu einer Benutzergruppe hinzu. Befolgen Sie die Anweisungen unter [Hinzufügen von Berechtigungen zu einem Benutzer (Konsole)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) im *IAM-Benutzerhandbuch*.
**So verwenden Sie den JSON-Richtlinieneditor zum Erstellen einer Richtlinie**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die IAM-Konsole unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Wählen Sie im Navigationsbereich auf der linken Seite **Policies (Richtlinien)**.
Wenn Sie zum ersten Mal **Policies (Richtlinien)** auswählen, erscheint die Seite **Welcome to Managed Policies (Willkommen bei verwalteten Richtlinien)**. Wählen Sie **Get Started**.
1. Wählen Sie oben auf der Seite **Create policy (Richtlinie erstellen)** aus.
1. Wählen Sie im Bereich **Policy editor** (Richtlinien-Editor) die Option **JSON** aus.
1. Geben oder fügen Sie ein JSON-Richtliniendokument ein. Weitere Informationen zur IAM-Richtliniensprache finden Sie in der [IAM-JSON-Richtlinienreferenz](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html).
1. Beheben Sie alle Sicherheitswarnungen, Fehler oder allgemeinen Warnungen, die während der [Richtlinien-Validierung](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_policy-validator.html) erzeugt wurden, und wählen Sie dann **Weiter**.
**Anmerkung**
Sie können jederzeit zwischen den Editoroptionen **Visual** und **JSON** wechseln. Wenn Sie jedoch Änderungen vornehmen oder im **Visual**-Editor **Weiter** wählen, strukturiert IAM Ihre Richtlinie möglicherweise um, um sie für den visuellen Editor zu optimieren. Weitere Informationen finden Sie unter [Richtlinienrestrukturierung](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_policies.html#troubleshoot_viseditor-restructure) im *IAM-Benutzerhandbuch*.
1. (Optional) Wenn Sie eine Richtlinie in der erstellen oder bearbeiten AWS-Managementkonsole, können Sie eine JSON- oder YAML-Richtlinienvorlage generieren, die Sie in CloudFormation Vorlagen verwenden können.
Wählen Sie dazu im **Richtlinien-Editor** **Aktionen** und anschließend ** CloudFormationVorlage generieren** aus. Weitere Informationen CloudFormation dazu finden Sie in der [Referenz zum AWS Identity and Access Management Ressourcentyp](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_IAM.html) im *AWS CloudFormation Benutzerhandbuch*.
1. Wenn Sie mit dem Hinzufügen von Berechtigungen zur Richtlinie fertig sind, wählen Sie **Next** (Weiter) aus.
1. Geben Sie auf der Seite **Prüfen und erstellen** unter **Richtlinienname** einen Namen und unter **Beschreibung** (optional) eine Beschreibung für die Richtlinie ein, die Sie erstellen. Überprüfen Sie **Permissions defined in this policy** (In dieser Richtlinie definierte Berechtigungen), um die Berechtigungen einzusehen, die von Ihrer Richtlinie gewährt werden.
1. (Optional) Fügen Sie der Richtlinie Metadaten hinzu, indem Sie Tags als Schlüssel-Wert-Paare anfügen. Weitere Informationen zur Verwendung von Tags in IAM finden Sie unter [Tags für AWS Identity and Access Management Ressourcen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) im *IAM-Benutzerhandbuch*.
1. Wählen Sie **Create policy** (Richtlinie erstellen) aus, um Ihre neue Richtlinie zu speichern.
**Richtliniendokument** – Kopieren Sie das folgende Dokument und fügen Sie es ein, um die JSON-Richtlinie zu erstellen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"dax:*"
],
"Effect": "Allow",
"Resource": [
"*"
]
},
{
"Action": [
"dynamodb:*"
],
"Effect": "Allow",
"Resource": [
"*"
]
}
]
}
```
------
# Schritt 3: Konfigurieren einer Amazon-EC2-Instance
Wenn Ihre Amazon-EC2-Instance verfügbar ist, können Sie sich bei der Instance anmelden und sie für die Verwendung vorbereiten.
**Anmerkung**
In den folgenden Schritten wird davon ausgegangen, dass Sie eine Verbindung mit Ihrer Amazon-EC2-Instance von einem Linux-Computer aus herstellen. Informationen über andere Möglichkeiten zum Herstellen einer Verbindung finden Sie unter [Herstellen einer Verbindung mit Ihrer Linux-Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html) im *Amazon-EC2-Benutzerhandbuch*.
**So konfigurieren Sie die EC2-Instance**
1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Verwenden Sie den `ssh`-Befehl, wie im folgenden Beispiel gezeigt, um sich bei der Amazon-EC2-Instance anzumelden.
```
ssh -i my-keypair.pem ec2-user@public-dns-name
```
Sie müssen Ihre private Schlüsseldatei (`.pem`-Datei) und den öffentlichen DNS-Namen Ihrer Instance angeben. (Siehe [Schritt 1: Starten einer Amazon-EC2-Instance](DAX.client.launch-ec2-instance.md)).
Die Anmelde-ID lautet `ec2-user`. Es ist kein Passwort erforderlich.
1. Nachdem Sie sich bei Ihrer EC2-Instance angemeldet haben, konfigurieren Sie Ihre AWS Anmeldeinformationen wie folgt. Geben Sie Ihre AWS Zugriffsschlüssel-ID und Ihren geheimen Schlüssel (von[Schritt 2: Erstellen eines Benutzers und einer Richtlinie](DAX.client.create-user-policy.md)) ein und legen Sie als Standardregionsnamen Ihre aktuelle Region fest. (Im folgenden Beispiel lautet der Standard-Regionsname `us-west-2`.)
```
aws configure
AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Default region name [None]: us-west-2
Default output format [None]:
```
Nach dem Start und der Konfiguration der Amazon-EC2-Instance können Sie die Funktionalität von DAX mit einer der verfügbaren Beispielanwendungen testen. Weitere Informationen finden Sie unter [Schritt 4: Ausführen einer Beispielanwendung](DAX.client.run-application.md).
# Schritt 4: Ausführen einer Beispielanwendung
Um Sie beim Testen der Amazon-DynamoDB-Accelerator-(DAX)-Funktionalität zu unterstützen, können Sie eine der verfügbaren Beispielanwendungen auf der Amazon-EC2-Instance ausführen
**Topics**
+ [Node.js und DAX](DAX.client.run-application-nodejs-3.md)
+ [DAX SDK für Go](DAX.client.run-application-go-2.md)
+ [Java und DAX](DAX.client.run-application-java.md)
+ [.NET und DAX](DAX.client.run-application-dotnet.md)
+ [Python und DAX](DAX.client.run-application-python.md)
# Node.js und DAX
# Standard-Client-Konfiguration für Node.js
Bei der Konfiguration des DAX JavaScript SDK-Clients können Sie verschiedene Parameter anpassen, um Leistung, Verbindungsbehandlung und Fehlerresistenz zu optimieren. In der folgenden Tabelle werden die Standardkonfigurationseinstellungen beschrieben, mit denen gesteuert wird, wie Ihr Client mit dem DAX-Cluster interagiert, u. a. Timeout-Werte, Wiederholungsmechanismen, Verwaltung von Anmeldeinformationen und Optionen zur Systemüberwachung. Weitere Informationen finden Sie unter [Dynamo DBClient Operations](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/dynamodb/).
**Standardeinstellungen für den DAX-JS-SDK-Client**
| Parameter | Typ | Description |
| --- | --- | --- |
| `region` optional | `string` | Der für den DAX-Client AWS-Region zu verwendende (Beispiel - 'us-east-1'). Dies ist ein erforderlicher Parameter, sofern er nicht über die Umgebungsvariable bereitgestellt wird. |
| `endpoint` Erforderlich | `string` | Der Endpunkt des Clusters, mit dem das SDK eine Verbindung herstellt. Beispiele: Unverschlüsselt — .region.amazonaws.com dax-cluster-name Verschlüsselt – daxs://Mein-Cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com |
| `requestTimeout` Standard: 6 000 ms | `number` | Dies definiert die maximale Zeit, die der Client auf eine Antwort von DAX wartet. |
| `writeRetries` Standard: 1 | `number` | Die Anzahl der Wiederholungsversuche für fehlgeschlagene Schreibanforderungen. |
| `readRetries` Standard: 1 | `number` | Die Anzahl der Wiederholungsversuche für fehlgeschlagene Leseanforderungen. |
| `maxRetries` Standard: 1 | `number` | Die maximale Anzahl von Versuchen bei fehlgeschlagenen Anforderungen. Wenn festgelegt readRetries/writeRetries sind, hat die in ReadRetries und WriteRetries festgelegte Konfiguration Vorrang vor MaxRetries. |
| `connectTimeout` Standard: 10 000 ms | `number` | Das Timeout (in Millisekunden) für das Herstellen einer Verbindung zu einem der Cluster-Knoten. |
| `maxConcurrentConnections` Standard: 100 | `number` | Beschränkt die Gesamtzahl der gleichzeitigen Verbindungen, die eine Client-Instance pro Knoten in einem DAX-Cluster herstellen kann. |
| `maxRetryDelay` Standard: 7 000 ms | `number` | Wenn der DAX-Server angibt, dass eine Wiederherstellung erforderlich ist, indem das `waitForRecoveryBeforeRetrying`-Flag auf „true“ gesetzt wird, hält der Client an, bevor er es erneut versucht. Während dieser Wiederherstellungsperioden bestimmt der `maxRetryDelay`-Parameter die maximale Wartezeit zwischen Wiederholungsversuchen. Diese für die Wiederherstellung spezifische Konfiguration gilt nur, wenn sich der DAX-Server im Wiederherstellungsmodus befindet. In allen anderen Szenarien folgt das Wiederholungsverhalten einem von zwei Mustern: entweder einer exponentiellen Verzögerung auf der Grundlage der Anzahl der Wiederholungen (bestimmt durch den Parameter `writeRetries`, `readRetries` oder `maxRetries`) oder einer sofortigen Wiederholung, abhängig vom Ausnahmetyp. |
| `credentials` optional | `[AwsCredentialIdentity](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/Package/-aws-sdk-credential-providers/)` \$1 `[AwsCredentialIdentityProvider](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/Package/-aws-sdk-credential-providers/)` | Die AWS Anmeldeinformationen, die für die Authentifizierung von Anfragen verwendet werden sollen. Dies kann als AwsCredentialIdentity oder als angegeben werden. AwsCredentialIdentityProvider Wenn nicht angegeben, verwendet das AWS -SDK automatisch die standardmäßige Anbieterkette für Anmeldeinformationen. Beispiel: `\$1 accessKeyId: 'AKIA... ' , secretAccessKey: ' ... ', sessionToken:'... '\$1 `\$1 @default Verwendet die Standard-Anbieterkette AWS für Anmeldeinformationen. |
| `healthCheckInterval` Standard: 5 000 ms | `number` | Das Intervall (in Millisekunden) zwischen den Cluster-Zustandsprüfungen. Bei einem kürzeren Intervall werden die Prüfungen häufiger durchgeführt. |
| `healthCheckTimeout` Standard: 1 000 ms | `number` | Das Timeout (in Millisekunden) für den Abschluss der Zustandsprüfung. |
| `skipHostnameVerification` Standard: falsch | `boolean` | Die Hostnamen-Überprüfung von TLS-Verbindungen wird übersprungen. Dies hat keine Auswirkungen auf unverschlüsselte Cluster. Standardmäßig wird die Überprüfung des Hostnamens durchgeführt. Wenn Sie diesen Wert auf „True“ setzen, wird die Überprüfung übersprungen. Sie müssen sich bewusst sein, welche Folgen eine Deaktivierung hat, d. h. dass der Cluster, zu dem Sie eine Verbindung herstellen, nicht authentifiziert werden kann. |
| `unhealthyConsecutiveErrorCount` Standard: 5 | `number` | Legt die Anzahl aufeinanderfolgender Fehler fest, die erforderlich sind, um innerhalb des Intervalls für die Zustandsprüfung zu signalisieren, dass der Knoten fehlerhaft ist. |
| `clusterUpdateInterval` Standard: 4 000 ms | `number` | Gibt das Intervall zwischen der Abfrage von Mitgliedschaftsänderungen bei Cluster-Mitgliedern zurück. |
| `clusterUpdateThreshold` Standard: 125 | `number` | Gibt den Schwellenwert zurück, unter dem der Cluster nicht nach Mitgliedschaftsänderungen abgefragt wird. |
| `credentailProvider` optional \$1 Standard null | `[AwsCredentialIdentityProvider](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/Package/-aws-sdk-credential-providers/)` | Benutzerdefinierter Anbieter für AWS Anmeldeinformationen, die zur Authentifizierung von Anfragen an DAX verwendet werden. |
**Paginierungskonfiguration für DaxDocument**
| Name | Typ | Detail |
| --- | --- | --- |
| `client` | DaxDocument | Instanz des DaxDocument Typs. |
| `pageSize` | number | Bestimmt die Anzahl der Elemente pro Seite. |
| `startingToken` Optional | any | LastEvaluatedKey aus der vorherigen Antwort kann für nachfolgende Anfragen verwendet werden. |
Informationen zur Verwendung der Paginierung finden Sie unter [TryDax.js](DAX.client.tutorial-TryDax.md).
# Migration zum DAX-Node.js-SDK V3
Dieser Migrationsleitfaden hilft Ihnen bei der Umstellung Ihrer vorhandenen DAX-Node.js-Anwendungen. Das neue SDK erfordert Node.js 18 oder höher und führt mehrere wichtige Änderungen in der Strukturierung Ihres DynamoDB-Accelerator-Codes ein. Dieser Leitfaden führt Sie durch die wichtigsten Unterschiede, darunter Syntaxänderungen, neue Importmethoden und aktualisierte asynchrone Programmiermuster.
## Verwendung von V2 Node.js DAX
```
const AmazonDaxClient = require('amazon-dax-client');
const AWS = require('aws-sdk');
var region = "us-west-2";
AWS.config.update({
region: region,
});
var client = new AWS.DynamoDB.DocumentClient();
if (process.argv.length > 2) {
var dax = new AmazonDaxClient({
endpoints: [process.argv[2]],
region: region,
});
client = new AWS.DynamoDB.DocumentClient({ service: dax });
}
// Make Get Call using Dax
var params = {
TableName: 'TryDaxTable',
pk: 1,
sk: 1
}
client.get(params, function (err, data) {
if (err) {
console.error(
"Unable to read item. Error JSON:",
JSON.stringify(err, null, 2)
);
} else {
console.log(data);
}
});
```
## Verwendung von V3 Node.js DAX
Für die Verwendung von DAX Node.js ist V3-Node-Version 18 oder höher die bevorzugte Version. Um zu Node 18 zu wechseln, verwenden Sie Folgendes:
```
import { DaxDocument } from '@amazon-dax-sdk/lib-dax';
import { DynamoDBDocument } from '@aws-sdk/lib-dynamodb';
import { DynamoDBClient } from '@aws-sdk/client-dynamodb';
let client: DynamoDBDocument | DaxDocument = DynamoDBDocument.from(
new DynamoDBClient({ region: 'us-west-2' })
);
if (process.argv.length > 2) {
client = new DaxDocument({
endpoints: [process.argv[2]],
region: 'us-west-2',
});
}
const params = {
TableName: 'TryDaxTable',
Key: { pk: 1, sk: 1 },
};
try {
const results = await client.get(params);
console.log(results);
} catch (err) {
console.error(err);
}
```
Das DAX-SDK für Node.js v3.x ist mit dem [AWS -SDK für Node.js v3.x](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/introduction/) kompatibel. Das DAX-SDK für Node.js v3.x unterstützt die Verwendung [aggregierter](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/introduction/#high-level-concepts) Clients. Beachten Sie, dass DAX die Erstellung von Bare-Bone-Clients nicht unterstützt. Weitere Informationen zu nicht unterstützten Funktionen finden Sie unter [Funktionen, die nicht mit AWS SDK V3 identisch sind](#DAX.client.run-application-nodejs-3-not-in-parity).
Um die Node.js-Beispielanwendung auf Ihrer Amazon-EC2-Instance auszuführen, gehen Sie wie folgt vor.
**So führen Sie das Node.js-Beispiel für DAX aus**
1. Richten Sie Node.js auf Ihrer Amazon-EC2-Instance wie folgt ein:
1. Installieren Sie den Node Version Manager (`nvm`).
```
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
```
1. Installieren Sie Node.js mit dem nvm.
```
nvm install 18
```
1. Verwenden Sie nvm, um Node 18 zu verwenden.
```
nvm use 18
```
1. Testen Sie, ob Node.js installiert ist und ordnungsgemäß ausgeführt wird.
```
node -e "console.log('Running Node.js ' + process.version)"
```
Die folgende Meldung sollte angezeigt werden.
`Running Node.js v18.x.x`
1. Installieren Sie den Client DaxDocument Node.js mit dem Node Package Manager (`npm`).
```
npm install @amazon-dax-sdk/lib-dax
```
## TryDax Beispielcode
Wenn Sie die Leistungsvorteile von DynamoDB Accelerator (DAX) bewerten möchten, gehen Sie wie folgt vor, um einen Beispieltest durchzuführen, bei dem die Lesevorgangszeiten zwischen Standard-DynamoDB und einem DAX-Cluster verglichen werden.
1. Nachdem Sie Ihren Workspace eingerichtet und `lib-dax` als Abhängigkeit hinzugefügt haben, kopieren Sie [TryDax.js](DAX.client.tutorial-TryDax.md) in Ihr Projekt.
1. Führen Sie das Programm für Ihren DAX-Cluster aus. Um den Endpunkt für Ihren DAX-Cluster zu bestimmen, wählen Sie einen der folgenden Schritte aus:
+ **Using the DynamoDB console** (Verwenden der DynamoDB-Konsole) — Wählen Sie Ihren DAX-Cluster aus. Der Cluster-Endpunkt wird auf der Konsole angezeigt, wie im folgenden Beispiel gezeigt.
```
dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com
```
+ **Verwenden** Sie AWS CLI— Geben Sie den folgenden Befehl ein.
```
aws dax describe-clusters --query "Clusters[*].ClusterDiscoveryEndpoint"
```
Der Cluster-Endpunkt wird in der Ausgabe angezeigt, wie im folgenden Beispiel gezeigt.
```
{
"Address": "my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com",
"Port": 8111,
"URL": "dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com"
}
```
1. Führen Sie jetzt das Programm aus, indem Sie den Cluster-Endpunkt als Befehlszeilenparameter angeben.
```
node TryDax.js dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com
```
Die Ausgabe sollte folgendermaßen oder ähnlich aussehen:
```
Attempting to create table; please wait...
Successfully created table. Table status: ACTIVE
Writing data to the table...
Writing 20 items for partition key: 1
Writing 20 items for partition key: 2
Writing 20 items for partition key: 3
...
Running GetItem Test
Total time: 153555.10 µs - Avg time: 383.89 µs
Total time: 44679.96 µs - Avg time: 111.70 µs
Total time: 36885.86 µs - Avg time: 92.21 µs
Total time: 32467.25 µs - Avg time: 81.17 µs
Total time: 32202.60 µs - Avg time: 80.51 µs
Running Query Test
Total time: 14869.25 µs - Avg time: 2973.85 µs
Total time: 3036.31 µs - Avg time: 607.26 µs
Total time: 2468.92 µs - Avg time: 493.78 µs
Total time: 2062.53 µs - Avg time: 412.51 µs
Total time: 2178.22 µs - Avg time: 435.64 µs
Running Scan Test
Total time: 2395.88 µs - Avg time: 479.18 µs
Total time: 2207.16 µs - Avg time: 441.43 µs
Total time: 2443.14 µs - Avg time: 488.63 µs
Total time: 2038.24 µs - Avg time: 407.65 µs
Total time: 1972.17 µs - Avg time: 394.43 µs
Running Pagination Test
Scan Pagination
[
{ pk: 1, sk: 1, someData: 'XXXXXXXXXX' },
{ pk: 1, sk: 2, someData: 'XXXXXXXXXX' },
{ pk: 1, sk: 3, someData: 'XXXXXXXXXX' }
]
[
{ pk: 1, sk: 4, someData: 'XXXXXXXXXX' },
{ pk: 1, sk: 5, someData: 'XXXXXXXXXX' },
{ pk: 1, sk: 6, someData: 'XXXXXXXXXX' }
]
...
Query Pagination
[
{ pk: 1, sk: 1, someData: 'XXXXXXXXXX' },
{ pk: 1, sk: 2, someData: 'XXXXXXXXXX' },
{ pk: 1, sk: 3, someData: 'XXXXXXXXXX' }
]
[
{ pk: 1, sk: 4, someData: 'XXXXXXXXXX' },
{ pk: 1, sk: 5, someData: 'XXXXXXXXXX' },
{ pk: 1, sk: 6, someData: 'XXXXXXXXXX' }
]
...
Attempting to delete table; please wait...
Successfully deleted table.
```
Beachten Sie die Zeitinformationen. Die Anzahl der Mikrosekunden, die für die `GetItem`-, `Query`-, `Scan`-Tests benötigt werden.
1. In diesem Fall haben Sie die Programme für den DAX-Cluster ausgeführt. Jetzt führen Sie das Programm erneut aus, diesmal für DynamoDB.
1. Führen Sie nun das Programm erneut aus, diesmal aber ohne die Cluster-Endpunkt-URL als Befehlszeilenparameter.
```
node TryDax.js
```
Sehen Sie sich die Ausgabe an und notieren Sie die Zeitinformationen. Die verstrichene Zeit sollte für `GetItem`, `Query` und `Scan` mit DAX deutlich kürzer sein als mit DynamoDB.
## Funktionen, die nicht mit AWS SDK V3 identisch sind
+ [Bare-Bone](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/introduction/#high-level-concepts)-Clients: Dax Node.js V3 unterstützt keine Bare-Bone-Clients.
```
const dynamoDBClient = new DynamoDBClient({ region: 'us-west-2' });
const regularParams = {
TableName: 'TryDaxTable',
Key: {
pk: 1,
sk: 1
}
};
// The DynamoDB client supports the send operation.
const dynamoResult = await dynamoDBClient.send(new GetCommand(regularParams));
// However, the DaxDocument client does not support the send operation.
const daxClient = new DaxDocument({
endpoints: ['your-dax-endpoint'],
region: 'us-west-2',
});
const params = {
TableName: 'TryDaxTable',
Key: {
pk: 1,
sk: 1
}
};
// This will throw an error - send operation is not supported for DAX. Please refer to documentation.
const result = await daxClient.send(new GetCommand(params));
console.log(result);
```
+ [Middleware-Stack](https://aws.amazon.com/blogs/developer/middleware-stack-modular-aws-sdk-js/): Dax Node.js V3 unterstützt die Verwendung von Middleware-Funktionen nicht.
```
const dynamoDBClient = new DynamoDBClient({ region: 'us-west-2' });
// The DynamoDB client supports the middlewareStack.
dynamoDBClient.middlewareStack.add(
(next, context) =>> async (args) => {
console.log("Before operation:", args);
const result = await next(args);
console.log("After operation:", result);
return result;
},
{
step: "initialize", // or "build", "finalizeRequest", "deserialize"
name: "loggingMiddleware",
}
);
// However, the DaxDocument client does not support the middlewareStack.
const daxClient = new DaxDocument({
endpoints: ['your-dax-endpoint'],
region: 'us-west-2',
});
// This will throw an error - custom middleware and middlewareStacks are not supported for DAX. Please refer to documentation.
daxClient.middlewareStack.add(
(next, context) => async (args) => {
console.log("Before operation:", args);
const result = await next(args);
console.log("After operation:", result);
return result;
},
{
step: "initialize", // or "build", "finalizeRequest", "deserialize"
name: "loggingMiddleware",
}
);
```
# TryDax.js
```
import { DynamoDB, waitUntilTableExists, waitUntilTableNotExists } from "@aws-sdk/client-dynamodb";
import { DaxDocument, daxPaginateScan, daxPaginateQuery } from "@amazon-dax-sdk/lib-dax";
import { DynamoDBDocument, paginateQuery, paginateScan } from "@aws-sdk/lib-dynamodb";
const region = "us-east-1";
const tableName = "TryDaxTable";
// Determine the client (DynamoDB or DAX)
let client = DynamoDBDocument.from(new DynamoDB({ region }));
if (process.argv.length > 2) {
client = new DaxDocument({ region, endpoint: process.argv[2] });
}
// Function to create table
async function createTable() {
const dynamodb = new DynamoDB({ region });
const params = {
TableName: tableName,
KeySchema: [
{ AttributeName: "pk", KeyType: "HASH" },
{ AttributeName: "sk", KeyType: "RANGE" },
],
AttributeDefinitions: [
{ AttributeName: "pk", AttributeType: "N" },
{ AttributeName: "sk", AttributeType: "N" },
],
ProvisionedThroughput: { ReadCapacityUnits: 25, WriteCapacityUnits: 25 },
};
try {
console.log("Attempting to create table; please wait...");
await dynamodb.createTable(params);
await waitUntilTableExists({ client: dynamodb, maxWaitTime: 30 }, { TableName: tableName });
console.log("Successfully created table. Table status: ACTIVE");
} catch (err) {
console.error("Error in table creation:", err);
}
}
// Function to insert data
async function writeData() {
console.log("Writing data to the table...");
const someData = "X".repeat(10);
for (let ipk = 1; ipk <= 20; ipk++) {
console.log("Writing 20 items for partition key: ", ipk)
for (let isk = 1; isk <= 20; isk++) {
try {
await client.put({ TableName: tableName, Item: { pk: ipk, sk: isk, someData } });
} catch (err) {
console.error("Error inserting data:", err);
}
}
}
}
// Function to test GetItem
async function getItemTest() {
console.log("Running GetItem Test");
for (let i = 0; i < 5; i++) {
const startTime = performance.now();
const promises = [];
for (let ipk = 1; ipk <= 20; ipk++) {
for (let isk = 1; isk <= 20; isk++) {
promises.push(client.get({ TableName: tableName, Key: { pk: ipk, sk: isk } }));
}
}
await Promise.all(promises);
const endTime = performance.now();
const iterTime = (endTime - startTime) * 1000;
const totalTime = iterTime.toFixed(2).padStart(3, ' ');
const avgTime = (iterTime / 400).toFixed(2).padStart(3, ' ');
console.log(`\tTotal time: ${totalTime} \u00B5s - Avg time: ${avgTime} \u00B5s`);
}
}
// Function to test Query
async function queryTest() {
console.log("Running Query Test");
for (let i = 0; i < 5; i++) {
const startTime = performance.now();
const promises = [];
for (let pk = 1; pk <= 5; pk++) {
const params = {
TableName: tableName,
KeyConditionExpression: "pk = :pkval and sk between :skval1 and :skval2",
ExpressionAttributeValues: { ":pkval": pk, ":skval1": 1, ":skval2": 2 },
};
promises.push(client.query(params));
}
await Promise.all(promises);
const endTime = performance.now();
const iterTime = (endTime - startTime) * 1000;
const totalTime = iterTime.toFixed(2).padStart(3, ' ');
const avgTime = (iterTime / 5).toFixed(2).padStart(3, ' ');
console.log(`\tTotal time: ${totalTime} \u00B5s - Avg time: ${avgTime} \u00B5s`);
}
}
// Function to test Scan
async function scanTest() {
console.log("Running Scan Test");
for (let i = 0; i < 5; i++) {
const startTime = performance.now();
const promises = [];
for (let pk = 1; pk <= 5; pk++) {
const params = {
TableName: tableName,
FilterExpression: "pk = :pkval and sk between :skval1 and :skval2",
ExpressionAttributeValues: { ":pkval": pk, ":skval1": 1, ":skval2": 2 },
};
promises.push(client.scan(params));
}
await Promise.all(promises);
const endTime = performance.now();
const iterTime = (endTime - startTime) * 1000;
const totalTime = iterTime.toFixed(2).padStart(3, ' ');
const avgTime = (iterTime / 5).toFixed(2).padStart(3, ' ');
console.log(`\tTotal time: ${totalTime} \u00B5s - Avg time: ${avgTime} \u00B5s`);
}
}
// Function to test Pagination
async function paginationTest() {
console.log("Running Pagination Test");
console.log("Scan Pagination");
const scanParams = { TableName: tableName };
const paginator = process.argv.length > 2 ? daxPaginateScan : paginateScan;
for await (const page of paginator({ client, pageSize: 3 }, scanParams)) {
console.log(page.Items);
}
console.log("Query Pagination");
const queryParams = {
TableName: tableName,
KeyConditionExpression: "pk = :pkval and sk between :skval1 and :skval2",
ExpressionAttributeValues: { ":pkval": 1, ":skval1": 1, ":skval2": 10 },
};
const queryPaginator = process.argv.length > 2 ? daxPaginateQuery : paginateQuery;
for await (const page of queryPaginator({ client, pageSize: 3 }, queryParams)) {
console.log(page.Items);
}
}
// Function to delete the table
async function deleteTable() {
const dynamodb = new DynamoDB({ region });
console.log("Attempting to delete table; please wait...")
try {
await dynamodb.deleteTable({ TableName: tableName });
await waitUntilTableNotExists({ client: dynamodb, maxWaitTime: 30 }, { TableName: tableName });
console.log("Successfully deleted table.");
} catch (err) {
console.error("Error deleting table:", err);
}
}
// Execute functions sequentially
(async function () {
await createTable();
await writeData();
await getItemTest();
await queryTest();
await scanTest();
await paginationTest();
await deleteTable();
})();
```
# DAX SDK für Go
Gehen Sie wie folgt vor, um die Amazon-DynamoDB-Accelerator-(DAX)-SDK für Go auf Ihrer Amazon-EC2-Instance auszuführen.
**So führen Sie das SDK-für-Go-Beispiel für DAX aus**
1. Richten Sie das SDK für Go auf Ihrer Amazon-EC2-Instance ein:
1. Installieren Sie die Go-Programmiersprache (`Golang`).
```
sudo yum install -y golang
```
1. Testen Sie, ob Golang installiert ist und ordnungsgemäß ausgeführt wird.
```
go version
```
Eine Nachricht wie diese sollte erscheinen.
```
go version go1.23.4 linux/amd64
```
1. Installieren Sie die Golang-Beispielanwendung.
```
go get github.com/aws-samples/sample-aws-dax-go-v2
```
1. Führen Sie die folgenden Golang-Programme aus. Das erste Programm erstellt eine DynamoDB-Tabelle mit dem Namen `TryDaxGoTable`. Das zweite Programm schreibt Daten in die Tabelle.
```
go run ~/go/pkg/mod/github.com/aws-samples/sample-aws-dax-go-v2@v1.0.0/try_dax.go -service dynamodb -command create-table
```
```
go run ~/go/pkg/mod/github.com/aws-samples/sample-aws-dax-go-v2@v1.0.0/try_dax.go -service dynamodb -command put-item
```
1. Führen Sie die folgenden Golang-Programme aus.
```
go run ~/go/pkg/mod/github.com/aws-samples/sample-aws-dax-go-v2@v1.0.0/try_dax.go -service dynamodb -command get-item
```
```
go run ~/go/pkg/mod/github.com/aws-samples/sample-aws-dax-go-v2@v1.0.0/try_dax.go -service dynamodb -command query
```
```
go run ~/go/pkg/mod/github.com/aws-samples/sample-aws-dax-go-v2@v1.0.0/try_dax.go -service dynamodb -command scan
```
Beachten Sie die Zeitinformationen – die Anzahl der benötigten Millisekunden für den `GetItem`-, `Query`- und `Scan`-Test.
1. Im vorherigen Schritt haben Sie die Programme für den DynamoDB-Endpunkt ausgeführt. Führen Sie die Programme jetzt erneut aus. Dieses Mal werden die `GetItem`-, `Query`- und `Scan`-Operationen aber vom DAX-Cluster verarbeitet.
Um den Endpunkt für Ihren DAX-Cluster zu bestimmen, wählen Sie einen der folgenden Schritte aus:
+ **Using the DynamoDB console** (Verwenden der DynamoDB-Konsole) — Wählen Sie Ihren DAX-Cluster aus. Der Cluster-Endpunkt wird auf der Konsole angezeigt, wie im folgenden Beispiel gezeigt.
```
dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com
```
+ **Verwenden von AWS CLI** — Geben Sie den folgenden Befehl ein.
```
aws dax describe-clusters --query "Clusters[*].ClusterDiscoveryEndpoint"
```
Der Cluster-Endpunkt wird wie im folgenden Beispiel in der Ausgabe angezeigt.
```
{
"Address": "my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com",
"Port": 8111,
"URL": "dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com"
}
```
Führen Sie jetzt die Programme erneut aus. Geben Sie dieses Mal jedoch den Cluster-Endpunkt als Befehlszeilenparameter an.
```
go run ~/go/pkg/mod/github.com/aws-samples/sample-aws-dax-go-v2@v1.0.0/try_dax.go -service dax -command get-item -endpoint my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com:8111
```
```
go run ~/go/pkg/mod/github.com/aws-samples/sample-aws-dax-go-v2@v1.0.0/try_dax.go -service dax -command query -endpoint my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com:8111
```
```
go run ~/go/pkg/mod/github.com/aws-samples/sample-aws-dax-go-v2@v1.0.0/try_dax.go -service dax -command scan -endpoint my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com:8111
```
```
go run ~/go/pkg/mod/github.com/aws-samples/sample-aws-dax-go-v2@v1.0.0/try_dax.go -service dax -command paginated-scan -endpoint my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com:8111
```
```
go run ~/go/pkg/mod/github.com/aws-samples/sample-aws-dax-go-v2@v1.0.0/try_dax.go -service dax -command paginated-query -endpoint my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com:8111
```
```
go run ~/go/pkg/mod/github.com/aws-samples/sample-aws-dax-go-v2@v1.0.0/try_dax.go -service dax -command paginated-batch-get -endpoint my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com:8111
```
Sehen Sie sich den Rest der Ausgabe an und notieren Sie die Zeitinformationen. Die verstrichene Zeit sollte für `GetItem`, `Query` und `Scan` mit DAX deutlich kürzer sein als mit DynamoDB.
1. Führen Sie das folgende Golang-Programm aus, um `TryDaxGoTable` zu löschen:
```
go run ~/go/pkg/mod/github.com/aws-samples/sample-aws-dax-go-v2@v1.0.0/try_dax.go -service dynamodb -command delete-table
```
## Funktionen, die nicht mit AWS SDK für Go V2 gleichwertig sind
Middleware Stack — DAX Go V2 unterstützt die Verwendung von Middleware Stacks bis jetzt nicht. APIoptions Weitere Informationen finden Sie unter [Anpassen](https://docs.aws.amazon.com/sdk-for-go/v2/developer-guide/middleware.html#:~:text=You%20can%20customize%20AWS%20SDK,step's%20input%20and%20output%20types) der v2-Client-Anfragen mit Middleware. AWS SDK für Go
Beispiel:
```
// Custom middleware implementation
type customSerializeMiddleware struct{}
// ID returns the identifier for the middleware
func (m *customSerializeMiddleware) ID() string {
return "CustomMiddleware"
}
// HandleSerialize implements the serialize middleware handler
func (m *customSerializeMiddleware) HandleSerialize(
ctx context.Context,
in middleware.SerializeInput,
next middleware.SerializeHandler,
) (
out middleware.SerializeOutput,
metadata middleware.Metadata,
err error,
) {
// Add your custom logic here before the request is serialized
fmt.Printf("Executing custom middleware for request: %v\n", in)
// Call the next handler in the middleware chain
return next.HandleSerialize(ctx, in)
}
func executeGetItem(ctx context.Context) error {
client, err := initItemClient(ctx)
if err != nil {
os.Stderr.WriteString(fmt.Sprintf("failed to initialize client: %v\n", err))
return err
}
st := time.Now()
for c := 0; c < iterations; c++ {
for i := 0; i < pkMax; i++ {
for j := 0; j < skMax; j++ {
// Create key using attributevalue.Marshal for type safety
pk, err := attributevalue.Marshal(fmt.Sprintf("%s_%d", keyPrefix, i))
if err != nil {
return fmt.Errorf("error marshaling pk: %v", err)
}
sk, err := attributevalue.Marshal(fmt.Sprintf("%d", j))
if err != nil {
return fmt.Errorf("error marshaling sk: %v", err)
}
key := map[string]types.AttributeValue{
"pk": pk,
"sk": sk,
}
in := &dynamodb.GetItemInput{
TableName: aws.String(table),
Key: key,
}
// Custom middleware option
customMiddleware := func(o *dynamodb.Options) {
o.APIOptions = append(o.APIOptions, func(stack *middleware.Stack) error {
// Add custom middleware to the stack
return stack.Serialize.Add(&customSerializeMiddleware{}, middleware.After)
})
}
// Apply options to the GetItem call
out, err := client.GetItem(ctx, in, customMiddleware)
if err != nil {
return err
}
writeVerbose(out)
}
}
}
d := time.Since(st)
os.Stdout.WriteString(fmt.Sprintf("Total Time: %v, Avg Time: %v\n", d, d/iterations))
return nil
}
```
Ausgabe:
```
failed to execute command: custom middleware through APIOptions is not supported in DAX client
exit status 1
```
# Standard-Client-Konfiguration für Go
In diesem Handbuch werden Sie durch die Konfigurationsoptionen geführt, mit denen Sie die Leistung, das Verbindungsmanagement und das Protokollierungsverhalten Ihres DAX-Clients optimieren können. Wenn Sie sich mit den Standardeinstellungen und deren Anpassung vertraut machen, können Sie die Interaktion Ihrer Go-Anwendung mit DAX optimieren.
**Topics**
+ [Standardeinstellungen für den DAX-Go-SDK-Client](#DAX-client-config-Go-sdk-client-defaults)
+ [Client-Erstellung](#DAX-client-config-Go-client-creation)
## Standardeinstellungen für den DAX-Go-SDK-Client
| Parameter | Typ | Description |
| --- | --- | --- |
| `Region` Erforderlich | `string` | Der für den DAX-Client AWS-Region zu verwendende (Beispiel- 'us-east-1'). Dies ist ein erforderlicher Parameter, sofern er nicht über die Umgebung bereitgestellt wird. |
| `HostPorts` Erforderlich | `[] string` | Liste der DAX-Cluster-Endpunkte, mit denen das SDK eine Verbindung herstellt. Beispiel: Nicht verschlüsselt – dax://Mein-Cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com Verschlüsselt – daxs://Mein-Cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com |
| `MaxPendingConnectionsPerHost` Standard: 10 | `number` | Die Anzahl der gleichzeitigen Verbindungsversuche. (Verbindungen können gleichzeitig hergestellt werden.) |
| `ClusterUpdateThreshold` Standard: 125 \$1 time.Millisecond | `time.Duration` | Die Mindestzeit, die zwischen Clusteraktualisierungen vergehen muss. |
| `ClusterUpdateInterval` Standard: 4 \$1 time.Second | `time.Duration` | Das Intervall, in dem der Client die DAX-Clusterinformationen automatisch aktualisiert. |
| `IdleConnectionsReapDelay` Standard: 30 \$1 time.Second | `time.Duration` | Das Intervall, in dem der Client inaktive Verbindungen im DAX-Client schließt. |
| `ClientHealthCheckInterval` Standard: 5 \$1 time.Second | `time.Duration` | Das Intervall, in dem der Client Zustandsprüfungen der DAX-Cluster-Endpunkte durchführt. |
| `Credentials` default | `aws.CredentialsProvider` | Die AWS Anmeldeinformationen, die vom DAX-Client zur Authentifizierung von Anfragen an den DAX-Dienst verwendet werden. Siehe [Credentials and Credential Providers](https://docs.aws.amazon.com/sdk-for-go/v2/developer-guide/migrate-gosdk.html#credentials--credential-providers). |
| `DialContext` default | `func` | Eine benutzerdefinierte Funktion, die vom DAX-Client verwendet wird, um Verbindungen zum DAX-Cluster herzustellen. |
| `SkipHostnameVerification` Standard: falsch | bool | Die Hostnamen-Überprüfung von TLS-Verbindungen wird übersprungen. Diese Einstellung wirkt sich nur auf verschlüsselte Cluster aus. Wenn sie auf „True“ gesetzt ist, wird die Überprüfung des Hostnamens deaktiviert. Wenn Sie die Überprüfung deaktivieren, können Sie die Identität des Clusters, zu dem Sie eine Verbindung herstellen, nicht authentifizieren, was ein Sicherheitsrisiko darstellt. Standardmäßig ist die Überprüfung des Hostnamens aktiviert. |
| `RouteManagerEnabled` Standard: falsch | `bool` | Dieses Flag wird verwendet, um Routen zu entfernen, bei denen Netzwerkfehler auftreten. |
| `RequestTimeout` Standard: 60 \$1 time.Second | `time.Duration` | Dies definiert die maximale Zeit, die der Client auf eine Antwort von DAX wartet. Priorität: Kontext-Timeout (falls festgelegt) > `RequestTimmeout` (falls festgelegt) > Standard von 60 s für `RequestTimeout`. |
| `WriteRetries` Standard: 2 | `number` | Die Anzahl der Wiederholungsversuche für fehlgeschlagene Schreibanforderungen. |
| `ReadRetries` Standard: 2 | `number` | Die Anzahl der Wiederholungsversuche für fehlgeschlagene Leseanforderungen. |
| `RetryDelay` Standard: 0 | `time.Duration` | Die Verzögerung bei nicht gedrosselten Fehlern (in Sekunden) bei Wiederholungsversuchen, wenn eine Anforderung fehlschlägt. |
| `Logger` optional | `logging.Logger` | Logger ist eine Schnittstelle zum Protokollieren von Einträgen bei bestimmten Klassifizierungen. |
| `LogLevel` Standard-Utils. LogOff | `number` | Dieses loglevel ist nur für DAX definiert. Es kann mit [Github importiert werden. com/aws/aws-dax-go-v2/tree/main/dax/utils](https://github.com/aws/aws-dax-go-v2/tree/main/dax/utils). const (
LogOff LogLevelType = 0
LogDebug LogLevelType = 1
LogDebugWithRequestRetries
LogLevelType = 2
)
|
**Anmerkung**
Für `time.Duration` ist die Standardeinheit Nanosekunde. Wenn für einen Parameter keine Einheit angegeben wird, wird dies als Nanosekunden betrachtet: `daxCfg.ClusterUpdateInterval = 10` bedeutet 10 Nanosekunden. (`daxCfg.ClusterUpdateInterval = 10 * time.Millisecond` bedeutet 10 Millisekunden).
## Client-Erstellung
**Erstellen Sie einen DAX-Client wie folgt:**
+ Erstellen Sie die DAX-Konfiguration und erstellen Sie dann den DAX-Client mithilfe der DAX-Konfiguration. Auf diese Weise können Sie eine DAX-Konfiguration bei Bedarf überschreiben.
```
import (
"github.com/aws/aws-dax-go-v2/dax/utils"
"github.com/aws/aws-dax-go-v2/dax"
)
// Non - Encrypted : 'dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com'.
// Encrypted : daxs://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com'.
config := dax.DefaultConfig()
config.HostPorts = []string{endpoint}
config.Region = region
config.LogLevel = utils.LogDebug
daxClient, err := dax.New(config)
```
# Migration zu DAX Go SDK V2
Dieser Migrationsleitfaden hilft Ihnen bei der Umstellung Ihrer vorhandenen DAX-Go-Anwendungen.
## Nutzung von V1 DAX Go SDK
```
package main
import (
"fmt"
"os"
"github.com/aws/aws-dax-go/dax"
"github.com/aws/aws-sdk-go/aws"
"github.com/aws/aws-sdk-go/aws/session"
"github.com/aws/aws-sdk-go/service/dynamodb"
)
func main() {
region := "us-west-2"
endpoint := "dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com"
// Create session
sess, err := session.NewSession(&aws.Config{
Region: aws.String(region),
})
if err != nil {
fmt.Printf("Failed to create session: %v\n", err)
os.Exit(1)
}
// Configure DAX client
cfg := dax.DefaultConfig()
cfg.HostPorts = []string{endpoint}
cfg.Region = region
// Create DAX client
daxClient, err := dax.New(cfg)
if err != nil {
fmt.Printf("Failed to create DAX client: %v\n", err)
os.Exit(1)
}
defer daxClient.Close() // Don't forget to close the client
// Create GetItem input
input := &dynamodb.GetItemInput{
TableName: aws.String("TryDaxTable"),
Key: map[string]*dynamodb.AttributeValue{
"pk": {
N: aws.String("1"),
},
"sk": {
N: aws.String("1"),
},
},
}
// Make the GetItem call
result, err := daxClient.GetItem(input)
if err != nil {
fmt.Printf("Failed to get item: %v\n", err)
os.Exit(1)
}
// Print the result
fmt.Printf("GetItem succeeded: %+v\n", result)
}
```
## Nutzung von V2 DAX Go SDK
```
package main
import (
"context"
"fmt"
"os"
"github.com/aws/aws-dax-go-v2/dax"
"github.com/aws/aws-sdk-go-v2/config"
"github.com/aws/aws-sdk-go-v2/service/dynamodb"
"github.com/aws/aws-sdk-go-v2/service/dynamodb/types"
"github.com/aws/aws-sdk-go-v2/feature/dynamodb/attributevalue"
"github.com/aws/aws-sdk-go-v2/aws"
)
func main() {
ctx := context.Background()
region := "us-west-2"
endpoint := "dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com"
// Create DAX config
config := dax.DefaultConfig()
// Specify Endpoint and Region
config.HostPorts = []string{endpoint}
config.Region = region
// Enabling logging
config.LogLevel = utils.LogDebug
// Create DAX client
daxClient, err := dax.New(config)
if err != nil {
fmt.Printf("Failed to create DAX client: %v\n", err)
os.Exit(1)
}
defer daxClient.Close() // Don't forget to close the client
// Create key using attributevalue.Marshal for type safety
pk, err := attributevalue.Marshal(fmt.Sprintf("%s_%d", keyPrefix, i))
if err != nil {
return fmt.Errorf("error marshaling pk: %v", err)
}
sk, err := attributevalue.Marshal(fmt.Sprintf("%d", j))
if err != nil {
return fmt.Errorf("error marshaling sk: %v", err)
}
// Create GetItem input
input := &dynamodb.GetItemInput{
TableName: aws.String("TryDaxTable"),
Key: map[string]types.AttributeValue{
"pk": pk,
"sk": sk,
},
}
// Make the GetItem call
result, err := daxClient.GetItem(ctx, input)
if err != nil {
fmt.Printf("Failed to get item: %v\n", err)
os.Exit(1)
}
// Print the result
fmt.Printf("GetItem succeeded: %+v\n", result)
}
```
Weitere Informationen zur API-Nutzung finden Sie unter [AWS -Beispiele](https://github.com/aws-samples/sample-aws-dax-go-v2).
# Java und DAX
DAX SDK für Java 2.x ist kompatibel mit [AWS SDK für Java 2.x](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/). Es basiert auf Java 8\$1 und bietet Unterstützung für blockierungsfreie I/O. Informationen zur Verwendung von DAX mit AWS SDK for Java 1.x finden Sie unter. [Verwenden von DAX mit AWS SDK for Java 1.x](DAX.client.java-sdk-v1.md)
## Verwenden des Clients als Maven-Abhängigkeit
Führen Sie die folgenden Schritte aus, um den Client für das DAX SDK for Java als Abhängigkeit in Ihrer Anwendung zu verwenden.
1. Laden Sie Apache Maven herunter und installieren Sie es. Weitere Informationen finden Sie unter [Downloading Apache Maven](https://maven.apache.org/download.cgi) und [Installing Apache Maven](https://maven.apache.org/install.html).
1. Fügen Sie die Client-Maven-Abhängigkeit der POM-Datei (Project Object Model) Ihrer Anwendung hinzu. In diesem Beispiel ersetzen Sie es *x.x.x* durch die tatsächliche Versionsnummer des Clients.
```
software.amazon.dax
amazon-dax-client
x.x.x
```
## TryDax Beispielcode
Nachdem Sie Ihren Workspace eingerichtet und das DAX-SDK als Abhängigkeit hinzugefügt haben, kopieren Sie [TryDax.java](DAX.client.TryDax.java.md) in Ihr Projekt.
Führen Sie den Code mit diesem Befehl aus.
```
java -cp classpath TryDax
```
Die Ausgabe sollte in etwa wie folgt aussehen:
```
Creating a DynamoDB client
Attempting to create table; please wait...
Successfully created table. Table status: ACTIVE
Writing data to the table...
Writing 10 items for partition key: 1
Writing 10 items for partition key: 2
Writing 10 items for partition key: 3
...
Running GetItem and Query tests...
First iteration of each test will result in cache misses
Next iterations are cache hits
GetItem test - partition key 1-100 and sort keys 1-10
Total time: 4390.240 ms - Avg time: 4.390 ms
Total time: 3097.089 ms - Avg time: 3.097 ms
Total time: 3273.463 ms - Avg time: 3.273 ms
Total time: 3353.739 ms - Avg time: 3.354 ms
Total time: 3533.314 ms - Avg time: 3.533 ms
Query test - partition key 1-100 and sort keys between 2 and 9
Total time: 475.868 ms - Avg time: 4.759 ms
Total time: 423.333 ms - Avg time: 4.233 ms
Total time: 460.271 ms - Avg time: 4.603 ms
Total time: 397.859 ms - Avg time: 3.979 ms
Total time: 466.644 ms - Avg time: 4.666 ms
Attempting to delete table; please wait...
Successfully deleted table.
```
Beachten Sie die Zeitinformationen – die Anzahl der benötigten Millisekunden für die `GetItem`- und `Query`-Prüfungen. In diesem Fall führten Sie das Programm über den DynamoDB-Endpunkt aus. Jetzt führen Sie das Programm erneut aus, diesmal gegen Ihren DAX-Cluster.
Um den Endpunkt für Ihren DAX-Cluster zu bestimmen, wählen Sie einen der folgenden Schritte aus:
+ Wählen Sie in der DynamoDB-Konsole den DAX-Cluster aus. Der Cluster-Endpunkt wird auf der Konsole angezeigt, wie im folgenden Beispiel gezeigt.
```
dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com
```
+ Geben Sie mit dem AWS CLI den folgenden Befehl ein:
```
aws dax describe-clusters --query "Clusters[*].ClusterDiscoveryEndpoint"
```
Die Adresse, der Port und die URL des Clusterendpunkts werden wie im folgenden Beispiel in der Ausgabe angezeigt.
```
{
"Address": "my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com",
"Port": 8111,
"URL": "dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com"
}
```
Führen Sie nun das Programm erneut aus, geben Sie jedoch diesmal die Clusterendpunkt-URL als Befehlszeilenparameter an.
```
java -cp classpath TryDax dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com
```
Sehen Sie sich die Ausgabe an und notieren Sie die Zeitinformationen. Die verstrichene Zeit für `GetItem` und `Query` sollten mit DAX deutlich geringer sein als mit DynamoDB.
## SDK-Metriken
Mit dem DAX SDK for Java 2.x können Sie Metriken über die Service-Clients in Ihrer Anwendung sammeln und die Ergebnisse in Amazon CloudWatch analysieren. Weitere Informationen finden Sie unter [Aktivieren von SDK-Metriken](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/metrics.html).
**Anmerkung**
Das DAX-SDK für Java erfasst nur `ApiCallSuccessful`- und `ApiCallDuration`-Metriken.
# TryDax.java
```
import java.util.Map;
import software.amazon.awssdk.services.dynamodb.DynamoDbAsyncClient;
import software.amazon.awssdk.services.dynamodb.model.AttributeDefinition;
import software.amazon.awssdk.services.dynamodb.model.AttributeValue;
import software.amazon.awssdk.services.dynamodb.model.BillingMode;
import software.amazon.awssdk.services.dynamodb.model.CreateTableRequest;
import software.amazon.awssdk.services.dynamodb.model.DeleteTableRequest;
import software.amazon.awssdk.services.dynamodb.model.DescribeTableRequest;
import software.amazon.awssdk.services.dynamodb.model.GetItemRequest;
import software.amazon.awssdk.services.dynamodb.model.KeySchemaElement;
import software.amazon.awssdk.services.dynamodb.model.KeyType;
import software.amazon.awssdk.services.dynamodb.model.PutItemRequest;
import software.amazon.awssdk.services.dynamodb.model.QueryRequest;
import software.amazon.awssdk.services.dynamodb.model.ScalarAttributeType;
import software.amazon.dax.ClusterDaxAsyncClient;
import software.amazon.dax.Configuration;
public class TryDax {
public static void main(String[] args) throws Exception {
DynamoDbAsyncClient ddbClient = DynamoDbAsyncClient.builder()
.build();
DynamoDbAsyncClient daxClient = null;
if (args.length >= 1) {
daxClient = ClusterDaxAsyncClient.builder()
.overrideConfiguration(Configuration.builder()
.url(args[0]) // e.g. dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com
.build())
.build();
}
String tableName = "TryDaxTable";
System.out.println("Creating table...");
createTable(tableName, ddbClient);
System.out.println("Populating table...");
writeData(tableName, ddbClient, 100, 10);
DynamoDbAsyncClient testClient = null;
if (daxClient != null) {
testClient = daxClient;
} else {
testClient = ddbClient;
}
System.out.println("Running GetItem and Query tests...");
System.out.println("First iteration of each test will result in cache misses");
System.out.println("Next iterations are cache hits\n");
// GetItem
getItemTest(tableName, testClient, 100, 10, 5);
// Query
queryTest(tableName, testClient, 100, 2, 9, 5);
System.out.println("Deleting table...");
deleteTable(tableName, ddbClient);
}
private static void createTable(String tableName, DynamoDbAsyncClient client) {
try {
System.out.println("Attempting to create table; please wait...");
client.createTable(CreateTableRequest.builder()
.tableName(tableName)
.keySchema(KeySchemaElement.builder()
.keyType(KeyType.HASH)
.attributeName("pk")
.build(), KeySchemaElement.builder()
.keyType(KeyType.RANGE)
.attributeName("sk")
.build())
.attributeDefinitions(AttributeDefinition.builder()
.attributeName("pk")
.attributeType(ScalarAttributeType.N)
.build(), AttributeDefinition.builder()
.attributeName("sk")
.attributeType(ScalarAttributeType.N)
.build())
.billingMode(BillingMode.PAY_PER_REQUEST)
.build()).get();
client.waiter().waitUntilTableExists(DescribeTableRequest.builder()
.tableName(tableName)
.build()).get();
System.out.println("Successfully created table.");
} catch (Exception e) {
System.err.println("Unable to create table: ");
e.printStackTrace();
}
}
private static void deleteTable(String tableName, DynamoDbAsyncClient client) {
try {
System.out.println("\nAttempting to delete table; please wait...");
client.deleteTable(DeleteTableRequest.builder()
.tableName(tableName)
.build()).get();
client.waiter().waitUntilTableNotExists(DescribeTableRequest.builder()
.tableName(tableName)
.build()).get();
System.out.println("Successfully deleted table.");
} catch (Exception e) {
System.err.println("Unable to delete table: ");
e.printStackTrace();
}
}
private static void writeData(String tableName, DynamoDbAsyncClient client, int pkmax, int skmax) {
System.out.println("Writing data to the table...");
int stringSize = 1000;
StringBuilder sb = new StringBuilder(stringSize);
for (int i = 0; i < stringSize; i++) {
sb.append('X');
}
String someData = sb.toString();
try {
for (int ipk = 1; ipk <= pkmax; ipk++) {
System.out.println(("Writing " + skmax + " items for partition key: " + ipk));
for (int isk = 1; isk <= skmax; isk++) {
client.putItem(PutItemRequest.builder()
.tableName(tableName)
.item(Map.of("pk", attr(ipk), "sk", attr(isk), "someData", attr(someData)))
.build()).get();
}
}
} catch (Exception e) {
System.err.println("Unable to write item:");
e.printStackTrace();
}
}
private static AttributeValue attr(int n) {
return AttributeValue.builder().n(String.valueOf(n)).build();
}
private static AttributeValue attr(String s) {
return AttributeValue.builder().s(s).build();
}
private static void getItemTest(String tableName, DynamoDbAsyncClient client, int pk, int sk, int iterations) {
long startTime, endTime;
System.out.println("GetItem test - partition key 1-" + pk + " and sort keys 1-" + sk);
for (int i = 0; i < iterations; i++) {
startTime = System.nanoTime();
try {
for (int ipk = 1; ipk <= pk; ipk++) {
for (int isk = 1; isk <= sk; isk++) {
client.getItem(GetItemRequest.builder()
.tableName(tableName)
.key(Map.of("pk", attr(ipk), "sk", attr(isk)))
.build()).get();
}
}
} catch (Exception e) {
System.err.println("Unable to get item:");
e.printStackTrace();
}
endTime = System.nanoTime();
printTime(startTime, endTime, pk * sk);
}
}
private static void queryTest(String tableName, DynamoDbAsyncClient client, int pk, int sk1, int sk2, int iterations) {
long startTime, endTime;
System.out.println("Query test - partition key 1-" + pk + " and sort keys between " + sk1 + " and " + sk2);
for (int i = 0; i < iterations; i++) {
startTime = System.nanoTime();
for (int ipk = 1; ipk <= pk; ipk++) {
try {
// Pagination API for Query.
client.queryPaginator(QueryRequest.builder()
.tableName(tableName)
.keyConditionExpression("pk = :pkval and sk between :skval1 and :skval2")
.expressionAttributeValues(Map.of(":pkval", attr(ipk), ":skval1", attr(sk1), ":skval2", attr(sk2)))
.build()).items().subscribe((item) -> {
}).get();
} catch (Exception e) {
System.err.println("Unable to query table:");
e.printStackTrace();
}
}
endTime = System.nanoTime();
printTime(startTime, endTime, pk);
}
}
private static void printTime(long startTime, long endTime, int iterations) {
System.out.format("\tTotal time: %.3f ms - ", (endTime - startTime) / (1000000.0));
System.out.format("Avg time: %.3f ms\n", (endTime - startTime) / (iterations * 1000000.0));
}
}
```
# .NET und DAX
Gehen Sie wie folgt vor, um das .NET-Beispiel auf Ihrer Amazon-EC2-Instance auszuführen.
**Anmerkung**
In diesem Tutorial wird das.NET 9 SDK verwendet. Sie zeigt, wie Sie ein Programm in der Standard-Amazon VPC ausführen können, um auf den Amazon-DynamoDB-Accelerator-(DAX)-Cluster zuzugreifen. Es funktioniert mit dem [AWS SDK v4 für .NET](https://docs.aws.amazon.com/sdk-for-net/v4/developer-guide/welcome.html). Einzelheiten zu Änderungen in V4 und Informationen zur Migration finden Sie unter [Migration auf Version 4 des AWS SDK for .NET](https://docs.aws.amazon.com/sdk-for-net/v4/developer-guide/net-dg-v4.html). Wenn Sie möchten, können Sie die verwenden, AWS Toolkit for Visual Studio um eine.NET-Anwendung zu schreiben und sie in Ihrer VPC bereitzustellen.
Weitere Informationen finden Sie unter [Erstellen und Bereitstellen von Elastic-Beanstalk-Anwendungen in .NET mit AWS -Toolkit for Visual Studio](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_NET.html) im *AWS Elastic Beanstalk -Entwicklerhandbuch*.
**So führen Sie das .NET-Beispiel für DAX aus**
1. Gehen Sie zur [Microsoft-Downloadseite](https://www.microsoft.com/net/download?initial-os=linux) und laden Sie das neueste.NET 9-SDK für Linux herunter. Der Name der heruntergeladenen Datei lautet `dotnet-sdk-N.N.N-linux-x64.tar.gz`.
1. Extrahieren Sie die SDK-Dateien.
```
mkdir dotnet
tar zxvf dotnet-sdk-N.N.N-linux-x64.tar.gz -C dotnet
```
Ersetzen Sie `N.N.N` durch die tatsächliche Versionsnummer des .NET SDK (z. B.: `9.0.305`).
1. Überprüfen Sie die Installation.
```
alias dotnet=$HOME/dotnet/dotnet
dotnet --version
```
Damit sollte die Versionsnummer des .NET SDK ausgegeben werden.
**Anmerkung**
Statt der Versionsnummer erhalten Sie möglicherweise die folgende Fehlermeldung:
error: libunwind.so.8: cannot open shared object file: No such file or directory (Fehler: libunwind.so.8: Die freigegebene Datei kann nicht geöffnet werden: Datei oder Verzeichnis nicht vorhanden)
Um den Fehler zu beheben, installieren Sie das `libunwind`-Paket.
```
sudo yum install -y libunwind
```
Anschließend sollte es möglich sein, den `dotnet --version`-Befehl fehlerfrei auszuführen.
1. Erstellen Sie ein neues .NET-Projekt.
```
dotnet new console -o myApp
```
Dies dauert einige Minuten, um ein one-time-only Setup durchzuführen. Nachdem sie fertig ist, führen Sie das Beispielprojekt aus.
```
dotnet run --project myApp
```
Sie sollten die folgende Meldung erhalten: `Hello World!`
1. Die Datei `myApp/myApp.csproj` enthält Metadaten über Ihr Projekt. Um den DAX-Client in Ihrer Anwendung nutzen zu können, ändern Sie die Datei, sodass sie wie folgt aussieht.
```
Exe
net9.0
```
1. Downloaden Sie den Quellcode des Beispielprogramms (`.zip`-Datei):
```
wget http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/samples/TryDax.zip
```
Wenn der Download abgeschlossen ist, extrahieren Sie die Quelldateien.
```
unzip TryDax.zip
```
1. Führen Sie nun nacheinander die Beispielprogramme von *DotNet* aus. Kopieren Sie für jedes Programm seinen Inhalt in die Datei `myApp/Program.cs` und führen Sie dann das `MyApp`-Projekt aus.
Führen Sie die folgenden .NET-Programme aus. Das erste Programm erstellt eine DynamoDB-Tabelle mit dem Namen `TryDaxTable`. Das zweite Programm schreibt Daten in die Tabelle.
```
cp TryDax/dotNet/01-CreateTable.cs myApp/Program.cs
dotnet run --project myApp
cp TryDax/dotNet/02-Write-Data.cs myApp/Program.cs
dotnet run --project myApp
```
1. Führen Sie jetzt einige Programme zur Durchführung von `GetItem`-, `Query`- und `Scan`-Operationen auf dem DAX-Cluster aus. Um den Endpunkt für Ihren DAX-Cluster zu bestimmen, wählen Sie einen der folgenden Schritte aus:
+ **Using the DynamoDB console** (Verwenden der DynamoDB-Konsole) — Wählen Sie Ihren DAX-Cluster aus. Der Cluster-Endpunkt wird auf der Konsole angezeigt, wie im folgenden Beispiel gezeigt.
```
dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com
```
+ **Verwenden Sie den AWS CLI** — Geben Sie den folgenden Befehl ein.
```
aws dax describe-clusters --query "Clusters[*].ClusterDiscoveryEndpoint"
```
Der Clusterendpunkt wird wie im folgenden Beispiel in der Ausgabe angezeigt.
```
{
"Address": "my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com",
"Port": 8111,
"URL": "dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com"
}
```
Führen Sie jetzt die folgenden Programme aus und geben Sie den Cluster-Endpunkt als Befehlszeilenparameter an. (Ersetzen Sie den Beispiel-Endpunkt durch den tatsächlichen DAX-Cluster-Endpunkt.)
```
cp TryDax/dotNet/03-GetItem-Test.cs myApp/Program.cs
dotnet run --project myApp dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com
cp TryDax/dotNet/04-Query-Test.cs myApp/Program.cs
dotnet run --project myApp dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com
cp TryDax/dotNet/05-Scan-Test.cs myApp/Program.cs
dotnet run --project myApp dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com
```
Beachten Sie die Zeitinformationen – die Anzahl der benötigten Millisekunden für den `GetItem`-, `Query`- und `Scan`-Test.
1. Führen Sie das folgende .NET-Programm aus, um `TryDaxTable` zu löschen.
```
cp TryDax/dotNet/06-DeleteTable.cs myApp/Program.cs
dotnet run --project myApp
```
Weitere Informationen zu diesen Programmen finden Sie in folgenden Abschnitten:
+ [0-1 CreateTable .cs](DAX.client.run-application-dotnet.01-CreateTable.md)
+ [02-Write-Data.cs](DAX.client.run-application-dotnet.02-Write-Data.md)
+ [03- -Test.cs GetItem](DAX.client.run-application-dotnet.03-GetItem-Test.md)
+ [04-Query-Test.cs](DAX.client.run-application-dotnet.04-Query-Test.md)
+ [05-Scan-Test.cs](DAX.client.run-application-dotnet.05-Scan-Test.md)
+ [0-6. DeleteTable cs](DAX.client.run-application-dotnet.06-DeleteTable.md)
# 0-1 CreateTable .cs
Das Programm `01-CreateTable.cs` erstellt eine Tabelle (`TryDaxTable`). Die restlichen .NET-Programme in diesem Abschnitt hängen von dieser Tabelle ab.
```
using System;
using System.Collections.Generic;
using System.Threading.Tasks;
using Amazon.DynamoDBv2;
using Amazon.DynamoDBv2.Model;
namespace ClientTest
{
class Program
{
public static async Task Main(string[] args)
{
AmazonDynamoDBClient client = new AmazonDynamoDBClient();
var tableName = "TryDaxTable";
var request = new CreateTableRequest()
{
TableName = tableName,
KeySchema = new List()
{
new KeySchemaElement{ AttributeName = "pk",KeyType = "HASH"},
new KeySchemaElement{ AttributeName = "sk",KeyType = "RANGE"}
},
AttributeDefinitions = new List() {
new AttributeDefinition{ AttributeName = "pk",AttributeType = "N"},
new AttributeDefinition{ AttributeName = "sk",AttributeType = "N"}
},
ProvisionedThroughput = new ProvisionedThroughput()
{
ReadCapacityUnits = 10,
WriteCapacityUnits = 10
}
};
var response = await client.CreateTableAsync(request);
Console.WriteLine("Hit to continue...");
Console.ReadLine();
}
}
}
```
# 02-Write-Data.cs
Das Programm `02-Write-Data.cs` schreibt Testdaten in `TryDaxTable`.
```
using System;
using System.Collections.Generic;
using System.Threading.Tasks;
using Amazon.DynamoDBv2;
using Amazon.DynamoDBv2.Model;
namespace ClientTest
{
class Program
{
public static async Task Main(string[] args)
{
AmazonDynamoDBClient client = new AmazonDynamoDBClient();
var tableName = "TryDaxTable";
string someData = new string('X', 1000);
var pkmax = 10;
var skmax = 10;
for (var ipk = 1; ipk <= pkmax; ipk++)
{
Console.WriteLine($"Writing {skmax} items for partition key: {ipk}");
for (var isk = 1; isk <= skmax; isk++)
{
var request = new PutItemRequest()
{
TableName = tableName,
Item = new Dictionary()
{
{ "pk", new AttributeValue{N = ipk.ToString() } },
{ "sk", new AttributeValue{N = isk.ToString() } },
{ "someData", new AttributeValue{S = someData } }
}
};
var response = await client.PutItemAsync(request);
}
}
Console.WriteLine("Hit to continue...");
Console.ReadLine();
}
}
}
```
# 03- -Test.cs GetItem
Das Programm `03-GetItem-Test.cs` führt `GetItem`-Operationen für `TryDaxTable` aus.
```
using System;
using System.Collections.Generic;
using System.Threading.Tasks;
using Amazon.DAX;
using Amazon.DynamoDBv2.Model;
using Amazon.Runtime;
namespace ClientTest
{
class Program
{
public static async Task Main(string[] args)
{
string endpointUri = args[0];
Console.WriteLine($"Using DAX client - endpointUri={endpointUri}");
var clientConfig = new DaxClientConfig(endpointUri)
{
AwsCredentials = FallbackCredentialsFactory.GetCredentials()
};
var client = new ClusterDaxClient(clientConfig);
var tableName = "TryDaxTable";
var pk = 1;
var sk = 10;
var iterations = 5;
var startTime = System.DateTime.Now;
for (var i = 0; i < iterations; i++)
{
for (var ipk = 1; ipk <= pk; ipk++)
{
for (var isk = 1; isk <= sk; isk++)
{
var request = new GetItemRequest()
{
TableName = tableName,
Key = new Dictionary() {
{"pk", new AttributeValue {N = ipk.ToString()} },
{"sk", new AttributeValue {N = isk.ToString() } }
}
};
var response = await client.GetItemAsync(request);
Console.WriteLine($"GetItem succeeded for pk: {ipk},sk: {isk}");
}
}
}
var endTime = DateTime.Now;
TimeSpan timeSpan = endTime - startTime;
Console.WriteLine($"Total time: {timeSpan.TotalMilliseconds} milliseconds");
Console.WriteLine("Hit to continue...");
Console.ReadLine();
}
}
}
```
# 04-Query-Test.cs
Das Programm `04-Query-Test.cs` führt `Query`-Operationen für `TryDaxTable` aus.
```
using System;
using System.Collections.Generic;
using System.Threading.Tasks;
using Amazon.Runtime;
using Amazon.DAX;
using Amazon.DynamoDBv2.Model;
namespace ClientTest
{
class Program
{
public static async Task Main(string[] args)
{
string endpointUri = args[0];
Console.WriteLine($"Using DAX client - endpointUri={endpointUri}");
var clientConfig = new DaxClientConfig(endpointUri)
{
AwsCredentials = FallbackCredentialsFactory.GetCredentials()
};
var client = new ClusterDaxClient(clientConfig);
var tableName = "TryDaxTable";
var pk = 5;
var sk1 = 2;
var sk2 = 9;
var iterations = 5;
var startTime = DateTime.Now;
for (var i = 0; i < iterations; i++)
{
var request = new QueryRequest()
{
TableName = tableName,
KeyConditionExpression = "pk = :pkval and sk between :skval1 and :skval2",
ExpressionAttributeValues = new Dictionary() {
{":pkval", new AttributeValue {N = pk.ToString()} },
{":skval1", new AttributeValue {N = sk1.ToString()} },
{":skval2", new AttributeValue {N = sk2.ToString()} }
}
};
var response = await client.QueryAsync(request);
Console.WriteLine($"{i}: Query succeeded");
}
var endTime = DateTime.Now;
TimeSpan timeSpan = endTime - startTime;
Console.WriteLine($"Total time: {timeSpan.TotalMilliseconds} milliseconds");
Console.WriteLine("Hit to continue...");
Console.ReadLine();
}
}
}
```
# 05-Scan-Test.cs
Das Programm `05-Scan-Test.cs` führt `Scan`-Operationen für `TryDaxTable` aus.
```
using System;
using System.Threading.Tasks;
using Amazon.Runtime;
using Amazon.DAX;
using Amazon.DynamoDBv2.Model;
namespace ClientTest
{
class Program
{
public static async Task Main(string[] args)
{
string endpointUri = args[0];
Console.WriteLine($"Using DAX client - endpointUri={endpointUri}");
var clientConfig = new DaxClientConfig(endpointUri)
{
AwsCredentials = FallbackCredentialsFactory.GetCredentials()
};
var client = new ClusterDaxClient(clientConfig);
var tableName = "TryDaxTable";
var iterations = 5;
var startTime = DateTime.Now;
for (var i = 0; i < iterations; i++)
{
var request = new ScanRequest()
{
TableName = tableName
};
var response = await client.ScanAsync(request);
Console.WriteLine($"{i}: Scan succeeded");
}
var endTime = DateTime.Now;
TimeSpan timeSpan = endTime - startTime;
Console.WriteLine($"Total time: {timeSpan.TotalMilliseconds} milliseconds");
Console.WriteLine("Hit to continue...");
Console.ReadLine();
}
}
}
```
# 0-6. DeleteTable cs
Das `06-DeleteTable.cs`-Programm löscht `TryDaxTable`. Führen Sie dieses Programm aus, sobald Sie mit dem Testen fertig sind.
```
using System;
using System.Threading.Tasks;
using Amazon.DynamoDBv2.Model;
using Amazon.DynamoDBv2;
namespace ClientTest
{
class Program
{
public static async Task Main(string[] args)
{
AmazonDynamoDBClient client = new AmazonDynamoDBClient();
var tableName = "TryDaxTable";
var request = new DeleteTableRequest()
{
TableName = tableName
};
var response = await client.DeleteTableAsync(request);
Console.WriteLine("Hit to continue...");
Console.ReadLine();
}
}
}
```
# Python und DAX
Um die Python-Beispielanwendung auf Ihrer Amazon-EC2-Instance auszuführen, gehen Sie wie folgt vor.
**So führen Sie das Python-Beispiel für DAX aus**
1. Installieren Sie den DAX-Python-Client mit dem `pip`-Dienstprogramm.
```
pip install amazon-dax-client
```
1. Downloaden Sie den Quellcode des Beispielprogramms (`.zip`-Datei):
```
wget http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/samples/TryDax.zip
```
Wenn der Download abgeschlossen ist, extrahieren Sie die Quelldateien.
```
unzip TryDax.zip
```
1. Führen Sie die folgenden Python-Programme aus. Das erste Programm erstellt eine Amazon-DynamoDB-Tabelle mit dem Namen `TryDaxTable`. Das zweite Programm schreibt Daten in die Tabelle.
```
python 01-create-table.py
python 02-write-data.py
```
1. Führen Sie die folgenden Python-Programme aus.
```
python 03-getitem-test.py
python 04-query-test.py
python 05-scan-test.py
```
Beachten Sie die Zeitinformationen – die Anzahl der benötigten Millisekunden für den `GetItem`-, `Query`- und `Scan`-Test.
1. Im vorherigen Schritt haben Sie die Programme für den DynamoDB-Endpunkt ausgeführt. Führen Sie die Programme jetzt erneut aus. Dieses Mal werden die `GetItem`-, `Query`- und `Scan`-Operationen aber vom DAX-Cluster verarbeitet.
Um den Endpunkt für Ihren DAX-Cluster zu bestimmen, wählen Sie einen der folgenden Schritte aus:
+ **Using the DynamoDB console** (Verwenden der DynamoDB-Konsole) — Wählen Sie Ihren DAX-Cluster aus. Der Cluster-Endpunkt wird auf der Konsole angezeigt, wie im folgenden Beispiel gezeigt.
```
dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com
```
+ **Verwenden** Sie AWS CLI— Geben Sie den folgenden Befehl ein.
```
aws dax describe-clusters --query "Clusters[*].ClusterDiscoveryEndpoint"
```
Der Cluster-Endpunkt wird wie in diesem Beispiel in der Ausgabe angezeigt.
```
{
"Address": "my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com",
"Port": 8111,
"URL": "dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com"
}
```
Führen Sie jetzt die Programme erneut aus. Geben Sie dieses Mal jedoch den Cluster-Endpunkt als Befehlszeilenparameter an.
```
python 03-getitem-test.py dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com
python 04-query-test.py dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com
python 05-scan-test.py dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com
```
Sehen Sie sich den Rest der Ausgabe an und notieren Sie die Zeitinformationen. Die verstrichene Zeit sollte für `GetItem`, `Query` und `Scan` mit DAX deutlich kürzer sein als mit DynamoDB.
1. Führen Sie das folgende Python-Programm aus, um `TryDaxTable` zu löschen:
```
python 06-delete-table.py
```
Weitere Informationen zu diesen Programmen finden Sie in folgenden Abschnitten:
+ [01-create-table.py](DAX.client.run-application-python.01-create-table.md)
+ [02-write-data.py](DAX.client.run-application-python.02-write-data.md)
+ [03-getitem-test.py](DAX.client.run-application-python.03-getitem-test.md)
+ [04-query-test.py](DAX.client.run-application-python.04-query-test.md)
+ [05-scan-test.py](DAX.client.run-application-python.05-scan-test.md)
+ [06-delete-table.py](DAX.client.run-application-python.06-delete-table.md)
# 01-create-table.py
Das Programm `01-create-table.py` erstellt eine Tabelle (`TryDaxTable`). Die restlichen Python-Programme in diesem Abschnitt hängen von dieser Tabelle ab.
```
import boto3
def create_dax_table(dyn_resource=None):
"""
Creates a DynamoDB table.
:param dyn_resource: Either a Boto3 or DAX resource.
:return: The newly created table.
"""
if dyn_resource is None:
dyn_resource = boto3.resource("dynamodb")
table_name = "TryDaxTable"
params = {
"TableName": table_name,
"KeySchema": [
{"AttributeName": "partition_key", "KeyType": "HASH"},
{"AttributeName": "sort_key", "KeyType": "RANGE"},
],
"AttributeDefinitions": [
{"AttributeName": "partition_key", "AttributeType": "N"},
{"AttributeName": "sort_key", "AttributeType": "N"},
],
"BillingMode": "PAY_PER_REQUEST",
}
table = dyn_resource.create_table(**params)
print(f"Creating {table_name}...")
table.wait_until_exists()
return table
if __name__ == "__main__":
dax_table = create_dax_table()
print(f"Created table.")
```
# 02-write-data.py
Das Programm `02-write-data.py` schreibt Testdaten in `TryDaxTable`.
```
import boto3
def write_data_to_dax_table(key_count, item_size, dyn_resource=None):
"""
Writes test data to the demonstration table.
:param key_count: The number of partition and sort keys to use to populate the
table. The total number of items is key_count * key_count.
:param item_size: The size of non-key data for each test item.
:param dyn_resource: Either a Boto3 or DAX resource.
"""
if dyn_resource is None:
dyn_resource = boto3.resource("dynamodb")
table = dyn_resource.Table("TryDaxTable")
some_data = "X" * item_size
for partition_key in range(1, key_count + 1):
for sort_key in range(1, key_count + 1):
table.put_item(
Item={
"partition_key": partition_key,
"sort_key": sort_key,
"some_data": some_data,
}
)
print(f"Put item ({partition_key}, {sort_key}) succeeded.")
if __name__ == "__main__":
write_key_count = 10
write_item_size = 1000
print(
f"Writing {write_key_count*write_key_count} items to the table. "
f"Each item is {write_item_size} characters."
)
write_data_to_dax_table(write_key_count, write_item_size)
```
# 03-getitem-test.py
Das Programm `03-getitem-test.py` führt `GetItem`-Operationen für `TryDaxTable` aus. Dieses Beispiel wird für die Region eu-west-1 gegeben.
```
import argparse
import sys
import time
import amazondax
import boto3
def get_item_test(key_count, iterations, dyn_resource=None):
"""
Gets items from the table a specified number of times. The time before the
first iteration and the time after the last iteration are both captured
and reported.
:param key_count: The number of items to get from the table in each iteration.
:param iterations: The number of iterations to run.
:param dyn_resource: Either a Boto3 or DAX resource.
:return: The start and end times of the test.
"""
if dyn_resource is None:
dyn_resource = boto3.resource('dynamodb')
table = dyn_resource.Table('TryDaxTable')
start = time.perf_counter()
for _ in range(iterations):
for partition_key in range(1, key_count + 1):
for sort_key in range(1, key_count + 1):
table.get_item(Key={
'partition_key': partition_key,
'sort_key': sort_key
})
print('.', end='')
sys.stdout.flush()
print()
end = time.perf_counter()
return start, end
if __name__ == '__main__':
parser = argparse.ArgumentParser()
parser.add_argument(
'endpoint_url', nargs='?',
help="When specified, the DAX cluster endpoint. Otherwise, DAX is not used.")
args = parser.parse_args()
test_key_count = 10
test_iterations = 50
if args.endpoint_url:
print(f"Getting each item from the table {test_iterations} times, "
f"using the DAX client.")
# Use a with statement so the DAX client closes the cluster after completion.
with amazondax.AmazonDaxClient.resource(endpoint_url=args.endpoint_url, region_name='eu-west-1') as dax:
test_start, test_end = get_item_test(
test_key_count, test_iterations, dyn_resource=dax)
else:
print(f"Getting each item from the table {test_iterations} times, "
f"using the Boto3 client.")
test_start, test_end = get_item_test(
test_key_count, test_iterations)
print(f"Total time: {test_end - test_start:.4f} sec. Average time: "
f"{(test_end - test_start)/ test_iterations}.")
```
# 04-query-test.py
Das Programm `04-query-test.py` führt `Query`-Operationen für `TryDaxTable` aus.
```
import argparse
import time
import sys
import amazondax
import boto3
from boto3.dynamodb.conditions import Key
def query_test(partition_key, sort_keys, iterations, dyn_resource=None):
"""
Queries the table a specified number of times. The time before the
first iteration and the time after the last iteration are both captured
and reported.
:param partition_key: The partition key value to use in the query. The query
returns items that have partition keys equal to this value.
:param sort_keys: The range of sort key values for the query. The query returns
items that have sort key values between these two values.
:param iterations: The number of iterations to run.
:param dyn_resource: Either a Boto3 or DAX resource.
:return: The start and end times of the test.
"""
if dyn_resource is None:
dyn_resource = boto3.resource("dynamodb")
table = dyn_resource.Table("TryDaxTable")
key_condition_expression = Key("partition_key").eq(partition_key) & Key(
"sort_key"
).between(*sort_keys)
start = time.perf_counter()
for _ in range(iterations):
table.query(KeyConditionExpression=key_condition_expression)
print(".", end="")
sys.stdout.flush()
print()
end = time.perf_counter()
return start, end
if __name__ == "__main__":
# pylint: disable=not-context-manager
parser = argparse.ArgumentParser()
parser.add_argument(
"endpoint_url",
nargs="?",
help="When specified, the DAX cluster endpoint. Otherwise, DAX is not used.",
)
args = parser.parse_args()
test_partition_key = 5
test_sort_keys = (2, 9)
test_iterations = 100
if args.endpoint_url:
print(f"Querying the table {test_iterations} times, using the DAX client.")
# Use a with statement so the DAX client closes the cluster after completion.
with amazondax.AmazonDaxClient.resource(endpoint_url=args.endpoint_url) as dax:
test_start, test_end = query_test(
test_partition_key, test_sort_keys, test_iterations, dyn_resource=dax
)
else:
print(f"Querying the table {test_iterations} times, using the Boto3 client.")
test_start, test_end = query_test(
test_partition_key, test_sort_keys, test_iterations
)
print(
f"Total time: {test_end - test_start:.4f} sec. Average time: "
f"{(test_end - test_start)/test_iterations}."
)
```
# 05-scan-test.py
Das Programm `05-scan-test.py` führt `Scan`-Operationen für `TryDaxTable` aus.
```
import argparse
import time
import sys
import amazondax
import boto3
def scan_test(iterations, dyn_resource=None):
"""
Scans the table a specified number of times. The time before the
first iteration and the time after the last iteration are both captured
and reported.
:param iterations: The number of iterations to run.
:param dyn_resource: Either a Boto3 or DAX resource.
:return: The start and end times of the test.
"""
if dyn_resource is None:
dyn_resource = boto3.resource("dynamodb")
table = dyn_resource.Table("TryDaxTable")
start = time.perf_counter()
for _ in range(iterations):
table.scan()
print(".", end="")
sys.stdout.flush()
print()
end = time.perf_counter()
return start, end
if __name__ == "__main__":
# pylint: disable=not-context-manager
parser = argparse.ArgumentParser()
parser.add_argument(
"endpoint_url",
nargs="?",
help="When specified, the DAX cluster endpoint. Otherwise, DAX is not used.",
)
args = parser.parse_args()
test_iterations = 100
if args.endpoint_url:
print(f"Scanning the table {test_iterations} times, using the DAX client.")
# Use a with statement so the DAX client closes the cluster after completion.
with amazondax.AmazonDaxClient.resource(endpoint_url=args.endpoint_url) as dax:
test_start, test_end = scan_test(test_iterations, dyn_resource=dax)
else:
print(f"Scanning the table {test_iterations} times, using the Boto3 client.")
test_start, test_end = scan_test(test_iterations)
print(
f"Total time: {test_end - test_start:.4f} sec. Average time: "
f"{(test_end - test_start)/test_iterations}."
)
```
# 06-delete-table.py
Das `06-delete-table.py`-Programm löscht `TryDaxTable`. Führen Sie dieses Programm aus, sobald Sie mit dem Testen der Amazon-DynamoDB-Accelerator-(DAX)-Funktionalität fertig sind.
```
import boto3
def delete_dax_table(dyn_resource=None):
"""
Deletes the demonstration table.
:param dyn_resource: Either a Boto3 or DAX resource.
"""
if dyn_resource is None:
dyn_resource = boto3.resource("dynamodb")
table = dyn_resource.Table("TryDaxTable")
table.delete()
print(f"Deleting {table.name}...")
table.wait_until_not_exists()
if __name__ == "__main__":
delete_dax_table()
print("Table deleted!")
```
# Ändern einer vorhandenen Anwendung für die Verwendung von DAX
Wenn Sie bereits über eine Java-Anwendung verfügen, die Amazon DynamoDB verwendet, müssen Sie sie so ändern, dass sie auf den DynamoDB-Accelerator-(DAX)-Cluster zugreifen kann. Sie müssen nicht die gesamte Anwendung neu schreiben, da der DAX-Java-Client dem DynamoDB-Low-Level-Client ähnelt, der im AWS SDK for Java 2.x enthalten ist. Weitere Informationen finden Sie unter [Arbeiten mit Elementen in DynamoDB](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/examples-dynamodb-items.html).
**Anmerkung**
In diesem Beispiel wird AWS SDK for Java 2.x verwendet. Weitere Informationen zur Legacy-SDK für Java 1.x-Version finden Sie unter [Verwenden einer vorhandenen SDK for Java 1.x Anwendung zur Nutzung von DAX](DAX.client.modify-your-app.java-sdk-v1.md).
Zum Ändern des Programms ersetzen Sie den DynamoDB-Client durch einen DAX-Client.
```
Region region = Region.US_EAST_1;
// Create an asynchronous DynamoDB client
DynamoDbAsyncClient client = DynamoDbAsyncClient.builder()
.region(region)
.build();
// Create an asynchronous DAX client
DynamoDbAsyncClient client = ClusterDaxAsyncClient.builder()
.overrideConfiguration(Configuration.builder()
.url() // for example, "dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com"
.region(region)
.addMetricPublisher(cloudWatchMetricsPub) // optionally enable SDK metric collection
.build())
.build();
```
Sie können auch die High-Level-Bibliothek verwenden, die Teil des AWS SDK for Java 2.x ist, und den DynamoDB-Client durch einen DAX-Client ersetzen.
```
Region region = Region.US_EAST_1;
DynamoDbAsyncClient dax = ClusterDaxAsyncClient.builder()
.overrideConfiguration(Configuration.builder()
.url() // for example, "dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com"
.region(region)
.build())
.build();
DynamoDbEnhancedAsyncClient enhancedClient = DynamoDbEnhancedAsyncClient.builder()
.dynamoDbClient(dax)
.build();
```
Weitere Informationen finden Sie unter [Mapping-Elementen in DynamoDB-Tabellen](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/examples-dynamodb-enhanced.html).
# Verwalten von DAX-Clustern
In diesem Abschnitt werden einige der gängigsten Verwaltungsaufgaben für Amazon-DynamoDB-Accelerator-(DAX)-Cluster erörtert.
**Topics**
+ [IAM-Berechtigungen zum Verwalten eines DAX-Clusters](#DAX.cluster-management.iam-permissions)
+ [Skalieren eines DAX-Clusters](#DAX.cluster-management.scaling)
+ [Anpassen der DAX-Cluster-Einstellungen](#DAX.cluster-management.custom-settings)
+ [Konfigurieren der TTL-Einstellungen](#DAX.cluster-management.custom-settings.ttl)
+ [Unterstützung von Markierungen für DAX](#DAX.management.tagging)
+ [AWS CloudTrail Integration](#DAX.management.cloudtrail)
+ [Löschen eines DAX-Clusters](#DAX.cluster-management.deleting)
## IAM-Berechtigungen zum Verwalten eines DAX-Clusters
Wenn Sie einen DAX-Cluster mithilfe von AWS-Managementkonsole oder AWS Command Line Interface (AWS CLI) verwalten, empfehlen wir dringend, den Umfang der Aktionen einzuschränken, die Benutzer ausführen können. So können Sie die Risiken minimieren und der Regel der geringsten Rechte folgen.
Die folgende Diskussion konzentriert sich auf die Zugriffskontrolle für das DAX-Management APIs. Weitere Informationen finden Sie unter [Amazon DynamoDB Accelerator](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations_Amazon_DynamoDB_Accelerator_(DAX).html) in *Amazon-DynamoDB-API-Referenz*.
**Anmerkung**
Ausführlichere Informationen zur Verwaltung von AWS Identity and Access Management (IAM-) Berechtigungen finden Sie im Folgenden:
IAM und Erstellen von DAX-Cluster: [Erstellen eines DAX-Clusters](DAX.create-cluster.md).
IAM und DAX-Operationen auf Dateneben: [DAX-Zugriffskontrolle](DAX.access-control.md).
Für das DAX-Management APIs können Sie API-Aktionen nicht auf eine bestimmte Ressource beschränken. Das `Resource` -Element muss auf `"*"` gesetzt sein. Dies ist anders als bei DAX-API-Operationen auf Datenebene, wie z. B. `GetItem`, `Query` und `Scan`. Operationen auf Datenebene werden über den DAX-Client bereitgestellt. Diese Operationen *können* auf bestimmte Ressourcen begrenzt werden.
Schauen Sie sich zur Veranschaulichung das folgende IAM-Richtliniendokument an.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"dax:*"
],
"Effect": "Allow",
"Resource": [
"arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01"
]
}
]
}
```
------
Angenommen, die Absicht dieser Richtlinie besteht darin, DAX-Verwaltungs-API-Aufrufe für den Cluster `DAXCluster01` – und nur für diesen Cluster – zuzulassen.
Nehmen wir nun an, ein Benutzer gibt den folgenden AWS CLI Befehl aus.
```
aws dax describe-clusters
```
Dieser Befehl schlägt mit der Ausnahme Nicht autorisiert fehl, da der zugrunde liegende API-Aufruf `DescribeClusters` nicht auf einen bestimmten Cluster beschränkt werden kann. Die Richtlinie ist syntaktisch zwar gültig, dennoch schlägt der Befehl fehl, da das `Resource`-Element auf `"*"` festgelegt sein muss. Wenn der Benutzer jedoch ein Programm ausführt, das DAX-Datenebenenaufrufe (z. B. `GetItem` oder `Query`) an `DAXCluster01` sendet, sind diese Aufrufe *erfolgreich*. Dies liegt daran, dass die DAX-Datenebene auf bestimmte Ressourcen beschränkt werden APIs kann (in diesem Fall`DAXCluster01`).
Wenn Sie eine einzige umfassende IAM-Richtlinie verfassen möchten, die sowohl das DAX-Management APIs als auch die DAX-Datenebene umfasst APIs, empfehlen wir Ihnen, zwei unterschiedliche Aussagen in das Richtliniendokument aufzunehmen. Eine dieser Aussagen sollte sich auf die DAX-Datenebene beziehen APIs, während sich die andere Aussage auf das DAX-Management bezieht. APIs
Es folgt eine Beispielrichtlinie, die diesen Ansatz veranschaulicht: Sie sehen, wie die `DAXDataAPIs`-Anweisung auf die Ressource `DAXCluster01` begrenzt ist; die Ressource für `DAXManagementAPIs` muss aber `"*"` lauten. Die in den Anweisungen gezeigten Aktionen dienen lediglich der Veranschaulichung. Sie können sie nach Bedarf für Ihre Anwendung anpassen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DAXDataAPIs",
"Action": [
"dax:GetItem",
"dax:BatchGetItem",
"dax:Query",
"dax:Scan",
"dax:PutItem",
"dax:UpdateItem",
"dax:DeleteItem",
"dax:BatchWriteItem"
],
"Effect": "Allow",
"Resource": [
"arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01"
]},
{
"Sid": "DAXManagementAPIs",
"Action": [
"dax:CreateParameterGroup",
"dax:CreateSubnetGroup",
"dax:DecreaseReplicationFactor",
"dax:DeleteCluster",
"dax:DeleteParameterGroup",
"dax:DeleteSubnetGroup",
"dax:DescribeClusters",
"dax:DescribeDefaultParameters",
"dax:DescribeEvents",
"dax:DescribeParameterGroups",
"dax:DescribeParameters",
"dax:DescribeSubnetGroups",
"dax:IncreaseReplicationFactor",
"dax:ListTags",
"dax:RebootNode",
"dax:TagResource",
"dax:UntagResource",
"dax:UpdateCluster",
"dax:UpdateParameterGroup",
"dax:UpdateSubnetGroup"
],
"Effect": "Allow",
"Resource": [
"*"
]
}
]
}
```
------
## Skalieren eines DAX-Clusters
Für die Skalierung eines DAX-Clusters gibt es zwei Möglichkeiten. Die erste Option ist die *horizontale Skalierung*, bei der Sie Read Replicas zum Cluster hinzufügen. Die zweite Option ist die *vertikale Skalierung*, bei der Sie verschiedene Knotentypen auswählen. Hinweise zur Auswahl einer geeigneten Clustergröße und des entsprechenden Knotentyps für Ihre Anwendung finden Sie unter [DAX-Clustergrößenleitfaden](DAX.sizing-guide.md).
### Horizontale Skalierung
Mit horizontaler Skalierung können Sie den Durchsatz für Lesevorgänge verbessern, indem Sie dem Cluster weitere Read Replicas hinzufügen. Ein einzelner DAX-Cluster unterstützt bis zu 10 Read Replicas, und Sie können Replikate hinzufügen oder entfernen, während der Cluster ausgeführt wird.
Wenn Sie einen neuen Knoten hinzufügen, müssen Sie die Cache-Daten von einem Peer-Knoten synchronisieren. Daher hängt die Dauer für das Hinzufügen von der Cache-Größe und der Workload Ihrer Anwendung ab. Als bewährte Methode empfehlen wir, Ihren Cluster vorab im Hinblick auf die erwarteten Datenverkehrsspitzen zu skalieren. Informationen zum Auswählen der richtigen Größe und Empfehlungen zur Überwachung finden Sie im [DAX-Clustergrößenleitfaden](DAX.sizing-guide.md).
Die folgenden AWS CLI Beispiele zeigen, wie die Anzahl der Knoten erhöht oder verringert werden kann. Das Argument `--new-replication-factor` gibt die Gesamtzahl der Knoten im Cluster an. Einer der Knoten ist der primäre Knoten und die anderen Knoten sind Read Replicas.
```
aws dax increase-replication-factor \
--cluster-name MyNewCluster \
--new-replication-factor 5
```
```
aws dax decrease-replication-factor \
--cluster-name MyNewCluster \
--new-replication-factor 3
```
**Anmerkung**
Wenn Sie den Replikationsfaktor ändern, wird der Clusterstatus in `modifying` geändert. Der Status ändert sich in `available`, wenn die Änderung abgeschlossen ist.
### Vertikale Skalierung
Wenn Sie mit einer großen Datenmenge arbeiten, profitiert Ihre Anwendung möglicherweise von der Verwendung größerer Knotentypen. Größere Knoten können es dem Cluster ermöglichen, mehr Daten im Arbeitsspeicher zu speichern. Dies reduziert Cache-Fehlgriffe und verbessert die allgemeine Leistung der Anwendung. (Alle Knoten in einem DAX-Cluster müssen vom selben Typ sein.)
Wenn Ihr DAX-Cluster eine hohe Rate von Schreibvorgängen oder Cache-Fehlern aufweist, kann Ihre Anwendung auch von der Verwendung größerer Knotentypen profitieren. Schreibvorgänge und Cachefehler verbrauchen Ressourcen auf dem primären Knoten des Clusters. Daher kann die Verwendung größerer Knotentypen die Leistung des primären Knotens erhöhen und dadurch einen höheren Durchsatz für diese Arten von Vorgängen ermöglichen.
Auf einem DAX-Cluster, der gerade ausgeführt wird, können Sie die Knotentypen nicht ändern. Sie müssen stattdessen einen neuen Cluster mit dem gewünschten Knotentyp erstellen. Eine Liste der unterstützten Knotentypen finden Sie unter [Knoten](DAX.concepts.cluster.md#DAX.concepts.nodes).
Sie können mit dem AWS-Managementkonsole, [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dax-cluster.html), oder dem [AWS SDK](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations_Amazon_DynamoDB_Accelerator_(DAX).html) einen neuen DAX-Cluster erstellen. AWS CLI(Verwenden Sie für den den `--node-type` Parameter AWS CLI, um den Knotentyp anzugeben.)
## Anpassen der DAX-Cluster-Einstellungen
Beim Erstellen eines DAX-Clusters werden die folgenden Standardeinstellungen verwendet:
+ Automatische Cache-Entfernung mit Time to Live (TTL) von 5 Minuten aktiviert
+ Keine Präferenz für Availability Zones
+ Keine Präferenz für Wartungsfenster
+ Benachrichtigungen deaktiviert
Für neue Cluster können Sie die Einstellungen zum Zeitpunkt der Erstellung anpassen. Um dies in der AWS-Managementkonsole auszuführen, deaktivieren Sie **Use default settings (Standardeinstellungen verwenden)**, um die folgenden Einstellungen zu ändern:
+ **Netzwerk und Sicherheit** — Ermöglicht es Ihnen, einzelne DAX-Clusterknoten in verschiedenen Availability Zones innerhalb der aktuellen AWS Region auszuführen. Wenn Sie **No Preference (Keine Präferenz)** auswählen, werden die Knoten automatisch zwischen den Availability Zones verteilt.
+ **Parametergruppe** – Dies ist ein benannter Satz von Parametern, die auf jeden Knoten im Cluster angewendet werden. Sie können eine Parametergruppe verwenden, um das Cache-TTL-Verhalten anzugeben. Sie können den Wert eines beliebigen Parameters innerhalb einer Parametergruppe (mit Ausnahme der Standardparametergruppe `default.dax.1.0`) jederzeit ändern.
+ **Wartungsfenster** – Dies ist ein wöchentlicher Zeitraum, in dem die Software-Upgrades und -Patches auf die Knoten im Cluster angewendet werden. Sie können den Starttag, den Startzeitpunkt und die Dauer des Wartungsfensters auswählen. Wenn Sie **No Preference (Keine Präferenz)** auswählen, wird das Wartungsfenster zufällig aus einem 8-Stunden-Block pro Region ausgewählt. Weitere Informationen finden Sie unter [Wartungsfenster](DAX.concepts.cluster.md#DAX.concepts.maintenance-window).
**Anmerkung**
**Parameter Group (Parametergruppe)** und **Maintenance Window (Wartungsfenster)** können auch jederzeit auf einem laufenden Cluster geändert werden.
Wenn ein Wartungsereignis auftritt, kann DAX Sie über Amazon Simple Notification Service (Amazon SNS) benachrichtigen. Zum Konfigurieren von Benachrichtigungen wählen Sie eine Option aus der Auswahl **Topic for SNS notification** aus. Sie können ein neues Amazon-SNS-Thema erstellen oder ein vorhandenes Thema verwenden.
Weitere Informationen zum Erstellen und Abonnieren eines Amazon-SNS-Themas finden Sie unter [Erste Schritte mit Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/GettingStarted.html) im *Amazon-Simple-Notification-Service-Entwicklerhandbuch*.
## Konfigurieren der TTL-Einstellungen
DAX verwaltet zwei Caches für Daten, die von DynamoDB gelesen werden:
+ **Element-Cache** – Für Elemente, die mit `GetItem` oder `BatchGetItem` abgerufen wurden.
+ **Abfragecache** – Für Ergebnismengen, die mit `Query` oder `Scan` abgerufen werden.
Weitere Informationen erhalten Sie unter [Element-Cache](DAX.concepts.md#DAX.concepts.item-cache) und [Abfrage-Cache](DAX.concepts.md#DAX.concepts.query-cache).
Die TTL-Standardeinstellung für jeden dieser Caches beträgt 5 Minuten. Wenn Sie andere TTL-Einstellungen verwenden möchten, können Sie einen DAX-Cluster über eine benutzerdefinierte Parametergruppe starten. Um diesen Vorgang in der Konsole auszuführen, wählen Sie **DAX \$1 Parameter groups (DAX \$1 Parametergruppen)** im Navigationsbereich aus.
Sie können diese Aufgaben auch mit der AWS CLI ausführen. Das folgende Beispiel zeigt, wie Sie einen neuen DAX-Cluster mit einer benutzerdefinierten Parametergruppe starten. In diesem Beispiel wird die TTL-Einstellung für den Element-Cache auf 10 Minuten und für den Abfrage-Cache auf 3 Minuten festgelegt.
1. Neue Parametergruppe erstellen.
```
aws dax create-parameter-group \
--parameter-group-name custom-ttl
```
1. Legen Sie die TTL-Einstellung für den Element-Cache auf 10 Minuten (600.000 Millisekunden) fest.
```
aws dax update-parameter-group \
--parameter-group-name custom-ttl \
--parameter-name-values "ParameterName=record-ttl-millis,ParameterValue=600000"
```
1. Legen Sie die TTL-Einstellung für den Abfrage-Cache auf 3 Minuten (180.000 Millisekunden) fest.
```
aws dax update-parameter-group \
--parameter-group-name custom-ttl \
--parameter-name-values "ParameterName=query-ttl-millis,ParameterValue=180000"
```
1. Überprüfen Sie, ob die Parameter korrekt festgelegt wurden.
```
aws dax describe-parameters --parameter-group-name custom-ttl \
--query "Parameters[*].[ParameterName,Description,ParameterValue]"
```
Sie können nun einen neuen DAX-Cluster mit dieser Parametergruppe starten.
```
aws dax create-cluster \
--cluster-name MyNewCluster \
--node-type dax.r3.large \
--replication-factor 3 \
--iam-role-arn arn:aws:iam::123456789012:role/DAXServiceRole \
--parameter-group custom-ttl
```
**Anmerkung**
Sie können eine Parametergruppe ändern, die an einen laufenden DAX-Cluster angehängt ist. Parameteränderungen gelten nur für Elemente, die nach der Änderung geschrieben wurden. Vorhandene zwischengespeicherte Elemente behalten die TTL und die Einstellungen bei, als sie ursprünglich geschrieben wurden.
## Unterstützung von Markierungen für DAX
Viele AWS Dienste, einschließlich DynamoDB, unterstützen *Tagging* — die Fähigkeit, Ressourcen mit benutzerdefinierten Namen zu kennzeichnen. Sie können DAX-Clustern Tags zuweisen, sodass Sie schnell alle Ihre AWS Ressourcen mit demselben Tag identifizieren oder Ihre AWS Rechnungen anhand der von Ihnen zugewiesenen Tags kategorisieren können.
Weitere Informationen finden Sie unter [Hinzufügen von Tags und Labels zu Ressourcen in DynamoDB](Tagging.md).
### Mit dem AWS-Managementkonsole
**So verwalten Sie Markierungen für DAX-Cluster**
1. Öffnen Sie die DynamoDB-Konsole unter. [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)
1. Klicken Sie im Navigationsbereich unter **DAX** auf **Cluster**.
1. Wählen Sie den Cluster aus, mit dem Sie arbeiten möchten.
1. Wählen Sie die Registerkarte **Tags** aus. Sie können Ihre Tags hier hinzufügen, auflisten, bearbeiten oder löschen.
Wenn Sie die gewünschten Einstellungen vorgenommen haben, wählen Sie **Apply Changes** aus.
### Mit dem AWS CLI
Wenn Sie die AWS CLI zur Verwaltung von DAX-Cluster-Tags verwenden, müssen Sie zuerst den Amazon-Ressourcennamen (ARN) für den Cluster ermitteln. Im folgenden Beispiel wird gezeigt, wie Sie einen ARN für einen Cluster namens `MyDAXCluster` bestimmen.
```
aws dax describe-clusters \
--cluster-name MyDAXCluster \
--query "Clusters[*].ClusterArn"
```
In der Ausgabe sieht der ARN in etwa wie folgt aus: `arn:aws:dax:us-west-2:123456789012:cache/MyDAXCluster`
Im folgenden Beispiel wird gezeigt, wie Sie den Cluster markieren.
```
aws dax tag-resource \
--resource-name arn:aws:dax:us-west-2:123456789012:cache/MyDAXCluster \
--tags="Key=ClusterUsage,Value=prod"
```
So listen Sie alle Tags für einen Cluster auf.
```
aws dax list-tags \
--resource-name arn:aws:dax:us-west-2:123456789012:cache/MyDAXCluster
```
Um ein Tag zu entfernen, geben Sie den zugehörigen Schlüssel an.
```
aws dax untag-resource \
--resource-name arn:aws:dax:us-west-2:123456789012:cache/MyDAXCluster \
--tag-keys ClusterUsage
```
## AWS CloudTrail Integration
DAX ist integriert AWS CloudTrail, sodass Sie DAX-Cluster-Aktivitäten überprüfen können. Mithilfe von CloudTrail Protokollen können Sie alle Änderungen anzeigen, die auf Clusterebene vorgenommen wurden. Sie können auch Änderungen an Cluster-Komponenten, z. B. Knoten, Subnetzgruppen und Parametergruppen, anzeigen. Weitere Informationen finden Sie unter [Protokollieren von DynamoDB-Vorgängen mithilfe von AWS CloudTrail](logging-using-cloudtrail.md).
## Löschen eines DAX-Clusters
Wenn Sie einen DAX-Cluster nicht mehr verwenden, sollten Sie ihn löschen, um zu verhindern, dass Ihnen nicht verwendete Ressourcen in Rechnung gestellt werden.
Sie können einen DAX-Cluster mithilfe der Konsole oder der AWS CLI löschen. Im Folgenden wird ein -Beispiel gezeigt.
```
aws dax delete-cluster --cluster-name mydaxcluster
```
# Überwachen von DynamoDB Accelerator
Die Überwachung ist ein wichtiger Bestandteil der Aufrechterhaltung der Zuverlässigkeit, Verfügbarkeit und Leistung von Amazon DynamoDB Accelerator (DAX) und Ihrer AWS Lösungen. Sie sollten Überwachungsdaten aus allen Teilen Ihrer AWS Lösung sammeln, damit Sie einen etwaigen Ausfall an mehreren Stellen leichter debuggen können.
Bevor Sie mit der Überwachung von DAX beginnen, sollten Sie einen Überwachungsplan mit Antworten auf die folgenden Fragen erstellen:
+ Was sind Ihre Ziele bei der Überwachung?
+ Welche Ressourcen werden überwacht?
+ Wie oft werden diese Ressourcen überwacht?
+ Welche Überwachungstools werden verwendet?
+ Wer soll die Überwachungsaufgaben ausführen?
+ Wer soll benachrichtigt werden, wenn Fehler auftreten?
**Topics**
+ [Überwachungstools für DynamoDB Accelerator](dax-monitoring-automated-manual.md)
+ [Überwachung mit Amazon CloudWatch](dax-monitoring-cloudwatch.md)
+ [Protokollierung von DAX-Vorgängen mit AWS CloudTrail](dax-logging-using-cloudtrail.md)
# Überwachungstools für DynamoDB Accelerator
AWS bietet Tools, mit denen Sie Amazon DynamoDB Accelerator (DAX) überwachen können. Sie können einige dieser Tools konfigurieren, damit diese die Überwachung für Sie ausführen. Einige Tools erfordern jedoch manuelle Eingriffe. Wir empfehlen, dass Sie die Überwachungsaufgaben möglichst automatisieren.
**Topics**
+ [Automatisierte Überwachungstools](#dax-monitoring-automated_tools)
+ [Manuelle Überwachungstools](#dax-monitoring-manual-tools)
## Automatisierte Überwachungstools
Sie können die folgenden automatisierten Tools zur Überwachung von DAX verwenden und möglicherweise auftretende Probleme melden:
+ **Amazon CloudWatch Alarms** — Überwachen Sie eine einzelne Metrik über einen von Ihnen angegebenen Zeitraum und führen Sie eine oder mehrere Aktionen aus, die auf dem Wert der Metrik im Verhältnis zu einem bestimmten Schwellenwert über mehrere Zeiträume basieren. Die Aktion ist eine Benachrichtigung, die an ein Amazon Simple Notification Service (Amazon SNS) -Thema oder eine Amazon EC2 Auto Scaling Scaling-Richtlinie gesendet wird. CloudWatch Alarme lösen keine Aktionen aus, nur weil sie sich in einem bestimmten Status befinden. Der Status muss sich geändert haben und für eine bestimmte Anzahl von Zeiträumen beibehalten worden sein. Weitere Informationen finden Sie unter [Überwachen von Metriken in DynamoDB mit Amazon CloudWatch](Monitoring-metrics-with-Amazon-CloudWatch.md).
+ **Amazon CloudWatch Logs** — Überwachen, speichern und greifen Sie auf Ihre Protokolldateien aus AWS CloudTrail oder anderen Quellen zu. Weitere Informationen finden Sie unter [Überwachung von Protokolldateien](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatchLogs.html) im * CloudWatch Amazon-Benutzerhandbuch*.
+ **Amazon CloudWatch Events** — Ordnen Sie Ereignisse zu und leiten Sie sie an eine oder mehrere Zielfunktionen oder Streams weiter, um Änderungen vorzunehmen, Statusinformationen zu erfassen und Korrekturmaßnahmen zu ergreifen. Weitere Informationen finden Sie unter [Was ist Amazon CloudWatch Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatchEvents.html) im * CloudWatch Amazon-Benutzerhandbuch*.
+ **AWS CloudTrail Protokollüberwachung** — Teilen Sie Protokolldateien zwischen Konten, überwachen CloudTrail Sie Protokolldateien in Echtzeit, indem Sie sie an CloudWatch Logs senden, schreiben Sie Protokollverarbeitungsanwendungen in Java und überprüfen Sie, ob sich Ihre Protokolldateien nach der Lieferung von nicht geändert haben CloudTrail. Weitere Informationen finden Sie unter [Arbeiten mit CloudTrail Protokolldateien](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-working-with-log-files.html) im *AWS CloudTrail Benutzerhandbuch*.
## Manuelle Überwachungstools
Ein weiterer wichtiger Teil der DAX-Überwachung ist die manuelle Überwachung der Elemente, die von den CloudWatch Alarmen nicht abgedeckt werden. Die DAX- CloudWatch Trusted Advisor,, und andere AWS-Managementkonsole Dashboards bieten einen at-a-glance Überblick über den Zustand Ihrer AWS Umgebung. Zudem empfehlen wir die Überprüfung der Protokolldateien auf DAX.
+ Auf dem DAX-Dashboard wird Folgendes angezeigt:
+ Servicezustand
+ Auf der CloudWatch Startseite wird Folgendes angezeigt:
+ Aktuelle Alarme und Status
+ Diagramme mit Alarmen und Ressourcen
+ Servicestatus
Darüber hinaus können CloudWatch Sie Folgendes verwenden:
+ Erstellen Sie [benutzerdefinierte Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/CloudWatch_Dashboards.html) zur Überwachung der Services, die Ihnen wichtig sind.
+ Aufzeichnen von Metrikdaten, um Probleme zu beheben und Trends zu erkennen.
+ Suchen und durchsuchen Sie alle Ihre AWS Ressourcenmetriken.
+ Erstellen und Bearbeiten von Alarmen, um über Probleme benachrichtigt zu werden.
# Überwachung mit Amazon CloudWatch
Sie können DynamoDB Accelerator (DAX) mithilfe von Amazon überwachen CloudWatch, das Rohdaten aus DAX sammelt und zu lesbaren, nahezu in Echtzeit verfügbaren Metriken verarbeitet. Diese Statistiken werden für einen Zeitraum von zwei Wochen aufgezeichnet. Sie können anschließend auf Verlaufsdaten zugreifen, um einen besseren Eindruck von der Leistung Ihrer Webanwendung oder Ihres Service zu erhalten. Standardmäßig werden DAX-Metrikdaten automatisch an CloudWatch gesendet. Weitere Informationen finden Sie unter [Was ist Amazon CloudWatch?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatch.html) im * CloudWatch Amazon-Benutzerhandbuch*.
**Topics**
+ [Wie verwende ich DAX-Metriken?](#dax-how-to-use-metrics)
+ [Anzeigen von DAX-Metriken und -Dimensionen](dax-metrics-dimensions-dax.md)
+ [CloudWatch Alarme zur Überwachung von DAX erstellen](dax-creating-alarms.md)
+ [Produktionsüberwachung](dax-production-monitoring.md)
## Wie verwende ich DAX-Metriken?
Die von DAX gemeldeten Metriken bieten Informationen, die Sie auf unterschiedliche Weise analysieren können. In der folgenden Liste finden Sie einige häufige Verwendungszwecke für die Metriken. Dies sind Vorschläge für den Einstieg. Es handelt sich nicht um eine umfassende Liste.
****
| Wie kann ich ...? | Relevante Metriken |
| --- | --- |
| Feststellen, ob Systemfehler aufgetreten sind? | Überwachen Sie `FaultRequestCount`, um festzustellen, ob Anforderungen zu einem HTTP 500-Fehler (Serverfehler) geführt haben. Dies kann auf einen internen DAX-Servicefehler oder auf einen HTTP 500 in der [SystemErrors Metrik](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html) der zugrunde liegenden Tabelle hinweisen. |
| Feststellen, ob Benutzerfehler aufgetreten sind? | Überwachen Sie `ErrorRequestCount`, um festzustellen, ob Anforderungen zu einem HTTP 400-Fehler (Clientfehler) geführt haben. Wenn Sie feststellen, dass die Zahl der Fehler zunimmt, sollten Sie möglicherweise untersuchen, ob Sie korrekte Clientanfragen senden, und dies sicherstellen. |
| Feststellen, ob Cache-Fehler aufgetreten sind? | Überwachen Sie `ItemCacheMisses`, um festzustellen, wie häufig ein Element nicht im Cache gefunden wurde. Überwachen Sie `QueryCacheMisses` und `ScanCacheMisses`, um festzustellen, wie häufig eine Abfrage oder ein Scanergebnis nicht im Cache gefunden wurden. |
| Überwachen von Cache-Zugriffsraten | Verwenden Sie [CloudWatch Metric Math, um mithilfe mathematischer](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) Ausdrücke eine Metrik zur Cache-Trefferquote zu definieren. Für den Element-Cache können Sie beispielsweise den Ausdruck m1/SUM([m1, m2])\$1100 verwenden. Hier sind m1 die `ItemCacheHits`-Metrik und m2 die `ItemCacheMisses`-Metrik für Ihren Cluster. Für die Abfrage- und Scan-Caches können Sie das gleiche Muster unter Verwendung der entsprechenden Abfrage- und Scan-Cache-Metriken verwenden. |
# Anzeigen von DAX-Metriken und -Dimensionen
Wenn Sie mit Amazon DynamoDB interagieren, sendet es Metriken und Dimensionen an Amazon. CloudWatch Sie können die folgenden Vorgehensweisen nutzen, um die Metriken für Ihre DynamoDB-Accelerators (DAX) anzuzeigen.
**So zeigen Sie Metriken an (Konsole)**
Metriken werden zunächst nach dem Service-Namespace und anschließend nach den verschiedenen Dimensionskombinationen in den einzelnen Namespaces gruppiert.
1. Öffnen Sie die CloudWatch Konsole unter. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)
1. Wählen Sie im Navigationsbereich **Metriken** aus.
1. Wählen Sie den Namespace **DAX** aus.
**So zeigen Sie Metriken an (AWS CLI)**
+ Geben Sie als Eingabeaufforderung den folgenden Befehl ein.
```
1. aws cloudwatch list-metrics --namespace "AWS/DAX"
```
## DAX-Metriken und -Dimensionen
Die folgenden Abschnitte enthalten die Metriken und Dimensionen, an die DAX sendet CloudWatch.
### DAX-Metriken
Die folgenden Metriken stehen in DAX zur Verfügung. DAX sendet Metriken CloudWatch nur dann an, wenn sie einen Wert ungleich Null haben.
**Anmerkung**
CloudWatch aggregiert die folgenden DAX-Metriken in Intervallen von einer Minute:
`CPUUtilization`
`CacheMemoryUtilization`
`NetworkBytesIn`
`NetworkBytesOut`
`BaselineNetworkBytesInUtilization`
`BaselineNetworkBytesOutUtilization`
`NetworkPacketsIn`
`NetworkPacketsOut`
`GetItemRequestCount`
`BatchGetItemRequestCount`
`BatchWriteItemRequestCount`
`DeleteItemRequestCount`
`PutItemRequestCount`
`UpdateItemRequestCount`
`TransactWriteItemsCount`
`TransactGetItemsCount`
`ItemCacheHits`
`ItemCacheMisses`
`QueryCacheHits`
`QueryCacheMisses`
`ScanCacheHits`
`ScanCacheMisses`
`TotalRequestCount`
`ErrorRequestCount`
`FaultRequestCount`
`FailedRequestCount`
`QueryRequestCount`
`ScanRequestCount`
`ClientConnections`
`EstimatedDbSize`
`EvictedSize`
`CPUCreditUsage`
`CPUCreditBalance`
`CPUSurplusCreditBalance`
`CPUSurplusCreditsCharged`
Nicht alle Statistiken, wie `Average` oder `Sum` sind für jede Metrik anwendbar. Alle diese Werte sind jedoch über die DAX-Konsole oder mithilfe der CloudWatch Konsole oder AWS SDKs für alle AWS CLI Metriken verfügbar. In der folgenden Tabelle enthält jede Metrik eine Liste gültiger Statistiken, die für diese Metrik gelten.
****
| Metrik | Description |
| --- | --- |
| CPUUtilization | Prozentsatz der CPU-Auslastung des Knotens oder Clusters. Einheiten: `Percent` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| CacheMemoryUtilization | Prozentsatz des verfügbaren Cachespeichers, der vom Elementcache und im Abfragecache auf dem Knoten oder Cluster verwendet wird. Zwischengespeicherte Daten werden entfernt, bevor die Speicherauslastung 100 % erreicht (siehe `EvictedSize`-Metrik). Wenn `CacheMemoryUtilization` 100 % auf jedem Knoten erreicht, werden Schreibanforderungen gedrosselt und Sie sollten in Erwägung ziehen, zu einem Cluster mit einem größeren Knotentyp zu wechseln. Einheiten: `Percent` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| NetworkBytesIn | Anzahl der von dem Knoten oder Cluster auf allen Netzwerkschnittstellen empfangenen Byte. Einheiten: `Bytes` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| NetworkBytesOut | Anzahl der vom Knoten oder Cluster auf allen Netzwerkschnittstellen gesendeten Byte. Diese Metrik identifiziert das Volumen des ausgehenden Datenverkehrs in Bezug auf die Anzahl der Bytes auf einem einzelnen Knoten oder Cluster. Einheiten: `Bytes` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| BaselineNetworkBytesInUtilization | Der Prozentsatz der verbrauchten Basis-Netzwerkbandbreite zu einem bestimmten Zeitpunkt für eingehenden Datenverkehr. Als Referenz bedeutet 50 %, dass die Hälfte der verfügbaren Netzwerkbandbreite für eingehenden Verkehr genutzt wird. Einheiten: `Percent` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| BaselineNetworkBytesOutUtilization | Der Prozentsatz der verbrauchten Basis-Netzwerkbandbreite zu einem bestimmten Zeitpunkt für ausgehenden Datenverkehr. Als Referenz bedeutet 50 %, dass die Hälfte der verfügbaren Netzwerkbandbreite für ausgehenden Verkehr genutzt wird. Einheiten: `Percent` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| NetworkPacketsIn | Anzahl der vom Knoten oder Cluster auf allen Netzwerkschnittstellen empfangenen Pakete. Einheiten: `Count` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| NetworkPacketsOut | Anzahl der vom Knoten oder Cluster auf allen Netzwerkschnittstellen gesendeten Pakete. Diese Metrik identifiziert das Volumen des ausgehenden Datenverkehrs in Bezug auf die Anzahl der Pakete auf einem einzelnen Knoten oder Cluster. Einheiten: `Count` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| GetItemRequestCount | Anzahl von `GetItem`-Anforderungen, die vom Knoten oder Cluster behandelt werden. Einheiten: `Count` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| BatchGetItemRequestCount | Anzahl von `BatchGetItem`-Anforderungen, die vom Knoten oder Cluster behandelt werden. Einheiten: `Count` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| BatchWriteItemRequestCount | Anzahl von `BatchWriteItem`-Anforderungen, die vom Knoten oder Cluster behandelt werden. Einheiten: `Count` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| DeleteItemRequestCount | Anzahl von `DeleteItem`-Anforderungen, die vom Knoten oder Cluster behandelt werden. Einheiten: `Count` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| PutItemRequestCount | Anzahl von `PutItem`-Anforderungen, die vom Knoten oder Cluster behandelt werden. Einheiten: `Count` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| UpdateItemRequestCount | Anzahl von `UpdateItem`-Anforderungen, die vom Knoten oder Cluster behandelt werden. Einheiten: `Count` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| TransactWriteItemsCount | Anzahl von `TransactWriteItems`-Anforderungen, die vom Knoten oder Cluster behandelt werden. Einheiten: `Count` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| TransactGetItemsCount | Anzahl von `TransactGetItems`-Anforderungen, die vom Knoten oder Cluster behandelt werden. Einheiten: `Count` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| ItemCacheHits | Gibt an, wie oft ein Element vom Knoten oder Cluster aus dem Cache zurückgegeben wurde. Einheiten: `Count` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| ItemCacheMisses | Die Häufigkeit, mit der sich ein Element nicht im Knoten- oder Cluster-Cache befand und von DynamoDB abgerufen werden musste. Einheiten: `Count` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| QueryCacheHits | Gibt an, wie oft ein Abfrageergebnis aus dem Knoten- oder Clustercache zurückgegeben wurde. Einheiten: `Count` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| QueryCacheMisses | Gibt an, wie oft sich ein Abfrageergebnis nicht im Knoten- oder Clustercache befand und aus DynamoDB abgerufen werden musste. Einheiten: `Count` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| ScanCacheHits | Gibt an, wie oft ein Scanergebnis aus dem Knoten- oder Clustercache zurückgegeben wurde. Einheiten: `Count` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| ScanCacheMisses | Gibt an, wie oft sich ein Scanergebnis nicht im Knoten- oder Clustercache befand und aus DynamoDB abgerufen werden musste. Einheiten: `Count` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| TotalRequestCount | Die Gesamtanzahl von Anforderungen, die vom Knoten oder Cluster behandelt werden. Einheiten: `Count` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| ErrorRequestCount | Die Gesamtanzahl der Anforderungen, die zu einem Benutzerfehler führten, der vom Knoten oder Cluster gemeldet wurde. Anforderungen, die vom Knoten oder Cluster gedrosselt wurden, sind enthalten. Einheiten: `Count` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| ThrottledRequestCount | Die Gesamtanzahl der Anforderungen, die vom Knoten oder Cluster gedrosselt werden. Anforderungen, die von DynamoDB gedrosselt wurden, sind nicht enthalten und können mit [DynamoDB-Metriken](metrics-dimensions.md) überwacht werden. Einheiten: `Count` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| FaultRequestCount | Die Gesamtanzahl der Anforderungen, die zu einem internen Fehler führten, der vom Knoten oder Cluster gemeldet wurde. Einheiten: `Count` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| FailedRequestCount | Die Gesamtanzahl der Anforderungen, die zu einem Fehler führten, der vom Knoten oder Cluster gemeldet wurde. Einheiten: `Count` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| QueryRequestCount | Anzahl von Abfrageanforderungen, die vom Knoten oder Cluster behandelt werden. Einheiten: `Count` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| ScanRequestCount | Anzahl von Scan-Anforderungen, die vom Knoten oder Cluster behandelt werden. Einheiten: `Count` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| ClientConnections | Die Anzahl der gleichzeitigen Verbindungen, die von Clients zum Knoten oder Cluster hergestellt werden. Einheiten: `Count` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| EstimatedDbSize | Eine Annäherung an die Datenmenge, die vom Knoten oder Cluster im Elementcache und im Abfragecache zwischengespeichert wird. Einheiten: `Bytes` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| EvictedSize | Die Datenmenge, die vom Knoten oder Cluster geräumt wurde, um Platz für neu angeforderte Daten zu schaffen. Wenn die Fehlrate steigt und Sie sehen, dass diese Metrik ebenfalls wächst, bedeutet dies wahrscheinlich, dass Ihr Working Set gestiegen ist. Sie sollten erwägen, zu einem Cluster mit einem größeren Knotentyp zu wechseln. Einheiten: `Bytes` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| CPUCreditUsage | Die Anzahl der vom Knoten für die CPU-Nutzung verbrauchten CPU-Guthaben. Ein CPU-Guthaben entspricht einer vCPU, die eine Minute lang bei 100% Auslastung läuft, oder einer äquivalenten Kombination aus vCPUs, Auslastung und Zeit (z. B. eine vCPU, die zwei Minuten lang mit 50% Auslastung läuft oder zwei v, die zwei Minuten lang mit 25% Auslastung CPUs laufen). Die Metriken für CPU-Guthaben sind nur mit einer fünfminütigen Frequenz verfügbar. Wenn Sie ein größeres Intervall als 5 Minuten angeben, verwenden Sie die Statistik `Sum` anstelle der `Average`. Einheiten: `Credits (vCPU-minutes)` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| CPUCreditBalance | Die Anzahl verdienter CPU-Guthaben, die ein Knotenangesammelt hat, seit er gestartet wurde. Guthaben werden auf dem Guthaben-Konto angesammelt, nachdem sie verdient wurden, und davon entfernt, wenn sie verbraucht werden. Der Guthaben-Kontostand hat ein maximales Limit, das anhand der DAX-Knoten-Größe bestimmt wird. Nachdem das Limit erreicht ist, verfallen alle neu verdienten Guthabenpunkte. Die Guthaben in `CPUCreditBalance` sind verfügbar, um die Leistung des Knotens über die CPU-Basisnutzung hinaus zu steigern. Einheiten: `Credits (vCPU-minutes)` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| CPUSurplusCreditBalance | Die Anzahl überzähliger Guthaben, die von einem DAX-Knoten verbraucht wurden, wenn ihr `CPUCreditBalance`-Wert null ist. Der `CPUSurplusCreditBalance`-Wert wird durch erworbene CPU-Guthaben abgezahlt. Wenn die Anzahl überzähliger Guthaben die Höchstzahl der Guthaben überschreitet, die der Knoten in einem 24-Stunden-Zeitraum verdienen kann, fallen für die verbrauchten überzähligen Guthaben zusätzliche Gebühren an. Einheiten: `Credits (vCPU-minutes)` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
| CPUSurplusCreditsCharged | Die Anzahl verbrauchter überzähliger Guthaben, die nicht durch verdiente CPU-Guthaben zurückgezahlt wurden, und für die deshalb eine zusätzliche Gebühr anfällt. Ausgegebene überschüssige Guthaben werden in Rechnung gestellt, wenn die ausgegebenen überschüssigen Guthaben die maximale Anzahl von Guthaben überschreiten, die der Knoten in einem Zeitraum von 24 Stunden verdienen kann. Über das Maximum hinaus ausgegebene überschüssige Guthaben werden am Ende der Stunde oder bei Beendigung des Knotens verrechnet. Einheiten: `Credits (vCPU-minutes)` Gültige Statistiken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/dax-metrics-dimensions-dax.html) |
**Anmerkung**
Die `CPUCreditUsage`-, `CPUCreditBalance`-, `CPUSurplusCreditBalance`- und `CPUSurplusCreditsCharged`-Metriken sind nur für T3-Knoten verfügbar.
### Dimensionen für DAX-Metriken
Die Metriken für DAX sind über die Werte für die Kombination von Konto, Cluster-ID oder Cluster-ID und Knoten-ID qualifiziert. Sie können die CloudWatch Konsole verwenden, um DAX-Daten für jede der Dimensionen in der folgenden Tabelle abzurufen.
****
| Dimension | CloudWatch Metrischer Namespace | Description |
| --- | --- | --- |
| Account | DAX Metrics | Stellt aggregierte Statistiken über alle Knoten in einem Konto bereit. |
| ClusterId | Cluster Metrics | Beschränkt die Daten auf einen Cluster. |
| ClusterId, NodeId | ClusterId, NodeId | Beschränkt die Daten auf einen Knoten innerhalb eines Clusters. |
# CloudWatch Alarme zur Überwachung von DAX erstellen
Sie können einen CloudWatch Amazon-Alarm erstellen, der eine Amazon Simple Notification Service (Amazon SNS) -Nachricht sendet, wenn sich der Status des Alarms ändert. Ein Alarm überwacht eine Metrik über einen bestimmten, von Ihnen definierten Zeitraum. Der Alarm führt eine oder mehrere Aktionen durch, basierend auf dem Wert der Metrik im Vergleich zu einem bestimmten Schwellenwert in einer Reihe von Zeiträumen. Die Aktion ist eine Benachrichtigung, die an ein Amazon-SNS-Thema oder eine Auto-Scaling-Richtlinie gesendet wird. Alarme lösen nur Aktionen für anhaltende Statusänderungen aus. CloudWatch Alarme lösen keine Aktionen aus, nur weil sie sich in einem bestimmten Zustand befinden. Der Status muss sich geändert haben und für eine festgelegte Anzahl an Zeiträumen aufrechterhalten worden sein.
## Wie kann ich über Abfrage-Cache-Fehler benachrichtigt werden?
1. Erstellen Sie ein Amazon-SNS-Thema, `arn:aws:sns:us-west-2:522194210714:QueryMissAlarm`.
Weitere Informationen finden Sie unter [Amazon Simple Notification Service einrichten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html) im * CloudWatch Amazon-Benutzerhandbuch*.
1. Erstellen Sie den Alarm.
```
aws cloudwatch put-metric-alarm \
--alarm-name QueryCacheMissesAlarm \
--alarm-description "Alarm over query cache misses" \
--namespace AWS/DAX \
--metric-name QueryCacheMisses \
--dimensions Name=ClusterID,Value=myCluster \
--statistic Sum \
--threshold 8 \
--comparison-operator GreaterThanOrEqualToThreshold \
--period 60 \
--evaluation-periods 1 \
--alarm-actions arn:aws:sns:us-west-2:522194210714:QueryMissAlarm
```
1. Testen Sie den Alarm.
```
aws cloudwatch set-alarm-state --alarm-name QueryCacheMissesAlarm --state-reason "initializing" --state-value OK
```
```
aws cloudwatch set-alarm-state --alarm-name QueryCacheMissesAlarm --state-reason "initializing" --state-value ALARM
```
**Anmerkung**
Sie können den Schwellenwert in einen höheren oder niedrigeren Schwellenwert ändern, der für Ihre Anwendung sinnvoll ist. Sie können [CloudWatch Metric Math](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) auch verwenden, um eine Metrik zur Cache-Fehlrate zu definieren und einen Alarm für diese Metrik einzurichten.
## Wie kann ich benachrichtigt werden, wenn Anforderungen zu internen Fehlern im Cluster führen?
1. Erstellen Sie ein Amazon-SNS-Thema, `arn:aws:sns:us-west-2:123456789012:notify-on-system-errors`.
Weitere Informationen finden Sie unter [Amazon Simple Notification Service einrichten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html) im * CloudWatch Amazon-Benutzerhandbuch*.
1. Erstellen Sie den Alarm.
```
aws cloudwatch put-metric-alarm \
--alarm-name FaultRequestCountAlarm \
--alarm-description "Alarm when a request causes an internal error" \
--namespace AWS/DAX \
--metric-name FaultRequestCount \
--dimensions Name=ClusterID,Value=myCluster \
--statistic Sum \
--threshold 0 \
--comparison-operator GreaterThanThreshold \
--period 60 \
--unit Count \
--evaluation-periods 1 \
--alarm-actions arn:aws:sns:us-east-1:123456789012:notify-on-system-errors
```
1. Testen Sie den Alarm.
```
aws cloudwatch set-alarm-state --alarm-name FaultRequestCountAlarm --state-reason "initializing" --state-value OK
```
```
aws cloudwatch set-alarm-state --alarm-name FaultRequestCountAlarm --state-reason "initializing" --state-value ALARM
```
# Produktionsüberwachung
Sie sollten einen Ausgangswert für die normale DAX-Leistung in Ihrer Umgebung festlegen, indem Sie die Leistung zu verschiedenen Zeiten und unter verschiedenen Lastbedingungen messen. Wenn Sie DAX überwachen, sollten Sie in Betracht ziehen, historische Überwachungsdaten zu speichern. Diese Daten bieten eine Basis für den Vergleich mit aktuellen Leistungsdaten, zur Erkennung normaler Leistungsmuster und von Leistungsanomalien sowie zur Entwicklung von Verfahren für den Umgang mit Problemen.
Um einen Ausgangswert zu erstellen, sollten Sie mindestens die folgenden Punkte sowohl während der Lasttests als auch in der Produktion überwachen.
+ CPU-Auslastung und gedrosselte Anforderungen, sodass Sie feststellen können, ob Sie möglicherweise einen größeren Knotentyp in Ihrem Cluster verwenden müssen. Die CPU-Auslastung Ihres Clusters ist anhand der `CPUUtilization` CloudWatch Metrik verfügbar. Die Durchschnittsstatistik für diese Metrik gibt einen Überblick über die durchschnittliche CPU-Auslastung aller Knoten in Ihrem Cluster. Für Entscheidungen zur Cluster-Skalierung empfehlen wir, die maximale Statistik zu verwenden, die die maximale Auslastung über alle Knoten hinweg darstellt.
**Anmerkung**
AWS hat die Granularität der `CPUUtilization` Metrik verbessert. Möglicherweise stellen Sie ab 17.05.2024 bis 22.06.2024 Änderungen an der Metrik fest.
+ Die Latenzzeit der Operation (gemessen auf der Client-Seite) sollte konsistent innerhalb der Latenzanforderungen Ihrer Anwendung bleiben.
+ Die Fehlerquoten sollten niedrig bleiben, wie aus den `FailedRequestCount` CloudWatch Kennzahlen `ErrorRequestCount``FaultRequestCount`, und hervorgeht.
+ Netzwerk-Byte-Verbrauch, sodass Sie bestimmen können, ob Sie mehr Knoten oder einen größeren Knotentyp in Ihrem Cluster verwenden sollten. Um den Verbrauch zu überwachen, können Sie Warnmeldungen `BaselineNetworkBytesInUtilization` und verfügbare `BaselineNetworkBytesOutUtilization` Metriken einrichten CloudWatch, die den prozentualen Verbrauch der verfügbaren Netzwerkbandbreite für Ihren Instance-Typ angeben, jeweils für eingehenden und ausgehenden Datenverkehr.
+ Zwischenspeichernutzung und bereinigte Größe, damit Sie feststellen können, ob für den Knotentyp des Clusters ausreichend Arbeitsspeicher für den aktiven Datensatz verfügbar ist.
**Anmerkung**
Bei einer großen Anzahl von Cache-Fehlern und Schreibvorgängen kann die Cache-Speicherauslastung um bis zu 100 % ansteigen, was zu Ausfallzeiten bei der Verfügbarkeit führen kann.
+ Clientverbindungen, damit Sie nicht erklärte Spitzen in Verbindungen zum Cluster entdecken können.
# Protokollierung von DAX-Vorgängen mit AWS CloudTrail
Amazon DynamoDB Accelerator (DAX) ist in einen Service integriert AWS CloudTrail, der eine Aufzeichnung der Aktionen bereitstellt, die von einem Benutzer, einer Rolle oder einem AWS Service in DAX ausgeführt wurden.
Weitere Informationen zu DAX und CloudTrail finden Sie im Abschnitt DynamoDB Accelerator (DAX) unter. [Protokollieren von DynamoDB-Vorgängen mithilfe von AWS CloudTrail](logging-using-cloudtrail.md)
# DAX-T3/T2-Instances mit Spitzenlastleistung
Mit DAX können Sie zwischen Instances mit fester Leistung (z. B. R4, R5 und R7) und Instances mit Spitzenlastleistung (wie T2 und T3) wählen. Instance mit Spitzenlastleistung bieten ein Basisniveau der CPU-Leistung mit der Möglichkeit, bei Bedarf über die Baseline zu steigen.
Die Baseline-Leistung und die Fähigkeit, darüber zu platzen, werden durch CPU-Credits bestimmt. Instance mit Spitzenlastleistung akkumulieren CPU-Credits kontinuierlich mit einer Rate, die durch die Instanzgröße bestimmt wird, wenn der Workload unter dem Baseline-Schwellenwert liegt. Diese Credits können dann verbraucht werden, wenn der Workload zunimmt. Ein CPU-Guthaben stellt die Leistung eines gesamten CPU-Kerns für eine Minute zur Verfügung.
Viele Workloads benötigen keine gleichbleibend hohen CPUs, profitieren jedoch von vollem Zugriff auf sehr schnelle CPUs, wenn sie diese benötigen. Instance mit Spitzenlastleistung werden speziell für diese Anwendungsfälle entwickelt. Wenn Sie eine gleichbleibend hohe CPU-Leistung für Ihre Datenbank benötigen, empfehlen wir Ihnen, Instanzen mit fester Leistung zu verwenden.
## DAX-T2-Instance-Familie
DAX-T2-Instances sind burstbare Allzweck-Performance-Instances, die ein Basisniveau der CPU-Leistung mit der Fähigkeit bieten, über die Baseline zu steigen. T2-Instances sind eine gute Wahl für Test- und Entwicklungs-Workloads, die Preisvorhersagbarkeit erfordern. DAX-T2-Instances sind für den Standardmodus konfiguriert. Wenn die Instance nicht mehr viele angesammelte Guthaben aufweist, wird die CPU-Nutzung schrittweise bis auf Baseline-Ebene gesenkt. Weitere Informationen zum Standardmodus finden Sie unter [Standardmodus für Instances mit Spitzenlastleistung](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-standard-mode.html) im Amazon-EC2-Benutzerhandbuch.
## DAX-T3-Instance-Familie
DAX-T3-Instances sind Allzweck-Instance-Typen mit Spitzenlastleistung der nächsten Generation, die eine CPU-Basisleistung mit der Fähigkeit bereitstellen, die CPU-Nutzung jederzeit so lange wie nötig zu steigern. T3-Instances bieten ein ausgewogenes Verhältnis von Rechen-, Speicher- und Netzwerkressourcen und sind ideal für Workloads mit moderater CPU-Nutzung, bei der temporäre Nutzungsspitzen auftreten. DAX-T3-Instances sind für den unbegrenzten Modus konfiguriert, was bedeutet, dass sie gegen eine zusätzliche Gebühr über ein 24-Stunden-Fenster über die Baseline hinausgehen können. Weitere Informationen zum unbegrenzten Modus finden Sie unter [Unbegrenzter Modus für Instances mit Spitzenlastleistung](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode.html) im Amazon-EC2-Benutzerhandbuch.
DAX-T3-Instances können eine hohe CPU-Leistung aufrechterhalten, solange ein Workload dies erfordert. Für die meisten allgemeinen Workloads bieten T3-Instances eine ausreichende Leistung ohne zusätzliche Gebühren. Der stündliche T3-Instance-Preis deckt automatisch alle zwischenzeitlichen Nutzungsspitzen ab, wenn die durchschnittliche CPU-Auslastung einer T3-Instance über ein 24-Stunden-Fenster auf oder unter dem Basiswert liegt.
Beispielsweise ein `dax.t3.small`-Instance erhält kontinuierlich Credits mit einer Rate von 24 CPU-Credits pro Stunde. Diese Funktion bietet eine Basisleistung, die 20% eines CPU-Kerns entspricht (20% × 60 Minuten = 12 Minuten). Wenn die Instance die erhaltenen Credits nicht verwendet, werden sie in ihrem CPU-Guthaben bis zu einem Maximum von 576 CPU-Credits gespeichert. Wenn die `t3.small`-Instance auf mehr als 20% eines Kerns hinausgehen muss, zieht sie aus seinem CPU-Guthaben, um diesen Anstieg automatisch zu bewältigen.
Während DAX-T2-Instances auf die Basisleistung beschränkt sind, sobald der CPU-Guthaben auf Null herabgesetzt wurde, können DAX-T3-Instances über der Basislinie herausgehen, selbst wenn ihr CPU-Guthaben gleich Null ist. Für die überwiegende Mehrheit der Workloads, bei denen die durchschnittliche CPU-Nutzung bei oder unterhalb der Baseline-Leistung liegt, deckt der Baseline-Stundenpreis für `t3.small` alle CPU-Bursts ab. Wenn die Instance zufällig mit einer durchschnittlichen CPU-Auslastung von 25% (5% über dem Basiswert) über einen Zeitraum von 24 Stunden nach der Berechnung des CPU-Guthabens auf Null läuft, werden zusätzliche 11,52 Cent (9,6 Cent/VCPU-Stunde × 1 vCPU × 5% × 24 Stunden) berechnet. Siehe [Amazon-DynamoDB-Preise](https://aws.amazon.com/dynamodb/pricing/on-demand/) für weitere Informationen zur Preisdetails.
# DAX-Zugriffskontrolle
DynamoDB Accelerator (DAX) kann mit DynamoDB zusammenarbeiten, um Anwendungen nahtlos eine Caching-Schicht hinzuzufügen. DAX und DynamoDB verfügen jedoch über separate Zugriffssteuerungsmechanismen. Beide Dienste verwenden AWS Identity and Access Management (IAM), um ihre jeweiligen Sicherheitsrichtlinien zu implementieren, aber die Sicherheitsmodelle für DAX und DynamoDB sind unterschiedlich.
*Wir empfehlen dringend, dass Sie beide Sicherheitsmodelle verstehen*, damit Sie für Ihre Anwendungen mit DAX ordnungsgemäße Sicherheitsmaßnahmen implementieren können.
In diesem Abschnitt werden die Zugriffskontrollmechanismen von DAX beschrieben und beispielhafte IAM-Richtlinien bereitgestellt, die Sie an Ihre Bedürfnisse anpassen können.
Mit DynamoDB können Sie IAM-Richtlinien erstellen, die Aktionen begrenzen, die ein Benutzer mit individuellen DynamoDB-Ressourcen durchführen kann. Sie können beispielsweise eine Benutzerrolle erstellen, die ausschließlich dem Benutzer erlaubt, schreibgeschützte Aktionen auf einer bestimmten DynamoDB-Tabelle durchzuführen. (Weitere Informationen finden Sie unter [Identity and Access Management für Amazon DynamoDB](security-iam.md).) Im Vergleich dazu konzentriert sich das DAX-Sicherheitsmodell auf Cluster-Sicherheit und die Fähigkeit des Clusters zum Ausführen von DynamoDB-API-Aktionen in Ihrem Namen.
**Warnung**
Wenn Sie derzeit IAM-Rollen und -Richtlinien zum Einschränken des Zugriffs auf DynamoDB-Tabellendaten nutzen, kann die Verwendung von DAX diese Richtlinien **unterlaufen**. Beispiel: Ein Benutzer hat Zugriff auf eine DynamoDB-Tabelle über DAX, aber keinen expliziten Zugriff auf dieselbe Tabelle, wenn er direkt auf DynamoDB zugreift. Weitere Informationen finden Sie unter [Identity and Access Management für Amazon DynamoDB](security-iam.md).
DAX erzwingt keine Separation der Daten in DynamoDB auf Benutzerebene. Stattdessen erben Benutzer die Berechtigungen der IAM-Richtlinie des DAX-Clusters, wenn sie auf diesen Cluster zugreifen. Beim Zugriff auf die DynamoDB-Tabellen über DAX sind daher die einzigen aktiven Zugriffskontrollen die Berechtigungen in der IAM-Richtlinie des DAX-Clusters. Es werden keine weiteren Berechtigungen erkannt.
Wenn Sie Isolation benötigen, empfehlen wir, dass Sie zusätzliche DAX-Cluster erstellen und die IAM-Richtlinie für jeden Cluster entsprechend abgrenzen. Sie können z. B. mehrere DAX-Cluster erstellen und jedem Cluster den Zugriff auf eine einzelne Tabelle erlauben.
## IAM-Servicerolle für DAX
Beim Erstellen eines DAX-Clusters, müssen Sie den Cluster mit einer IAM-Rolle verknüpfen. Dies wird als *Servicerolle* für den Cluster bezeichnet.
Angenommen, Sie möchten einen neuen DAX-Cluster mit dem Namen erstellen. *DAXCluster01* Sie könnten eine Servicerolle mit dem Namen *DAXServiceRole* erstellen und die Rolle zuordnen *DAXCluster01*. Die Richtlinie für *DAXServiceRole* würde die DynamoDB-Aktionen definieren, die im Namen der Benutzer, mit denen interagiert, ausgeführt werden *DAXCluster01*könnten. *DAXCluster01*
Wenn Sie eine Servicerolle erstellen, müssen Sie eine Vertrauensbeziehung zwischen *DAXServiceRole* und dem DAX-Service selbst angeben. Eine Vertrauensstellung bestimmt, welche Entitäten eine Rolle übernehmen und deren Berechtigungen nutzen können. Im Folgenden finden Sie ein Beispiel für ein Dokument zur Vertrauensstellung für *DAXServiceRole*:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "dax.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Diese Vertrauensstellung ermöglicht es einem DAX-Cluster, *DAXServiceeine Rolle* zu übernehmen und DynamoDB-API-Aufrufe in Ihrem Namen durchzuführen.
*Die zulässigen DynamoDB-API-Aktionen werden in einem IAM-Richtliniendokument beschrieben, das Sie an Role anhängen. DAXService* Dies ist ein Beispiel für ein Richtliniendokument.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DaxAccessPolicy",
"Effect": "Allow",
"Action": [
"dynamodb:DescribeTable",
"dynamodb:PutItem",
"dynamodb:GetItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:Query",
"dynamodb:Scan",
"dynamodb:BatchGetItem",
"dynamodb:BatchWriteItem",
"dynamodb:ConditionCheckItem"
],
"Resource": [
"arn:aws:dynamodb:us-west-2:123456789012:table/Books"
]
}
]
}
```
------
Diese Richtlinie erlaubt DAX die Durchführung aller DynamoDB-API-Aktionen an einer DynamoDB-Tabelle. Die `dynamodb:DescribeTable`-Aktion ist erforderlich, damit DAX Metadaten über die Tabelle beibehält, und die anderen sind Lese- und Schreibvorgänge, die für Elemente in der Tabelle ausgeführt werden. Die Tabelle mit dem Namen `Books` befindet sich in der Region us-west-2 und ist im Besitz der AWS-Konto-ID `123456789012`.
**Anmerkung**
DAX unterstützt Mechanismen, um das Confused-Deputy-Problem beim dienstübergreifenden Zugriff zu verhindern. Weitere Informationen finden Sie unter [Das Problem des verwirrten Stellvertreters](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) im *IAM-Benutzerhandbuch*.
## IAM-Richtlinie, um DAX-Cluster-Zugriff zu gewähren
Nach dem Erstellen eines DAX-Clusters müssen Sie einem Benutzer Berechtigungen erteilen, damit er auf den DAX-Cluster zugreifen kann.
Nehmen wir beispielsweise an, Sie möchten einem Benutzer namens Alice *DAXCluster01*Zugriff gewähren. Sie würden zunächst eine IAM-Richtlinie (*AliceAccessPolicy*) erstellen, die die DAX-Cluster und DAX-API-Aktionen definiert, auf die der Empfänger zugreifen kann. Sie können anschließend den Zugriff gewähren, indem Sie diese Richtlinie der Benutzerin Alice zuweisen.
Das folgende Richtliniendokument gewährt dem Empfänger vollen Zugriff auf *DAXCluster01*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"dax:*"
],
"Effect": "Allow",
"Resource": [
"arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01"
]
}
]
}
```
------
Das Richtliniendokument erlaubt den Zugriff auf den DAX-Cluster, erteilt jedoch keine DynamoDB-Berechtigungen. (Die DynamoDB-Berechtigungen werden von der DAX-Servicerolle zugewiesen.)
Sie würden für die Benutzerin Alice zunächst eine `AliceAccessPolicy` mit dem zuvor gezeigten Richtliniendokument erstellen. Anschließend würden Sie die Richtlinie Alice zuweisen.
**Anmerkung**
Anstatt die Richtlinie einem Benutzer zuzuweisen, könnten Sie sie einer IAM-Rolle zuweisen. Auf diese Weise hätten alle Benutzer, die diese Rolle übernehmen, die Berechtigungen, die Sie in der Richtlinie festgelegt haben.
Die Benutzerrichtlinie bestimmt in Verbindung mit der DAX-Servicerolle die DynamoDB-Ressourcen und API-Aktionen, auf die der Empfänger über DAX zugreifen kann.
## Fallstudie: Zugreifen auf DynamoDB und DAX
Das folgende Szenario kann helfen, das Verständnis der IAM-Richtlinien für die Verwendung mit DAX zu vertiefen. (Wir werden uns für den Rest dieses Abschnitts auf dieses Szenario beziehen.) Das folgende Diagramm zeigt einen allgemeinen Überblick des Szenarios.
![\[Ein allgemeiner Überblick über ein IAM-Richtlinien-Szenario für die Verwendung von DAX.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/dax-access-control-scenario.png)
In diesem Szenario gibt es die folgenden Entitäten:
+ Ein Benutzer (Bob).
+ Eine IAM-Rolle (`BobUserRole`). Bob übernimmt diese Rolle zur Laufzeit.
+ Eine IAM-Richtlinie (`BobAccessPolicy`). Diese Richtlinie ist an `BobUserRole` angehängt. `BobAccessPolicy` definiert die Ressourcen DynamoDB und DAX, auf die `BobUserRole` zugreifen darf.
+ Ein DAX-Cluster (`DAXCluster01`).
+ Eine IAM-Servicerolle (`DAXServiceRole`). Diese Rolle erlaubt `DAXCluster01` den Zugriff auf DynamoDB.
+ Eine IAM-Richtlinie (`DAXAccessPolicy`). Diese Richtlinie ist beigefügt`DAXServiceRole`. `DAXAccessPolicy`definiert die DynamoDB APIs und die Ressourcen, auf die `DAXCluster01` zugegriffen werden darf.
+ Eine DynamoDB-Tabelle (`Books`)
Die Kombination der Richtlinienanweisungen in `BobAccessPolicy` und `DAXAccessPolicy` bestimmt, was Bob mit der Tabelle `Books` machen kann. Beispielsweise kann Bob `Books` direkt (über den DynamoDB-Endpunkt), indirekt (über den DAX-Cluster) oder beides zugreifen. Bob könnte auch Daten von `Books` lesen, Daten in `Books` schreiben oder beides.
## Zugriff auf DynamoDB, aber kein Zugriff mit DAX
![\[Überblick über eine IAM-Richtlinie, die direkten Zugriff auf eine Tabelle ermöglicht, den indirekten Zugriff aber mit einem DAX-Cluster blockiert.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/dax-access-control-ddb-only.png)
Es ist möglich, direkten Zugriff auf eine DynamoDB-Tabelle zuzulassen, während ein indirekter Zugriff mit einem DAX-Cluster verhindert wird. Für direkten Zugriff auf DynamoDB werden die Berechtigungen für `BobUserRole` durch `BobAccessPolicy` bestimmt (welche an die Rolle angehängt sind).
### Lesezugriff auf (nur) DynamoDB
*Bob* kann auf DynamoDB mit `BobUserRole` zugreifen. Die dieser Rolle (`BobAccessPolicy`) zugeordnete IAM-Richtlinie bestimmt, auf welche DynamoDB-Tabellen zugegriffen `BobUserRole` werden kann und welche APIs davon `BobUserRole` aufgerufen werden können.
Berücksichtigen Sie das folgende Richtliniendokument für `BobAccessPolicy`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DynamoDBAccessStmt",
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:Query",
"dynamodb:Scan"
],
"Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books"
}
]
}
```
------
Wenn dieses Dokument an `BobAccessPolicy` angehängt wird, ermöglicht es `BobUserRole` den Zugriff auf den DynamoDB-Endpunkt und das Ausführen von schreibgeschützten Operationen mit der `Books`-Tabelle.
DAX erscheint nicht in dieser Richtlinie, sodass ein Zugriff über DAX verweigert wird.
### Lese- und Schreibzugriff auf (nur) DynamoDB
Wenn read/write Zugriff auf DynamoDB `BobUserRole` erforderlich ist, würde die folgende Richtlinie funktionieren.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DynamoDBAccessStmt",
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:Query",
"dynamodb:Scan",
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:BatchWriteItem",
"dynamodb:ConditionCheckItem"
],
"Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books"
}
]
}
```
------
Erneut erscheint DAX nicht in dieser Richtlinie, sodass ein Zugriff über DAX verweigert wird.
## Zugriff auf DynamoDB und DAX
![\[Eine IAM-Richtlinie, die Zugriff auf eine DynamoDB-Tabelle und einen DAX-Cluster gewährt.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/dax-access-control-ddb-and-dax.png)
Um einen Zugriff auf einen DAX-Cluster zu erlauben, müssen Sie DAX-spezifische Aktionen in einer IAM-Richtlinie angeben.
Die folgenden DAX-spezifischen Aktionen entsprechen ihren Gegenstücken mit vergleichbaren Namen in der DynamoDB-API:
+ `dax:GetItem`
+ `dax:BatchGetItem`
+ `dax:Query`
+ `dax:Scan`
+ `dax:PutItem`
+ `dax:UpdateItem`
+ `dax:DeleteItem`
+ `dax:BatchWriteItem`
+ `dax:ConditionCheckItem`
Das Gleiche gilt für den `dax:EnclosingOperation`-Bedingungsschlüssel.
### Schreibgeschützter Zugriff auf DynamoDB und schreibgeschützter Zugriff auf DAX
In diesem Beispiel gehen wir davon aus, dass Bob Lesezugriff auf die `Books`-Tabelle aus DynamoDB und DAX benötigt. Die folgende Richtlinie (`BobUserRole` zugeordnet) gewährt diesen Zugriff.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DAXAccessStmt",
"Effect": "Allow",
"Action": [
"dax:GetItem",
"dax:BatchGetItem",
"dax:Query",
"dax:Scan"
],
"Resource": "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01"
},
{
"Sid": "DynamoDBAccessStmt",
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:Query",
"dynamodb:Scan"
],
"Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books"
}
]
}
```
------
Die Richtlinie enthält eine Anweisung für DAX-Zugriff (`DAXAccessStmt`) und eine weitere Anweisung für Dynamo DBaccess (). `DynamoDBAccessStmt` Diese Anweisungen würden Bob gestatten, `GetItem`-, `BatchGetItem`-, `Query`- und `Scan`-Anforderungen an den `DAXCluster01` zu senden.
Die Servicerolle für `DAXCluster01` würde jedoch auch Lesezugriff auf die `Books`-Tabelle in DynamoDB erfordern. Die folgende, an `DAXServiceRole` angehängte IAM-Richtlinie würde diese Anforderung erfüllen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DynamoDBAccessStmt",
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:Query",
"dynamodb:Scan"
],
"Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books"
}
]
}
```
------
### Lese-/Schreibzugriff auf DynamoDB und schreibgeschützt mit DAX
Für eine bestimmte Benutzerrolle können Sie read/write Zugriff auf eine DynamoDB-Tabelle gewähren und gleichzeitig den schreibgeschützten Zugriff über DAX zulassen.
Für Bob müsste die IAM-Richtlinie für `BobUserRole` DynamoDB-Lese- und Schreibaktionen für die `Books`-Tabelle zulassen und gleichzeitig schreibgeschützte Aktionen über `DAXCluster01` unterstützen.
Das folgende Richtliniendokument für `BobUserRole` gewährt diesen Zugriff.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DAXAccessStmt",
"Effect": "Allow",
"Action": [
"dax:GetItem",
"dax:BatchGetItem",
"dax:Query",
"dax:Scan"
],
"Resource": "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01"
},
{
"Sid": "DynamoDBAccessStmt",
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:Query",
"dynamodb:Scan",
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:BatchWriteItem",
"dynamodb:DescribeTable",
"dynamodb:ConditionCheckItem"
],
"Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books"
}
]
}
```
------
Zudem würde `DAXServiceRole` eine IAM-Richtlinie erforderlich machen, die `DAXCluster01` schreibgeschützte Aktionen mit der `Books`-Tabelle erlaubt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DynamoDBAccessStmt",
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:Query",
"dynamodb:Scan",
"dynamodb:DescribeTable"
],
"Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books"
}
]
}
```
------
### Read/write access to DynamoDB and read/writeZugriff auf DAX
Nehmen wir nun an, Bob benötigte read/write Zugriff auf die `Books` Tabelle, direkt von DynamoDB oder indirekt von. `DAXCluster01` Das folgende Richtliniendokument, das `BobAccessPolicy` zugeordnet ist, gewährt diesen Zugriff.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DAXAccessStmt",
"Effect": "Allow",
"Action": [
"dax:GetItem",
"dax:BatchGetItem",
"dax:Query",
"dax:Scan",
"dax:PutItem",
"dax:UpdateItem",
"dax:DeleteItem",
"dax:BatchWriteItem",
"dax:ConditionCheckItem"
],
"Resource": "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01"
},
{
"Sid": "DynamoDBAccessStmt",
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:Query",
"dynamodb:Scan",
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:BatchWriteItem",
"dynamodb:DescribeTable",
"dynamodb:ConditionCheckItem"
],
"Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books"
}
]
}
```
------
Darüber hinaus `DAXServiceRole` wäre eine IAM-Richtlinie erforderlich, die es ermöglicht, read/write Aktionen `DAXCluster01` an der Tabelle auszuführen. `Books`
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DynamoDBAccessStmt",
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:Query",
"dynamodb:Scan",
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:BatchWriteItem",
"dynamodb:DescribeTable"
],
"Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books"
}
]
}
```
------
## Zugriff auf DynamoDB via DAX, aber kein direkter Zugriff auf DynamoDB
In diesem Szenario kann Bob über DAX auf die `Books`-Tabelle zugreifen, hat aber keinen direkten Zugriff auf die `Books`-Tabelle in DynamoDB. Wenn Bob also Zugriff auf DAX erhält, erhält er auch Zugriff auf eine DynamoDB-Tabelle, auf die er sonst möglicherweise nicht zugreifen könnte. Wenn Sie eine IAM-Richtlinie für die DAX-Servicerolle konfigurieren, denken Sie daran, dass jeder Benutzer, dem über die Benutzerzugriffsrichtlinie Zugriff auf den DAX-Cluster gewährt wird, Zugriff auf die in dieser Richtlinie angegebenen Tabellen erhält. In diesem Fall erhält `BobAccessPolicy` Zugriff auf die in `DAXAccessPolicy` angegebenen Tabellen.
![\[Ein Szenario, in dem ein Benutzer über einen DAX-Cluster ohne direkten DynamoDB-Zugriff auf eine Tabelle zugreifen kann.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/dax-access-control-dax-only.png)
Wenn Sie derzeit IAM-Rollen und -Richtlinien verwenden, um den Zugriff auf DynamoDB-Tabellen und -Daten einzuschränken, kann die Verwendung von DAX diese Richtlinien untergraben. In der folgenden Richtlinie hat Bob zugriff auf eine DynamoDB-Tabelle über DAX, aber keinen expliziten direkten Zugriff auf dieselbe Tabelle in DynamoDB.
Das folgende Richtliniendokument (`BobAccessPolicy`), das an `BobUserRole` angehängt ist, würde diesen Zugriff gewähren.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DAXAccessStmt",
"Effect": "Allow",
"Action": [
"dax:GetItem",
"dax:BatchGetItem",
"dax:Query",
"dax:Scan",
"dax:PutItem",
"dax:UpdateItem",
"dax:DeleteItem",
"dax:BatchWriteItem",
"dax:ConditionCheckItem"
],
"Resource": "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01"
}
]
}
```
------
In dieser Zugriffsrichtlinie gibt es keine Berechtigungen, um direkt auf DynamoDB zuzugreifen.
Zusammen mit `BobAccessPolicy` gibt `BobUserRole` der Folgenden `DAXAccessPolicy` den Zugriff auf die DynamoDB-Tabelle `Books`, auch wenn `BobUserRole` nicht direkt auf die `Books`-Tabelle zugegriffen werden kann.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DynamoDBAccessStmt",
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:Query",
"dynamodb:Scan",
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:BatchWriteItem",
"dynamodb:DescribeTable",
"dynamodb:ConditionCheckItem"
],
"Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books"
}
]
}
```
------
Wie dieses Beispiel zeigt, müssen Sie bei der Konfiguration der Zugriffskontrolle für die Benutzerzugriffsrichtlinie und die DAX-Clusterzugriffsrichtlinie den end-to-end Zugriff vollständig verstehen, um sicherzustellen, dass das Prinzip der geringsten Rechte eingehalten wird. Stellen Sie zudem sicher, dass, wenn Sie einem Benutzer Zugriff auf einen DAX-Cluster gewähren, zuvor festgelegte Zugriffskontrollrichtlinien nicht unterlaufen werden.
# DAX-Verschlüsselung im Ruhezustand
Die Amazon-DynamoDB-Accelerator-(DAX)-Funktion zur Verschlüsselung von Daten im Ruhezustand stellt eine zusätzliche Sicherheitsebene für die Daten bereit, indem die Daten vor unautorisiertem Zugriff auf den zugrunde liegenden Speicher geschützt werden. Richtlinien der Organisation, Vorschriften der Branche oder Behörde und Compliance-Anforderungen schreiben möglicherweise zum Schutz Ihrer Daten die Verschlüsselung im Ruhezustand vor. Sie können mithilfe der Verschlüsselung den Datenschutz Ihrer in der Cloud bereitgestellten Anwendungen erhöhen.
Bei der Verschlüsselung im Ruhezustand werden die von DAX auf der Festplatte persistenten Daten mit dem 256-Bit Advanced Encryption Standard, auch bekannt als AES-256-Verschlüsselung, verschlüsselt. DAX schreibt Daten auf den Datenträger als Teil der Weitergabe von Änderungen vom primären Knoten an Read Replicas.
Die DAX-Verschlüsselung im Ruhezustand wird automatisch in AWS Key Management Service (AWS KMS) integriert, um den Standardschlüssel für den einzelnen Dienst zu verwalten, der zur Verschlüsselung Ihrer Cluster verwendet wird. Wenn bei der Erstellung Ihres verschlüsselten DAX-Clusters kein Dienst-Standardschlüssel vorhanden ist, AWS KMS wird automatisch ein neuer AWS verwalteter Schlüssel für Sie erstellt. Dieser Schlüssel wird für verschlüsselte Cluster verwendet, die in future erstellt werden. AWS KMS kombiniert sichere, hochverfügbare Hardware und Software, um ein für die Cloud skaliertes Schlüsselverwaltungssystem bereitzustellen.
Nachdem Sie die Daten verschlüsselt haben, übernimmt DAX die Entschlüsselung Ihrer Daten auf transparente Art und Weise und mit minimaler Auswirkung auf die Leistung. An Ihren Anwendungen sind keine Änderungen zur Nutzung der Verschlüsselung erforderlich.
**Anmerkung**
DAX ruft nicht AWS KMS für jeden einzelnen DAX-Vorgang auf. DAX verwendet den Schlüssel nur beim Starten des Clusters. Auch wenn der Zugriff verweigert wird, kann DAX auf die Daten zugreifen, bis der Cluster heruntergefahren wurde. Vom Kunden angegebene AWS KMS Schlüssel werden nicht unterstützt.
Die DAX-Verschlüsselung von Daten im Ruhezustand ist für die folgenden Cluster-Knotentypen verfügbar.
| Familie | Knotentyp |
| --- | --- |
| Speicheroptimiert (R4, R5 und R7) | dax.r4.large dax.r4.xlarge dax.r4.2xlarge dax.r4.4xlarge dax.r4.8xlarge dax.r4.16xlarge dax.r5.large dax.r5.xlarge dax.r5.2xlarge dax.r5.4xlarge dax.r5.8xlarge dax.r5.12xlarge dax.r5.16xlarge dax.r5.24xlarge dax.r7i.large dax.r7i.xlarge dax.r7i.2xlarge dax.r7i.4xlarge dax.r7i.8xlarge dax.r7i.12xlarge dax.r7i.16xlarge dax.r7i.24xlarge |
| Allgemein (T2) | dax.t2.small dax.t2.medium |
| Allgemein (T3) | dax.t3.small dax.t3.medium |
**Wichtig**
Die DAX-Verschlüsselung von Daten im Ruhezustand wird für `dax.r3.*`-Knotentypen nicht unterstützt.
Sie können die Verschlüsselung von Daten im Ruhezustand nicht aktivieren oder deaktivieren, nachdem ein Cluster erstellt wurde. Sie müssen den Cluster neu erstellen, um Verschlüsselung von Daten im Ruhezustand zu aktivieren, wenn die Funktion bei der ursprünglichen Erstellung nicht aktiviert wurde.
Die DAX-Verschlüsselung im Ruhezustand wird ohne zusätzliche Kosten angeboten (es fallen Gebühren für die Nutzung des AWS KMS Verschlüsselungsschlüssels an). Vollständige Informationen zu Preisen finden Sie unter [Amazon-DynamoDB-Preise](https://aws.amazon.com/dynamodb/pricing).
## Aktivierung der Verschlüsselung im Ruhezustand mit dem AWS-Managementkonsole
Gehen Sie wie folgt vor, um die DAX-Verschlüsselung von Daten im Ruhezustand mit der Konsole zu aktivieren.
**Um die DAX-Verschlüsselung im Ruhezustand zu aktivieren,**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die DynamoDB-Konsole unter. [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)
1. Wählen Sie im Navigationsbereich auf der linken Seite der Konsole unter **DAX** die Option **Clusters (Cluster)**.
1. Wählen Sie **Cluster erstellen**.
1. Geben Sie unter **Cluster name (Cluster-Name)** einen Kurznamen für den Cluster ein. Wählen Sie einen **Node type (Knotentyp)** für alle Knoten im Cluster und geben Sie als Cluster-Größe **3** Knoten an.
1. Unter **Encryption (Verschlüsselung)** muss **Enable encryption (Verschlüsselung aktivieren)** ausgewählt sein.
![\[Screenshot der Cluster-Einstellungen in der Konsole mit der "Enable encryption (Verschlüsselung aktivieren)"-Einstellung.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/dax_encrypt.PNG)
1. Wählen Sie nach Auswahl von IAM-Rolle, Subnetzgruppe, Sicherheitsgruppen und Cluster-Einstellungen die Option **Launch cluster (Cluster starten)**.
Sie können ermitteln, ob der Cluster verschlüsselt ist, indem Sie die Cluster-Details im Bereich **Clusters (Cluster)** prüfen. Die Verschlüsselung sollte **ENABLED (AKTIVIERT)** sein.
# DAX-Verschlüsselung während der Übertragung
Amazon DynamoDB Accelerator (DAX) unterstützt die Verschlüsselung bei der Übertragung von Daten zwischen Ihrer Anwendung und Ihrem DAX-Cluster, sodass Sie DAX in Anwendungen mit strengen Verschlüsselungsanforderungen verwenden können.
Unabhängig davon, ob Sie die Verschlüsselung bei der Übertragung wählen oder nicht, bleibt der Datenverkehr zwischen Ihrer Anwendung und Ihrem DAX-Cluster in Ihrer Amazon VPC. Dieser Datenverkehr wird an Elastic-Network-Schnittstellen mit privaten IP-Adressen in Ihrer VPC weitergeleitet, die an die Knoten des Clusters angeschlossen sind. Mit Ihrer VPC als Vertrauensgrenze haben Sie erhebliche Kontrolle über die Sicherheit Ihrer Daten durch die Verwendung von Standardwerkzeugen wie Sicherheitsgruppen, Subnetzsegmentierung mit Netzwerk-ACLs und VPC-Ablaufverfolgung. Die DAX-Verschlüsselung bei der Übertragung erhöht diese Vertraulichkeitsstufe und stellt sicher, dass alle Anforderungen und Antworten zwischen der Anwendung und dem Cluster durch TLS (Transport Level Security) verschlüsselt werden und Verbindungen mit dem Cluster durch Überprüfung eines x509-Cluster-Zertifikats authentifiziert werden können. Daten, die von DAX auf die Festplatte geschrieben werden, können auch verschlüsselt werden, wenn Sie beim Erstellen Ihres DAX-Clusters die [Verschlüsselung im Ruhezustand](DAXEncryptionAtRest.md) wählen.
Die Verschlüsselung bei der Übertragung mit DAX ist einfach. Wählen Sie einfach diese Option aus, wenn Sie einen neuen Cluster erstellen, und verwenden Sie eine aktuelle Version eines der [DAX-Clients](DAX.client.md) in Ihrer Anwendung. Cluster, die Verschlüsselung während der Übertragung verwenden, unterstützen keinen unverschlüsselten Datenverkehr. Daher besteht keine Möglichkeit, Ihre Anwendung falsch zu konfigurieren und die Verschlüsselung zu umgehen. Der DAX-Client verwendet das x509-Zertifikat des Clusters, um die Identität des Clusters zu authentifizieren, wenn er Verbindungen herstellt, und stellt sicher, dass Ihre DAX-Anforderungen an die gewünschte Stelle gehen. Alle Methoden zum Erstellen von DAX-Clustern unterstützen die Verschlüsselung bei der Übertragung: die AWS-Managementkonsole, AWS CLI, alle SDKs und CloudFormation.
Verschlüsselung bei der Übertragung kann auf einem vorhandenen DAX-Cluster nicht aktiviert werden. Um die Verschlüsselung bei der Übertragung in einer vorhandenen DAX-Anwendung zu verwenden, erstellen Sie einen neuen Cluster mit aktivierter Verschlüsselung im Transit, verlagern Sie den Datenverkehr Ihrer Anwendung und löschen Sie dann den alten Cluster.
# Verwendung von serviceverknüpften IAM-Rollen für DAX
[Amazon DynamoDB Accelerator (DAX) verwendet AWS Identity and Access Management (IAM) serviceverknüpfte Rollen.](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) Eine serviceverknüpfte Rolle ist ein spezieller Typ einer IAM-Rolle, die direkt mit DAX verknüpft ist. Servicebezogene Rollen sind von DAX vordefiniert und beinhalten alle Berechtigungen, die der Service benötigt, um andere AWS Dienste in Ihrem Namen aufzurufen.
Eine serviceverknüpfte Rolle vereinfacht das Einrichten von DAX, da Sie die erforderlichen Berechtigungen nicht manuell hinzufügen müssen. DAX definiert die Berechtigungen seiner serviceverknüpften Rollen. Sofern keine andere Konfiguration festgelegt wurde, kann nur DAX die Rollen übernehmen. Die definierten Berechtigungen umfassen die Vertrauens- und Berechtigungsrichtlinie. Diese Berechtigungsrichtlinie kann an keine andere IAM-Entität angefügt werden.
Sie können die Rollen nur nach dem Löschen der zugehörigen Ressourcen löschen. Dies schützt Ihre DAX-Ressourcen, da Sie nicht versehentlich die Berechtigung für den Zugriff auf die Ressourcen entfernen können.
Informationen zu anderen Services, die serviceverlinkte Rollen unterstützen, finden Sie unter [AWS -Services, die mit IAM funktionieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) im *IAM-Benutzerhandbuch*. Suchen Sie nach den Services, für die **Ja** in der Spalte **Serviceverknüpfte Rollen** angegeben ist. Wählen Sie den Link **Ja**, um die Dokumentation zu serviceverknüpften Rollen für diesen Service anzuzeigen.
**Topics**
+ [Berechtigungen von serviceverknüpften Rollen für DAX](#service-linked-role-permissions)
+ [Erstellen einer serviceverknüpften Rolle für DAX](#create-service-linked-role)
+ [Bearbeiten einer serviceverknüpften Rolle für DAX](#edit-service-linked-role)
+ [Löschen einer serviceverknüpften Rolle für DAX](#delete-service-linked-role)
## Berechtigungen von serviceverknüpften Rollen für DAX
DAX verwendet die serviceverknüpfte Rolle namens `AWSServiceRoleForDAX`. Diese Rolle ermöglicht es DAX, Services im Namen Ihres DAX-Clusters aufzurufen.
**Wichtig**
Mit der serviceverknüpften Rolle `AWSServiceRoleForDAX` ist es einfacher für Sie, einen DAX-Cluster einzurichten und zu verwalten. Sie müssen jedoch weiterhin jedem Cluster Zugriff auf DynamoDB gewähren, bevor Sie ihn verwenden können. Weitere Informationen finden Sie unter [DAX-Zugriffskontrolle](DAX.access-control.md).
Die serviceverknüpfte Rolle `AWSServiceRoleForDAX` vertraut darauf, dass die folgenden Services die Rolle annehmen:
+ `dax.amazonaws.com`
Mit der Rollenberechtigungsrichtlinie kann DAX die folgenden Aktionen für die angegebenen Ressourcen ausführen:
+ Aktionen auf `ec2`:
+ `AuthorizeSecurityGroupIngress`
+ `CreateNetworkInterface`
+ `CreateSecurityGroup`
+ `DeleteNetworkInterface`
+ `DeleteSecurityGroup`
+ `DescribeAvailabilityZones`
+ `DescribeNetworkInterfaces`
+ `DescribeSecurityGroups`
+ `DescribeSubnets`
+ `DescribeVpcs`
+ `ModifyNetworkInterfaceAttribute`
+ `RevokeSecurityGroupIngress`
Sie müssen Berechtigungen konfigurieren, damit eine juristische Stelle von IAM (z. B. Benutzer, Gruppe oder Rolle) eine serviceverknüpfte Rolle erstellen, bearbeiten oder löschen kann. Weitere Informationen finden Sie unter [serviceverknüpfte Rollenberechtigungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) im *IAM-Benutzerhandbuch*.
**Um es einer IAM-Entität zu ermöglichen, dienstbezogene AWSService RoleFor DAX-Rollen zu erstellen**
Fügen Sie den Berechtigungen für diese IAM-Entität die folgende Richtlinienanweisung hinzu.
```
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": "*",
"Condition": {"StringLike": {"iam:AWSServiceName": "dax.amazonaws.com"}}
}
```
## Erstellen einer serviceverknüpften Rolle für DAX
Sie müssen eine serviceverknüpfte Rolle nicht manuell erstellen. Wenn Sie einen Cluster erstellen, erstellt DAX die dienstverknüpfte Rolle für Sie.
**Wichtig**
Wenn Sie den DAX-Service vor dem 28. Februar 2018 verwendet haben, als er mit der Unterstützung servicebezogener Rollen begann, hat DAX die `AWSServiceRoleForDAX`-Rolle in Ihrem Konto erstellt. Weitere Informationen finden Sie unter [Eine neue Rolle wurde in „Mein AWS Konto](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared)“ angezeigt im *IAM-Benutzerhandbuch*.
Wenn Sie diese serviceverknüpfte Rolle löschen und dann erneut erstellen müssen, können Sie die Rolle in Ihrem Konto mit demselben Verfahren neu anlegen. DAX erstellt die serviceverknüpfte Rolle erneut für Sie, wenn Sie eine Instance oder einen Cluster erstellen.
## Bearbeiten einer serviceverknüpften Rolle für DAX
DAX verhindert die Bearbeitung der `AWSServiceRoleForDAX` serviceverknüpften Rolle. Da möglicherweise verschiedene Entitäten auf die Rolle verweisen, kann der Rollenname nach dem Erstellen einer serviceverknüpften Rolle nicht mehr geändert werden. Sie können jedoch die Beschreibung der Rolle mit IAM bearbeiten. Weitere Informationen finden Sie unter [Bearbeiten einer serviceverknüpften Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) im *IAM-Benutzerhandbuch*.
## Löschen einer serviceverknüpften Rolle für DAX
Wenn Sie ein Feature oder einen Dienst, die bzw. der eine serviceverknüpften Rolle erfordert, nicht mehr benötigen, sollten Sie diese Rolle löschen. Auf diese Weise haben Sie keine ungenutzte juristische Stelle, die nicht aktiv überwacht oder verwaltet wird. Sie müssen jedoch alle Ihre DAX-Cluster löschen, bevor Sie die serviceverknüpfte Rolle löschen können.
### Bereinigen einer serviceverknüpften Rolle
Bevor Sie mit IAM eine serviceverknüpfte Rolle löschen können, müssen Sie sich zunächst vergewissern, dass die Rolle über keine aktiven Sitzungen verfügt, und alle Ressourcen entfernen, die von der Rolle verwendet werden.
**So überprüfen Sie in der IAM-Konsole, ob die serviceverknüpfte Rolle über eine aktive Sitzung verfügt**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die IAM-Konsole unter. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Wählen Sie im Navigationsbereich der IAM Console **Roles** (Rollen) aus. Wählen Sie dann den Namen (nicht das Kontrollkästchen) der **AWSServiceRoleForDAX-Rolle** aus.
1. Wählen Sie auf der Seite **Summary** für die ausgewählte Rolle die Registerkarte **Access Advisor**.
1. Überprüfen Sie auf der Registerkarte **Access Advisor** die jüngsten Aktivitäten für die serviceverknüpfte Rolle.
**Anmerkung**
Wenn Sie sich nicht sicher sind, ob DAX die Rolle `AWSServiceRoleForDAX` verwendet, können Sie versuchen, die Rolle zu löschen. Wenn der Service die Rolle verwendet, schlägt der Löschvorgang fehl und Sie können die Regionen anzeigen, in denen die Rolle verwendet wird. Wenn die Rolle verwendet wird, müssen Sie Ihre DAX-Cluster löschen, bevor Sie die Rolle löschen können. Die Sitzung für eine serviceverknüpfte Rolle können Sie nicht widerrufen.
Wenn Sie die Rolle `AWSServiceRoleForDAX` entfernen wollen, müssen Sie zunächst alle DAX-Cluster löschen.
#### Löschen Ihrer kompletten DAX-Cluster
Verwenden Sie eine dieser Verfahren, um alle Ihre DAX-Cluster zu löschen.
**So löschen Sie einen DAX-Cluster (Konsole)**
1. Öffnen Sie die DynamoDB-Konsole unter. [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)
1. Klicken Sie im Navigationsbereich unter **DAX** auf **Cluster**.
1. Wählen Sie **Aktionen** und anschließend **Löschen** aus.
1. Wählen Sie im Dialogfeld **Löschbestätigung für den Cluster)** die Option **Löschen** aus.
**So löschen Sie einen DAX-Cluster (AWS CLI)**
Sehen Sie [Cluster löschen](https://docs.aws.amazon.com/cli/latest/reference/dax/delete-cluster.html) in der *AWS CLI -Befehlsreferenz*.
**So löschen Sie einen DAX-Cluster (API)**
Weitere Informationen finden Sie [DeleteCluster](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_dax_DeleteCluster.html)in der *Amazon DynamoDB DynamoDB-API-Referenz*.
#### Löschen der serviceverknüpften Rolle
**So löschen Sie die serviceverknüpfte Rolle mit IAM**
Sie können die IAM-Konsole, die IAM-CLI oder die IAM-API verwenden, um die `AWSServiceRoleForDAX`-serviceverknüpfte Rolle zu löschen. Weitere Informationen finden Sie unter [Löschen einer serviceverknüpften Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) im *IAM-Leitfaden*.
# AWS Kontenübergreifender Zugriff auf DAX
Stellen Sie sich vor, Sie haben einen DynamoDB Accelerator (DAX) -Cluster, der in einem AWS Konto (Konto A) läuft, und der DAX-Cluster muss von einer Amazon Elastic Compute Cloud (Amazon EC2) -Instance in einem anderen AWS Konto (Konto B) aus zugänglich sein. In diesem Tutorial erreichen Sie dies, indem Sie eine EC2-Instance in Konto B mit einer IAM-Rolle in Konto B starten. Anschließend verwenden Sie temporäre Sicherheitsanmeldeinformationen von der EC2-Instance, um eine IAM-Rolle in Konto A zu übernehmen. Schließlich verwenden Sie die temporären Sicherheitsanmeldeinformationen von der übernommenen IAM-Rolle in Konto A, um Anwendungsaufrufe über eine VPC-Peering-Verbindung an den DAX-Cluster in Konto A auszugeben. Um diese Aufgaben ausführen zu können, benötigen Sie Administratorzugriff in beiden AWS Konten.
**Wichtig**
Es ist nicht möglich, dass ein DAX-Cluster von einem anderen Konto aus auf eine DynamoDB-Tabelle zugreift.
**Topics**
+ [IAM-einrichten](#DAX.cross-account-access.iam-setup)
+ [Einrichten einer VPC](#DAX.cross-account-access.vpc-setup)
+ [Ändern des DAX-Clients, um den kontoübergreifenden Zugriff zu erlauben](#DAX.cross-account-access.modify-client)
## IAM-einrichten
1. Erstellen Sie die Textdatei `AssumeDaxRoleTrust.json` mit dem folgenden Inhalt, der es Amazon EC2 ermöglicht, in Ihrem Auftrag zu arbeiten.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
1. Erstellen Sie in Konto B eine Rolle, die von Amazon EC2 beim Starten von Instances verwendet werden kann.
```
aws iam create-role \
--role-name AssumeDaxRole \
--assume-role-policy-document file://AssumeDaxRoleTrust.json
```
1. Erstellen Sie eine Textdatei `AssumeDaxRolePolicy.json` mit dem folgenden Inhalt, die es Code ermöglicht, der auf der EC2-Instance in Konto B ausgeführt wird, eine IAM-Rolle in Konto A anzunehmen. *accountA* Ersetzen Sie sie durch die tatsächliche ID von Konto A.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/DaxCrossAccountRole"
}
]
}
```
------
1. Fügen Sie diese Richtlinie der gerade erstellten Rolle hinzu.
```
aws iam put-role-policy \
--role-name AssumeDaxRole \
--policy-name AssumeDaxRolePolicy \
--policy-document file://AssumeDaxRolePolicy.json
```
1. Erstellen Sie ein Instance-Profil, damit Instances die Rolle verwenden können.
```
aws iam create-instance-profile \
--instance-profile-name AssumeDaxInstanceProfile
```
1. Ordnen Sie die Rolle dem Instance-Profil zu.
```
aws iam add-role-to-instance-profile \
--instance-profile-name AssumeDaxInstanceProfile \
--role-name AssumeDaxRole
```
1. Erstellen Sie die Textdatei `DaxCrossAccountRoleTrust.json` mit dem folgenden Inhalt, der es Konto B gestattet, eine Rolle von Kontos A zu übernehmen. *accountB*Durch die tatsächliche ID von Konto B ersetzen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/AssumeDaxRole"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
1. Erstellen Sie in Konto A die Rolle, die Konto B übernehmen kann.
```
aws iam create-role \
--role-name DaxCrossAccountRole \
--assume-role-policy-document file://DaxCrossAccountRoleTrust.json
```
1. Erstellen Sie eine Textdatei mit dem Namen `DaxCrossAccountPolicy.json`, die den Zugriff auf den DAX-Cluster ermöglicht. *dax-cluster-arn*Ersetzen Sie es durch den richtigen Amazon-Ressourcennamen (ARN) Ihres DAX-Clusters.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dax:GetItem",
"dax:BatchGetItem",
"dax:Query",
"dax:Scan",
"dax:PutItem",
"dax:UpdateItem",
"dax:DeleteItem",
"dax:BatchWriteItem",
"dax:ConditionCheckItem"
],
"Resource": "arn:aws:dax:us-east-1:111122223333:cache/dax-cluster-name"
}
]
}
```
------
1. Fügen Sie in Konto A die Richtlinie zur Rolle hinzu.
```
aws iam put-role-policy \
--role-name DaxCrossAccountRole \
--policy-name DaxCrossAccountPolicy \
--policy-document file://DaxCrossAccountPolicy.json
```
## Einrichten einer VPC
1. Suchen Sie die Subnetzgruppe des DAX-Clusters von Konto A. *cluster-name*Ersetzen Sie es durch den Namen des DAX-Clusters, auf den Konto B zugreifen muss.
```
aws dax describe-clusters \
--cluster-name cluster-name
--query 'Clusters[0].SubnetGroup'
```
1. Suchen Sie damit *subnet-group* die VPC des Clusters.
```
aws dax describe-subnet-groups \
--subnet-group-name subnet-group \
--query 'SubnetGroups[0].VpcId'
```
1. Suchen Sie damit *vpc-id* den CIDR der VPC.
```
aws ec2 describe-vpcs \
--vpc vpc-id \
--query 'Vpcs[0].CidrBlock'
```
1. Erstellen Sie in Konto B eine VPC mit einer anderen, nicht überlappenden CIDR als der, die im im vorherigen Schritt gefunden wurde. Erstellen Sie dann mindestens ein Subnetz. Sie können entweder den [VPC-Erstellungsassistenten](https://docs.aws.amazon.com/vpc/latest/userguide/getting-started-ipv4.html#getting-started-create-vpc) in AWS-Managementkonsole oder in verwenden. [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-vpc.html)
1. Fordern Sie in Konto B eine Peering-Verbindung mit der VPC von Konto A an, wie unter [Erstellen und Akzeptieren einer VPC-Peering-Verbindung](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html) beschrieben. Akzeptieren Sie die Verbindung in Konto A.
1. Suchen Sie in Konto B die Routingtabelle der neuen VPC. *vpc-id*Ersetzen Sie durch die ID der VPC, die Sie in Konto B erstellt haben.
```
aws ec2 describe-route-tables \
--filters 'Name=vpc-id,Values=vpc-id' \
--query 'RouteTables[0].RouteTableId'
```
1. Fügen Sie eine Route hinzu, um Datenverkehr für die CIDR von Konto A an die VPC-Peering-Verbindung zu senden. Denken Sie daran, jeden Wert *user input placeholder* durch die richtigen Werte für Ihre Konten zu ersetzen.
```
aws ec2 create-route \
--route-table-id accountB-route-table-id \
--destination-cidr accountA-vpc-cidr \
--vpc-peering-connection-id peering-connection-id
```
1. Suchen Sie von Konto A aus nach der Routing-Tabelle des DAX-Clusters, indem *vpc-id* Sie die zuvor gefundene Tabelle verwenden.
```
aws ec2 describe-route-tables \
--filters 'Name=vpc-id, Values=accountA-vpc-id' \
--query 'RouteTables[0].RouteTableId'
```
1. Fügen Sie in Konto A eine Route hinzu, um Datenverkehr für die CIDR von Konto B an die VPC-Peering-Verbindung zu senden. Ersetzen Sie jeden *user input placeholder* Wert durch die richtigen Werte für Ihre Konten.
```
aws ec2 create-route \
--route-table-id accountA-route-table-id \
--destination-cidr accountB-vpc-cidr \
--vpc-peering-connection-id peering-connection-id
```
1. Starten Sie in Konto B eine EC2-Instance in der zuvor von Ihnen erstellten VPC. Ordnen Sie ihr das `AssumeDaxInstanceProfile` zu. Sie können entweder den [Startassistenten](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/launching-instance.html) im AWS-Managementkonsole oder im verwenden [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html). Notieren Sie sich die Sicherheitsgruppe der Instance.
1. Suchen Sie in Konto A die Sicherheitsgruppe, die vom DAX-Cluster verwendet wird. Denken Sie daran, es *cluster-name* durch den Namen Ihres DAX-Clusters zu ersetzen.
```
aws dax describe-clusters \
--cluster-name cluster-name \
--query 'Clusters[0].SecurityGroups[0].SecurityGroupIdentifier'
```
1. Aktualisieren Sie die Sicherheitsgruppe des DAX-Clusters, um eingehenden Datenverkehr von der Sicherheitsgruppe der EC2-Instance zuzulassen, die Sie in Konto B erstellt haben. Denken Sie daran, die durch die *user input placeholders* richtigen Werte für Ihre Konten zu ersetzen.
```
aws ec2 authorize-security-group-ingress \
--group-id accountA-security-group-id \
--protocol tcp \
--port 8111 \
--source-group accountB-security-group-id \
--group-owner accountB-id
```
An dieser Stelle kann eine Anwendung auf der EC2-Instance von Konto B mithilfe des Instance-Profils die Rolle `arn:aws:iam::accountA-id:role/DaxCrossAccountRole` übernehmen und den DAX-Cluster nutzen.
## Ändern des DAX-Clients, um den kontoübergreifenden Zugriff zu erlauben
**Anmerkung**
AWS -Security-Token-Service (AWS STS) Anmeldeinformationen sind temporäre Anmeldeinformationen. Einige Clients nehmen automatisch Aktualisierungen vor, während andere zusätzliche Logik benötigen, um die Anmeldeinformationen zu aktualisieren. Wir empfehlen Ihnen, die Anleitung der entsprechenden Dokumentation zu befolgen.
------
#### [ Java ]
Dieser Abschnitt unterstützt Sie beim Ändern Ihres vorhandenen DAX-Clientcodes, um kontoübergreifenden DAX-Zugriff zu ermöglichen. Wenn Sie noch keinen DAX-Clientcode haben, finden Sie Beispiele von funktionierendem Code im Tutorial [Java und DAX](DAX.client.run-application-java.md).
1. Fügen Sie die folgenden Importe hinzu.
```
import com.amazonaws.auth.STSAssumeRoleSessionCredentialsProvider;
import com.amazonaws.services.securitytoken.AWSSecurityTokenService;
import com.amazonaws.services.securitytoken.AWSSecurityTokenServiceClientBuilder;
```
1. Rufen Sie einen Anbieter für Anmeldeinformationen von ab AWS STS und erstellen Sie ein DAX-Client-Objekt. Denken Sie daran, jeden Wert *user input placeholder* durch die richtigen Werte für Ihre Konten zu ersetzen.
```
AWSSecurityTokenService awsSecurityTokenService = AWSSecurityTokenServiceClientBuilder
.standard()
.withRegion(region)
.build();
STSAssumeRoleSessionCredentialsProvider credentials = new STSAssumeRoleSessionCredentialsProvider.Builder("arn:aws:iam::accountA:role/RoleName", "TryDax")
.withStsClient(awsSecurityTokenService)
.build();
DynamoDB client = AmazonDaxClientBuilder.standard()
.withRegion(region)
.withEndpointConfiguration(dax_endpoint)
.withCredentials(credentials)
.build();
```
------
#### [ .NET ]
Dieser Abschnitt unterstützt Sie beim Ändern Ihres vorhandenen DAX-Clientcodes, um kontoübergreifenden DAX-Zugriff zu ermöglichen. Wenn Sie noch keinen DAX-Clientcode haben, finden Sie Beispiele von funktionierendem Code im Tutorial [.NET und DAX](DAX.client.run-application-dotnet.md).
1. Füge das hinzu [AWSSDK. SecurityToken](https://www.nuget.org/packages/AWSSDK.SecurityToken) NuGet Paket zur Lösung.
```
```
1. Verwenden Sie die Pakete `SecurityToken` und `SecurityToken.Model`.
```
using Amazon.SecurityToken;
using Amazon.SecurityToken.Model;
```
1. Fordern Sie temporäre Anmeldeinformationen von `AmazonSimpleTokenService` an und erstellen Sie ein `ClusterDaxClient`-Objekt. Denken Sie daran, jeden Wert *user input placeholder* durch die richtigen Werte für Ihre Konten zu ersetzen.
```
IAmazonSecurityTokenService sts = new AmazonSecurityTokenServiceClient();
var assumeRoleResponse = sts.AssumeRole(new AssumeRoleRequest
{
RoleArn = "arn:aws:iam::accountA:role/RoleName",
RoleSessionName = "TryDax"
});
Credentials credentials = assumeRoleResponse.Credentials;
var clientConfig = new DaxClientConfig(dax_endpoint, port)
{
AwsCredentials = assumeRoleResponse.Credentials
};
var client = new ClusterDaxClient(clientConfig);
```
------
#### [ Go ]
Dieser Abschnitt unterstützt Sie beim Ändern Ihres vorhandenen DAX-Clientcodes, um kontoübergreifenden DAX-Zugriff zu ermöglichen. Falls Sie noch keinen DAX-Client-Code haben, finden Sie [funktionierende Codebeispiele unter GitHub](https://github.com/aws-samples/aws-dax-go-sample/blob/master/try_dax.go).
1. Importieren Sie die Pakete AWS STS und die Sitzungspakete.
```
import (
"github.com/aws/aws-sdk-go/aws/session"
"github.com/aws/aws-sdk-go/service/sts"
"github.com/aws/aws-sdk-go/aws/credentials/stscreds"
)
```
1. Fordern Sie temporäre Anmeldeinformationen von `AmazonSimpleTokenService` an und erstellen Sie ein DAX-Clientobjekt. Denken Sie daran, jeden Wert *user input placeholder* durch die richtigen Werte für Ihre Konten zu ersetzen.
```
sess, err := session.NewSession(&aws.Config{
Region: aws.String(region)},
)
if err != nil {
return nil, err
}
stsClient := sts.New(sess)
arp := &stscreds.AssumeRoleProvider{
Duration: 900 * time.Second,
ExpiryWindow: 10 * time.Second,
RoleARN: "arn:aws:iam::accountA:role/role_name",
Client: stsClient,
RoleSessionName: "session_name",
}cfg := dax.DefaultConfig()
cfg.HostPorts = []string{dax_endpoint}
cfg.Region = region
cfg.Credentials = credentials.NewCredentials(arp)
daxClient := dax.New(cfg)
```
------
#### [ Python ]
Dieser Abschnitt unterstützt Sie beim Ändern Ihres vorhandenen DAX-Clientcodes, um kontoübergreifenden DAX-Zugriff zu ermöglichen. Wenn Sie noch keinen DAX-Clientcode haben, finden Sie Beispiele von funktionierendem Code im Tutorial [Python und DAX](DAX.client.run-application-python.md).
1. Importieren Sie `boto3`.
```
import boto3
```
1. Fordern Sie temporäre Anmeldeinformationen von `sts` an und erstellen Sie ein `AmazonDaxClient`-Objekt. Denken Sie daran, jeden Wert *user input placeholder* durch die richtigen Werte für Ihre Konten zu ersetzen.
```
sts = boto3.client('sts')
stsresponse = sts.assume_role(RoleArn='arn:aws:iam::accountA:role/RoleName',RoleSessionName='tryDax')
credentials = botocore.session.get_session()['Credentials']
dax = amazondax.AmazonDaxClient(session, region_name=region, endpoints=[dax_endpoint], aws_access_key_id=credentials['AccessKeyId'], aws_secret_access_key=credentials['SecretAccessKey'], aws_session_token=credentials['SessionToken'])
client = dax
```
------
#### [ Node.js ]
Dieser Abschnitt unterstützt Sie beim Ändern Ihres vorhandenen DAX-Clientcodes, um kontoübergreifenden DAX-Zugriff zu ermöglichen. Wenn Sie noch keinen DAX-Clientcode haben, finden Sie Beispiele von funktionierendem Code im Tutorial [Node.js und DAX](DAX.client.run-application-nodejs.md). Denken Sie daran, jeden Wert *user input placeholder* durch die richtigen Werte für Ihre Konten zu ersetzen.
```
const AmazonDaxClient = require('amazon-dax-client');
const AWS = require('aws-sdk');
const region = 'region';
const endpoints = [daxEndpoint1, ...];
const getCredentials = async() => {
return new Promise((resolve, reject) => {
const sts = new AWS.STS();
const roleParams = {
RoleArn: 'arn:aws:iam::accountA:role/RoleName',
RoleSessionName: 'tryDax',
};
sts.assumeRole(roleParams, (err, session) => {
if(err) {
reject(err);
} else {
resolve({
accessKeyId: session.Credentials.AccessKeyId,
secretAccessKey: session.Credentials.SecretAccessKey,
sessionToken: session.Credentials.SessionToken,
});
}
});
});
};
const createDaxClient = async() => {
const credentials = await getCredentials();
const daxClient = new AmazonDaxClient({endpoints: endpoints, region: region, accessKeyId: credentials.accessKeyId, secretAccessKey: credentials.secretAccessKey, sessionToken: credentials.sessionToken});
return new AWS.DynamoDB.DocumentClient({service: daxClient});
};
createDaxClient().then((client) => {
client.get(...);
...
}).catch((error) => {
console.log('Caught an error: ' + error);
});
```
------
# DAX-Clustergrößenleitfaden
In diesem Handbuch finden Sie Hinweise zur Auswahl einer geeigneten Amazon-DynamoDB-Accelerator-(DAX)-Clustergröße und des Knotentyps für Ihre Anwendung. Diese Anweisungen führen Sie durch die Schritte zum Schätzen des DAX-Datenverkehrs Ihrer Anwendung, zur Auswahl einer Clusterkonfiguration und zum Testen dieser Anwendung.
Wenn Sie über einen vorhandenen DAX-Cluster verfügen und prüfen möchten, ob er die entsprechende Anzahl und Größe von Knoten hat, lesen Sie bitte [Skalieren eines DAX-Clusters](DAX.cluster-management.md#DAX.cluster-management.scaling).
**Topics**
+ [-Übersicht](#DAX.sizing-guide.overview)
+ [Schätzung des Datenverkehrs](#DAX.sizing-guide.estimating-traffic)
+ [Lasttest](#DAX.sizing-guide.load-testing)
## -Übersicht
Es ist wichtig, den DAX-Cluster entsprechend für Ihre Workload zu skalieren, unabhängig davon, ob Sie einen neuen Cluster erstellen oder einen vorhandenen Cluster verwalten. Wenn die Zeit vergeht und sich der Workload Ihrer Anwendung ändert, sollten Sie Ihre Skalierungsentscheidungen regelmäßig überprüfen, um sicherzustellen, dass sie weiterhin angemessen sind.
Der Prozess führt in der Regel folgende Schritte aus:
1. **Schätzung des Datenverkehrs.** In diesem Schritt machen Sie Vorhersagen über das Datenvolumen, das Ihre Anwendung an DAX senden wird, die Art des Datenverkehrs (Lese- vs. Schreibvorgänge) und die erwartete Cache-Trefferrate.
1. **Durchführung eines Lasttests.** In diesem Schritt erstellen Sie einen Cluster und senden Datenverkehr an ihn und spiegeln dabei Ihre Schätzungen aus dem vorherigen Schritt. Wiederholen Sie diesen Schritt, bis Sie eine geeignete Clusterkonfiguration gefunden haben.
1. **Produktionsüberwachung.** Während Ihre Anwendung DAX in der Produktion verwendet, sollten Sie den [Cluster überwachen](DAX.Monitoring.md), um kontinuierlich zu überprüfen, ob er immer noch korrekt skaliert ist, wenn sich Ihre Workload im Laufe der Zeit ändert.
## Schätzung des Datenverkehrs
Es gibt drei Hauptfaktoren, die eine typische DAX-Workload charakterisieren:
+ Cache-Trefferrate
+ [Lesekapazitätseinheiten](provisioned-capacity-mode.md#read-write-capacity-units) (RCUs) pro Sekunde
+ [Schreibkapazitätseinheiten](provisioned-capacity-mode.md#read-write-capacity-units) (WCUs) pro Sekunde
### Schätzen der Cache-Zugriffsrate
Wenn Sie bereits über einen DAX-Cluster verfügen, können Sie anhand der [ CloudWatch Metriken `ItemCacheHits` und `ItemCacheMisses` Amazon](dax-metrics-dimensions-dax.md) die Cache-Trefferquote ermitteln. Die Cache-Zugriffsrate ist gleich `ItemCacheHits` / (`ItemCacheHits` \$1 `ItemCacheMisses`). Wenn Ihr Workload `Query`- oder `Scan`-Operationen beinhaltet, sollten Sie sich auch die Metriken `QueryCacheHits`, `QueryCacheMisses`, `ScanCacheHits` und `ScanCacheMisses` ansehen. Die Cache-Trefferraten variieren von Anwendung zu Anwendung und werden stark von der TTL-Einstellung (Time to Live) des Clusters beeinflusst. Typische Trefferraten für Anwendungen, die DAX verwenden, liegen bei 85-95 Prozent.
### Schätzen von Lese- und Schreibkapazitätseinheiten
[Wenn Sie bereits über DynamoDB-Tabellen für Ihre Anwendung verfügen, sehen Sie sich die Metriken `ConsumedReadCapacityUnits` und `ConsumedWriteCapacityUnits` CloudWatch an.](dax-metrics-dimensions-dax.md) Verwenden Sie die Statistik `Sum` und dividieren Sie durch die Anzahl der Sekunden im Zeitraum.
Wenn Sie auch bereits über einen DAX-Cluster verfügen, denken Sie daran, dass die DynamoDB-Metrik `ConsumedReadCapacityUnits` nur Cache-Fehlschläge berücksichtigt. Um eine Vorstellung von den Lesekapazitätseinheiten pro Sekunde zu erhalten, die von Ihrem DAX-Cluster verarbeitet werden, teilen Sie die Zahl durch Ihre Cache-Fehlerrate (d. h. 1 - Cache-Trefferrate).
Wenn Sie noch keine DynamoDB-Tabelle haben, lesen Sie die Dokumentation zu [Lese- und Schreibkapazitätseinheiten](provisioned-capacity-mode.md#read-write-capacity-units), um den Datenverkehr basierend auf der geschätzten Anforderungsrate Ihrer Anwendung, der Anzahl der Elemente, auf die pro Anforderung zugegriffen wird, und der Elementgröße zu schätzen.
Planen Sie bei der Erstellung von Datenverkehrsschätzungen das zukünftige Wachstum sowie die erwarteten und unerwarteten Spitzen, um sicherzustellen, dass Ihr Cluster genügend Spielraum für den Datenverkehr hat.
## Lasttest
Der nächste Schritt nach der Schätzung des Datenverkehrs besteht darin, die Clusterkonfiguration unter Last zu testen.
1. Für den ersten Lasttest empfehlen wir, dass Sie mit dem `dax.r4.large`-Knotentyp beginnen, dem speicheroptimierten Knotentyp mit einer Leistung mit den niedrigsten Fixkosten.
1. Ein fehlertoleranter Cluster erfordert mindestens drei Knoten, verteilt auf drei Availability Zones. Wenn in diesem Fall eine Availability Zone nicht mehr verfügbar ist, wird die effektive Anzahl von Availability Zones um ein Drittel reduziert. Für den ersten Lasttest empfehlen wir, mit einem Cluster mit zwei Knoten zu beginnen, der den Ausfall einer Availability Zone in einem Cluster mit drei Knoten simuliert.
1. Leiten Sie für die Dauer des Lasttests anhaltenden Datenverkehr (wie im vorherigen Schritt geschätzt) zu Ihrem Testcluster.
1. Überwachen Sie die Leistung des Clusters während des Lasttests.
Idealerweise sollte das Datenverkehrsprofil, das Sie während des Lasttests steuern, dem realen Datenverkehr Ihrer Anwendung so ähnlich wie möglich sein. Dazu gehören die Aufteilung der Vorgänge (z. B. 70 Prozent `GetItem`, 25 Prozent `Query` und 5 Prozent `PutItem`), die Anforderungsrate für jeden Vorgang, die Anzahl der Elemente, auf die pro Anforderung zugegriffen wird, und die Verteilung der Elementgrößen. Um eine Cache-Zugriffsrate zu erreichen, die der erwarteten Cache-Zugriffsrate Ihrer Anwendung entspricht, achten Sie genau auf die Verteilung der Schlüssel im Testdatenverkehr.
**Anmerkung**
Seien Sie vorsichtig, wenn Sie die Last der T2-Knotentypen (`dax.t2.small` und `dax.t2.medium`) testen. T2-Knotentypen bieten eine [dynamische CPU-Leistung](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html), die je nach CPU-Guthaben des Knotens im Laufe der Zeit variiert. Ein DAX-Cluster, der auf T2-Knoten ausgeführt wird, scheint normal zu funktionieren, aber wenn einer der Knoten die [Basisleistung](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html) seiner Instance überschreitet, gibt der Knoten sein aufgelaufenes CPU-Guthaben aus. Wenn der Gutschriftensaldo niedrig ist, wird die [Leistung schrittweise auf das Basisleistungsniveau gesenkt](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-standard-mode.html).
[Überwachen Sie Ihren DAX-Cluster](DAX.Monitoring.md) während des Lasttests, um festzustellen, ob der Knotentyp, den Sie für den Lasttest verwenden, der richtige Knotentyp für Sie ist. Darüber hinaus sollten Sie während eines Lasttests Ihre Anforderungsrate und die Cache-Zugriffsrate überwachen, um sicherzustellen, dass Ihre Testinfrastruktur tatsächlich den von Ihnen beabsichtigten Datenverkehr steuert.
Sie sollten auf den Netzwerk-Byte-Verbrauch Ihres ausgewählten Cluster-Instance-Typs achten. Eine Überschreitung der verfügbaren Basisbandbreite für eine Amazon-EC2-Instance weist darauf hin, dass Ihr Cluster die Workload Ihrer Anwendung möglicherweise nicht unterstützt und skaliert werden muss.
Wenn Auslastungstests darauf hindeuten, dass die ausgewählte Clusterkonfiguration die Workload-Auslastung Ihrer Anwendung nicht aufrechterhalten kann, wird empfohlen, zu einem [größeren Knotentyp zu wechseln](DAX.cluster-management.md#DAX.cluster-management.scaling.node-types), insbesondere wenn Sie eine hohe CPU-Auslastung auf dem Primärknoten im Cluster, hohe Bereinigungsraten oder eine hohe Cachespeicherauslastung feststellen. Wenn die Zugriffsraten konstant hoch sind und das Verhältnis zwischen Lese- und Schreibdatenverkehr hoch ist, sollten Sie dem [Cluster weitere Knoten hinzufügen](DAX.cluster-management.md#DAX.cluster-management.scaling.read-scaling). Weitere Hinweise zum Verwenden eines größeren Knotentyps (vertikale Skalierung) oder zum Hinzufügen weiterer Knoten (horizontale Skalierung) finden Sie unter [Skalieren eines DAX-Clusters](DAX.cluster-management.md#DAX.cluster-management.scaling).
Sie sollten den Lasttest wiederholen, nachdem Sie Änderungen an der Clusterkonfiguration vorgenommen haben.