Die Entwicklung von HighLoad-Anwendungen am Beispiel eines regionalen Portals öffentlicher Dienste

„Morgen ist der 20., was bedeutet, dass es wieder einen Sturm geben wird. Es ist unmöglich, es zu stoppen, nur um sich darauf vorzubereiten und zu hoffen, dass es diesmal weht, ein Wunder geschieht und unsere Seefähre den Ozean erobert . “ Solche Überlegungen haben das Team, das das kommunale Dienstleistungsportal vor einigen Jahren unterstützte, überfordert. Wie wir in diese Situation geraten sind und wie wir einen Ausweg gefunden haben, wird unten beschrieben.

Wie alles begann

In den fernen 1990er Jahren erlebte der Wohnungsbau und der kommunale Dienstleistungssektor einen Boom in der Entwicklung, neue Technologien wurden eingeführt, automatisierte Informationssysteme und neue Ausrüstungsgegenstände wurden angeschafft. Aber etwas blieb für lange Zeit praktisch unverändert, nämlich die Zahlungen für die Wohnung. Ja, die gleichen Quittungen für eine Wohnung, die in Zahlungsdokumente umgewandelt, Barcodes erworben und detailliert entschlüsselt wurden, blieben als Zettel zurück. Das typische Arbeitsschema des Siedlungszentrums des Unternehmens für Wohnungswesen und kommunale Dienstleistungen oder des Unternehmens für die Bereitstellung von Ressourcen lautete wie folgt:



Allmählich wurde das moderne Internet durch einen Breitbandzugang ersetzt, der Gedanke entstand - warum nicht Online-Zahlungsdokumente in elektronischer Form erhalten? Zur gleichen Zeit wankte der Wohnungsbau- und Kommunaldienstleistungssektor in organisatorischer Form, MPP-Wohnungsbau und Kommunaldienstleistungen (kommunaler Produktionsbetrieb für Wohnungsbau und Kommunaldienstleistungen) wurden durch kommunale Einheitsbetriebe (kommunale Einheitsbetriebe), DEZs (Direktionen eines einzelnen Kunden) ersetzt. Infolge aller Umgestaltungen wurden die IT-Abteilungen der Wohnungsunternehmen und kommunalen Dienstleistungsunternehmen entfremdet und verschiedene Siedlungszentren auf ihrer Grundlage gegründet. Das Wesentliche an den Siedlungszentren war in der Tat die Berechnung der Miete und der Informationsunterstützung der Bevölkerung.

Wachstumsphase, 00s

Damals entstanden die ersten Informationsportale, die die Bevölkerung mit elektronischen Diensten versorgten. Die Anzahl der Erstnutzer wurde in Dutzenden gemessen, nicht jeder vertraute elektronischen Zahlungsdokumenten, andere hatten nichts von Innovationen gehört, mobile Anwendungen im Bereich der öffentlichen Dienste waren selten. Die Arbeit von Informationsportalen unterschied sich nicht wesentlich von der Arbeit bekannter Informationssysteme und war natürlich nie eine Hochlast-Architektur.



Jahre vergingen, die Portale verbesserten sich, es gab Möglichkeiten, Messgeräte abzulesen, Zertifikate zu erstellen usw. Zu dieser Zeit tauchten die ersten „Wolken“ am Horizont auf, und immer mehr Nutzer registrierten sich auf Portalen und forderten Daten an. In der Ferne tauchte die erste Welle sich nähernder Lasten auf.

Das Team (im Folgenden als Team 1 bezeichnet) hat die folgenden Optimierungsmaßnahmen ergriffen:

• Ändern der Größe eines Zahlungsdokuments in PDF von 0,5 MB auf 0,2 MB
• Erstellen einer Warteschlange zur Bildung von Zahlungsbelegen
• Speicherung der generierten Zahlungsdokumente zur wiederholten Anforderung
• Erstellen eines Replikats der Hauptdatenbank, nur für die Anforderungen des Portals

Seit einigen Jahren schien die Situation stabil, die Anzahl der Nutzer einzelner Portale wurde zu Tausenden gemessen, es war noch nicht stürmisch, aber es erschütterte erheblich, die Dezentralisierung von Clearing-Zentren spielte den Entwicklern in die Hände.

Big Jump Stage

Ein neuer Meilenstein in der Geschichte war die Entwicklung eines kommunalen Dienstleistungsportals auf regionaler Ebene. Die Einbeziehung eines einzigen Einstiegspunkts für jeden Einwohner der Republik war eine verlockende Idee, und dies würde die Bewertung des staatlichen Standorts auf das Niveau der besten Geschäfts- oder Bankstandorte bringen, an denen jeder Einwohner der Region viele verschiedene Arten von Dienstleistungen erhalten würde. Eine der beliebtesten Möglichkeiten könnte die Bezahlung von Wohnraum und kommunalen Dienstleistungen sowie die Einbeziehung von Zählerständen sein.

Der nächste Schritt war daher die Trennung der Betriebsinformationen der Abrechnungszentren von den im Zahlungsbeleg angezeigten Informationen. Hierzu wurden ein einfaches Datenübertragungsformat und eine Datenbank zur Speicherung von Informationen entwickelt und die Berechnung des Speicherplatzbedarfs für 5 Betriebsjahre durchgeführt.

Wichtige Entscheidungen, die zu diesem Zeitpunkt getroffen wurden:

• Informationsabteilung Teil der operativen Datenbank;
• Entwicklung einer Datenbank zur Speicherung dieses Formats;
• Zusammenführung der Daten der Siedlungszentren der Regionen in einer einzigen Datenbank;
• Integration mit Portalprozessen, Entwicklung von Diensten.

In dieser Phase verwandelte sich die Lösung von einem vollwertigen in ein Backend, da das Portal den Benutzern eine einzige Oberfläche zur Verfügung stellte. Das Portal hatte ein eigenes Team, das es unabhängig von der aktuellen Lösung der Siedlungszentren weiterentwickelte. In unserer Geschichte erscheint das zweite Team (im Folgenden als Team 2 bezeichnet) und ein neuer Anbieter. Wie wir später sehen werden, hat dies die Entwicklung und Lösung von Problemen erheblich beeinflusst. Das Wesen der Designlösung war wie folgt:



Beim Entwurf der Datenbank wurde eine einfache Zuordnung des Formats zur Datenbank akzeptiert. Als DBMS wurde PostgreSQL 9.3 ausgewählt (zu dieser Zeit war es eine sehr aktuelle Version). Das Format bestand aus 9 Flatfiles, von denen jedes mit dem Befehl COPY (wir lasen - sehr schnell) in die vielen Tabellen eines bestimmten Settlement Centers (jedes Settlement Center hatte eine eigene Registrierungsnummer) der Portaldatenbank geladen wurde. In einigen Abrechnungszentren betrug die Anzahl der für die Erstellung von Zahlungsdokumenten erforderlichen Aufzeichnungen 1.000.000, in einem Jahr 12.000.000, in einem Zeitraum von 5 Jahren -60.000.000. Die Anzahl der Anfragen an diese Datenbank erhöhte sich auf die Summe aller Nutzer von Bezirksportalen und konnte machen Zehntausende aus. Es gab etwas zu überlegen.

Team 1 unternahm die folgenden Schritte, um die potenzielle Belastung zu verringern:

• Die Tabellen wurden nach Siedlungszentren und Monaten der Aufteilung aufgeteilt;
• Der Datenladevorgang ist für verschiedene Abrechnungsstellen zeitlich getrennt.

Herausforderungen zu schnelles Wachstum

Das Portal wurde gestartet und die vorbereiteten Pläne wurden mit der Realität konfrontiert:

• Die Anzahl der Benutzer hat die Schätzung sehr schnell überschritten.
• Abfragen wurden an die Mastertabelle gesendet, aber das DBMS hat weiterhin alle Tabellen abgefragt
• Auslastung des Datenbankservers. Auf diesem Server befanden sich andere, unvergleichlich große Datenbanken, deren Informationen in zufälligen Momenten kamen und alle verfügbaren Ressourcen in Anspruch nahmen
• Der Service zur Erstellung eines Zahlungsbelegs wurde aufgrund ineffizienter Implementierung verlangsamt
• Die Last der Benutzer war nicht gleichmäßig über den Monat verteilt, sondern konzentrierte sich auf zwei Zeiträume:
  
  

Dieser Moment wird am Anfang des Beitrags beschrieben. Es war schwierig, das Problem zu diagnostizieren, da die Probleme an allen Stellen gleichzeitig auftraten. Team 1 und Team 2, die von ihrer Führung gleichermaßen geliebt wurden, haben Schritte unternommen, um aus der Situation herauszukommen, aber es gab praktisch keine Kommunikation zwischen ihnen:



Team 2 schien einen logischen und nützlichen Schritt zu machen: Die Erstellung eines Zahlungsbelegs begann sofort, nachdem der Benutzer das System betreten hatte, in der Erwartung, dass der AP bereits gebildet war, während er die Seiten auf den Seiten erreichte, und das fertige Dokument schnell erstellt werden konnte.

Zu diesem Zeitpunkt hat Team 1 jeden Monat ein Problem heldenhaft gelöst und den Kunden jedes Mal davon überzeugt, dass sich dort die Ursache des Problems versteckt hat:

• Optimiertes SQL (erhielt zeitweise eine Leistungssteigerung);
• Trennte den Datenbankserver für das Portal vom Rest der Datenbanken.
• Wir haben die Erstellung eines Zahlungsbelegs in einem separaten Antrag durchgeführt und diesen auch optimiert;
• Wir haben den Aufruf an die Master-Tabelle überarbeitet und die Version von PostgreSQL geändert.
• Wir haben den Aufruf noch einmal überarbeitet (jetzt wurde nur noch eine Partition aus der Master-Tabelle angefordert - manchmal sogar eine Beschleunigung).

Die heldenhaften Bemühungen der Teams führten zu lokalen Erfolgen (2-3 Monate lang schien das Problem gelöst zu sein). Aber die Realität hat die ganze Zeit über neue einleitende Worte geworfen:

• Die Datenbank enthält bereits mehrere Jahre und ist über 1 TB gewachsen.
• Die Anzahl der Nutzer lag bereits bei Hunderttausenden.

Während des Kampfes richtete Team 2 einen automatischen Servicetest ein, sodass Leistungsprobleme innerhalb weniger Minuten bekannt wurden und das Problem automatisch per E-Mail auf die höchsten Kontrollebenen eskalierte.

Zu diesem Zeitpunkt in Team 1 :

• Die Archivierungszeit der Datenbank überschritt allmählich die zulässigen Grenzen (der Dienst war nicht mehr verfügbar).
• Ein Anruf bei dem Dienst, der sich unmittelbar auf viele Monate auswirkte, erzeugte viele Anfragen.
• DBMS hat sich bei der Erfüllung von Abfragen aufgrund einer Zunahme der Anzahl von Tabellen (Partitionen) verschlechtert.
• Benutzer, die nur Instrumentenablesungen durchführen wollten, forderten weiterhin die Erstellung von Zahlungsdokumenten an (Rückruf nach Entscheidung von Team 2).

Es stellte sich heraus, dass die Lösung aus technischer Sicht an ihre Grenzen stieß und es an der Zeit war, das Nutzerverhalten zu analysieren, um Prozesse zu optimieren oder Technologien radikal zu verändern.

Als Ergebnis der Analyse (hier ist das Thema für einen separaten Artikel) wurden die folgenden Maßnahmen ergriffen:

• Die Daten wurden bis zu den letzten drei Jahren abgeschnitten, da in der Vorperiode keine Anrufe getätigt wurden. seitdem ist die alte Periode jährlich abgeschnitten worden;
• Wir haben den Aufruf an die Master-Tabelle überarbeitet, direkt auf eine bestimmte Partition zu verweisen (dies hat die Belastung des DBMS verringert).

Die Gegenwart

Jetzt ist das System ziemlich stabil, passt in den regulatorischen Zeitrahmen und die Anforderungen für nicht-funktionale Eigenschaften, aber es tauchten wieder Wolken am Horizont auf:

• Eine weitere Steigerung der Nutzerzahl;
• Zunahme der Zahl der betreuten Haushalte;
• Erhöhung der Komplexität der erbrachten Dienstleistungen;
• Verbesserte Granularität der Daten, die den Benutzern zur Verfügung stehen.

Dazu wird ein Plan erstellt und die Umsetzung folgender Maßnahmen vorbereitet:

• Analyse des Benutzerverhaltens: Wie viele von ihnen sehen sich den Zahlungsbeleg tatsächlich an und wie viele zahlen einfach den Betrag, wie für ein Mobiltelefon;
• Vorläufige Erstellung von Zahlungsdokumenten für Benutzer, die normalerweise Zahlungsdokumente zum Zeitpunkt der geringsten Belastung anzeigen.
• Übergang zu alternativen Technologien (ja, viele derjenigen, die an diesem Punkt angekommen sind, haben viel fortgeschrittenere Lösungen, die alle Probleme zunächst auf den Ressourcen eines Mobiltelefons gelöst haben).

Es scheint, dass dies einen großen optimistischen Punkt setzen kann. Alles gut gemacht: diejenigen, die es getan haben und diejenigen, die es sofort besser gemacht hätten. Aber morgen wird es neue Highload-Projekte geben, neue ungewohnte Probleme. Wie kann man sich jetzt darauf vorbereiten, was kann man sich vorstellen, wenn noch keine Daten vorliegen?

Ein systematischer Lösungsansatz

Können wir Erfahrung in eine Methodik für die Lösung von Problemen in Highload-Projekten umwandeln? Seltsamerweise lautet die Antwort JA, alles ist bereits für uns erfunden worden und erfolgt im Rahmen der Theory of Constraint TOC . Nur 5 einfache Schritte:

1. Finden Sie die Einschränkungen des Systems.
2. Entscheiden Sie, wie Sie die Systembeschränkungen optimal nutzen möchten.
3. Unterordnen Sie alles andere dieser Entscheidung.
4. Erweitern Sie die Einschränkungen des Systems.
5. ACHTUNG! Wenn die Einschränkung in den vorherigen 4 Schritten entfernt wurde, kehren Sie zu Schritt 1 zurück, lassen Sie jedoch nicht zu, dass die Trägheit eine Systemeinschränkung verursacht.

Die Beschreibung dieser Theorie und die Essenz der Schritte sind in der Literatur am Ende des Artikels ziemlich gut beschrieben, aber ich werde meine Vision im Rahmen des gegenwärtigen Prozesses schreiben:

1. Einschränkung: Zeitpunkt der Erstellung des Zahlungsbelegs.
2. Lösung: Generieren Sie alle Zahlungsdokumente im Voraus, wenn Sie Daten herunterladen.
3. Der Entscheidung untergeordnet: Bei Kontaktaufnahme mit dem Benutzer ein fertiges Dokument ausstellen.
4. Einschränkung erweitern: Optimieren Sie die Zeit für die Bildung des Zahlungsbelegs.
5. Setzen Sie das Vorbereitungssystem für ALLE Haushalte außer Kraft und definieren Sie eine neue Einschränkung.

Ein solcher Ansatz würde die Lösungszeit um mehrere Jahre verkürzen und die Arbeitskosten für Programmierer minimieren. In der Veröffentlichung werden nicht alle aufgetretenen Probleme aufgeführt, und es gibt keine Details zu den Lösungen, da sie im vorgeschlagenen Ansatz nicht so wichtig sind.

Was zum Thema zu lesen:

1. „Das Ziel. Kontinuierlicher Verbesserungsprozess “, so Eliyahu Goldratt
2. „Theorie der Zwänge. Grundlegende Ansätze, Werkzeuge und Lösungen “ , Dmitry Egorov
3. „Goldratts Theorie der Zwänge. Ein Systemansatz zur kontinuierlichen Verbesserung “, so William Detmer