Ich habe eine E-Commerce-Website mit rund 30.000 täglichen Benutzern und über 50.000 Sitzungen. Wir verwenden die RDS m5.xlarge-Instanz. Im Alltag haben wir keine Probleme mit Lese- oder Schreibvorgängen. Aber gelegentlich stehen wir vor folgenden Herausforderungen:
- An manchen Tagen haben wir aufgrund von Sonderangeboten oder aggressivem Marketing mehr als doppelt so viele Benutzer. Zu solchen Zeiten ist die CPU-Auslastung mehrmals am Tag auf 100 % ausgelastet.
- Sehr gelegentlich, während einige schwere Schreibvorgänge ausgeführt werden, wird das Lesen langsam
Wenn ich mir das anschaue, kann ich nicht beurteilen, ob ich die RDS-Instanz weiter vertikal skalieren oder eine Lese-Replik hochfahren soll. Zwei Punkte, die ich bei dieser Entscheidung berücksichtigen möchte:
- Hilft mir eine Lese-Replik dabei, die Datenbank an Tagen mit hohem Datenverkehr nicht weiter vertikal zu verteilen?
- Kann ich mit einer Lese-Replik die Kosten senken oder gleich halten und gleichzeitig eine höhere Skalierbarkeit erreichen?
Im Durchschnitt habe ich folgende Nutzung der m5.xlarge-Instanz:
- CPU-Auslastung 40 %
- DB-Anschlüsse 100
- RAM 6 GB verwendet
- 125 Schreib-IOPS
- 3 IOPS lesen
Abgesehen von der CPU scheint die Nutzung sehr gering zu sein. Ist eine Lese-Replik eine Möglichkeit, eine höhere Skalierbarkeit ohne Kostensteigerung zu erreichen?
Antwort1
Es klingt, als bräuchten Sie ein automatisch skalierendes RDS, das es für Computeranwendungen leider nicht gibt.
RDS-Größe erhöhen
Wenn Sie die Größe Ihrer Instanz erhöhen, zahlen Sie rund um die Uhr mehr. Das ist die einfachste Lösung und sollte viele Ihrer Probleme verringern. Wenn die Kosten kein Problem darstellen, ist dies wahrscheinlich das beste Problem.
Replikat lesen
Die andere wichtige Option ist eine Lese-Replik. Sie müssten Ihre Software ändern, um eine Lese-Replik zu verwenden, da diese einen anderen Endpunkt als die URL der Hauptdatenbank hat. Sie könnten beispielsweise alle Schreibvorgänge an die Hauptdatenbank und alle Lesevorgänge an die Lese-Replik senden. Die Lese-Replik kann den Aktualisierungen des Masters etwas hinterherhinken. Möglicherweise können Sie sogar die Größe der Hauptdatenbank reduzieren – aber Sie müssen Benchmarks durchführen oder bei Ihrem Ansatz konservativ vorgehen.
Sie könnten erwägen, vor allen erwarteten größeren Ereignissen manuell eine Lese-Replik hochzufahren. Dies würde manuell erfolgen und einige Zeit in Anspruch nehmen, und Ihre Anwendung müsste mit einer Datenbank zurechtkommen, die manchmal, aber nicht immer, vorhanden ist.
Zwischenspeicherung
Abhängig von Ihren Zugriffsmustern kann das Zwischenspeichern von Daten in Redis/Memcached die Datenbanklast möglicherweise so weit reduzieren, dass Sie Ihre Datenbank nicht aktualisieren müssen. Dies setzt natürlich voraus, dass dieselben Daten mehr als einmal gelesen werden müssen und über ausreichend Cache-Speicher verfügen.
Aurora
Sie könnten in Betracht ziehenAmazon Aurora für MySQL. Ich habe es selbst nicht verwendet, aber es soll sehr gut skalierbar sein – obwohl jede einzelne Transaktion möglicherweise nicht ganz so schnell ist wie beim Standard-RDS.
Datenbankoptimierung
Eine andere Möglichkeit besteht darin, zu prüfen, was Datenbankkapazität beansprucht, und „teure“ Abfragen oder Indizes zu optimieren. Wenn Sie einfache Abfragen haben und nur eine hohe Auslastung vorliegt, hilft das möglicherweise nicht.