If you want to help people,
keep it simple!

Einfach besser in der Cloud - Datenbanken mit Amazon RDS
Ich betreue einige Projekte, bei denen im Hintergrund relationale Datenbanken laufen. Dabei liegt oft auch die Verantwortung für die Bereitstellung und den Betrieb der notwendigen Datenbank-Systeme in meinen Händen. Was liegt da näher, als einen Teil der daraus folgenden Arbeit abzugeben und Datenbanksysteme zu nutzen, deren Qualität ich selber nur mit unverhältnismäßig hohem Aufwand erreichen könnte.

Was sind die Nachteile selbstverwalteter Datenbanksystemen?

Was stört mich am Betrieb selbst verwalteter Datenbanksystemen? Hauptsächlich mein eigener Qualitätsanspruch: Ich möchte nicht, dass eine Anwendung Fehlermeldungen liefert, weil das Datenbank-Backend Probleme bereitet. Ich erwarte zum einen also eine möglichst hohe Verfügbarkeit. Zum anderen gibt es die meist schwammigen Aussagen zu den künftigen Lastanforderungen an das neue System. Dann hat man später entweder Probleme oder man startet gleich mit einem überdimensionierten System. Dazu kommt dann noch das konsistente Sichern der Daten und das regelmäßige Patchen der Systeme.

Ich gebe zu: die genannten Punkte lassen sich jeder einzeln für sich sicher und zufriedenstellend lösen. So habe ich das jahrelang selber gelebt. Aber muss ich mir die Arbeit wirklich selber machen? Kann ich meine Energie nicht viel besser in die bereitzustellende Anwendung stecken, als in die Administration der Datenbanken im Hintergrund der Systeme?

Weniger Arbeit und bessere Datenbanken durch die Cloud

Aus meiner Sicht bieten in der Cloud gehostete Datenbanken entscheidende Vorteile: In den Bereichen Verfügbarkeit, Skalierbarkeit, erreichbare Performance, Sicherheit und Backup werden da Qualitäten erreicht, die ich selber nur mit unverhältnismäßig hohem Aufwand (finanziell und administrativ) erreichen könnte.

Amazon bietet in seinem AWS Portfolio mit Amazon RDS einen für meine Einsatzzwecke nahezu perfekt zugeschnittenen Service an.
Aktuell kann man bei Amazon RDS zwischen fünf Datenbank-Engines wählen:

  • MySQL
  • PostgreSQL
  • Oracle
  • Microsoft SQL-Server
  • Amazon Aurora (im Preview)

Während sich die ersten vier Varianten vor allem für eine einfache Migration bestehender Anwendungen eignen, verspricht Amazon für das selbst entwickelte Aurora "eine bis zu fünfmal höhere Leistung als MySQL zu einem Preis von nur einem Zehntel eines kommerziellen RDBMS, aber mit ähnlicher Leistung und Verfügbarkeit."

Die Vorteile von Amazon RDS

Welche Vorteile bietet der Einsatz von Amazon RDS im Vergleich zu einer selbstverwalteten Datenbank?
  • sehr schnelle Bereitstellung und einfache Administration
    Neue Datenbanken sind innerhalb von Minuten einsatzbereit. Die Administration der Instanzen erfolgt entweder per Web-Frontend oder per Kommandozeilen-Toolkit.
  • hohe Verfügbarkeit
    Die in Amazon RDS erstellten Datenbanken lassen sich als sogenannte "Multi-AZ" Instanzen clustern. Dabei werden replizierende Datenbank-Instanzen auf voneinander unabhängigen Infrastrukturen ("Availablity-Zones") verteilt, so dass die Datenbanken selbst beim Ausfall eines Amazon Rechenzentrums noch funktionsfähig sind. Amazon verspricht für solche Installationen eine Uptime von 99,95%.
  • nahezu unbegrenzte Skalierbarkeit
    Datenbanken lassen sich bei Amazon RDS jederzeit einfach und schnell an sich ändernde Lastanforderungen anpassen: Zum einen können die zugrunde liegenden Server-Instanzen (EC2 Instanzen) in Ihrer RAM und CPU-Austattung angepasst werden. Zum anderen können bestehende Installationen um sogenannte "Read Replicas" erweitert werden, wodurch sich Lesezugriffe auf die Datenbank auf verschiedene Server-Instanzen verteilen lassen. Read-Replicas sind allerdings ausschließlich für MySQL, PostgreSQL und Amazon Aurora verfügbar.
  • einfaches integriertes Backup und Desaster-Recovery
    Backups werden über automatisierte Snapshots realisiert, die ihrerseits jederzeit als Grundlage für  neue Datenbank-Instanzen dienen können.
  • automatisches Einspielen von Sicherheitspatches und Fehlerbehebungen
    Sicherheits-Paches oder Fehlerbehebungen werden vom AWS-Team automatisiert eingespielt. Dafür bietet Amazon zwei verschiedene Möglichkeiten an: Bei nicht geclusterten Datenbanken wird die Datenbank in einem vorher definierten Wartungsfenster gepatcht (z.B. Montags 01:00-1:30). Bei Multi-AZ Bereitstellungen werden die Cluster-Knoten nacheinander aktualisiert, so dass aus Anwendungssicht keine Downtime erkennbar ist.
  • Kosten: Pay as you go - auch für Lizenzem
    Wie bei AWS üblich, fallen nur für die direkte Nutzung der RDS-Ressourcen Kosten an. Das gilt für Server-Ressourcen (EC2-Instanzen), Plattenplatz (Datenbank und Backups) und Datentransfer sowie für die Lizenzen. Wenn eine Datenbank vorübergehend nicht benötigt wird, kann die betreffende Instanzen komplett deaktiviert werden. Eine spätere Wiederinbetriebnahme erfolgt dann innerhalb von Minuten auf Grundlage eines vorher erstellten Snapshots.

Beispiel: Bereitstellung einer MySQL-Datenbank mit Amazon RDS

Wie genau funktioniert jetzt das Erzeugen und Nutzen einer Datenbank mit Amazon RDS? Am einfachsten über die AWS-Webkonsole. Unter Services -> Database findet Ihr dort der Punkt RDS. Ein Klick auf "Get Started Now" startet den Wizard für die Konfiguration einer neuen Datenbank-Instanz.

Auswahl der Datenbank-Engine

Am Anfang steht die die Auswahl der Datenbank-Engine. Bei der Wahl von MS SQL Server oder Oracle sind in einem folgendem Schritt noch Details zur gewünschten (Lizenz-) Version auszugeben. Bei Oracle "Standard Edition One", "Standard Edition" oder "Enterprise", bei MS SQL Server entsprechend "SQL Server Express" bzw. die Web-  Standard -oder Enterprise-Edition. Für das Beispiel hier verwende ich MySQL.
Auswahl der Datenbank-Engine

Produktiv oder Test

Im Schritt 2 fragt Euch der Wizard, ob die zu erstellende Datenbank-Instanz für den Produktiveinsatz oder nur zu Testzwecken verwendet werden soll. Als Resultat werden dann die Default-Einstellungen für das Multi-AZ Deployment (Datenbank-Cluster) oder den zu verwendenden Plattenspeicher initialisiert.

Production oder Test?

Wer sich hier nicht sicher ist, verwendet die Voreinstellungen für Testumgebungen. Ein späteres Anpassen dieser Konfigurationen ist später jederzeit möglich.

Konfiguration der Datenbank-Details

Ab hier wird es interessant. Zunächst wird die genaue Version der zu verwendenden Datenbank-Engine ausgewählt. Das ist vor allem dann nützlich, wenn eine bestehende Anwendung zu Amazon RDS migriert werden soll und Abhängigkeiten zu einer bestimmten Datenbank-Version zu beachten sind. Für lizenzpflichtige Datenbankversionen (Oracle, SQL-Server) gibt es unter "Licence Model" die Möglichkeit anzugeben, dass bereits gekaufte eigene Lizenzen für die Datenbank-Instanz verwendet werden sollen.

Auswahl der DB-Version

Performance Tuning

Anschließend konfiguriert Ihr die gewünschte Performance für die neue Datenbank-Instanz. Da die Datenbank-Instanzen auf gewöhnlichen EC2-Instanzen ausgeführt werden, findet Ihr unter "DB Instance Class" die gewohnten EC2 Instanz-Typen. Beim Multi-AZ Deployment werden durch den Wizard dann zwei EC2 Instanzen der gewählten Konfiguration gestartet.

Konfiguration der Performance
Beim Storage-Typ habt Ihr die Wahl zwischen "normalen" Magnetfestplatten, SSDs und SSDs mit konfigurierbaren I/O-Anforderungen. Die "General Purpose (SSD)" sollte für kleinere Datenbanken vollkommen ausreichend sein - zumal solche Datenbanken oft sowieso komplett aus dem RAM der EC2-Instanz bedient werden.

Anders sieht es bei größeren Datenbanken oder Anwendungen mit hohen Latenzanforderungen aus. Hier müsst Ihr Euch überlegen, ob die "General Purpose (SSD)" genügend Durchsatz liefert. AWS garantiert hier 3 IOPS je provisioniertem GB und generell eine kurzfristige Leistung (Burst) von 3000 IOPS. Wenn Ihr Eure Datenbank also mit einem 10 GB Storage ausstattet, liefert euch AWS eine Dauerleistung mit 30 IOPS mit 3000 IOPS Maximalleistung.

Aber auch hier gilt: Ein späteres Anpassen dieser Parameter ist jederzeit möglich. Einzige Ausnahme: Das Verkleinern des bereitgestellten Speichers ist nicht möglich.

Zugangsdaten

Im letzten Punkt des Dialogs gebt Ihr Eurer Datenbank-Instanz einen Namen und konfiguriert die Zugangsdaten.

Instanz-Name und Zugangsdaten

Der letzte Schritt: Absicherung, Backup und Patches

Der vierte Schritt des Konfigurations-Wizards bietet Euch die Möglichkeit, die Netzwerkzugehörigkeit der Datenbank sowie angepasste Firewall-Regeln zu konfigurieren. 

Einstellungen zur Sicherheit

Die Standard-Einstellungen verbinden Eure neue Datenbank in Euer Default-Netzwerk bei AWS und erlaubten den Zugriff auf die Datenbank von der IP-Adresse aus, von der Ihr den Konfigurations-Wizard gestartet habt. Wenn Ihr später Zugriff von einem anderen System erlauben wollt, müsst Ihr das neu erzeugte Security-Profile über die AWS-Konsole anpassen und die passenden IP-Adressen nachtragen. In meiner Umgebung existiert schon eine passende Security-Group, die Zugriff von wichtigen Systemen aus erlaubt.

Einstellungen zur Netzwerksicherheit
Wenn Amazon RDS zum Start eine neue leere Datenbank auf Eurer Datenbank-Instanz erzeugen soll, könnt Ihr den betreffenden Datenbank-Namen angeben. Alternativ erzeugt Ihr die Datenbank dann beim Erzeugen bzw. Importieren Eurer Daten mit den passenden SQL-Statements. Eine Verschlüsselung der kompletten Datenbank-Instanz kann auch angefordert werden:

Angabe des Ports und Einschalten der Veschlüsselung

Backups

Backups werden von Amazon RDS per Snapshot durchgeführt. Diese Snapshots finden täglich statt, und Ihr könnt festlegen, wie lange Eure Snapshots aufgehoben werden sollen. Mit dem optionalen Backup-Fenster legt Ihr zudem fest, zu welchem Zeitpunkt des Tages die Snapshots erzeugt werden sollen. Wenn Ihr z.B. wisst, dass die meisten Änderungen in Eurer Datenbank tagsüber erfolgen, macht eine Sicherung am späten Abend oder in den frühen Morgenstunden sicherlich Sinn:

Backupzeiten können vorgegeben werden

Snapshots, die einmal erzeugt worden sind, existieren losgelöst von der originalen Datenbank-Instanz. Ihr könnt also jederzeit Eure Datenbank-Instanzen löschen, ohne die Backups zu verlieren. Außerdem könnt Ihr jederzeit aus einem vorhandenen Snapshot eine neue Datenbank-Instanz erzeugen.

Wenn die täglichen Snapshots für Euren Anwendungsfall nicht ausreichend sind, lassen sich später über die Webconsole oder die AWS-Kommandozeilentools weitere Snapshots erzeugen.

Automatisches Einspielen von Patches

Für Eure Datenbank könnt Ihr festlegen, dass Minor-Version-Upgrades (also in der Regel Sicherheitspatches und Bugfixes) automatisiert eingespielt werden sollen. Für eine geclusterte Datenbank-Instanz (Multi-AZ Bereitstellung) passiert das komplett ohne erkennbare Downtime der Datenbank: Die Patches werden auf dem Standby-Knoten eingespielt, die Rollen werden getauscht und dann ist der zweite Knoten dran.

Besteht Eure Datenbank nur aus einem Knoten, gebt Ihr auch hier am besten ein Wartungsfenster vor, zu dem eine kurze Downtime der Datenbank am ehesten zu verschmerzen ist:

Das Patchen erfolgt während des Wartungsfensters

Test der neuen Datenbank

Nach eine Klick auf "Launch DB Instance" werden die notwendingen virtuellen Maschinen erzeugt und mit der geforderten Datenbank-Konfiguration versehen. Abschließend gibt es noch einen initialen Snapshot, und danach ist die neue Datenbank wie gewohnt nutzbar. Angesprochen wird die Datenbank über den Endpoint-Namen, der in der Instanz-Übersicht angegeben wird. Für meine Beispieldatenbank heißt der Endpoint z.B. "events.cdv6sqv5eeby.eu-west-1.rds.amazonaws.com". 

Um die Datenbank zu testen, migriere ich eine bestehende Datenbank zu Amazon RDS:


Und was kostet das ganze?

Die Gesamtkosten für eine Amazon RDS - Instanz hängen von einigen Faktoren ab. Angefangen von der Ausstattung der Virtuellen Maschinen, über die Art und Menge des genutzten SSD-Speichers, über die Region, in der die Datenbank gehostet werden soll, die Art der Cluster-Konfiguration bist hin zur Möglichkeit, für Oracle und MS SQL-Server eigene Lizenzen mitzubringen. Außerdem spielt z.B. beim MS-SQL Server zusätzlich noch die Lizenz-Edition eine entscheidende Rolle (Express, Web, Standard).

Als Anhaltspunkte habe ich die Minimalkonfiguration von MySQL, Oracle und MS SQL-Server Express zusammengesucht:

Inklusive eventuell benötigter Lizenzen lassen sich MySQL-Instanzen für unter 10,- / Monat realisieren, MS-SQL Server Express ist geringfügig teurer aber immer noch für unter 10,- / Monat möglich. Eine Oracle-Instanz  lässt sich ab knapp 20,- im Monat realisieren. (Stand März 2015)

Genaue und aktuelle Informationen zu den RDS-Preisen findet Ihr unter Amazon RDS Preisgestaltung oder im AWS Pricing Calculator.

Fazit

Das Hosten einer Datenbank in der AWS-Cloud ist mit relativ wenig Aufwand zu realisieren. Die erreichbare Verfügbarkeit und Performance gibt es zu moderaten Kosten in einer Qualität, für die bei einem eigenen Hosting ein weitaus größerer finanzieller und administrativer Aufwand notwendig wäre. Backup und Desaster-Recovery ist integriert und die Ausstattung der Instanzen kann jederzeit an sich ändernde Anforderungen angepasst werden.

Gegen die Nutzung von Amazon-RDS sprechen aus meiner Sicht eigentlich nur Bedenken bezüglich der etwas höheren Netzwerk-Latenz zwischen einer Anwendung im eigenen Rechenzentrum und einer Datenbank in der Cloud. Ob dadurch die eigene Anwendung negativ beeinflusst wird, lässt sich nur durch Tests ermitteln. Mögliche Auswirkungen lassen sich teilweise durch geschicktes Caching in der Anwendung minimieren, oder Ihr zieht Eure Anwendung auch gleich mit in die Cloud um. Was soll da schon dagegen sprechen? :-)