Wie AWS seine elastischen Dienste "zaubert". Skalierung von Servern und Datenbanken

Clouds sind wie eine magische Box – du gibst an, was du brauchst, und die Ressourcen erscheinen einfach aus dem Nichts. Virtuelle Maschinen, Datenbanken, Netzwerke – all das gehört nur dir. Es gibt auch andere Tenant im Cloud, aber in deinem Universum bist du der alleinige Herrscher. Du kannst dir sicher sein, dass du immer die benötigten Ressourcen erhältst, ohne Rücksicht auf andere, und entscheidest selbst, wie das Netzwerk aussehen soll. Wie funktioniert diese Magie, die es der Cloud ermöglicht, Ressourcen elastisch bereitzustellen und die Tenants vollständig voneinander zu isolieren?

Die AWS-Cloud ist ein megakomplexes System, das sich seit 2006 evolutionär weiterentwickelt. Ein Teil dieser Entwicklung hat Wassili Pantjuchin — Architekt von Amazon Web Services. Als Architekt sieht er nicht nur das Endergebnis, sondern auch die Herausforderungen, die AWS bewältigen muss. Je mehr Verständnis für das System besteht, desto höher ist das Vertrauen. Daher wird Wladimir die Geheimnisse der AWS-Cloud-Services mit Ihnen teilen. Im Detail erfahren Sie, wie die physikalischen Server von AWS aufgebaut sind, welche elastische Skalierbarkeit die Datenbanken bieten, welche maßgeschneiderte Amazon-Datenbanken existieren und wie die Leistung virtueller Maschinen gesteigert und gleichzeitig die Kosten gesenkt werden können. Kenntnisse über die Architekturansätze von Amazon helfen dabei, die AWS-Services effizienter zu nutzen und möglicherweise neue Ideen für eigene Lösungen zu entwickeln.

Über den Referenten: Wladimir Pantyuchin (Hen) begann als Unix-Administrator in .ru-Unternehmen, arbeitete 6 Jahre mit großen Geräten von Sun Microsystems und setzte sich 11 Jahre lang für die Datenzentrierung bei EMC ein. Natürlich entwickelte er sich zu Private Clouds weiter und wandte sich 2017 den Public Clouds zu. Heute gibt er technische Ratschläge, um im AWS-Cloud-Umfeld zu leben und sich weiterzuentwickeln.

Haftungsausschluss: Alles, was unten steht, ist die persönliche Meinung von Wladimir und könnte von der Position von Amazon Web Services abweichen. Die Videoaufzeichnung des Vortrags, auf dessen Grundlage dieser Artikel erstellt wurde, ist auf unserem YouTube-Kanal verfügbar.

Warum spreche ich über das Amazon-Gerät

Mein erstes Auto hatte eine "Schaltung" – mit einem manuellen Getriebe. Das war großartig, weil ich das Gefühl hatte, dass ich das Auto steuern und vollständig kontrollieren kann. Außerdem gefiel mir, dass ich zumindest ungefähr verstehe, wie es funktioniert. Natürlich stellte ich mir die Funktionsweise des Getriebes ziemlich primitiv vor – etwa wie das einer Fahrradschaltung.

Alles war wunderbar, bis auf eines – das Stehen in Staus. Man sitzt da und macht nichts, aber wechselt ständig die Gänge, drückt die Kupplung, das Gas, die Bremse – das strengt wirklich an. Das Problem mit den Staus wurde teilweise gelöst, als wir ein Auto mit Automatikgetriebe bekamen. Am Steuer hatte ich Zeit, über etwas nachzudenken oder ein Hörbuch zu hören.

Ein weiteres Rätsel trat in mein Leben, denn ich verstand überhaupt nicht mehr, wie mein Auto funktioniert. Ein modernes Fahrzeug ist ein komplexes Gerät. Es passt sich gleichzeitig an Dutzende von verschiedenen Parametern an: Gas- und Bremsbetätigung, Fahrstil, Straßenqualität. Ich verstehe nicht mehr, wie das funktioniert.

Als ich begann, mich mit Amazon Cloud zu beschäftigen, war es auch für mich ein Rätsel. Doch dieses Rätsel ist von viel größerem Umfang, denn im Fahrzeug sitzt ein Fahrer, während es in AWS Millionen gibt. Alle Nutzer steuern gleichzeitig, beschleunigen und bremsen. Es ist faszinierend, dass sie dorthin fahren, wo sie wollen – für mich ist das ein Wunder! Das System passt sich automatisch an, skaliert und passt sich elastisch jedem Nutzer an, sodass es ihm vorkommt, als wäre er der Einzige im Universum.

Die Magie verblasste ein wenig, als ich später als Architekt bei Amazon anfing. Ich sah, mit welchen Herausforderungen wir konfrontiert sind, wie wir sie lösen und wie wir die Dienste weiterentwickeln. Mit wachsendem Verständnis für die Funktionsweise des Systems steigt auch das Vertrauen in den Dienst. Daher möchte ich ein Bild davon zeichnen, was sich unter der Haube der AWS-Cloud verbirgt.

Worüber wir sprechen werden

Ich habe einen diversifizierten Ansatz gewählt – ich habe vier interessante Dienste ausgewählt, über die es sich zu sprechen lohnt.

Serveroptimierung. Ephemere Clouds mit physischer Verankerung: Physische Rechenzentren, in denen physische Server stehen, die summen, Wärme erzeugen und mit Lichtern blinken.

Serverless-Funktionen (Lambda) – wahrscheinlich der skalierbarste Dienst in der Cloud.

Datenbank-Skalierung. Ich werde erläutern, wie wir unsere eigenen skalierbaren Datenbanken aufbauen.

Netzwerkskalierung. Im letzten Teil werde ich die Struktur unseres Netzwerks aufzeigen. Es ist eine großartige Sache – jeder Cloud-Nutzer hat das Gefühl, dass er alleine in der Cloud ist und keine anderen Mandanten sieht.

Hinweis. In diesem Artikel geht es um die Optimierung von Servern und die Skalierung von Datenbanken. Die Netzwerkskalierung werden wir im nächsten Artikel betrachten. Wo bleiben die serverlosen Funktionen? Dazu gibt es eine separate Ausarbeitung „Klein, aber oho. Unboxing der Mikro-Virtualisierung Firecracker“. Darin werden verschiedene Ansätze zur Skalierung vorgestellt, und die Lösung Firecracker wird detailliert behandelt – eine Symbiose aus den besten Eigenschaften von virtuellen Maschinen und Containern.

Server

Die Cloud ist flüchtig. Doch dieser Flüchtigkeit liegt eine physische Grundlage zugrunde – Server. Ursprünglich war deren Architektur klassisch. Ein Standard-x86-Chipsatz, Netzwerkkarten, Linux, ein Hypervisor Xen, auf dem virtuelle Maschinen betrieben wurden.

Im Jahr 2012 erfüllte eine solche Architektur ihre Aufgaben durchaus. Xen ist ein hervorragender Hypervisor, hat aber einen gravierenden Nachteil. Er hat genug hohe Overheadkosten für die Emulation von Geräten. Wenn neue, schnellere Netzwerkkarten oder SSDs erscheinen, werden diese Overheadkosten zu hoch. Wie können wir dieses Problem lösen? Wir haben beschlossen, gleich an zwei Fronten zu arbeiten — sowohl die Hardware als auch den Hypervisor zu optimieren. Das ist eine sehr ernste Herausforderung.

Optimierung von Hardware und Hypervisor

Es wird nicht möglich sein, alles sofort und gut zu machen. Was «gut» ist, war ursprünglich auch unklar.

Wir haben uns entschieden, einen evolutionären Ansatz zu verfolgen — wir ändern ein wichtiges Architekturelement und setzen es sofort in Produktion.

Wir stoßen auf alle möglichen Probleme, hören uns Beschwerden und Vorschläge an. Danach ändern wir eine andere Komponente. So verändern wir die gesamte Architektur schrittweise basierend auf dem Feedback der Benutzer und der Unterstützung.

Die Transformation begann 2013 mit dem Schwierigsten — dem Netzwerk. In den C3 Instanzen haben wir der Standardnetzwerkkarte eine spezielle Network Accelerator-Karte hinzugefügt. Sie wurde buchstäblich mit einem kurzen Loopback-Kabel an der Vorderseite verbunden. Unsichtbar in der Cloud, aber das direkte Zusammenspiel mit der Hardware hat das Jitter und die Netzwerkkapazität erheblich verbessert.

Wir haben uns dann entschieden, den Zugriff auf EBS — Elastic Block Storage zu verbessern. Dies ist eine Kombination aus Netzwerk und Speicher. Die Schwierigkeit bestand darin, dass es zwar Netzwerkbeschleunigerkarten auf dem Markt gab, jedoch keine Möglichkeit bestand, Hardware für Speicherbeschleuniger zu erwerben. Daher wandten wir uns an ein Startup, Annapurna Labs, das für uns spezielle ASIC-Chips entwickelt hat. Diese ermöglichten es, entfernte EBS-Volumes wie NVMe-Geräte anzuschließen.

In den Instanzen C4 haben wir zwei Ziele erreicht. Erstens haben wir eine Basis für die vielversprechende, damals jedoch noch neue NVMe-Technologie geschaffen. Zweitens haben wir die zentrale Verarbeitungseinheit entlastet, indem wir die Verarbeitung der Anfragen an EBS auf die neue Karte verlagert haben. Es war ein voller Erfolg, weshalb Annapurna Labs jetzt Teil von Amazon ist.

Bis November 2017 hatten wir das Gefühl, dass es an der Zeit war, auch den Hypervisor selbst zu wechseln.

Den neuen Hypervisor haben wir auf der Grundlage verbesserter KVM-Kernmodule entwickelt.

Er ermöglichte eine signifikante Reduzierung des Overheads bei der Emulation von Geräten und direkte Interaktion mit den neuen ASICs. Die Instanzen C5 waren die ersten virtuellen Maschinen, die den neuen Hypervisor unter der Haube hatten. Wir haben ihn Nitro.

genannt. Die Evolution der Instanzen auf der Zeitachse.

Alle neuen Typen von virtuellen Maschinen, die seit November 2017 eingeführt wurden, laufen auf diesem Hypervisor. Bare Metal Instanzen haben keinen Hypervisor,werden jedoch ebenfalls als Nitro bezeichnet, da sie spezialisierte Nitro-Karten nutzen.

In den folgenden zwei Jahren hat die Anzahl der Nitro-Instanztypen mehrere Dutzend überschritten: A1, C5, M5, T3 und andere.

Instanztypen.

Wie moderne Nitro-Maschinen aufgebaut sind

Sie bestehen aus drei Hauptkomponenten: dem Nitro-Hypervisor (der bereits erwähnt wurde), einem Sicherheitsschip und den Nitro-Karten.

Das Sicherheitsschip ist direkt auf dem Motherboard integriert. Es überwacht viele wichtige Funktionen, wie die Kontrolle über das Booten des Host-OS.

Nitro-Karten – es gibt vier Typen davon. Alle wurden von Annapurna Labs entwickelt und basieren auf gemeinsamen ASICs. Ein Teil ihrer Firmware ist ebenfalls gemeinsam.

Vier Typen von Nitro-Karten.

Eine der Karten ist für die Arbeit mit dem NetzwerkVPC. Diese wird in den virtuellen Maschinen als Netzwerkkarte angezeigt ENA – Elastic Network Adaptor. Sie kapselt auch den Datenverkehr, wenn er über das physische Netzwerk übertragen wird (darüber sprechen wir im zweiten Teil des Artikels), überwacht die Firewall-Sicherheitsgruppen, ist für das Routing zuständig und kümmert sich um weitere Netzwerkfragen.

Einzelne Karten arbeiten mit Blockspeicher EBS und Festplatten, die in den Server integriert sind. In der virtuellen Umgebung erscheinen sie als NVMe-Adapter. Sie sind auch für die Verschlüsselung von Daten und die Überwachung der Festplatten verantwortlich.

Das Nitro-Kartensystem, der Hypervisor und der Sicherheitschip sind in ein SDN oder Software Defined Networkverbunden. Die Verwaltung dieses Netzwerks (Control Plane) erfolgt durch eine Controller-Karte.

Natürlich arbeiten wir weiterhin an der Entwicklung neuer ASICs. Zum Beispiel haben wir Ende 2018 den Inferentia-Chip veröffentlicht, der die Verarbeitung von Aufgaben im Bereich maschinelles Lernen effizienter gestaltet.

Inferentia Machine Learning Processor-Chip.

Skalierbare Datenbank

Eine traditionelle Datenbank hat eine schichtweise Struktur. Wenn man es stark vereinfacht, ergeben sich folgende Ebenen.

• SQL – darauf laufen Client- und Anfrage-Dispatcher.
• Transaktionssicherung – das ist klar, ACID und so weiter. Caching
• , das durch Pufferpools bereitgestellt wird.– sorgt für die Verarbeitung von Redo-Logs. In MySQL heißen sie Bin Logs, in PostgreSQL – Write Ahead Logs (WAL).
• Protokollierung – direktes Schreiben auf die Festplatte.
• Speicherung Schichtstruktur der Datenbank.

Schichtweise Datenbankstruktur.

Es gibt verschiedene Methoden zur Skalierung von Datenbanken: Sharding, Shared Nothing-Architektur und geteilte Festplatten.

Allerdings behalten all diese Methoden die gleiche monolithische Struktur der Datenbank bei. Das schränkt die Skalierung deutlich ein. Um dieses Problem zu lösen, haben wir unsere eigene Datenbank entwickelt — Amazon Aurora. Sie ist kompatibel mit MySQL und PostgreSQL.

Amazon Aurora

Die grundlegende architektonische Idee besteht darin, die Ebenen für Speicherung und Logging von der Hauptdatenbank zu trennen.

Vorausschickend möchte ich erwähnen, dass wir auch die Caching-Ebene unabhängig gestaltet haben. Die Architektur hört auf, ein Monolith zu sein, und wir gewinnen zusätzliche Freiheitsgrade zur Skalierung einzelner Komponenten.

Die Logging- und Speicherungsebenen sind von der Datenbank getrennt.

Traditionelle DBMS schreiben Daten in der Form von Blöcken auf ein Speichersystem. In Amazon Aurora haben wir ein 'intelligentes' Speichersystem entwickelt, das die Sprache der Redo-Logsversteht. Innerhalb wandelt das Speichersystem Logs in Datenblöcke um, überwacht deren Integrität und sichert sie automatisch.

Dieser Ansatz ermöglicht die Realisierung von interessanten Funktionen wie dem Klonen. Es funktioniert wesentlich schneller und kosteneffizienter, da keine vollständige Kopie aller Daten erstellt werden muss.

Die Speicherebene wird als verteiltes System realisiert. Es besteht aus einer sehr großen Anzahl physischer Server. Jeder Redo-Log wird gleichzeitig verarbeitet und gespeichert in sechs Knoten. Das gewährleistet Datensicherheit und Lastverteilung.

Die Skalierung für Lesevorgänge kann durch entsprechende Replikate sichergestellt werden. Der verteilte Speicher eliminiert die Notwendigkeit zur Synchronisation zwischen der Haupt-DB-Instanz, über die wir Daten schreiben, und den anderen Replikaten. Aktuelle Daten sind garantiertermaßen für alle Replikate verfügbar.

Das einzige Problem ist die Zwischenablage alter Daten auf den Lese-Replikaten. Aber dieses Problem wird gelöst durch die Übertragung aller Redo-Logs an die Replikate über das interne Netzwerk. Wenn der Log im Cache vorhanden ist, wird er als ungültig markiert und neu geschrieben. Wenn er nicht im Cache vorhanden ist, wird er einfach verworfen.

Das Speicherproblem haben wir geklärt.

Wie man die Ebenen der DBMS skalieren kann

Hier ist horizontale Skalierung deutlich schwieriger. Daher gehen wir den bewährten Weg. klassisches vertikales Scaling.

Angenommen, wir haben eine Anwendung, die über einen Master-Knoten mit einer Datenbank kommuniziert.

Beim vertikalen Scaling erstellen wir einen neuen Knoten mit mehr Prozessoren und mehr Speicher.

Dann wechseln wir die Anwendung vom alten Master-Knoten auf den neuen. Dabei treten Probleme auf.

• Dies wird zu spürbaren Ausfallzeiten der Anwendung führen.
• Der neue Master-Knoten hat einen kalten Cache. Die Datenbankleistung erreicht ihren Höchstwert erst nach dem Aufwärmen des Caches.

Wie können wir die Situation verbessern? Wir setzen einen Proxy zwischen der Anwendung und dem Master-Knoten ein.

Was bringt uns das? Jetzt müssen alle Anwendungen nicht manuell auf den neuen Knoten umgeleitet werden. Der Wechsel kann unter dem Proxy erfolgen und ist dabei grundlegend schneller.

Es scheint, als wäre das Problem gelöst. Aber nein, wir leiden immer noch unter der Notwendigkeit, den Cache aufzuwärmen. Zudem gibt es ein neues Problem – jetzt ist der Proxy ein potenzieller Ausfallpunkt.

Endgültige Lösung mit Amazon Aurora serverless

Wie haben wir diese Probleme gelöst?

Wir haben den Proxy beibehalten. Dies ist kein separater Instanz, sondern eine gesamte verteilte Flotte von Proxys, über die Anwendungen mit der Datenbank verbunden werden. Jeder Knoten kann im Falle eines Ausfalls praktisch sofort ersetzt werden.

Wir haben einen Pool von warmen Knoten unterschiedlicher Größe hinzugefügt.. Daher ist bei Bedarf sofort ein neuer Knoten in größerer oder kleinerer Größe verfügbar. Es ist nicht notwendig zu warten, bis er hochgefahren ist.

Der gesamte Skalierungsprozess wird von einem speziellen Überwachungssystem kontrolliert. Die Überwachung beobachtet ständig den Zustand des aktuellen Master-Knotens. Wenn sie beispielsweise feststellt, dass die CPU-Auslastung einen kritischen Wert erreicht hat, informiert sie den Pool warmer Instanzen über die Notwendigkeit, einen neuen Knoten bereitzustellen.

Verteilte Proxys, warme Instanzen und Überwachung.

Der Knoten mit der erforderlichen Leistung ist verfügbar. Die Pufferpools werden auf ihn kopiert, und das System beginnt, auf einen sicheren Moment für den Wechsel zu warten.

In der Regel tritt der Wechselmoment recht schnell ein. Dann wird die Kommunikation zwischen dem Proxy und dem alten Master-Knoten unterbrochen, und alle Sitzungen werden auf den neuen Knoten umgeschaltet.

Die Arbeit mit der Datenbank wird fortgesetzt.

Die Grafik zeigt, dass die Unterbrechung tatsächlich sehr kurz ist. Im blauen Diagramm sehen wir die Belastung, und die roten Stufen representieren die Skalierungsmomente. Die kurzfristigen Ausfälle im blauen Diagramm stellen genau die besagte kurze Verzögerung dar.

Übrigens ermöglicht Amazon Aurora erhebliche Einsparungen, indem die Datenbank abgeschaltet werden kann, wenn sie nicht genutzt wird, zum Beispiel an Wochenenden. Nach dem Stopp reduziert die Datenbank allmählich ihre Kapazität und schaltet sich für eine Weile ab. Wenn die Last zurückkommt, wird sie wieder sanft hochgefahren.

Im nächsten Teil unserer Betrachtung von Amazon werden wir über die Netzwerkskalierung sprechen. Melden Sie sich an für den Newsletter und bleiben Sie auf dem Laufenden, um den Artikel nicht zu verpassen.

Auf HighLoad++ Wassili Pantjuchin wird einen Vortrag halten mit dem Titel „Houston, wir haben ein Problem. Designs für Ausfallsicherheit, Muster für die Entwicklung interner Amazon-Cloud-Dienste“. Welche Entwurfsmuster für verteilte Systeme nutzen die Entwickler von Amazon, welche Ursachen gibt es für Dienstausfälle, was ist Cell-based Architecture, Constant Work, Shuffle Sharding? Das wird spannend. Weniger als ein Monat bis zur Konferenz — buchen Sie Ihre Tickets. Am 24. Oktober steigen die Preise endgültig.

Quelle: habr.com