Die Integration ging einher mit einem Kampf mit buchstäblich jeder Millisekunde Latenz, einem Infrastruktur-Upgrade und der Entwicklung von Technologien zur Bereitstellung von Inhalten, die wir uns selbst ausdenken mussten. Wir erzählen Ihnen, was wir im Laufe der Arbeit erlebt haben, was am Ende passiert ist und warum Benutzer es brauchen.
Warum überhaupt Cloud in CDN integrieren?
Zuallererst ist eine öffentliche Cloud eine skalierbare Kapazität. Sie können auf beliebige Weise verwendet werden: zum Entwickeln und Testen von Diensten sowie zum Speichern und Verarbeiten von Daten. Wir von G-Core Labs haben die Cloud letztes Jahr gestartet und es bereits geschafft, sie in Hochlastprojekten einzusetzen. Zum Beispiel verwendet unser langjähriger Client - Wargaming - diese Lösung für mehrere Aufgaben gleichzeitig:
- Testen neuer Funktionen und Dienste verschiedener Projekte;
- Vorbereiten von Testprototypen mit externen Entwicklern, die Zugriff auf isolierte benutzerdefinierte und kontrollierte Ressourcen benötigen;
- Bedienung des Online-Spiels "Calibre" auf virtuellen Maschinen.
Die Wolke bewältigt all das mit einem Knall, aber die Arbeit endet nicht dort. Unabhängig davon, wofür diese oder jene Kapazitäten genutzt werden, muss das Ergebnis ihrer Arbeit immer noch an den Bestimmungsort geliefert werden. Unabhängig davon, ob es sich um ein Online-Spiel oder um echte militärische Formationen handelt, tritt hier das Problem auf: Es ist äußerst schwierig, schwere Daten schnell an entfernte Regionen mit mehreren Tonnen militärischer Ausrüstung zu liefern. Diese Aufgabe kann durch die Integration der Cloud in das Content Delivery-Netzwerk vereinfacht werden. Mit Hilfe von CDN kann der transportable Teil - statische Daten - "drahtlos" direkt zum Ziel geworfen werden, und es bleibt nur noch das Senden von "übergroßen" dynamischen Daten aus der Cloud. Mit diesem Ansatz können Sie auch auf anderen Kontinenten sicher mit der Arbeit beginnen, da die Integration es schnelleren Wettbewerbern ermöglicht, umfangreiche Inhalte auf der ganzen Welt bereitzustellen.
, , : CDN
Kommen wir zu den Einzelheiten. Wir wissen aus erster Hand, dass es lange dauert, schwere Inhalte direkt aus der Cloud an entfernte Regionen zu liefern, und es kann teuer sein, die Kapazität der Infrastruktur entsprechend der zunehmenden Last ständig zu erhöhen. Glücklicherweise haben wir zusätzlich zur öffentlichen Cloud unser eigenes CDN erhalten, das sogar in das Guinness-Buch der Rekorde aufgenommen wurde und eine ununterbrochene Erfahrung beim Spielen von World of Tanks in Spitzenzeiten bietet.
Um zwei Fliegen mit einer Klappe zu schlagen, mussten wir sie in die Wolke integrieren. Dann könnten wir den Benutzern eine Lösung anbieten, die weniger kostet als ein Infrastruktur-Upgrade und eine schnellere Datenlieferung an entfernte Regionen ermöglicht. Also haben wir die erste Arbeitsphase begonnen und die Hauptprobleme gelöst:
1. Cloud-Dienste waren unter ständiger Last.Benutzer von Hochlastprojekten forderten regelmäßig Inhalte aus den Clouds unserer Kunden an. Dies führte zu einer hohen Last und einer langen Datenrückgabe. Es wurde eine Lösung benötigt, mit der sich die Anzahl der Verweise auf die Quelle leicht verringern lässt. Zu diesem Zweck haben wir öffentliche Cloud-Server und CDN-Cache-Server integriert und eine einzige Schnittstelle für die Verwaltung dieser Dienste erstellt. Mithilfe dieser Funktion können Benutzer statische Daten an die gewünschten Präsenzpunkte im Netzwerk verschieben. Aus diesem Grund erfolgen die Aufrufe der Cloud nur bei den ersten Anforderungen nach Inhalten. Es funktioniert auf standardmäßige Weise: CDN nimmt Daten von der Quelle und sendet sie an den Benutzer sowie an den nächstgelegenen Cache-Server, von wo aus der Inhalt bei nachfolgenden Anforderungen verteilt wird.
2. Die Daten wurden lange Zeit zwischen der Cloud und dem CDN übertragen.Durch die Kombination der Cloud mit einem Netzwerk für die Bereitstellung von Inhalten haben wir festgestellt, dass die Latenz bei der Datenbereitstellung verringert werden kann. Um so viele wertvolle Millisekunden wie möglich zu sparen, mussten wir den Datenaustausch zwischen den Cache-Servern und der Cloud im Backbone implementieren.
3. Die Belastung der Quelle war ungleichmäßig. Auch nach dem Verbinden des CDN wurden die verbleibenden Anforderungen an die Cloud ineffizient verteilt. Wir haben dies mit HTTP (S) Balancern behoben. Zum Zeitpunkt der Inhaltsanforderung bestimmen sie nun, aus welcher Quelldaten (virtuelle Maschine oder Cloud-Speicher-Bucket) Daten zwischengespeichert werden sollen.
4. Es dauerte lange, bis schwere Inhalte die Benutzer erreichten.Um die Wartezeit zu verkürzen, haben wir die Kapazität und Geografie der CDN-Präsenz ständig erhöht. Jetzt müssen Benutzer nicht mehr darauf warten, dass Inhalte sie auf der halben Welt erreichen. Zum Zeitpunkt des Kontakts wählt das Netzwerk für die Bereitstellung von Inhalten den nächstgelegenen von 100 Präsenzpunkten auf fünf Kontinenten aus. Infolgedessen liegt die durchschnittliche Antwortzeit weltweit innerhalb von 30 ms.
Nachdem wir uns mit diesen Problemen befasst haben, haben wir die Arbeit bereits als abgeschlossen betrachtet. Aber die Cloud mit CDN hatte andere Pläne für uns.
So wurde der Stahl gehärtet: Wir modernisieren die Infrastruktur
An einem Punkt wurde klar, dass sich die Wirkung all unserer Bemühungen nicht vollständig manifestieren konnte, während wir die alte Hardwarekonfiguration verwendeten. Damit die Server und die auf ihnen gehosteten Anwendungen besser funktionieren und die Inhalte schneller übertragen werden, war ein Infrastruktur-Upgrade erforderlich. Die Sterne am Himmel kamen Anfang dieses Jahres zusammen: Wir begannen mit dem Upgrade, sobald die Intel Xeon Scalable-Prozessorreihe der zweiten Generation veröffentlicht wurde.
Jetzt sieht die Standardserverkonfiguration folgendermaßen aus:
- Cloud-Dienste, die auf Intel Xeon Gold 6152-, 6252- und 5220-Prozessoren ausgeführt werden, verfügen über bis zu 1 TB RAM sowie SSD und HDD mit dreifacher Replikation.
- CDN-Cache-Server sind mit Intel Xeon Platinum, virtuellem RAID auf CPU und SSD D3-S4610 ausgestattet.
Infolge des Upgrades hat sich die Leistung so stark erhöht, dass wir einige Server aufgegeben und die Betriebskosten gesenkt haben. Es schien, dass all das mehr als genug für die Arbeit eines Projekts sein würde. Aber einmal war das nicht genug.
Abschirmung, Sharding und Geoverteilung: Beschleunigung der Bereitstellung von Inhalten unter extremen Bedingungen
Das Unglück kommt nie allein. Dies gilt insbesondere für globale Projekte. Mangel an geografisch verteilter Infrastruktur, hohe Auslastung durch viele Benutzer aus der ganzen Welt und ein Meer heterogener Daten, die sie schnell bereitstellen müssen - einer unserer Kunden, eine große Medienressource, musste all diese Komplexitäten gleichzeitig bewältigen. Einige Details:
- Der Inhalt erreichte die Benutzer lange Zeit und manchmal erreichte er sie aufgrund hoher Verzögerungen und Netzwerkprobleme überhaupt nicht. Die Schwierigkeit bestand darin, dass sich der gesamte große Pool von Servern mit Daten an einem geografischen Punkt befand.
- Auf die Inhaltsquelle wurde von Benutzern aus der ganzen Welt zugegriffen, was zu einer erhöhten Belastung der Infrastruktur führte und zu hohen Wartungskosten sowie einer langsamen Datenlieferung führte.
- Die Benutzer mussten eine große Menge ständig aktualisierter Inhalte bereitstellen, die für jede Region einzigartig waren.
Die grundlegenden Funktionen der Cloud-Integration mit CDN waren hier unverzichtbar. Wir haben begonnen, zusätzliche Lösungen zu entwickeln.
Wie wir zu einer regionalen Abschirmung gekommen sind
Wir haben dieses Konzept und jetzt einen bestehenden Dienst eingeführt, um das Problem mit der Entfernung der Inhaltsquelle zu lösen. Aufgrund der Tatsache, dass sich alle Server des Clients an einem geografischen Punkt befanden, dauerte es lange, bis die Daten von ihnen Benutzer aus verschiedenen Teilen der Welt erreichten. Die Situation wurde durch die Tatsache kompliziert, dass es notwendig war, verschiedene, ständig aktualisierte Inhalte für verschiedene Regionen bereitzustellen. Ein einfaches Zwischenspeichern von Daten auf Edgeservern würde das Problem nicht beheben - sie greifen immer noch häufig auf der ganzen Welt auf die Quelle zu.
Wir haben das Problem gelöst, indem wir einen großen Pool von Cache-Servern an beliebten Verkehrsaustauschpunkten auf verschiedenen Kontinenten bereitgestellt haben. "Regionale Schutzschilde" sind zu einer Art Schicht zwischen Quell- und Edgeservern in den Ländern des Benutzers geworden. Jetzt fielen alle in den entsprechenden Teilen der Welt geforderten Inhalte zuerst auf sie und wurden dann an die Cache-Server übertragen. Durch die Abschirmung wurde die Belastung der Client-Quelle sofort verringert und die Verzögerungen für die Endbenutzer verringert. Der Client wiederum sparte bei der Platzierung mehrerer Serverpools mit demselben Inhalt in verschiedenen Teilen der Welt, da mit diesem Arbeitsprinzip eine Datenquelle ausreichte.
Warum brauchten Sie Content Sharding?
Regionale Abschirmungen haben das Problem der langfristigen Bereitstellung von Inhalten in verschiedenen Teilen der Welt gelöst. Jetzt entstand jedoch eine neue Komplexität: Da der Client über viele Daten verfügte und diese ständig aktualisiert wurden, gelangte er nicht in den Cache der Edgeserver, auf die Benutzer zugegriffen haben. Dies führte dazu, dass eine Vielzahl von Anfragen von Cache-Servern ständig an regionale Pools weitergeleitet wurden, deren Anzahl in einer Gruppe 20 bis 30 Stück erreichte. Um einen Teil dieser Last von den Schutzschildern zu entfernen und den Benutzern noch schneller Inhalte bereitzustellen, haben wir die Möglichkeit hinzugefügt, die erforderlichen Daten vom nächstgelegenen Edgeserver im Pool zu übernehmen.
Jetzt begannen Cache-Server in den Regionen der Präsenz erst dann auf Shields zuzugreifen, wenn die Daten nicht in der gesamten Gruppe verfügbar waren. Darüber hinaus wurde der Inhalt auch in diesen Fällen sofort von dem Server angefordert, der ihn enthielt - dank Sharding "wussten" Edgeserver im Voraus, wo sich eine bestimmte Datei befindet, und befragten nicht den gesamten Pool regionaler Schutzschilde dafür. Dieses Funktionsprinzip reduzierte die Anzahl der Anforderungen an den Pool und ermöglichte es, Inhalte effizient über den Pool zu verteilen, anstatt Kopien der Daten auf jedem Server zu speichern. Infolgedessen enthielten Schilde mehr Inhalt und belasteten infolgedessen die Quelle des Kunden weniger.
Die Schaffung einer solchen Infrastruktur konnte nur eine weitere Schwierigkeit mit sich bringen. Angesichts der Anzahl der Cache-Server in den Gruppen wäre es dumm anzunehmen, dass keiner von ihnen ausfallen kann. In einer solchen Situation, wie beim Hinzufügen eines neuen Servers zum Pool, musste der Cache in den Gruppen optimal neu verteilt werden. Zu diesem Zweck haben wir die Organisation eines Sharded-Cache mit einem konsistenten Hashing-Algorithmus im Upstream-Block in Nginx implementiert:
upstream cache_servers {
hash $cache_key consistent;
server edge1.dc1.gcorelabs.com;
server edge2.dc1.gcorelabs.com;
server edge3.dc1.gcorelabs.com;
}
Das Auftreten nicht verfügbarer Server im Pool war auch mit einem anderen Problem behaftet: Andere Server sendeten weiterhin Anforderungen an sie und warteten auf eine Antwort. Um diese Verzögerung zu beseitigen, haben wir einen Algorithmus zum Erkennen solcher Server im Pool geschrieben. Aufgrund der Tatsache, dass sie in der Upstream-Gruppe automatisch in den Down-Status versetzt werden, greifen wir nicht mehr auf inaktive Server zu und erwarten keine Daten von ihnen.
Infolge dieser Arbeiten haben wir die Kosten für Dienstleistungen für den Kunden gesenkt, ihn vor den erheblichen Kosten für die Organisation seiner eigenen Infrastruktur bewahrt und die Bereitstellung von Daten für Benutzer trotz aller Schwierigkeiten erheblich beschleunigt.
Wer braucht eine Cloud mit CDN
Die Integrationsarbeit ist beendet und unsere Kunden nutzen das Produkt bereits. Wir teilen mit, wer von ihnen das Beste daraus macht.
Nehmen wir sofort an, dass die Lösung nicht für alle nützlich war. Wir haben nichts anderes erwartet: Für einige reichen nur Speicher und virtuelle Maschinen aus, und für jemanden - Content Delivery-Netzwerke. Wenn sich beispielsweise die gesamte Zielgruppe eines Projekts in derselben Region befindet, muss das CDN praktisch nicht mit der Cloud verbunden werden. In diesem Fall reicht ein Server aus, der sich nicht weit von den Benutzern befindet, um Verzögerungen zu minimieren.
Die Integration zeigt sich in ihrer ganzen Pracht, wenn Sie einer großen Anzahl von Benutzern schnell und weit entfernte Inhalte bereitstellen müssen. Hier einige Beispiele, wie eine Cloud mit CDN verschiedenen Projekten hilft:
- Streaming-Dienste , die für Latenz und Pufferung von entscheidender Bedeutung sind, gewährleisten einen stabilen Betrieb und qualitativ hochwertige Sendungen.
- Online-Unterhaltungsdienste liefern schwere Spiele schneller in verschiedene Teile der Welt und reduzieren die Belastung der Server, auch bei Spitzenlasten.
- Medienprojekte beschleunigen die Ladezeiten von Anzeigen und bleiben verfügbar, wenn der Datenverkehr steigt.
- Online-Shops werden in verschiedenen Ländern schneller geladen, auch bei Werbeaktionen und Verkäufen.
Wir sehen weiterhin genau, wie sie die Cloud mit CDN nutzen. Wir sind wie Sie an den Zahlen interessiert: Wie stark wird die Infrastruktur entlastet, wie viel schneller erhalten Benutzer Inhalte in bestimmten Regionen und wie viel Integration hilft, Geld zu sparen. Wir werden dies alles in zukünftigen Fällen teilen.