Clouds sind wie eine Zauberkiste – man fragt, was man braucht, und die Ressourcen erscheinen einfach aus dem Nichts. Virtuelle Maschinen, Datenbanken, Netzwerk – all das gehört nur Ihnen. Es gibt andere Cloud-Mieter, aber in Ihrem Universum sind Sie der alleinige Herrscher. Sie sind sicher, dass Sie immer die benötigten Ressourcen erhalten, nehmen auf niemanden Rücksicht und bestimmen selbstständig, wie das Netzwerk aussehen soll. Wie funktioniert diese Magie, die dafür sorgt, dass die Cloud Ressourcen elastisch zuweist und die Mandanten vollständig voneinander isoliert?
Die AWS-Cloud ist ein mega-superkomplexes System, das sich seit 2006 evolutionär weiterentwickelt. Ein Teil dieser Entwicklung fand statt Wassili Pantjuchin - Amazon Web Services-Architekt. Als Architekt erhält er nicht nur einen Einblick in das Endergebnis, sondern auch in die Herausforderungen, die AWS meistert. Je besser das Verständnis über die Funktionsweise des Systems ist, desto größer ist das Vertrauen. Daher wird Vasily die Geheimnisse der AWS-Cloud-Dienste teilen. Nachfolgend finden Sie das Design physischer AWS-Server, die Skalierbarkeit elastischer Datenbanken, eine benutzerdefinierte Amazon-Datenbank und Methoden zur Steigerung der Leistung virtueller Maschinen bei gleichzeitiger Reduzierung ihres Preises. Wenn Sie die Architekturansätze von Amazon kennen, können Sie AWS-Services effektiver nutzen und erhalten möglicherweise neue Ideen für die Entwicklung Ihrer eigenen Lösungen.
Über den Redner: Vasily Pantyukhin () begann als Unix-Administrator bei .ru-Unternehmen, arbeitete sechs Jahre lang an großer Sun Microsystem-Hardware und predigte 6 Jahre lang eine datenzentrierte Welt bei EMC. Es entwickelte sich natürlich zu privaten Clouds und wurde 11 zu öffentlichen Clouds verlagert. Jetzt bietet er technische Ratschläge, um das Leben und die Entwicklung in der AWS-Cloud zu unterstützen.
Haftungsausschluss: Alles Folgende ist Vasilys persönliche Meinung und stimmt möglicherweise nicht mit der Position von Amazon Web Services überein. Der dem Artikel zugrunde liegende Bericht ist auf unserem YouTube-Kanal verfügbar.
Warum spreche ich vom Amazon-Gerät?
Mein erstes Auto hatte ein Schaltgetriebe. Es war großartig, weil ich das Gefühl hatte, das Auto fahren zu können und die volle Kontrolle darüber zu haben. Mir gefiel auch, dass ich das Funktionsprinzip zumindest grob verstanden habe. Natürlich habe ich mir den Aufbau der Box recht primitiv vorgestellt – so etwas wie ein Getriebe bei einem Fahrrad.
Alles war großartig, bis auf eine Sache: Ich stand im Stau. Es kommt einem so vor, als würde man sitzen und nichts tun, aber man wechselt ständig die Gänge, drückt die Kupplung, das Gas, die Bremse – das macht einen wirklich müde. Das Stauproblem wurde teilweise gelöst, als die Familie ein Automatikauto bekam. Während der Fahrt hatte ich Zeit, über etwas nachzudenken und mir ein Hörbuch anzuhören.
Ein weiteres Rätsel tauchte in meinem Leben auf, weil ich völlig aufgehört hatte zu verstehen, wie mein Auto funktioniert. Ein modernes Auto ist ein komplexes Gerät. Das Auto passt sich gleichzeitig an Dutzende verschiedener Parameter an: Gasdruck, Bremse, Fahrstil, Straßenqualität. Ich verstehe nicht mehr, wie es funktioniert.
Als ich anfing, an der Amazon-Cloud zu arbeiten, war es auch für mich ein Rätsel. Nur ist dieses Rätsel um eine Größenordnung größer, denn im Auto sitzt ein einziger Fahrer, und in AWS gibt es Millionen davon. Alle Nutzer lenken, geben Gas und bremsen gleichzeitig. Es ist erstaunlich, dass sie dorthin gehen, wohin sie wollen – für mich ist es ein Wunder! Das System passt sich jedem Benutzer automatisch an, skaliert und passt sich elastisch an, sodass es für ihn so aussieht, als wäre er allein in diesem Universum.
Der Zauber ließ etwas nach, als ich später als Architekt bei Amazon arbeitete. Ich habe gesehen, mit welchen Problemen wir konfrontiert sind, wie wir sie lösen und wie wir Dienstleistungen entwickeln. Mit zunehmendem Verständnis der Funktionsweise des Systems wächst das Vertrauen in den Dienst. Deshalb möchte ich ein Bild davon teilen, was sich unter der Haube der AWS-Cloud verbirgt.
Worüber sollen wir reden
Ich habe mich für einen abwechslungsreichen Ansatz entschieden – ich habe 4 interessante Dienstleistungen ausgewählt, über die es sich zu sprechen lohnt.
Serveroptimierung. Flüchtige Wolken mit einer physischen Verkörperung: physische Rechenzentren, in denen es physische Server gibt, die summen, sich erwärmen und mit Lichtern blinken.
Serverlose Funktionen (Lambda) ist wahrscheinlich der am besten skalierbare Dienst in der Cloud.
Datenbankskalierung. Ich erzähle Ihnen, wie wir unsere eigenen skalierbaren Datenbanken aufbauen.
Netzwerkskalierung. Der letzte Teil, in dem ich das Gerät unseres Netzwerks öffnen werde. Das ist eine wunderbare Sache – jeder Cloud-Benutzer glaubt, dass er allein in der Cloud ist und andere Mieter überhaupt nicht sieht.
Notiz. In diesem Artikel werden Serveroptimierung und Datenbankskalierung erläutert. Wir werden uns im nächsten Artikel mit der Netzwerkskalierung befassen. Wo sind die serverlosen Funktionen? Über sie wurde ein separates Transkript veröffentlicht „" Es geht um verschiedene Skalierungsmethoden und ausführlich um die Firecracker-Lösung – eine Symbiose der besten Eigenschaften einer virtuellen Maschine und von Containern.
Server
Die Wolke ist vergänglich. Aber diese Vergänglichkeit hat immer noch eine physische Verkörperung – Server. Ursprünglich war ihre Architektur klassisch. Standard-x86-Chipsatz, Netzwerkkarten, Linux, Xen-Hypervisor, auf dem virtuelle Maschinen gestartet wurden.
Im Jahr 2012 hat diese Architektur ihre Aufgaben recht gut gemeistert. Xen ist ein großartiger Hypervisor, hat aber einen großen Nachteil. Er hat genug hoher Overhead für die Geräteemulation. Wenn neue, schnellere Netzwerkkarten oder SSD-Laufwerke verfügbar werden, wird dieser Overhead zu hoch. Wie geht man mit diesem Problem um? Wir haben beschlossen, an zwei Fronten gleichzeitig zu arbeiten – Optimieren Sie sowohl Hardware als auch Hypervisor. Die Aufgabe ist sehr ernst.
Optimierung von Hardware und Hypervisor
Alles auf einmal zu machen und es gut zu machen, wird nicht funktionieren. Auch was „gut“ ist, war zunächst unklar.
Wir haben uns für einen evolutionären Ansatz entschieden – wir ändern ein wichtiges Element der Architektur und bringen es in die Produktion.
Wir treten auf jede Rechenfläche, nehmen Beschwerden und Anregungen entgegen. Dann ändern wir eine weitere Komponente. Daher ändern wir in kleinen Schritten die gesamte Architektur radikal, basierend auf dem Feedback von Benutzern und dem Support.
Die Transformation begann 2013 mit der komplexesten Sache – dem Netzwerk. IN С3 In einigen Fällen wurde der Standard-Netzwerkkarte eine spezielle Netzwerkbeschleunigerkarte hinzugefügt. Der Anschluss erfolgte buchstäblich mit einem kurzen Loopback-Kabel an der Frontplatte. Es ist nicht schön, aber in der Cloud ist es nicht sichtbar. Aber die direkte Interaktion mit der Hardware verbesserte den Jitter und den Netzwerkdurchsatz grundlegend.
Als nächstes haben wir beschlossen, den Zugriff auf den Blockdatenspeicher EBS – Elastic Block Storage – zu verbessern. Es ist eine Kombination aus Netzwerk und Speicher. Die Schwierigkeit besteht darin, dass es zwar Netzwerkbeschleunigerkarten auf dem Markt gab, es jedoch keine Möglichkeit gab, einfach Speicherbeschleuniger-Hardware zu kaufen. Also wandten wir uns an ein Startup Annapurna Labs, der für uns spezielle ASIC-Chips entwickelt hat. Sie ermöglichten die Bereitstellung entfernter EBS-Volumes als NVMe-Geräte.
In Fällen C4 Wir haben zwei Probleme gelöst. Erstens haben wir eine Grundlage für die Zukunft der vielversprechenden, aber damals neuen NVMe-Technologie geschaffen. Zweitens haben wir den zentralen Prozessor erheblich entlastet, indem wir die Bearbeitung von Anfragen an EBS auf eine neue Karte übertragen haben. Es hat gut geklappt, sodass Annapurna Labs nun Teil von Amazon ist.
Im November 2017 wurde uns klar, dass es an der Zeit war, den Hypervisor selbst zu ändern.
Der neue Hypervisor wurde auf Basis modifizierter KVM-Kernelmodule entwickelt.
Dadurch war es möglich, den Aufwand der Geräteemulation grundlegend zu reduzieren und direkt mit neuen ASICs zu arbeiten. Instanzen С5 waren die ersten virtuellen Maschinen mit einem neuen Hypervisor unter der Haube. Wir haben ihn benannt Nitro.
Entwicklung der Instanzen auf der Zeitachse.
Auf diesem Hypervisor laufen alle neuen Typen virtueller Maschinen, die seit November 2017 erschienen sind. Bare-Metal-Instanzen verfügen nicht über einen Hypervisor, werden aber auch Nitro genannt, da sie spezielle Nitro-Karten verwenden.
In den nächsten zwei Jahren überstieg die Anzahl der Arten von Nitro-Instanzen ein paar Dutzend: A1, C5, M5, T3 und andere.
Instanztypen.
So funktionieren moderne Nitro-Maschinen
Sie bestehen aus drei Hauptkomponenten: dem Nitro-Hypervisor (siehe oben), dem Sicherheitschip und den Nitro-Karten.
Sicherheitschip direkt in das Mainboard integriert. Es steuert viele wichtige Funktionen, beispielsweise die Steuerung des Ladens des Host-Betriebssystems.
Nitro-Karten - Es gibt vier Arten davon. Sie alle werden von Annapurna Labs entwickelt und basieren auf gängigen ASICs. Ein Teil ihrer Firmware ist ebenfalls üblich.
Vier Arten von Nitrokarten.
Eine der Karten ist für die Arbeit konzipiert NetzwerkVPC. Dies ist das, was in virtuellen Maschinen als Netzwerkkarte sichtbar ist ENA – Elastischer Netzwerkadapter. Es kapselt auch den Datenverkehr bei der Übertragung über ein physisches Netzwerk (wir werden darüber im zweiten Teil des Artikels sprechen), steuert die Firewall der Sicherheitsgruppen und ist für das Routing und andere Netzwerkfunktionen verantwortlich.
Ausgewählte Karten funktionieren mit Blockspeicher EBS und Festplatten, die in den Server integriert sind. Sie erscheinen der virtuellen Gastmaschine als NVMe-Adapter. Sie sind auch für die Datenverschlüsselung und die Festplattenüberwachung verantwortlich.
Das System aus Nitrokarten, Hypervisor und Sicherheitschip wird in ein SDN-Netzwerk integriert bzw Softwaredefiniertes Netzwerk. Verantwortlich für die Verwaltung dieses Netzwerks (Kontrollebene) Controller-Karte.
Selbstverständlich entwickeln wir auch weiterhin neue ASICs. Ende 2018 brachten sie beispielsweise den Inferentia-Chip auf den Markt, der es Ihnen ermöglicht, effizienter mit maschinellen Lernaufgaben zu arbeiten.
Inferentia Machine Learning-Prozessorchip.
Skalierbare Datenbank
Eine herkömmliche Datenbank hat eine mehrschichtige Struktur. Der Vereinfachung halber werden folgende Ebenen unterschieden.
- SQL — Client- und Request-Dispatcher arbeiten daran.
- Bestimmungen Transaktionen - Hier ist alles klar, ACID und so.
- Caching, die von Pufferpools bereitgestellt wird.
- Protokollierung – ermöglicht die Arbeit mit Redo-Logs. In MySQL heißen sie Bin Logs, in PosgreSQL - Write Ahead Logs (WAL).
- Lagerung – direkte Aufnahme auf Festplatte.
Mehrschichtige Datenbankstruktur.
Es gibt verschiedene Möglichkeiten, Datenbanken zu skalieren: Sharding, Shared Nothing-Architektur, Shared Disks.
Alle diese Methoden behalten jedoch dieselbe monolithische Datenbankstruktur bei. Dies schränkt die Skalierung erheblich ein. Um dieses Problem zu lösen, haben wir unsere eigene Datenbank entwickelt − Amazonas-Aurora. Es ist mit MySQL und PostgreSQL kompatibel.
Amazonas-Aurora
Die Hauptidee der Architektur besteht darin, die Speicher- und Protokollierungsebenen von der Hauptdatenbank zu trennen.
Mit Blick auf die Zukunft werde ich sagen, dass wir auch die Caching-Ebene unabhängig gemacht haben. Die Architektur ist kein Monolith mehr und wir gewinnen zusätzliche Freiheitsgrade bei der Skalierung einzelner Blöcke.
Die Protokollierungs- und Speicherebenen sind von der Datenbank getrennt.
Ein herkömmliches DBMS schreibt Daten in Form von Blöcken in ein Speichersystem. Bei Amazon Aurora haben wir einen intelligenten Speicher entwickelt, der Sprache sprechen kann Redo-Logs. Im Inneren wandelt der Speicher Protokolle in Datenblöcke um, überwacht deren Integrität und erstellt automatisch Backups.
Mit diesem Ansatz können Sie so interessante Dinge umsetzen wie Klonen. Es arbeitet wesentlich schneller und wirtschaftlicher, da keine vollständige Kopie aller Daten erstellt werden muss.
Die Speicherschicht ist als verteiltes System implementiert. Es besteht aus einer sehr großen Anzahl physischer Server. Jedes Redo-Log wird gleichzeitig verarbeitet und gespeichert sechs Knoten. Dies gewährleistet Datenschutz und Lastverteilung.
Eine Leseskalierung kann mithilfe geeigneter Replikate erreicht werden. Durch den verteilten Speicher entfällt die Notwendigkeit einer Synchronisierung zwischen der Hauptdatenbankinstanz, über die wir Daten schreiben, und den verbleibenden Replikaten. Es ist garantiert, dass allen Replikaten aktuelle Daten zur Verfügung stehen.
Das einzige Problem besteht darin, alte Daten auf Read Replicas zwischenzuspeichern. Aber dieses Problem wird gelöst Übertragung aller Redo-Logs zu Replikaten über das interne Netzwerk. Befindet sich das Protokoll im Cache, wird es als fehlerhaft markiert und überschrieben. Wenn es nicht im Cache ist, wird es einfach verworfen.
Wir haben die Lagerung geklärt.
So skalieren Sie DBMS-Ebenen
Hier ist die horizontale Skalierung deutlich schwieriger. Gehen wir also die ausgetretenen Pfade entlang klassische vertikale Skalierung.
Nehmen wir an, wir haben eine Anwendung, die über einen Masterknoten mit dem DBMS kommuniziert.
Bei der vertikalen Skalierung weisen wir einen neuen Knoten zu, der über mehr Prozessoren und Speicher verfügt.
Als nächstes stellen wir die Anwendung vom alten Masterknoten auf den neuen um. Probleme entstehen.
- Dies erfordert erhebliche Ausfallzeiten der Anwendung.
- Der neue Masterknoten verfügt über einen Cold-Cache. Die Datenbankleistung ist erst dann maximal, wenn der Cache aufgewärmt ist.
Wie kann die Situation verbessert werden? Richten Sie einen Proxy zwischen der Anwendung und dem Masterknoten ein.
Was bringt uns das? Jetzt müssen nicht alle Anwendungen manuell auf den neuen Knoten umgeleitet werden. Der Wechsel kann unter einem Proxy erfolgen und ist grundsätzlich schneller.
Es scheint, dass das Problem gelöst wurde. Aber nein, wir leiden immer noch unter der Notwendigkeit, den Cache aufzuwärmen. Darüber hinaus ist ein neues Problem aufgetreten – nun ist der Proxy ein potenzieller Fehlerpunkt.
Endgültige Lösung mit Amazon Aurora serverlos
Wie haben wir diese Probleme gelöst?
Einen Proxy hinterlassen. Hierbei handelt es sich nicht um eine separate Instanz, sondern um eine ganze verteilte Flotte von Proxys, über die Anwendungen eine Verbindung zur Datenbank herstellen. Im Falle eines Ausfalls kann jeder Knoten nahezu sofort ausgetauscht werden.
Ein Pool warmer Knoten unterschiedlicher Größe hinzugefügt. Wenn daher ein neuer Knoten größerer oder kleinerer Größe zugewiesen werden muss, steht dieser sofort zur Verfügung. Sie müssen nicht warten, bis es geladen ist.
Der gesamte Skalierungsprozess wird durch ein spezielles Überwachungssystem gesteuert. Die Überwachung überwacht ständig den Zustand des aktuellen Masterknotens. Wenn beispielsweise festgestellt wird, dass die Prozessorauslastung einen kritischen Wert erreicht hat, benachrichtigt es den Pool warmer Instanzen über die Notwendigkeit, einen neuen Knoten zuzuweisen.
Verteilte Proxys, warme Instanzen und Überwachung.
Ein Knoten mit der erforderlichen Leistung ist verfügbar. Pufferpools werden dorthin kopiert und das System beginnt, auf einen sicheren Moment für den Wechsel zu warten.
Normalerweise kommt der Moment zum Wechseln recht schnell. Dann wird die Kommunikation zwischen dem Proxy und dem alten Masterknoten ausgesetzt, alle Sitzungen werden auf den neuen Knoten umgeschaltet.
Die Arbeit mit der Datenbank wird fortgesetzt.
Die Grafik zeigt, dass die Federung tatsächlich sehr kurz ist. Das blaue Diagramm zeigt die Belastung und die roten Stufen zeigen die Skalierungsmomente. Kurzfristige Einbrüche im blauen Diagramm sind genau diese kurze Verzögerung.
Mit Amazon Aurora können Sie übrigens völlig Geld sparen und die Datenbank ausschalten, wenn sie beispielsweise am Wochenende nicht verwendet wird. Nach dem Stoppen der Last reduziert die DB schrittweise ihre Leistung und schaltet sich für einige Zeit ab. Wenn die Last zurückkehrt, steigt sie wieder sanft an.
Im nächsten Teil der Geschichte über das Amazon-Gerät sprechen wir über die Netzwerkskalierung. Abonnieren und bleiben Sie dran, damit Sie den Artikel nicht verpassen.
Auf Vasily Pantyukhin wird einen Bericht halten „" Welche Designmuster für verteilte Systeme von Amazon-Entwicklern verwendet werden, was sind die Gründe für Dienstausfälle, was ist Cell-basierte Architektur, Constant Work, Shuffle Sharding – es wird interessant sein. Weniger als einen Monat bis zur Konferenz – . Endgültige Preiserhöhung am 24. Oktober.
Source: habr.com