Allgemeine Nutzungsszenarien

Skalierbarkeit der Anwendung

Verbindungsverarbeitung in serverlosen und ereignisgesteuerten Anwendungen

Serverlose und ereignisgesteuerte Anwendungen, wie APIs und Webdienste, auf denen diese basieren AWS Lambda, müssen häufig eine große Anzahl kurzlebiger Client-Anfragen unterstützen. Dieses Nutzungsmuster kann zu einer Verbindungsabwanderung auf der Datenbankseite führen, ohne dass Verbindungspooling auf der Anwendungsseite implementiert werden kann. Die Datenbankleistung könnte allein aufgrund der Anzahl gleichzeitiger Verbindungen beeinträchtigt werden, oder die Datenbank könnte ihr Verbindungslimit überschreiten, was zu Fehlern beim Client führen könnte.

In diesen Szenarien kann RDS Proxy die folgenden Vorteile bieten:

1. Es entlastet die Kosten für den Verbindungsaufbau von der Datenbank zum Proxy und bietet Verbindungspooling und Multiplexing, um eine große Anzahl von Client-Verbindungen in eine viel kleinere Anzahl von Back-End-Datenbankverbindungen zu übersetzen. Dies trägt dazu bei, den Verbindungsaufwand und Datenbankkonflikte zu reduzieren, insbesondere bei Datenbank-Engines wie PostgreSQL, wo die Kosten für den Aufbau und die Wartung von Verbindungen relativ hoch sind.

2. Es kann Verbindungsspitzen besser bewältigen. Wenn eine Datenbank beispielsweise ihr Verbindungslimit überschreitet, gibt sie sofort einen Fehler an den Client zurück. Wenn der RDS-Proxy eine Verbindung aus dem Pool aufnehmen muss, der Pool jedoch bereits ausgelastet ist, kann der Proxy warten, bis eine Verbindung verfügbar wird. Diese Funktion kann das Kundenerlebnis verbessern, indem schwerwiegende Fehler zu einer leichten Erhöhung der Abfragelatenz führen.

3. Dank der konfigurierbaren Größe des Verbindungspools können Sie den RDS-Proxy auch als Drosselungs- oder Load-Shedding-Mechanismus verwenden. Wenn die Anzahl der Verbindungen die von Ihnen angegebenen Grenzwerte überschreitet, wartet RDS Proxy darauf, dass eine Verbindung innerhalb eines konfigurierbaren Timeouts verfügbar wird. Dies kann in Fällen nützlich sein, in denen die Datenbank mehrere Workloads bedient und Sie den Druck begrenzen möchten, den ein bestimmter Workload auf die Datenbank ausüben kann.

Verbindungsverarbeitung in containerbasierten verteilten Anwendungen

Eine containerbasierte verteilte Anwendungsarchitektur kann Hunderte oder sogar Tausende von Containern umfassen, von denen jeder eine Kopie des Anwendungscodes ausführt. Auch wenn die einzelnen Container in der Lage sind, Verbindungspools zu bilden, sind diese Pools containerspezifisch und daher sehr klein. Die Anzahl der Container multipliziert mit der Größe jedes Container-Minipools kann möglicherweise die Verbindungslimits in Ihren Amazon RDS- oder Aurora-Datenbanken überschreiten.

In dieser Situation ist die Fähigkeit von RDS Proxy, Verbindungspooling (Wiederverwendung von Verbindungen) und Multiplexing (Bedienung mehrerer Clients über eine Back-End-Verbindung) durchzuführen, am wertvollsten. Sie können weiterhin das Verbindungspooling innerhalb jedes Containers verwenden, um die Fluktuation zwischen den Anwendungsthreads und dem RDS-Proxy zu reduzieren, aber der Proxy kann dazu beitragen, die Anzahl der Back-End-Datenbankverbindungen auf ein überschaubares Niveau zu senken.

Verbesserung der Nutzung von Read Replicas

Read-heavy Datenbanken benötigen möglicherweise mehrere Read Replicas, um schreibgeschützten Datenverkehr zu unterstützen. Anwendungen können ihre eigene Logik verwenden, um auszuwählen, mit welchem Replikat eine Verbindung hergestellt werden soll, oder, was häufiger vorkommt, sie verwenden einen DNS-based Round-Robin-Mechanismus wie den Aurora-Cluster-Reader-Endpunkt. Ein solcher DNS-based Ansatz kann jedoch aufgrund von DNS-Caching zu einer ungleichmäßigen Nutzung der Replikate führen. Beispielsweise könnten sich Clients an ein bestimmtes Replikat „anheften“, sie könnten nicht erkennen, dass neue Replikate dem Cluster hinzugefügt werden, oder sie könnten versuchen, eine Verbindung zu Replikaten herzustellen, die nicht mehr existieren.

Wenn Sie einen schreibgeschützten RDS-Proxy-Endpunkt verwenden, leitet der Proxy Client-Verbindungen zwischen allen verfügbaren Replikaten weiter und verwendet dabei die Logik der „wenigsten ausstehenden Verbindungen“. Der RDS-Proxy verteilt den Datenverkehr nicht auf der Grundlage von Datenbankmetriken wie der CPU-Auslastung, sondern versucht, die Anzahl der Client-Verbindungen auf jedem Replikat auszugleichen, gewichtet nach dem Verbindungslimit der Datenbank. Wenn Sie beispielsweise drei Aurora-Repliken mit einer max_connections Einstellung von 500, 500 und 1000 (jeweils) laufen, versucht der Proxy, ungefähr doppelt so viele Verbindungen an das dritte Replikat zu senden wie an die anderen beiden.

Sie können RDS-Proxy-Leser-Endpunkte mit Aurora-Clustern oder Amazon Multi-AZ RDS-DB-Cluster-Bereitstellungen mit zwei lesbaren Standbys verwenden. Proxyleser-Endpunkte werden für Bereitstellungen von Amazon RDS-DB-Instances mit Read Replicas nicht unterstützt.

Verbesserung der Verbindungseffizienz

Bei der Einführung eines Proxys zwischen Client-Anwendungen und der Datenbank besteht Ihr Ziel in der Regel darin, die Effizienz der Verbindungsverarbeitung zu erhöhen und gleichzeitig die Latenzkosten zu berücksichtigen, die durch einen zusätzlichen Netzwerk-Hop über den Proxy entstehen. Eine zusätzliche Zwischenschicht kann im Hinblick auf die Verbesserung der Verbindungseffizienz kontraintuitiv erscheinen, da jede Verbindung, die direkt mit der Datenbank geöffnet worden wäre, jetzt für den Proxy geöffnet wird. Die Schritte beim Protokoll-Handshake sind in beiden Fällen identisch. Wenn Sie also immer noch Ressourcen für Verbindungs-Handshakes ausgeben, ist möglicherweise nicht klar, woher die Effizienzverbesserungen kommen.

Der Proxy macht die Herstellung von Verbindungen nicht unbedingt billiger. Stattdessen verlagert er den Großteil der Handshake-Verarbeitung von der Datenbankebene auf die Proxyschicht. Wenn Sie für Datenbankressourcen bezahlen, möchten Sie, dass diese Ressourcen für Datenbankarbeit und nicht für zusätzliche Gemeinkosten ausgegeben werden. Dies ist besonders wichtig, wenn verschlüsselte Verbindungen verwendet werden: Obwohl der Aufwand für die Übertragung verschlüsselter Daten über eine bestehende Verbindung nicht signifikant ist, ist der anfängliche Aufwand beim Aufbau einer verschlüsselten Verbindung beträchtlich. In Umgebungen, in denen Hunderte oder Tausende von Verbindungen pro Sekunde verarbeitet werden, kann sich dieser zusätzliche Aufwand schnell summieren. Möglicherweise möchten Sie diese CPU-Zeit nicht für (relativ teure) Datenbankressourcen aufwenden, sondern sie stattdessen auf die (vergleichsweise günstige) Proxyschicht auslagern.

Was die Latenz anbelangt, die durch einen zusätzlichen Netzwerk-Hop entsteht, so hängt ihr Ausmaß davon ab, wie „gesprächig“ Ihre Anwendung ist und wie viele Anweisungen sie pro „Konversation“ mit der Datenbank ausführt. In RDS Proxy beobachten Sie in der Regel eine zusätzliche Latenz im niedrigen einstelligen Millisekundenbereich, dies hat jedoch nicht unbedingt sichtbare Auswirkungen auf Ihre Anwendungen. Beispiel:

• Bei einem Workload, bei dem die Ausführungszeiten von Abfragen in der Größenordnung von zehn oder Hunderten von Millisekunden (oder mehr) liegen, ist es unwahrscheinlich, dass der Proxy-Overhead bemerkt wird, da er nur einen kleinen Bruchteil der gesamten Abfragezeit ausmacht.

• Eine Anwendung, die Abfragen im einstelligen Millisekundenbereich oder unter einer Millisekunde ausführt, kann einen Unterschied feststellen, da der Abfrageaufwand (ein zusätzlicher Netzwerk-Hop pro Abfrage) im Vergleich zur Ausführungszeit der Abfrage beträchtlich ist. Dies ist möglicherweise kein Problem, wenn eine Clientsitzung nur eine Handvoll Abfragen umfasst, sodass der kumulative Overhead immer noch gering ist.

Wenn die zusätzliche Latenz in Ihrer Situation sowohl spürbar als auch unerwünscht ist, müssen Sie sie gegen die anderen Vorteile der Verwendung eines Proxys (Pooling, Multiplexing, Failover-Behandlung) abwägen.

Hohe Verfügbarkeit

Multi-AZ Datenbanken, die auf Amazon RDS und Aurora laufen (mit Ausnahme von Aurora DSQL), verwenden Failover-Mechanismen, um die Verfügbarkeit bei Problemen mit der primären Datenbank-Instance wiederherzustellen. Failovers werden auch als Teil betrieblicher Workflows verwendet, z. B. als Rechenskalierung für die primäre Instance. Ein Failover beinhaltet eine DNS-Änderung, bei der der primäre (read/write-fähige) Datenbankendpunkt von der vorherigen Primärinstanz auf die neu hochgestufte Instanz verschoben wird. Diese DNS-Änderung muss von den Client-Anwendungen beobachtet und erkannt werden, damit die Clients der primären Version ohne Verzögerung folgen können.

Einige Anwendungen können aufgrund von DNS-Caching im Betriebssystem oder auf Anwendungsebene Probleme mit der rechtzeitigen Erkennung von DNS-Änderungen haben. Es ist zwar eine bewährte Methode, Probleme mit dem DNS-Caching auf Anwendungsebene zu lösen, dies ist jedoch aufgrund der Komplexität der Anwendung oder der Kosten für die Einführung von Änderungen nicht immer machbar.

In diesem Szenario ist RDS Proxy eine effektive Methode, um DNS-related Failover-Verzögerungen zu vermeiden. Die read/write Endpunkte und die optionalen schreibgeschützten Endpunkte, die von RDS Proxy bereitgestellt werden, sind insofern „stabil“, als sich die IP-Adressen hinter diesen Endpunkten nicht ändern, wenn Datenbank-Instances ihre Rollen austauschen. RDS Proxy verfolgt kontinuierlich die Topologie der Back-End-Datenbank und abstrahiert die Änderungen der Instanzrollen von den Clients.

Es gibt alternative Möglichkeiten, Probleme mit dem DNS-Caching zu lösen, z. B. durch die Verwendung von fortschrittlichen Treibern, die die Datenbanktopologie direkt erkennen können, ohne auf DNS angewiesen zu sein. Es könnte jedoch einfacher sein, einen einzelnen Proxy vor der Datenbank bereitzustellen, anstatt Codeänderungen und neue Treiber auf Anwendungsebene einzuführen.

Verfügbarkeit lesen

RDS Proxy verbessert nicht nur das Kundenerlebnis bei Datenbank-Failovers, sondern trägt auch zur Verfügbarkeit von Anwendungen bei Read Replica-Problemen bei. Dies geschieht auf zwei Arten:

1. Wenn ein Read Replica nicht mehr verfügbar ist, aber andere Replikate im Cluster verfügbar sind, kann der Proxy neue Verbindungen zu den verfügbaren Replikaten weiterleiten. Die Clients müssen sich keine Gedanken über Verzögerungen bei der DNS-Übertragung oder DNS-Caching machen.

2. Bei einer bestehenden Multiplexverbindung kann der Proxy nachfolgende Abfragen von dieser Verbindung an ein anderes verfügbares Replikat senden. In dieser Situation bemerkt der Client möglicherweise nicht einmal, dass bei einem Back-End-Replikat ein Problem aufgetreten ist. Bei Verwendung dieser Technik stellt RDS Proxy sicher, dass das neue Replikat in Bezug auf die Replikationsverzögerung nicht hinter dem vorherigen zurückbleibt. Auf diese Weise werden bei nachfolgenden Abfragen, die vom Client gesendet werden, keine Daten erkannt, die als veraltet angesehen werden könnten.

Verwenden mehrerer Proxys mit einem Ziel

Es hat sich bewährt, einen RDS-Proxy pro Datenbankziel wie einer Amazon RDS-Instance oder einem Aurora-Cluster zu verwenden. Dies funktioniert in den meisten Szenarien gut, hält die Konfiguration einfach und macht das Kundenerlebnis vorhersehbarer. Im Vergleich dazu müssen Sie bei der Verwendung mehrerer Proxys die Konfiguration sorgfältig auf alle Proxys abstimmen, um unerwartetes Verhalten zu vermeiden. Sie müssen beispielsweise sicherstellen, dass die Gesamtgröße aller Proxypools die Verbindungslimits des einzelnen Datenbankziels nicht überschreitet.

Möglicherweise erwägen Sie immer noch die Idee, in bestimmten Situationen mehrere Proxys zu verwenden. In den folgenden Abschnitten werden die gängigsten Szenarien erörtert und die Vor- und Nachteile eines einzelnen Proxys im Vergleich zu einem Ansatz mit mehreren Proxys beschrieben.

Verfügbarkeit von Proxys

Die RDS-Proxy-Infrastruktur ist hochverfügbar und wird standardmäßig über mehrere Availability Zones (AZs) bereitgestellt. Die Proxykapazität ist auf viele Knoten verteilt und bietet eine kontinuierliche Zustandsüberwachung. Sie wird automatisch an die bereitgestellte Instanzgröße oder die maximalen ACU-Einstellungen für Serverless v2 Ihrer Datenbank angepasst. Aufgrund des verteilten Multi-AZ Designs des Proxys müssen Sie aus Gründen der Hochverfügbarkeit nicht mehrere Proxys vor Ihren Amazon RDS- oder Aurora-Clustern ausführen.

Tatsächlich bedeutet die Verwendung mehrerer Proxys vor einem einzigen Datenbankziel, dass der Anwendungsstapel nun dafür verantwortlich ist, Probleme zu erkennen und darauf zu reagieren, anstatt sich auf die robusten Mechanismen zu verlassen, die im Proxy integriert sind. Aus Gründen der Hochverfügbarkeit wird daher dringend davon abgeraten, mehrere Proxys zu verwenden, da dadurch wahrscheinlich mehr Probleme entstehen als gelöst werden können.

Umgang mit mehreren Client-Pools

Jeder Proxy bietet einen read/write Endpunkt und (optional) zusätzliche read/write oder schreibgeschützte Endpunkte. Wenn ein einziger Proxy verwendet wird, um mehrere Gruppen von Clients oder mehrere Workloads zu verarbeiten, können sich diese Workloads potenziell gegenseitig beeinflussen. Beispielsweise kann ein Workload den Verbindungspool bis zu dem Punkt monopolisieren, dass nicht mehr genügend freie Verbindungen übrig sind, um andere Workloads zu bewältigen. Die Verwendung separater Proxys zur Isolierung von Workloads könnte eine überzeugende Lösung sein, aber Sie können zunächst andere Optionen in Betracht ziehen:

• Die Datenbank selbst bietet möglicherweise einfachere Alternativen zur Ausführung mehrerer Proxys. Wenn das Problem beispielsweise dadurch verursacht wird, dass bestimmte Benutzer den Pool monopolisieren, könnten Sie das Berechtigungssystem der Datenbank verwenden, um die Anzahl der gleichzeitigen Verbindungen zu begrenzen, die diese Benutzer öffnen dürfen.

• In ähnlicher Weise können Abfrage-Timeouts und Leerlauf-Timeouts auf Datenbankebene Probleme mit verwaisten Verbindungen oder außer Kontrolle geratenen Abfragen beheben.

• Wenn das Problem durch die Abfrage- oder Transaktionsdauer oder den Ressourcenverbrauch pro Abfrage und nicht durch die Anzahl gleichzeitiger Verbindungen verursacht wird, hilft die Verwendung zusätzlicher Proxys nicht, da der Proxy keine Beschränkungen für die Abfrage- oder Transaktionsgewichtung festlegt. Wenn das Problem nicht an der Quelle behoben werden kann, können Sie den Ereignisplaner der Datenbank verwenden, um Code auszuführen, der Client-Aktivitäten anhand willkürlicher Bedingungen erkennt und beendet, anstatt diese problematischen Clients auf einen separaten Proxy zu verschieben.

Wenn Sie sich dafür entscheiden, mehrere Proxys vor demselben Ziel zu verwenden, stellen Sie sicher, dass die Gesamtgröße aller Verbindungspools die Kapazitäten der Zieldatenbank nicht überschreitet. Beispielsweise muss die Summe aller MaxConnectionsPercent Proxys kleiner als 100 sein, andernfalls versuchen die Proxys möglicherweise, mehr Verbindungen zu öffnen, als die Datenbank für die Verarbeitung konfiguriert ist.

Jeder Proxy wird separat in Rechnung gestellt, und der Abrechnungssatz hängt von der Größe der zugrunde liegenden Datenbankressourcen und nicht von der Workload-Aktivität ab. Vergleichen Sie die Kosten für den Betrieb mehrerer Proxys im Vergleich zu den Kosten für die Implementierung alternativer Lösungen, falls es welche gibt.

Unabhängige Steuerung von Lese- und Schreibpools

Jeder Proxy bietet einen read/write Endpunkt und (optional) zusätzliche read/write oder schreibgeschützte Endpunkte. Die Grenzwerte und Timeouts werden jedoch für das gesamte Proxyziel und nicht für jeden Proxyendpunkt einzeln konfiguriert.

Sie haben beispielsweise einen Aurora-Cluster, der eine große Menge an schreibgeschützten Abfragen verarbeitet und dabei mehrere Read Replicas und den Reader-Endpunkt des Proxys verwendet, aber Sie möchten die Anzahl der read/write Verbindungen einschränken, um den Ressourcendruck auf den einzelnen Writer zu verringern. Da die MaxConnectionsPercent Einstellung für das gesamte Proxyziel (Cluster) definiert ist, können Sie die Anzahl der Verbindungen mit dem Endpunkt nicht einschränken, ohne auch die Grenzwerte des schreibgeschützten read/write Endpunkts zu beeinflussen.

Es gibt mehrere Möglichkeiten, diese Herausforderung anzugehen:

Sie können zusätzliche Read Replicas im Cluster starten und die Proxy-Einstellung proportional reduzieren. MaxConnectionsPercent Dadurch bleibt die Gesamtgröße des schreibgeschützten Verbindungspools erhalten und gleichzeitig wird die maximale Anzahl der auf dem Writer zulässigen Verbindungen reduziert. Dies erhöht jedoch auch die Clusterkosten und ist zunehmend weniger effektiv, je mehr Replikate Sie haben.

Sie könnten Parametergruppen auf Instanzebene verwenden, um Datenbankverbindungslimits (wie max_connections in Aurora MySQL oder PostgreSQL) für die Read Replicas getrennt vom Writer zu konfigurieren. Sie müssen jedoch die Verwendung einer asymmetrischen Parameterkonfiguration vermeiden, da Replikate während eines Failovers zu einer Autorenrolle heraufgestuft werden können, sodass die anfängliche Parameterdifferenzierung nicht dauerhaft ist. Sie könnten erwägen, die Failover-Prioritätseinstellungen auf Instanzebene zu ändern, um zu beeinflussen, welche Replikate bei Failovers hochgestuft werden, und dies als Mechanismus zum Ausschluss von Soft-Failovers verwenden, um die asymmetrische Konfiguration vorhersehbarer zu machen. Failover-Prioritäten dienen jedoch nur als Hinweise und sind keine Garantie für das Failover-Verhalten. Multi-instance Von Konfigurationen mit asymmetrischen Einstellungen wird daher abgeraten, da sie eine kontinuierliche Überwachung erfordern und zu unerwartetem Verhalten führen können, wenn ein Failover auf einer Instanz landet, die Sie nicht bevorzugen.

In diesem Szenario könnte die Verwendung mehrerer Proxys die sauberste Methode sein, Lese- und Schreibpools getrennt zu verwalten. Sie können zwei Proxys für das einzelne Datenbankziel erstellen und dann Anwendungen so konfigurieren, dass sie den Writer-Endpunkt des ersten Proxys und den schreibgeschützten Endpunkt des zweiten Proxys verwenden. Ein Proxy verarbeitet nur Schreib-Workloads, der andere Proxy verarbeitet nur Lese-Workloads, und die MaxConnectionsPercent (sowie andere Einstellungen) können unabhängig für jeden Proxy konfiguriert werden. Bei dieser Lösung fallen zusätzliche Kosten für den Betrieb des zweiten Proxys an, sie ist jedoch einfacher und vorhersehbarer als die vorherigen Alternativen.