Ganz ohne Ausfall wird die Umstellung des Datastore verständlicherweise nicht sein. Entwickler die App Engine nutzen finden die geplanten Umstellungszeiten am Ende des Artikels.

Als Open Source Software kann der Quelltext jederzeit eingesehen und angepasst werden. Zum Zugriff sollen verschiedene Bibliotheken angeboten werden. Zur Zeit ist lediglich eine für C verfügbar. Laut Dokumentation sind allerdings weitere für Python, PHP und Java geplant. Interessierte können aber sicher mithelfen. Stichwort Open Source.

Neben der Möglichkeit über ein eigenes Protokoll auf die Datenbank zuzugreifen, gibt es auch die Möglichkeit alle Funktionen über HTTP aufzurufen. Was allerdings auf Grund des Overheads nur für die Entwicklung empfohlen wird. Hier allerdings, kann es durchaus Vorteile haben mal eben per Webbrowser in die Datenbank “gucken” zu können.

Das Bild rechts zeigt die Vorteile auf einen Blick. Neben der konsistenten Replikation, der Hochverfügbarkeit und Fehlertoleranz möchte Keyspace insbesondere durch hohe Performance und den einfachen Upgradepfad überzeugen.

Wie sich Keyspace im Vergleich mit anderen Key-Value Datenbanken schlägt muss sich noch zeigen. Vom Ansatz her wirkt das ganze aber sehr interessant.

Gegründet wurde Scalien, das Startup hinter Keyspace von Marton Trencseni und Attila Gazso. Marton bloggt unter Bytepawn.com.

Man kann übersichtlich neue Musik der Künstler mit denen man innerhalb des Dienstes verbunden ist hören, man kann eigene Musik an andere senden und Soundcloud bietet zusätzlich noch einen Player um die eigene Musik in andere Seiten einzubinden und dort anhörbar zu machen. Die Versandfunktion will das versenden von großen Dateien erleichtern. Selbst ausprobiert habe ich den Dienst nicht. Bin aber auch wahrlich kein Musiker.

Warum ich jetzt über Soundcloud schreibe ist dieser Blogpost. Bei Soundcloud kam es im Zuge eines zur Behebung von Geschwindigkeitsproblemen ohnehin geplanten Serverumzuges zu einem Fehler mit den Festplatten des Datenbankservers. Dadurch ging die Seite offline und weil man sich gerade im Umzug befand blieb sie dies auch bis der Umzug abgeschlossen war. Für geschlagene zwölf Stunden.

Solche Vorfälle passieren immer wieder. Ob jetzt menschliches Versagen oder einfach Pech die Ursache dafür waren ist eigentlich nebensächlich. Fakt  ist, sowas darf nicht passieren wenn man ein Unternehmen aufbauen will.

Das Problem, die Skalierung der eigenen Plattform mit den Anforderungen ist schon tausendmal gelöst worden. Doch trotzdem muss es jedes Startup für sich selbst neu lösen. Warum? Weil die Hostingunternehmen nicht in der Lage sind funktionierende Lösungen zu schaffen um dieses Problem zu lösen.

Man ruht sich lieber auf seinen Lorbeeren aus und übertrifft sich gegenseitig mit Absenz jeglicher Innovation.

Das Problem, gerade für Startups, dabei ist, dass man vorher nicht sagen kann welche der Daten sich gut zum sharding eignen, wo es sich lohnt und wenn nach welchem Muster man die Daten aufteilt. Ausserdem macht es häufig keinen Sinn Probleme zu lösen, die man noch nicht hat. Die wenigsten Startups haben direkt vom Start weg Performanceprobleme.

Wer an einem eigenen Webprojekt arbeitet sollte sich deshalb unbedingt den Artikel Sharding for Startups auf Lessons learned durchlesen. In ausführlichster Form wird dort erklärt wie man ohne nicht vorhandene Probleme zu lösen trotzdem darauf vorbereitet sein kann.

via Highscalability

Zu Beginn nimmt sich der Artikel dabei die Zeit einige Begriffe zu erklären. Besonders hervorzuheben ist dabei die wichtige Unterscheidung zwischen Geschwindigkeit (Performance) und Skalierbarkeit. Der Unterschied ist nämlich, dass es bei Geschwindigkeit darum geht wie schnell ein System eine einzelne Anfrage beantworten kann, wohingegen Skalierbarkeit sich auf die Qualität des Systems unter Last bezieht.

Der Artikel will dabei die Frage beantworten, wieso unterteilen wir unsere Daten und wie hilft uns diese Unterteilung die Skalierbarkeit sicherzustellen. Dazu wirft der Autor zuersteinmal einen Blick auf verschiedene Anwendungszenarien an Hand derer man dann die beste Shardingstrategie für die eigenen Daten ableiten können soll. Die verschiedenen Szenarien gehen allerdings alle von bereits bestehenden Datensets aus. Wenn man noch garnicht genau weiss, wie die eigenen Daten aussehen werden helfen einem die Beispiele erstmal auch nicht übermässig. Gerade was Datum- bzw. Zeitabhängige Unterteilung angeht, denn diese ist nur dann sinnvoll, wenn die Datensätze auch gleichmässig über die Zeit verteilt sind. Dies wird allerdings nur bei den wenigsten Anwendungsszenarien von vorneherein absehbar sein. Auf dieses Problem geht der Artikel allerdings ebenfalls ein und widmet sich in einem eigenen Abschnitt der später vielleicht notwendig gewordenen Neuverteilung.

Im Anschluss beschäftigt sich der Artikel zusätzlich noch mit der Frage, wie das beschriebene System noch zusätzlich Hochverfügbar gemacht werden kann.

Hier gehts lang!

Das größte Problem bei EC2 Instanzen bisher bestand darin, dass es keine Datenpersistenz gab. Das bedeutet, alle während der Laufzeit einer Instanz geänderten Daten die auf die Festplatte dieser Instanz geschrieben wurden waren verloren wenn die Instanz beendet wurde.

Wie jedem sofort einleuchten wird, ist dies natürlich ein großes Problem, wenn sich eine Maschine auf Grund irgendeines Fehlers während der Laufzeit verabschiedet. Normale Server fährt man wieder hoch und dank der Innovation bei den Journaling-Dateisystemen der letzten zehn Jahre kommt es nur sehr selten zu Datenverlusten. EC2 Instanzen hingegen kann man nicht wieder hoch fahren. Das Prinzip der Wolke ist ja gerade, dass man nur virtuelle Maschinen hat. Es kann einem also egal sein auf welcher physischen Hardware man tatsächlich landet. Weil nach mir höchstwahrscheinlich jemand anderes auf der Maschine landet, ist es sogar in meinem Interesse, dass die Daten nicht auf der Platte bleiben.

Nun stellte die fehlende Persistenz Unternehmen vor 2 Probleme. Das eine Problem ist noch relativ leicht zu verkraften. Während der Laufzeit installierte Software, Sicherheitsupdates oder Konfigurationsänderungen wurden eben auch nicht übernommen. Jedesmal wenn das Image neu gestartet wurde hatte es wieder genau den Stand in dem man es bei S3 abgelegt hatte. Was im übrigen auch Vorteile hat. Man startet dadurch jede neue Instanz in einem genau vorhersehbaren Zustand. Lösungen für dieses Problem gab es zwei, entweder man lud nach seinen Änderungen jedesmal ein neues Image auf den S3 Speicherdienst hoch oder man speicherte die Änderung in kleinen inkrementellen Archiven ab. Diese wurden dann nach dem Start des Image nacheinander eingespielt und enthielten die nötigen Änderungen.

Wirklich problematisch ist, bzw. jetzt war, die fehlende Persistenz bei Datenbankservern. Wenn man nämlich seine komplette Infrastruktur innerhalb von Amazons EC2 betreiben wollte, hatte man immer das Problem, dass man seine Datenbankserver redundant und am besten nochmal irgendwo ausserhalb von EC2 vorhalten musste. Sonst wären nämlich alle Daten in der Datenbank seit dem letzten Backup beim beenden der Instanz verloren gewesen. Sobald eine Webapplikation die Datenbank aber ein bisschen intensiver nutzt als das 0815 Katzencontentblog sind häufige Backups ein echtes Problem.

EBS zur Rettung

EBS steht für Elastic Block Store und ist quasi eine Festplattenwolke. EBS ist ein Blockspeicher, der von jeder EC2 Instanz aus gemountet werden kann. Daten die auf EBS gespeichert sind, sind somit auch von jeder EC2 Instanz aus zu erreichen.

Details wie das ganze technisch umgesetzt ist und wie das ganze genutzt werden kann werde ich in Kürze nachliefern. Dazu möchte ich mir zwecks Recherche ein weniger mehr Zeit nehmen. Jetzt nur so viel, bereits der erste Blick auf die Möglichkeiten von EBS hat mir ein Lächeln ins Gesicht getrieben.

Abgerechnet wird EBS jedenfalls wie alle Amazon Web Services nach tatsächlicher Nutzung.

Ausblick

Mir persönlich fällt damit nur noch ein wirklicher Kritikpunkt bezüglich der Amazon Web Services ein. Es gibt keine SLAs (Service Level Agreements). D.h. Amazon garantiert nicht, dass man innerhalb einer bestimmten Zeit neue Maschinen bekommt. Sei es weil die eine ausgefallen oder man wegen eines Lastanstiegs mehr braucht.

Wer also sehr knapp kalkuliert und das werden junge Startups und Hobbyadmins, die EC2 als Ersatz für einen einzelnen Dedicated Server nutzen möchten, tun, hat ein Problem. Sobald man eine größere Anzahl EC2 Maschinen gleichzeitig nutzt spielt das ganze eine untergeordnete Rolle. Ob jetzt von meinen 3000 Instanzen 3 ausgefallen sind und ich die nächsten Stunden mit 2997 auskommen muss sollte den meisten Admins keine wirklichen Kopfschmerzen bereiten.

Fazit

Alles in allem ist EBS genau der Service der den Amazon Web Services noch gefehlt hat. Genau wie Markus auf Netzwertig.com bin auch ich hellauf begeistert von dieser Neuigkeit. Markus kreidet noch an, dass ein einfaches Benutzerinterface bisher fehlt. Aber wie er auch direkt prognostiziert werden wir da in Zukunft sicher noch einiges sehen. Wenn es nach mir geht in sehr naher Zukunft! Aber mehr kann ich dazu, zum jetzigen Zeitpunkt noch nicht verraten.