Grundlegende Anleitungen für den Amazon-Neptune-Betrieb

Im Folgenden finden Sie einige grundlegenden Anleitungen für den Betrieb, die bei der Arbeit mit Neptune befolgt werden sollten.

• Machen Sie sich mit Neptune-DB-Instances vertraut, damit Sie sie entsprechend Ihren Leistungs- und Anwendungsanforderungen dimensionieren können. Siehe Amazon-Neptune-DB-Cluster und -Instances.

• Sie müssen die Nutzung von CPU und Arbeitsspeicher überwachen. Auf diese Weise können Sie leichter erkennen, wann auf eine DB-Instance-Klasse mit mehr CPU- oder Speicherkapazität migriert werden sollte, um die erforderliche Abfrageleistung zu erzielen. Sie können Amazon CloudWatch so einrichten, dass Sie benachrichtigt werden, wenn sich Nutzungsmuster ändern oder wenn die Kapazität Ihrer Bereitstellung fast erreicht ist. Auf diese Weise können Sie leichter die Leistung und Verfügbarkeit des Systems wahren. Weitere Informationen hierzu finden Sie unter Überwachen von Instances und Überwachen von Neptune.

  Da Neptune über einen eigenen Speichermanager verfügt, ist es normal, eine relativ geringe Speichernutzung zu sehen, auch wenn die CPU-Auslastung hoch ist. Das Auftreten von Out-of-Memory-Ausnahmen bei der Ausführung von Abfragen weist am deutlichsten darauf hin, dass Sie den freigebbaren Arbeitsspeicher erhöhen müssen.

• Aktivieren Sie automatische Sicherungen und richten Sie das Sicherungsfenster so ein, dass diese zu einem günstigen Zeitpunkt durchgeführt werden.

• Testen Sie den Failover für Ihre DB-Instance, um zu verstehen, wie lange der Vorgang für Ihren Anwendungsfall dauert. Auch können Sie leichter sicherstellen, dass die Anwendung, mit der auf Ihre DB-Instance zugegriffen wird, nach einem Failover automatisch eine Verbindung mit der neuen DB-Instance herstellen kann.

• Führen Sie Ihren Client und den Neptune-Cluster nach Möglichkeit in derselben Region und VPC aus, da regionsübergreifende Verbindungen mit VPC-Peering zu Verzögerungen bei den Query-Antworten führen können. Bei Query-Antworten im einstelligen Millisekundenbereich müssen sich Client und Neptune-Cluster in derselben Region und VPC befinden.

• Wenn Sie eine Lesereplikat-Instance erstellen, sollte sie mindestens so groß sein wie die primäre Writer-Instance. Dies hilft, die Replikationsverzögerung in Grenzen zu halten und vermeidet einen Neustart des Replicas. Siehe Vermeiden Sie verschiedene DB-Instance-Klassen in einem Cluster.

• Bevor Sie auf eine neue Hauptversion der Engine aktualisieren, sollten Sie Ihre Anwendung darauf testen, bevor Sie das Upgrade durchführen. Sie können dies tun, indem Sie Ihren DB-Cluster klonen, so dass auf dem Klon-Cluster die neue Engine-Version ausgeführt wird, und anschließend Ihre Anwendung auf dem Klon testen.

• Um Failovers zu erleichtern, sollten alle Instances idealerweise gleich groß sein.

Bewährte Methoden für die Sicherheit in Amazon Neptune

Verwenden Sie AWS Identity and Access Management (IAM)-Konten zum Steuern des Zugriffs auf Neptune-API-Aktionen. Steuern Sie Aktionen, die Neptune-Ressourcen erstellen, ändern oder löschen (beispielsweise DB-Instances, Sicherheitsgruppen, Optionsgruppen oder Parametergruppen), sowie Aktionen, die allgemeine administrative Aktionen (wie die Sicherung und Wiederherstellung von DB-Instances) ausführen.

• Verwenden Sie nach Möglichkeit temporäre statt persistenter Anmeldeinformationen.

• Weisen Sie jeder Person, die Amazon Relational Database Service (Amazon RDS)-Ressourcen verwaltet, ein individuelles IAM-Konto zu. Verwenden Sie niemals AWS-Konto-Root-Benutzer, um Neptune-Ressourcen zu verwalten. Erstellen Sie einen IAM-Benutzer für jede Person einschließlich Sie selbst.

• Gewähren Sie jedem Benutzer nur den Mindestsatz an Berechtigungen, die für die Ausführung seiner Aufgaben erforderlich sind.

• Verwenden Sie IAM-Gruppen, um Berechtigungen für mehrere Benutzer effektiv zu verwalten.

• Wechseln Sie regelmäßig die IAM-Anmeldeinformationen.

Weitere Informationen zur Verwendung von IAM für den Zugriff auf Neptune-Ressourcen finden Sie unter Sicherheit in Amazon Neptune. Allgemeine Informationen über das Arbeiten mit IAM finden Sie unter AWS Identity and Access Management und Bewährte Methoden für IAM im IAM-Benutzerhandbuch.

Vermeiden Sie verschiedene DB-Instance-Klassen in einem Cluster

Wenn Ihr DB-Cluster Instances verschiedener Klassen enthält, können im Laufe der Zeit Probleme auftreten. Das häufigste Problem besteht darin, dass eine kleine Reader-Instance aufgrund von Replikationsverzögerungen in einen Zyklus wiederholter Neustarts geraten kann. Wenn ein Reader-Knoten eine schwächere DB-Instance-Klassenkonfiguration als die einer Writer-DB-Instance hat, kann das Volumen der Änderungen so groß sein, dass der Reader damit nicht Schritt halten kann.

Wichtig

Um wiederholte Neustarts aufgrund von Verzögerungen bei der Replikation zu vermeiden, konfigurieren Sie Ihren DB-Cluster so, dass alle Instances dieselbe Instance-Klasse (Größe) haben.

Sie können die Verzögerung zwischen der Writer-Instance (der primären Instance) und den Readern in Ihrem DB-Cluster anhand der ClusterReplicaLag-Metrik in Amazon CloudWatch sehen. Mit der VolumeWriteIOPs-Metrik können Sie auch Spitzen von Schreibaktivitäten in Ihrem Cluster erkennen, die zu Verzögerungen bei der Replikation führen können.

Vermeiden Sie wiederholte Neustarts während eines Massenladevorgangs

Wenn es aufgrund von Replikationsverzögerungen während eines Massenladevorgangs zu einem Zyklus wiederholter Lesereplikat-Neustarts kommt, können Ihre Replikate wahrscheinlich nicht mit dem Writer im DB-Cluster Schritt halten.

Sie können die Reader so skalieren, dass sie größer als der Writer sind. Sie können sie auch während des Massenladens vorübergehend entfernen und nach dem Abschluss des Vorgangs erneut erstellen.

Aktivieren Sie den OSGP-Index, wenn Sie eine große Anzahl von Prädikaten haben

Wenn Ihr Datenmodell eine große Anzahl unterschiedlicher Prädikate enthält, führt dies möglicherweise zu einer reduzierten Leistung und höheren Betriebskosten.

In diesem Fall können Sie die Leistung verbessern, indem Sie den OSGP-Index aktivieren. Siehe Der OSGP-Index.

Vermeiden Sie lang laufende Transaktionen, wenn möglich

Lang andauernde (Nur-Lese- oder Lese-Schreib-) Transaktionen können zu unerwarteten Problemen der folgenden Art führen:

Eine lang andauernde Transaktion auf einer Reader- oder Writer-Instance mit gleichzeitigen Schreibvorgängen kann zu einer großen Anhäufung verschiedener Datenversionen führen. Dies kann zu höheren Latenzen bei Leseabfragen führen, die einen großen Teil ihrer Ergebnisse herausfiltern.

In einigen Fällen können die im Laufe von Stunden angesammelten Versionen dazu führen, dass neue Schreibvorgänge gedrosselt werden.

Eine lang andauernde Lese- und Schreibtransaktion mit vielen Schreibvorgängen kann ebenfalls zu Problemen führen, wenn die Instance neu gestartet wird. Wenn eine Instance aufgrund eines Wartungsereignisses oder eines Absturzes neu gestartet wird, werden alle nicht festgeschriebenen Schreibvorgänge zurückgesetzt. Solche Undo-Operationen werden normalerweise im Hintergrund ausgeführt und verhindern nicht, dass die Instance wieder hochgefahren wird. Aber alle neuen Schreibvorgänge, die mit den Vorgängen, die zurückgesetzt werden, in Konflikt geraten, schlagen dann fehl.

Wenn beispielsweise dieselbe Abfrage erneut versucht wird, nachdem die Verbindung beim vorherigen Durchlauf getrennt wurde, schlägt dies möglicherweise fehl, wenn die Instance neu gestartet wird.

Die Zeit, die für das Rückgängigmachen von Vorgängen benötigt wird, ist proportional zum Umfang der Änderungen.

Bewährte Methoden zur Verwendung von Neptune-Metriken

Sie können die Metriken überwachen, die für Ihren Neptune-DB-Cluster verfügbar sind, um Leistungsprobleme aufgrund unzureichender Ressourcen und anderer häufiger Engpässe zu identifizieren.

Überwachen Sie die Leistungsmetriken regelmäßig, um die Durchschnitts-, Höchst- und Mindestwerte für eine Vielzahl von Zeitbereichen zu sammeln. Auf diese Weise können Sie feststellen, wenn die Leistung nachlässt. Mithilfe dieser Daten können Sie auch Amazon-CloudWatch-Alarme für bestimmte Metrikschwellenwerte einrichten, um benachrichtigt zu werden, wenn diese erreicht werden.

Wenn Sie einen neuen DB-Cluster einrichten und in diesem ein typisches Workload ausführen, versuchen Sie, die Durchschnitts-, Höchst- und Mindestwerte aller Leistungsmetriken in unterschiedlichen Intervallen zu erfassen (beispielsweise eine Stunde, 24 Stunden, eine Woche, zwei Wochen). Auf diese Weise erhalten Sie eine Vorstellung davon, was normal ist. Dies hilft, um Vergleichswerte für Betriebsstunden während und außerhalb von Spitzenbelastungen zu erhalten. Sie können diese Informationen anschließend verwenden, um festzustellen, wann die Leistung unter Standardwerte absinkt, und die Alarme entsprechend festlegen.

Weitere Informationen zum Anzeigen von Neptune-Metriken finden Sie unter Überwachung von Neptune mit Amazon CloudWatch.

Es folgen die wichtigsten Metriken, mit denen gestartet werden soll:

• BufferCacheHitRatio – Der Prozentsatz der vom Buffer-Cache bedienten Anfragen. Cache-Fehler erhöhen die Latenz bei der Abfrageausführung erheblich. Wenn die Cache-Trefferquote unter 99,9 % liegt und die Latenz ein Problem für Ihre Anwendung darstellt, sollten Sie ein Upgrade des Instance-Typs in Betracht ziehen, um mehr Daten im Arbeitsspeicher zwischenzuspeichern.

• CPU-Nutzung – Prozentsatz der verwendeten Verarbeitungskapazität des Computers. Hohe Werte für den CPU-Verbrauch können abhängig von Ihren Zielen für die Abfrageleistung angemessen sein.

• Freisetzbarer Arbeitsspeicher – Größe des RAM, der in der DB-Instance verfügbar ist (in Megabyte). Neptune hat seinen eigenen Speichermanager, daher ist diese Metrik möglicherweise niedriger als erwartet. Ein guter Hinweis darauf, dass Sie ein Upgrade Ihrer Instance-Klasse auf eine mit mehr RAM in Erwägung ziehen sollten, ist, wenn es bei Abfragen häufig zu Out-of-Memory-Ausnahmen kommt.

Die rote Linie in der Metrik der Registerkarte Monitoring (Überwachung) kennzeichnet 75 % für CPU- und Arbeitsspeichermetriken. Wenn der Speicherverbrauch der Instance diese Linie häufig überschreitet, prüfen Sie Ihren Workload und ziehen Sie ein Upgrade Ihrer Instance in Betracht, um die Abfrageleistung verbessern.

Bewährte Methoden für das Optimieren von Neptune-Abfragen

Eine der besten Möglichkeiten zur Verbesserung der Neptune-Leistung besteht darin, die am häufigsten verwendeten und ressourcenintensivsten Abfragen so anzupassen, dass ihre Ausführung weniger aufwändig wird.

Informationen über das Anpassen von Gremlin-Abfragen finden Sie unter Gremlin-Abfragehinweise und Optimieren von Gremline-Abfragen. Informationen über das Anpassen von SPARQL-Abfragen finden Sie unter SPARQL-Abfragehinweise.

Load Balancing über Lesereplikate hinweg

Das Round Robin-Routing für den Leser-Endpunkt funktioniert durch Ändern des Hosts, auf den der DNS-Eintrag verweist. Der Client muss eine neue Verbindung erstellen und den DNS-Datensatz auflösen, um eine Verbindung zu einem neuen Read Replica zu erhalten, da WebSocket-Verbindungen oft über längere Zeiträume bestehen bleiben.

Um verschiedene Read Replicas für aufeinanderfolgende Anforderungen abzurufen, stellen Sie sicher, dass der Client den DNS-Eintrag bei jeder Verbindung auflöst. Dies erfordert möglicherweise das Schließen der Verbindung und das erneute Verbinden mit dem Leser-Endpunkt.

Sie können einen Lastausgleich auch über Read Replicas hinweg durchführen, indem Sie explizit Verbindungen zu Instance-Endpunkten herstellen.

Schnelleres Laden mithilfe einer vorübergehend größeren Instance

Ihre Ladeleistung steigt mit größeren Instances. Wenn Sie keinen großen Instance-Typ verwenden, aber dennoch die Ladegeschwindigkeiten erhöhen möchten, können Sie eine größere Instance zum Laden verwenden und diese dann löschen.

Anmerkung

Die folgende Vorgehensweise gilt für einen neuen Cluster. Wenn Sie einen vorhandenen Cluster haben, können Sie eine neue größere Instance hinzufügen und diese dann zu einer primären DB-Instance machen.

So laden Sie Daten mit einer größeren Instance-Größe:

1. Erstellen Sie einen Cluster mit einer einzelnen r5.12xlarge-Instance. Diese Instance ist die primäre DB-Instance.

2. Erstellen Sie mindestens ein Lesereplikat derselben Größe (r5.12xlarge).

   Sie können die Lesereplikate in einer kleineren Größe erstellen. Wenn sie jedoch nicht groß genug sind, um mit den Schreibvorgängen der primären Instance Schritt zu halten, müssen sie möglicherweise häufig neu gestartet werden. Die daraus resultierenden Ausfallzeiten reduzieren die Leistung erheblich.

3. Fügen Sie im Bulk-Loader-Befehl “parallelism” : “OVERSUBSCRIBE” hinzu, um Neptune anzuweisen, alle verfügbaren CPU-Ressourcen für das Laden zu verwenden (siehe Neptune-Loader-Anforderungsparameter). Der Ladevorgang wird dann so schnell fortgesetzt, wie E/A dies zulässt, was in der Regel 60–70 % der CPU-Ressourcen erfordert.

4. Laden Sie Ihre Daten mit dem Neptune-Loader. Der Ladevorgang wird auf der primären DB-Instance durchgeführt.

5. Stellen Sie nach Abschluss des Ladens der Daten sicher, dass Sie alle Instances im Cluster auf denselben Instance-Typ herunterskalieren, um zusätzliche Gebühren und wiederholte Neustartprobleme zu vermeiden (siehe Vermeiden Sie unterschiedliche Instance-Größen).

Ändern Sie die Größe Ihrer Writer-Instance, indem Sie ein Failover auf ein Lesereplikat durchführen

Die beste Methode, die Größe einer Instance in Ihrem DB-Cluster, einschließlich der Writer-Instance, zu ändern, besteht darin, eine Lesereplikat-Instance so zu erstellen oder zu ändern, dass sie die gewünschte Größe hat, und dann bewusst auf dieses Lesereplikat umzuschalten. Bei der Ausfallzeit Ihrer Anwendung handelt es sich lediglich um die Zeit, die für die Änderung der IP-Adresse des Writers erforderlich ist. Diese sollte etwa 3 bis 5 Sekunden betragen.

Die Neptune-Verwaltungs-API, die Sie verwenden, um ein absichtliches Failover der aktuellen Writer-Instance auf eine Lesereplikat-Instance durchzuführen, ist FailoverDBCluster. Wenn Sie den Gremlin-Java-Client verwenden, müssen Sie nach dem Failover möglicherweise ein neues Client-Objekt erstellen, um die neue IP-Adresse zu übernehmen, wie hier beschrieben.

Stellen Sie sicher, dass Sie alle Ihre Instances auf dieselbe Größe umstellen, um einen Zyklus wiederholter Neustarts zu vermeiden, wie unten beschrieben.

Wiederholen des Uploads nach „Data Prefetch Task Interrupted“-Fehler

Wenn Sie mit dem Massen-Loader Daten in Neptune laden, kann dies gelegentlich zum Status LOAD_FAILED führen. In der Antwort auf die Anforderung detaillierter Informationen werden die Meldungen PARSING_ERROR und Data prefetch task interrupted angezeigt.

"errorLogs" : [
  {
    "errorCode" : "PARSING_ERROR",
    "errorMessage" : "Data prefetch task interrupted: Data prefetch task for 11467 failed",
    "fileName" : "s3://some-source-bucket/some-source-file",
    "recordNum" : 0
  }
]

Wenn dieser Fehler auftritt, wiederholen Sie einfach die Massen-Upload-Anforderung.

Der Fehler tritt auf, wenn es eine temporäre Unterbrechung gab, die in der Regel nicht durch Ihre Anforderung oder Ihre Daten verursacht wurde, und er kann in der Regel behoben werden, indem die Massen-Upload-Anforderung erneut ausgeführt wird.

Wenn Sie Standardeinstellungen verwenden, nämlich "mode":"AUTO" und "failOnError":"TRUE", überspringt der Loader Dateien, die er bereits erfolgreich geladen hat und fährt mit dem Laden von Dateien fort, die noch nicht geladen wurden, als die Unterbrechung stattfand.