Säule der Zuverlässigkeit

Die Zuverlässigkeitssäule von AWS Well-Architected Framework umfasst die Fähigkeit eines Workloads, seine vorgesehene Funktion korrekt und konsistent auszuführen, wenn dies erwartet wird. Dazu gehört auch die Fähigkeit, den Workload während seines gesamten Lebenszyklus zu betreiben und zu testen.

Ausgangspunkt für eine zuverlässige Workload sind vorab getroffene Designentscheidungen für Software und Infrastruktur. Ihre Architekturentscheidungen wirken sich auf Ihr Workload-Verhalten in allen Well-Architected-Säulen aus. Aus Gründen der Zuverlässigkeit müssen Sie bestimmten Mustern folgen, wie in diesem Abschnitt beschrieben.

Die Säule Zuverlässigkeit konzentriert sich auf die folgenden Schlüsselbereiche:

• Workload-Architektur, einschließlich Servicequotas und Bereitstellungsmustern

• Änderungsmanagement

• Fehlerverwaltung

Neptune-Dienstkontingente verstehen

Ihr AWS Konto verfügt über Standardkontingente (früher als Limits bezeichnet) für jedes Konto. AWS-Service Wenn nicht anders angegeben, gilt jedes Kontingent spezifisch für eine Region. Sie können Erhöhungen für einige, aber nicht für alle Kontingente beantragen.

Um Kontingente für Neptune Analytics zu finden, öffnen Sie die Service Quotas Console. Wählen Sie im Navigationsbereich Amazon Neptune AWS-ServicesAnalytics aus und wählen Sie es dann aus. Achten Sie auf die Kontingente für die Anzahl der Graphen und Snapshots, den maximal bereitgestellten Speicher für ein Diagramm und die API-Anforderungsraten.

Wenn der maximal bereitgestellte Speicher für Ihren Datensatz nicht ausreicht, sollten Sie abwägen, welche Knoten- und Edge-Typen für Ihre beabsichtigte analytische Nutzung unerlässlich sind. Laden Sie eine Teilmenge der Daten, sodass Analysen innerhalb der zulässigen bereitgestellten Kapazität möglich sind. Viele Analytics-Workloads, insbesondere solche, die Graph-Algorithmen ausführen, benötigen statt des vollständigen Transaktionsgraphen nur die Topologie mit einer begrenzten Anzahl von Eigenschaften. (Eine Erläuterung der Unterschiede zwischen transaktionalen und analytischen Workloads finden Sie im Abschnitt Leistungseffizienz.)

Wenn die maximale Anzahl von Grafiken für Ihren Verwendungszweck nicht ausreicht:

• Erwägen Sie, Grafiken zu kombinieren, die ähnliche Verwendungszwecke haben.

• Beurteilen Sie, wie viele Grafiken gleichzeitig ausgeführt werden müssen. Wenn Sie einen Anwendungsfall für kurzlebige Analysen haben, erstellen Sie einen Snapshot von einem Diagramm und löschen Sie es, wenn es nicht mehr benötigt wird. Dadurch wird die Anzahl der Grafiken im Vergleich zum Kontingent reduziert.

• Erwägen Sie die Bereitstellung von Diagrammen in verschiedenen AWS-Konten Varianten.

Verstehen Sie die Einsatzmuster von Neptune

Machen Sie sich mit den folgenden Entscheidungspunkten vertraut, wenn Sie planen, ein Neptune Analytics-Diagramm bereitzustellen:

• Seeding: Entscheiden Sie, ob Sie ein leeres Diagramm erstellen oder bei der Erstellung Daten mit Daten aus Amazon S3, einem vorhandenen Neptune-Datenbank-Cluster oder einem vorhandenen Neptune-Datenbank-Snapshot in dieses laden möchten.

  Empfehlung: Wenn es sich bei der Quelle um einen Neptun-Cluster oder -Snapshot handelt, müssen Sie dessen Daten bei der Erstellung des Diagramms laden. Wenn es sich bei der Quelle um Amazon S3 handelt, laden Sie die Daten zum Zeitpunkt der Erstellung, wenn der Ladeaufwand erheblich ist und sich am besten als Infrastrukturbereitstellungsaktivität eignet. Wenn Sie es vorziehen, Daten als Datentechnik- oder Anwendungsaktivität zu laden, erstellen Sie ein leeres Diagramm und laden Sie später Daten aus Amazon S3.

• Kapazität: Schätzen Sie die erforderliche bereitgestellte Kapazität für ein Diagramm unter Berücksichtigung der Datengröße und der erwarteten Anwendungsnutzung.

  Empfehlung: Geben Sie bei der Erstellung den maximal bereitgestellten Speicher an, um die Diagrammgröße zu begrenzen. Diese Einstellung ist verpflichtend. Sie können die Kapazität bei Bedarf später ändern.

• Verfügbarkeit und Fehlertoleranz: Entscheiden Sie, ob Replikate für die Verfügbarkeit erforderlich sind. Ein Replikat fungiert als Warm-Standby für die Wiederherstellung im Falle eines Graphausfalls. Ein Diagramm mit Replikaten wird schneller wiederhergestellt als ein Diagramm ohne Replikate. Überlegen Sie auch, wie lange das Diagramm benötigt wird, ob es nur für kurzlebige Analysen bestimmt ist und, falls ja, wann es entfernt wird.

  Empfehlung: Ermitteln Sie die Verfügbarkeitsanforderungen, z. B. wie lange das Diagramm nicht verfügbar sein kann und wann es entfernt werden kann, bevor Sie ein Diagramm erstellen.

• Netzwerk und Sicherheit: Stellen Sie fest, ob Sie öffentliche Konnektivität, private Konnektivität oder beides benötigen und ob Sie Ihre Daten verschlüsseln möchten.

  Empfehlung: Machen Sie sich mit den organisatorischen Anforderungen vertraut, z. B. ob öffentliche Konnektivität zulässig ist und wo Graph-Client-Anwendungen bereitgestellt werden, bevor Sie ein Diagramm erstellen.

• Backups und Wiederherstellung: Ermitteln Sie, ob Snapshots erstellt werden sollen, und wenn ja, wann oder unter welchen Bedingungen. Überlegen Sie, ob Ihr Unternehmen Anforderungen an die Notfallwiederherstellung (DR) stellt.

  Empfehlung: Das Erstellen von Snapshots ist eine manuelle Aktivität. Entscheiden Sie, wann Snapshots erstellt werden sollen, und berücksichtigen Sie Ihre DR-Anforderungen, bevor Sie ein Diagramm erstellen.

Neptun-Cluster verwalten und skalieren

Ein Neptune Analytics-Diagramm besteht aus einer einzigen, speicheroptimierten Instanz. Die Kapazität (m-NCU) der Instanz wird zum Zeitpunkt der Erstellung festgelegt. Die Instanz kann vertikal skaliert werden, indem die bereitgestellte Kapazität durch eine administrative Maßnahme erhöht wird. Die bereitgestellte Kapazität kann auch verringert werden. Replikate sind passive Failover-Ziele, sodass sie den Maßstab eines Graphen nicht erhöhen. In dieser Hinsicht unterscheidet sich eine Graphreplik von einer Neptune-Datenbank-Read-Replica, bei der es sich um eine aktive Instanz in einem Neptune-Cluster handelt, die Lesevorgänge von Anwendungen verarbeiten kann.

Replikate sind mit Kosten verbunden. Der Preis für das Replikat entspricht dem in der Abbildung angegebenen m-NCU-Kurs. Wenn ein Diagramm beispielsweise für 128 m-NCU bereitgestellt wird und über ein einzelnes Replikat verfügt, sind die Kosten doppelt so hoch wie bei einem gleichwertigen Diagramm ohne Replikate.

In der Analytik gibt es zwei Hauptgründe für eine Skalierung:

• Um mehr Speicher und CPU für analytische Abfragen und Algorithmen zur Verfügung zu stellen, weil die einzelne Abfrage teuer ist, der auszuführende Graph-Algorithmus von Natur aus komplex ist und aufgrund seiner Eingabe mehr Ressourcen benötigt, oder die Rate der gleichzeitigen Anfragen ist hoch. Wenn bei solchen Abfragen out-of-memory Fehler auftreten, ist eine Skalierung eine vernünftige Abhilfe.

• Um eine größere Grafikgröße als geplant zu unterstützen. Wenn die derzeit bereitgestellte Kapazität beispielsweise 128 m-NCU zur Unterstützung von 60 GB an Quelldaten beträgt und Sie weitere 40 GB an Quelldaten benötigen, ist eine Erhöhung auf 256 m-NCU gerechtfertigt.

Überwachen Sie CloudWatch Metriken für Neptune Analytics, wieNumQueuedRequestsPerSec,NumOpenCypherRequestsPerSec, und GraphStorageUsagePercentGraphSizeBytes, um festzustellenCPUUtilization, ob eine Skalierung erforderlich ist. Sie können die Konfiguration eines Diagramms über die Konsole, AWS CLI, oder aktualisieren. SDKs (Beispiele und bewährte Verfahren finden Sie im Abschnitt Operational Excellence.)

Backups und Failover-Ereignisse verwalten

Verwenden Sie Replikate, um sicherzustellen, dass im Falle eines Fehlers ein Diagramm verfügbar bleibt. Ein Diagramm verwendet protokollbasierte Persistenz, um Änderungen in allen Availability Zones in einem zu übernehmen. AWS-Region Das Replikat fungiert als Warm-Standby und hat Zugriff auf diese Daten. Wenn ein Fehler auftritt, nimmt der Graph den Betrieb des Replikats wieder auf. Die Anwendung verwendet weiterhin denselben Endpunkt, um eine Verbindung zum Diagramm herzustellen. Anfragen während des Fehlers während des Fehlers führen zu Fehlern mit einer Ausnahme, dass der Dienst nicht verfügbar ist. Erwägen Sie, einen Wiederholungsversuch mit Backoff-Muster im Anwendungscode zu verwenden, um catch Fehler zu erkennen, und versuchen Sie es nach einem kurzen Intervall erneut. Neue Anfragen, die während des Failovers gestellt werden, werden in die Warteschlange gestellt und es kann zu einer längeren Latenz kommen.

Wenn kein Replikat konfiguriert ist und das Diagramm fehlschlägt, stellt Neptune Analytics die Daten von einem dauerhaften Speicher wieder her. Die Wiederherstellung dauert jedoch länger, da Neptune Ressourcen neu initialisieren muss.

Erstellen Sie Schnappschüsse des Graphen. (Neptune Analytics macht keine automatischen Schnappschüsse.) Wenn das Diagramm nach der Erstellung regelmäßig geändert wird, machen Sie regelmäßig Schnappschüsse, um seinen aktuellen Status zu erfassen. Löschen Sie ältere Schnappschüsse, wenn eine Wiederherstellung zu einem früheren Zeitpunkt nicht erforderlich ist.

Sie können Schnappschüsse mit anderen Konten und anderen Nutzern teilen. AWS-Regionen Wenn Sie DR-Anforderungen haben, sollten Sie überlegen, ob die Wiederherstellung des Diagramms aus einem Snapshot in einer anderen Region Ihren Anforderungen an das Recovery Time Objective (RTO) und das Recovery Point Objective (RPO) entspricht.