Planen des Verwendungsortes von RDS-Proxy - Amazon Relational Database Service

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.

Planen des Verwendungsortes von RDS-Proxy

Sie können ermitteln, welche Ihrer DB-Instances, Cluster und Anwendungen möglicherweise am meisten von der Verwendung von RDS Proxy profitieren. Berücksichtigen Sie dazu folgende Faktoren:

  • Alle DB-Instances, auf denen gelegentlich der Fehler „zu viele Verbindungen“ auftritt, sind gut geeignet für die Zuordnung zu einem Proxy. Dies ist oft durch einen hohen Wert der -ConnectionAttempts CloudWatch Metrik gekennzeichnet. Der Proxy ermöglicht es Anwendungen, viele Clientverbindungen zu öffnen, während der Proxy eine geringere Anzahl langlebiger Verbindungen mit der DB-Instance  verwaltet.

  • Bei DB-Instance, die kleinere AWS Instance-Klassen wie T2 oder T3 verwenden, kann die Verwendung eines Proxys dazu beitragen, out-of-memory Bedingungen zu vermeiden. Sie kann auch dazu beitragen, den CPU-Overhead für das Herstellen von Verbindungen zu reduzieren. Diese Bedingungen können auftreten, wenn es um eine große Anzahl von Verbindungen geht.

  • Sie können bestimmte Amazon- CloudWatch Metriken überwachen, um festzustellen, ob sich eine DB-Instanceein DB- bestimmten Arten von Grenzwerten nähert. Diese Grenzwerte gelten für die Anzahl der Verbindungen und den Arbeitsspeicher, der mit der Verbindungsverwaltung verbunden ist. Sie können auch bestimmte CloudWatch Metriken überwachen, um festzustellen, ob eine DB-Instance ein DB- viele kurzlebige Verbindungen verarbeitet. Das Öffnen und Beenden solcher Verbindungen kann einen Leistungs-Overhead für Ihre Datenbank verursachen. Informationen zu den zu überwachenden Metriken finden Sie unter Überwachen von RDS-Proxy-Metriken mit Amazon CloudWatch.

  • AWS Lambda-Funktionen können auch gute Kandidaten für die Verwendung eines Proxys sein. Diese Funktionen stellen häufig kurze Datenbankverbindungen her, die von dem von RDS Proxy angebotenen Verbindungspooling profitieren. Sie können alle IAM-Authentifizierungen nutzen, die Sie bereits für Lambda-Funktionen haben, anstatt Datenbankanmeldeinformationen im Lambda-Anwendungscode zu verwalten.

  • Anwendungen, die in der Regel eine große Anzahl von Datenbankverbindungen öffnen und schließen und über keine integrierten Mechanismen für das Verbindungspooling verfügen, bieten sich für die Verwendung eines Proxys an.

  • Anwendungen, die eine große Anzahl von Verbindungen über lange Zeiträume offen halten, sind in der Regel gute Kandidaten für die Verwendung eines Proxys. Anwendungen in Branchen wie Software as a Service (SaaS) oder E-Commerce minimieren häufig die Latenz für Datenbankanfragen, da sie Verbindungen offen lassen. Mit RDS Proxy kann eine Anwendung mehr Verbindungen offen halten als möglich, wenn eine direkte Verbindung mit der DB-Instancedem DB hergestellt wird.

  • Möglicherweise haben Sie die IAM-Authentifizierung und Secrets Manager aufgrund der Komplexität der Einrichtung einer solchen Authentifizierung für alle DB-Instances nicht übernommen. Wenn dies der Fall ist, können Sie die vorhandenen Authentifizierungsmethoden beibehalten und die Authentifizierung an einen Proxy delegieren. Der Proxy kann die Authentifizierungsrichtlinien für Clientverbindungen für bestimmte Anwendungen erzwingen. Sie können alle IAM-Authentifizierungen nutzen, die Sie bereits für Lambda-Funktionen haben, anstatt Datenbankanmeldeinformationen im Lambda-Anwendungscode zu verwalten.

  • RDS-Proxy kann dazu beitragen, Anwendungen widerstandsfähiger und transparenter gegenüber Datenbankausfällen zu machen. RDS-Proxy umgeht Domain Name System (DNS)-Caches, um die Failover-Zeiten für Multi-AZ-DB-Instances von Amazon RDS um bis zu 66 % zu reduzieren. RDS-Proxy leitet den Datenverkehr außerdem automatisch an eine neue Datenbank-Instance weiter, wobei Anwendungsverbindungen erhalten bleiben. Dadurch werden Failovers für Anwendungen transparenter.