Wolken sind wie eine magische Kiste - Sie fragen, was Sie brauchen, und Ressourcen erscheinen einfach aus dem Nichts. Virtuelle Maschinen, Datenbanken, ein Netzwerk - all das gehört nur Ihnen. Es gibt andere Mieter der Wolke, aber in Ihrem Universum sind Sie der alleinige Herrscher. Sie sind sicher, dass Sie immer die erforderlichen Ressourcen erhalten, Sie rechnen mit niemandem und bestimmen unabhängig, wie das Netzwerk aussehen wird. Wie ist diese Magie, die die Cloud dazu bringt, Ressourcen elastisch zuzuweisen und Mandanten vollständig voneinander zu isolieren?
AWS Cloud ist ein hochentwickeltes System, das sich seit 2006 weiterentwickelt hat. Ein Teil dieser Entwicklung wurde von
Vasily Pantyukhin , Architekt von Amazon Web Services, gefunden. Als Architekt sieht er nicht nur das Endergebnis, sondern auch die Herausforderungen, die AWS bewältigt. Je besser das System verstanden wird, desto mehr Vertrauen entsteht. Daher wird Vasily die Geheimnisse der AWS-Cloud-Services weitergeben. Unter dem Schnitt sind das Gerät für physische AWS-Server, die flexible Skalierbarkeit der Datenbank, die benutzerdefinierte Datenbank von Amazon und Methoden zur Steigerung der Leistung virtueller Maschinen bei gleichzeitiger Senkung des Preises. Wenn Sie die Architekturansätze von Amazon kennen, können Sie die AWS-Services besser nutzen und neue Ideen für die Erstellung eigener Lösungen liefern.
Über den Sprecher: Vasily Pantyukhin ( Hen ) begann als Unix-Administrator in.ru-Unternehmen, arbeitete 6 Jahre lang in großen Sun Microsystem-Drüsen und predigte 11 Jahre lang die Datenzentriertheit der Welt in EMC. Natürlich zu privaten Clouds entwickelt und 2017 zu öffentlichen Clouds. Jetzt mit technischen Tipps hilft er, in der AWS-Cloud zu leben und sich zu entwickeln.
Haftungsausschluss: Alles, was unten steht, ist Vasilys persönliche Meinung und stimmt möglicherweise nicht mit der Position von Amazon Web Services überein. Ein Video des Berichts, auf dessen Grundlage der Artikel erstellt wurde, ist auf unserem YouTube-Kanal verfügbar.Warum spreche ich über ein Amazon-Gerät?
Mein erstes Auto hatte einen „Griff“ - an einem Schaltgetriebe. Es war großartig, weil ich das Gefühl hatte, die Maschine steuern und vollständig steuern zu können. Mir hat auch gefallen, dass ich das Prinzip ihrer Arbeit zumindest grob verstehe. Natürlich habe ich mir das Boxgerät ganz primitiv vorgestellt - ungefähr wie ein Getriebe auf einem Fahrrad.
Alles war wunderbar, bis auf eine Sache - im Stau stehen. Es scheint, als ob Sie sitzen und nichts tun, aber Sie schalten ständig die Gänge, drücken die Kupplung, das Gas, die Bremse - Sie werden es wirklich leid. Das Problem der Staus wurde teilweise gelöst, als eine Maschine auf der Maschine in der Familie erschien. Am Steuer war Zeit, über etwas nachzudenken und ein Hörbuch zu hören.
In meinem Leben tauchte ein Rätsel auf, weil ich im Allgemeinen nicht mehr verstand, wie mein Auto funktioniert. Ein modernes Auto ist ein komplexes Gerät. Das Auto passt sich gleichzeitig Dutzenden verschiedener Parameter an: Drücken des Gases, Bremse, Fahrstil, Straßenqualität. Ich verstehe nicht mehr, wie das funktioniert.
Als ich anfing, Amazon Cloud zu machen, war mir das auch ein Rätsel. Nur dieses Geheimnis ist um eine Größenordnung höher, weil sich ein Fahrer im Auto befindet und es Millionen in AWS gibt. Alle Benutzer lenken gleichzeitig, drücken auf Gas und bremsen. Es ist erstaunlich, dass sie gehen, wo sie wollen - für mich ist es ein Wunder! Das System passt sich automatisch an jeden Benutzer an, skaliert ihn und passt ihn flexibel an, sodass er den Eindruck hat, dass er allein in diesem Universum ist.
Die Magie löste sich ein wenig auf, als ich später als Architekt bei Amazon arbeitete. Ich habe gesehen, mit welchen Problemen wir konfrontiert sind, wie wir sie lösen, wie wir Dienstleistungen entwickeln. Mit zunehmendem Verständnis des Systems steigt das Vertrauen in den Service. Daher möchte ich ein Bild davon teilen, was sich unter der Haube der AWS-Cloud befindet.
Worüber werden wir reden?
Ich habe mich für einen diversifizierten Ansatz entschieden - ich habe 4 interessante Dienste ausgewählt, über die es sich zu sprechen lohnt.
Serveroptimierung . Vergängliche Wolken mit einer physischen Ausführungsform: physische Rechenzentren, in denen physische Server summen, sich erwärmen und Glühbirnen blinken.
Serverlose Funktionen (Lambda) sind wahrscheinlich der skalierbarste Dienst in der Cloud.
Datenbankskalierung . Ich werde darüber sprechen, wie wir unsere eigenen skalierbaren Datenbanken erstellen.
Netzwerkskalierung . Der letzte Teil, in dem ich das Gerät unseres Netzwerks öffnen werde. Dies ist eine wunderbare Sache - jeder Benutzer der Cloud glaubt, dass er alleine in der Cloud ist und überhaupt keine anderen Mieter sieht.
Hinweis Dieser Artikel konzentriert sich auf die Serveroptimierung und die Datenbankskalierung. Die Netzwerkskalierung wird im nächsten Artikel erläutert. Wo sind die serverlosen Funktionen? Ein separates Protokoll kam über sie heraus: „ Mal, ja, gewagt. Anboxing von Firecracker-Mikrovirtualen . " Es werden verschiedene Skalierungsmethoden beschrieben und die Firecracker-Lösung wird detailliert analysiert - 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. Anfangs war ihre Architektur klassisch. Standard x86-Chipsatz, Netzwerkkarten, Linux, Xen-Hypervisor, auf dem virtuelle Maschinen ausgeführt werden.
Im Jahr 2012 hat eine solche Architektur ihre Arbeit gut gemacht. Xen ist ein großartiger Hypervisor, aber mit einem großen Fehler. Er hat einen ziemlich
hohen Overhead für das Emulieren von Geräten . Mit dem Aufkommen neuer schnellerer Netzwerkkarten oder SSDs werden diese Overheads zu hoch. Wie gehe ich mit diesem Problem um? Wir haben uns entschlossen, an zwei Fronten gleichzeitig zu arbeiten -
um sowohl die Hardware als auch den Hypervisor zu
optimieren . Die Aufgabe ist sehr ernst.
Optimierung von Eisen und Hypervisor
Alles auf einmal und gut zu machen wird nicht funktionieren. Was „gut“ ist, war zunächst unverständlich.
Wir haben uns für einen evolutionären Ansatz entschieden - wir ändern ein wichtiges Element der Architektur und werfen es in die Produktion.
Wir treten auf alle Rechen, hören auf Beschwerden und Vorschläge. Dann ändern wir eine andere Komponente. Daher ändern wir in kleinen Schritten die gesamte Architektur radikal, basierend auf dem Feedback und der Unterstützung der Benutzer.
Die Transformation begann 2013 mit dem Schwierigsten - dem Netzwerk. In
C3- Fällen wurde der Standard-Netzwerkkarte eine spezielle Network Accelerator-Karte hinzugefügt. Es wurde mit einem buchstäblich kurzen Loopback-Kabel an der Frontplatte verbunden. Hässlich, aber in der Wolke nicht sichtbar. Die direkte Interaktion mit der Hardware verbesserte jedoch die Jitter- und Netzwerkbandbreite grundlegend.
Dann haben wir beschlossen, uns auf die Verbesserung des Zugriffs auf den EBS-Blockspeicher zu konzentrieren - Elastic Block Storage. Dies ist eine Kombination aus Netzwerk und Speicher. Die Schwierigkeit besteht darin, dass es keine Möglichkeit gab, Storage Accelerator-Hardware zu kaufen, wenn es auf dem Markt Network Accelerator-Karten gab. Deshalb haben wir uns an das Startup
Annapurna Labs gewandt, das spezielle ASIC-Chips für uns entwickelt hat. Sie konnten Remote-EBS-Volumes als NVMe-Geräte verbinden.
In
C4- Fällen haben wir zwei Probleme gelöst. Zunächst haben wir die Grundlagen für die Zukunft mit vielversprechender, aber zu dieser Zeit neuer NVMe-Technologie umgesetzt. Die zweite - entlastete den Zentralprozessor erheblich, indem die Verarbeitung von Anforderungen an EBS auf eine neue Karte übertragen wurde. Es hat sich als gut herausgestellt, und jetzt ist Annapurna Labs Teil von Amazon.
Bis November 2017 wurde uns klar, dass es Zeit war, den Hypervisor selbst zu ändern.
Der neue Hypervisor wurde auf Basis modifizierter KVM-Kernelmodule entwickelt.
Dadurch konnten die Overhead-Kosten für die Emulation von Geräten grundlegend gesenkt und direkt mit den neuen ASICs gearbeitet werden.
C5- Instanzen waren die ersten virtuellen Maschinen, unter deren Haube ein neuer Hypervisor ausgeführt wird. Wir haben es
Nitro genannt .
Die Entwicklung der Instanzen auf der Zeitachse.Alle neuen Arten von virtuellen Maschinen, die seit November 2017 erscheinen, funktionieren auf diesem Hypervisor.
Iron Bare Metal-Instanzen haben keinen Hypervisor , werden aber auch als Nitro bezeichnet, da sie spezielle Nitro-Karten verwenden.
In den nächsten zwei Jahren überstieg die Anzahl der Arten von Nitro-Instanzen einige Dutzend: A1, C5, M5, T3 und andere.
Arten von Instanzen.Wie moderne Nitroautos funktionieren
Sie bestehen aus drei Hauptkomponenten: einem Nitro-Hypervisor (siehe oben), einem Sicherheitschip und Nitro-Karten.
Der Sicherheitschip ist direkt in das Motherboard integriert. Es steuert viele wichtige Funktionen, z. B. das Laden des Host-Betriebssystems.
Nitro-Karten - es gibt vier Arten von ihnen. 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 funktioniert mit
einem VPC- Netzwerk . Sie ist in
virtuellen Maschinen als
ENA- Netzwerkkarte
- Elastic Network Adapter - sichtbar. Es kapselt auch Datenverkehr, wenn er über das physische Netzwerk übertragen wird (wir werden im zweiten Teil des Artikels darauf eingehen), steuert die Firewall der Sicherheitsgruppen, ist für das Routing und andere Netzwerkaufgaben verantwortlich.
Separate Karten funktionieren mit
EBS- Blockspeicher und Festplatten, die in den Server integriert sind. Sie werden virtuellen
Gastmaschinen als
NVMe-Adapter präsentiert . Sie sind auch für die Datenverschlüsselung und die Festplattenüberwachung verantwortlich.
Das System aus Nitro-Karten, einem Hypervisor und einem Sicherheitschip ist in ein SDN oder
Software Defined Network integriert . Die Steuerkarte ist für die Verwaltung dieses Netzwerks verantwortlich (Steuerungsebene).
Natürlich entwickeln wir weiterhin neue ASICs. Zum Beispiel haben sie Ende 2018 den Inferentia-Chip veröffentlicht, der eine effizientere Arbeit mit maschinellen Lernaufgaben ermöglicht.
Inferentia-Prozessorchip für maschinelles Lernen.Skalierbare Datenbank
Die traditionelle Datenbank hat eine Schichtstruktur. Wenn stark vereinfacht, werden die folgenden Ebenen unterschieden.
- SQL - Client und Query Dispatcher arbeiten daran.
- Transaktionen sichern - hier ist alles klar, ACID und so weiter.
- Zwischenspeicherung durch Pufferpools.
- Protokollierung - Ermöglicht die Arbeit mit Redo-Protokollen. In MySQL heißen sie Bin Logs, in PosgreSQL Write Ahead Logs (WAL).
- Speicher - direkt auf die Festplatte schreiben.
Schichtdatenbankstruktur.Es gibt verschiedene Möglichkeiten, Datenbanken zu skalieren: Sharding, Shared Nothing-Architektur, Shared Drive.
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 -
Amazon Aurora . Es ist kompatibel mit MySQL und PostgreSQL.
Amazon Aurora
Die Hauptidee der Architektur besteht darin, die Speicher- und Protokollierungsebenen von der Hauptdatenbank zu trennen.
Mit Blick auf die Zukunft möchte ich sagen, dass wir auch die Cache-Ebene unabhängig gemacht haben. Architektur hört auf, ein Monolith zu sein, und wir erhalten zusätzliche Freiheitsgrade bei der Skalierung einzelner Blöcke.
Protokollierungs- und Speicherebenen sind von der Datenbank getrennt.Ein herkömmliches DBMS schreibt Daten in Form von Blöcken in das Speichersystem. Bei Amazon Aurora haben wir ein „intelligentes“ Repository erstellt, das die Sprache von
Redo-Logs sprechen kann. Im Inneren wandelt das Repository Protokolle in Datenblöcke um, überwacht deren Integrität und sichert automatisch.
Mit diesem Ansatz können Sie interessante Dinge wie das
Klonen implementieren. Es funktioniert grundlegend schneller und wirtschaftlicher, da nicht alle Daten vollständig erstellt werden müssen.
Die Speicherebene ist als verteiltes System implementiert. Es besteht aus einer sehr großen Anzahl physischer Server. Jedes Redo-Log wird gleichzeitig von
sechs Knoten verarbeitet und gespeichert. Dies bietet Datenschutz und Lastausgleich.
Die Leseskalierung kann mit geeigneten Replikaten erreicht werden. Durch verteilten Speicher entfällt die Notwendigkeit einer Synchronisierung zwischen der Haupt-DB-Instanz, über die Daten geschrieben werden, und anderen Replikaten. Aktuelle Daten sind garantiert für alle Replikate verfügbar.
Das einzige Problem ist das Zwischenspeichern alter Daten in Lesereplikaten. Dieses Problem wird jedoch gelöst, indem
alle Redo-Logs auf Replikate im internen Netzwerk übertragen werden. Befindet sich das Protokoll im Cache, wird es als ungültig markiert und überschrieben. Wenn es sich nicht im Cache befindet, wird es einfach verworfen.
Wir haben den Speicher herausgefunden.
So skalieren Sie DBMS-Ebenen
Hier ist die horizontale Skalierung viel schwieriger. Lassen Sie uns daher den ausgetretenen Pfaden der
klassischen vertikalen Skalierung folgen .
Angenommen, wir haben eine Anwendung, die über einen Masterknoten mit einem DBMS kommuniziert.
Bei der vertikalen Skalierung wählen wir einen neuen Knoten mit mehr Prozessoren und Speicher aus.
Wechseln Sie als Nächstes die Anwendung vom alten Masterknoten zum neuen. Es gibt Probleme.
- Dies erfordert eine spürbare Ausfallzeit der Anwendung.
- Der neue Masterknoten verfügt über einen kalten Cache. Die Datenbankleistung ist erst nach dem Aufwärmen des Caches maximal.
Wie kann man die Situation verbessern? Fügen Sie einen Proxy zwischen der Anwendung und dem Masterknoten ein.
Was wird es uns geben? Jetzt müssen nicht mehr alle Anwendungen manuell auf einen neuen Knoten umgeleitet werden. Das Umschalten kann unter einem Proxy und gleichzeitig wesentlich schneller erfolgen.
Das Problem scheint gelöst zu sein. Aber nein, wir leiden immer noch unter der Notwendigkeit, den Cache aufzuwärmen. Außerdem ist ein neues Problem aufgetreten - jetzt ist der Proxy ein potenzieller Fehlerpunkt.
Endlösung mit Amazon Aurora Serverless
Wie haben wir diese Probleme gelöst?
Hat einen Proxy hinterlassen . Dies ist keine separate Instanz, sondern eine ganze verteilte Flotte von Proxys, über die Anwendungen eine Verbindung zur Datenbank herstellen. Im Falle eines Fehlers kann jeder der Knoten fast sofort ersetzt werden.
Wir haben einen Pool warmer Knoten verschiedener Größen hinzugefügt . Wenn Sie einen neuen Knoten mit einer größeren oder kleineren Größe auswählen müssen, ist dieser sofort verfügbar. Sie müssen nicht warten, bis es geladen ist.
Der gesamte Skalierungsprozess wird von einem speziellen Überwachungssystem gesteuert. Die Überwachung überwacht ständig den Status des aktuellen Masterknotens. Wenn beispielsweise festgestellt wird, dass die Prozessorlast einen kritischen Wert erreicht hat, benachrichtigt es den Pool warmer Instanzen über die Notwendigkeit, einen neuen Knoten zuzuweisen.
Verteilte Proxys, Warminstanzen und Überwachung.Ein Knoten mit der erforderlichen Leistung ist verfügbar. Pufferpools werden darauf kopiert, und das System beginnt, auf einen sicheren Moment zum Umschalten zu warten.
Normalerweise kommt der Moment zum Umschalten schnell genug. Dann wird die Kommunikation zwischen dem Proxy und dem alten Masterknoten unterbrochen, alle Sitzungen wechseln zum neuen Knoten.
Die Arbeit mit der Datenbank wird fortgesetzt.
Die Grafik zeigt, dass die Federung wirklich sehr kurz ist. Auf dem blauen Diagramm die Last und auf den roten Stufen - die Momente der Skalierung. Kurzfristige Einbrüche im blauen Diagramm sind genau diese kurze Verzögerung.
Mit Amazon Aurora können Sie die Datenbank übrigens vollständig speichern und deaktivieren, wenn Sie sie beispielsweise am Wochenende nicht verwenden. Nach dem Stoppen des Ladevorgangs verringert die Datenbank allmählich ihre Leistung und schaltet sich für eine Weile aus. Wenn die Last zurückkehrt, steigt sie wieder gleichmäßig an.
Im nächsten Teil des Amazon-Gerätegesprächs werden wir uns mit der Netzwerkskalierung befassen. Abonnieren Sie den Newsletter und bleiben Sie auf dem Laufenden , um den Artikel nicht zu verpassen.
Bei HighLoad ++ wird Vasily Pantyukhin einen Vortrag halten: „ Houston, wir haben ein Problem. Design von Fehlersystemen, Muster für die Entwicklung interner Amazon Cloud-Dienste . “ Was Amazon-Designentwickler für verteilte Systemdesignmuster verwenden, was sind die Gründe für Servicefehler, was ist zellbasierte Architektur, konstante Arbeit, Shuffle Sharding - es wird interessant sein. Weniger als einen Monat vor der Konferenz - buchen Sie Ihre Tickets . 24. Oktober die endgültige Preiserhöhung.