Die Geschichte der industriellen Wirtschaft ist die Geschichte des Verbrauchs einer begrenzten Ressource. Im Falle von Elektrizität gab es einen ausgeprägten Abendgipfel, und daher setzten sich die Eigentümer von Kraftwerken für den modernen städtischen Verkehr ein und schufen die Unterhaltungselektronikindustrie von Grund auf neu. Das heißt, sie haben die Lebensweise von Millionen verändert, so dass Kraftwerke gleichmäßiger beladen werden.
Computerressourcen haben eine ähnliche Geschichte. Selten nutzt jemand sie voll effektiv. Lassen Sie uns über die Ausnutzung und ein wenig über die nächste Generation der Programmierung für solche Umgebungen sprechen, in denen es sehr flexibel ist, Ressourcen gemeinsam zu nutzen.
Saisonaler Verbrauch
Der saisonale Verbrauch eines Saisonkunden sieht aus wie 11 Monate Ruhe und ein Monat Doppel-Dreifach-Belastung. Jeder kennt seinen Höhepunkt. Der Einzelhandel friert alle Aktivitäten bis Dezember und Neujahrsverkäufe ein und erhält virtuelle Maschinen. Jeder hat immer noch seine eigene Saison mit Rabatten und großen Verkäufen - für jemanden am 1. September, für Geschenke am 8. März und so weiter. Alle B2C-Dienste haben verständliche saisonale Aktivitäten nur zu Geschäftszeiten, beispielsweise bei Internetbanken. Wir bei Technoserv Cloud planen für diese Zeiträume keine Wartungsarbeiten.
Geologen kommen von der Expedition nach Hause und beginnen, ihre Fossilien in der Wolke zu zählen. In großen Unternehmen werden Berichte bis zum Ende des Zeitraums von einer Reihe von Subsystemen gesammelt - irgendwo effizient und irgendwo mit einem Knarren, fast bis zum Aufprall. Maschinelles Lernen und Analytik verursachen sehr große Belastungen, tun dies jedoch nicht dauerhaft.
Sommerspitzen sind eine Tourismusbranche, aber sie haben keine nennenswerten Sprünge, aber es gibt DDoS in der Saison, normalerweise, wenn Leute Tickets für die Maiferien kaufen.
Normaler Verbrauch
Unser durchschnittlicher Kunde in unserer Cloud verbraucht Ressourcen mit „täglicher Säge“: Am Morgen mit Beginn des Arbeitstages beginnt der Anstieg, am Nachmittag ein kurzer Rückgang, am Abend ein Rückgang um das 2-3-fache. Nachts werden Systemaufgaben gestartet - Backups, Datenüberläufe in Analysen, Einzelhandelsbestands- und Logistikbestandsberechnungen, Umsatzprognosen. Finanzen hat unterschiedliche Bonitätshistorien und andere Caches. Es gibt keine ABSs in der Cloud, sie, die Mobilfunkbetreiber und Unternehmen wie Eisenbahnen haben nachts Clearing, dh das tägliche Guthaben für alle Operationen wird reduziert. Dies bedeutet relativ gesehen nicht, nachts einzusteigen, sondern ähnliche Transaktionen in Paketen zu sammeln und während des Zeitraums gegeneinander aufzurechnen.
Im Allgemeinen "sah" ein gewöhnliches Büro. Die fortgeschrittensten Administratoren schreiben bereits eine Skalierung vor, aber bisher sehen wir nur vereinzelte Beispiele.
In einem einfachen Fall sieht es so aus: Erhöhen Sie um 11:00 Uhr eine andere virtuelle Maschine, stellen Sie sie mit Diensten in den Balancer, migrieren Sie sanft um 19:00 Uhr und zahlen Sie sich aus. Das heißt, die Zahlung erfolgt nur für ein Drittel des Tages, und in Spitzenzeiten ist die Verfügbarkeit dieselbe wie bei der dauerhaften Anmietung einer zusätzlichen virtuellen Maschine.
Dies liegt daran, dass wir eine Uhrendiskretisierung haben Unsere Kunden sind oft an einer anderen Variante dieses Skripts interessiert - der automatischen Skalierung. Wenn der Ressourcenverbrauch auf 80% steigt, steigt eine andere Maschine. Bis zu einer bestimmten Grenze fallen - das Auto schaltet ab. Im Finanzvertrag haben wir Pay-as-you-go, dh Nachzahlung für tatsächlich verbrauchte Ressourcen, Quantisierung von VMs pro Stunde. In der Konsole können Sie eine Reihe von Autos selbst anheben. Der Administrator tritt ein und tut dies mit seinen Händen unter Last (z. B. am Black Friday, wenn die Last auf der Site zunimmt), oder er schreibt ein Skript, das die VM startet und löscht. Es gibt ein Unternehmen, Entwickler, das unter bestimmten Bedingungen Bankanwendungen entwickelt - sie benötigen eine automatische Skalierung zum Testen und Spitzenwerte beim Schleifen der Datenbank. Sie haben eine sehr geeignete Architektur für die Automatisierung, und mit ihnen testen wir ein vollautomatisches System, wenn die Cloud selbst die richtige Menge an VM zuweist. Das heißt, wie von selbst - über einen separaten Vitnes-Server (eine dedizierte VM oder eine externe Maschine), der die Last, die Anwendungsverteilung und den Ausgleich über die API verwalten kann. Sie werden zuerst automatisch skaliert und helfen dabei, die richtigen Prioritäten zu setzen. Gleichzeitig arbeiten sie für uns als Tester. Das Produkt ist je nach Bedarf sehr billig geschrieben: Wir haben keinen solchen Service in der Cloud wie einen Plug-In-Service, aber wir experimentieren. Bisher ist alles manuell, plus dieses Alpha: Wir haben alle Berichte und detaillierten Gespräche des Produkttechnologen mit seinen Entwicklern für den Job. So entsteht ein Produkt, das von all diesen Teams benötigt wird.
Software-Architekturfunktionen
Warum gibt es nur wenige Administratoren mit automatischer Skalierung, obwohl dies rentabler ist? Denn um die Last in der Cloud richtig zu skalieren, müssen Sie über eine vorbereitete Anwendungs- und Datenbankarchitektur verfügen. Wenn sich eine Anwendung wie eine Webfront normalerweise leicht skalieren lässt, ist das Schreiben in die Datenbank bereits eine interessantere Frage. Nicht alle Anwendungen werden einfach in Front-Back- oder Microservices unterteilt, um sie auf verschiedene Maschinen zu verteilen.
Diejenigen, die es haben - die natürlich retten. Und sie erhalten ein Plus an Stabilität, über das wir hier in einem Beitrag über
häufige Architekturfehler geschrieben haben .
Natürlich müssen Sie dafür die Software neu schreiben. Was nicht immer schnell und prinzipiell nicht immer möglich ist.
Die nächste Generation der Cloud-Geschichte sieht jedoch noch interessanter aus.
Containervirtualisierung
Die nächste Generation sind Container. Jetzt scheint es sich um eine Art leichtgewichtige virtuelle Maschinen mit Microservices zu handeln, die während der Handhabung ansteigen und ohne Aktivität aus dem RAM entladen werden. Das heißt, sie werden angezeigt und als Anwendungen im RAM und Austausch moderner Betriebssysteme ersetzt - so wie sie verwendet werden. Es klingt einfach und viele große Unternehmen haben ihre Architektur bereits speziell für Container neu geschrieben.
Das heißt, dies sind nicht einmal separate VMs, sondern nur Prozesse auf ihnen, ähnlich wie bei Citrix Xen-Anwendungen. Oder die guten alten VMs in der Container-Shell - also die gleichen Maschinen mit tiefer Autoskalierung.
Dies ist jedoch nur der erste Schritt. Tatsache ist, dass die Containerisierung von Funktionen noch interessanter ist. Dies ist immer noch eine Fantasie von Architekten, aber wenn Sie den Code direkt unter das Popup-Containersystem schreiben, können Sie ihn in jede einzelne Funktion einschließen. Es gibt Eingaben, es gibt Ausgaben und es gibt eine „Black Box“ - den Container selbst. Die Funktion wird im Code aufgerufen - der Container "tauchte auf", arbeitete aus und ging zurück, um auf den nächsten Aufruf zu warten.
Der Code muss natürlich das Ganze umgestalten und neu optimieren. Aber es lohnt sich und dies ist einer der möglichen Zweige der Zukunft. Nach unserer Einschätzung ist es sehr weit entfernt - mindestens drei Jahre bis zur Einführung durch die ersten Giganten und 15 Jahre vor dem industriellen Einsatz in Russland.
In der Zwischenzeit Container - leider ein Produkt für Geeks, weil sie nicht sehr gut funktionieren. Und es gibt keine Anfragen für sie in Russland, aber es gibt Anfragen für die automatische Skalierung. Und kein einziger neuer Vertrag wird ohne Umlage unterzeichnet.