{"id":83188,"date":"2020-05-29T07:43:02","date_gmt":"2020-05-29T05:43:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali"},"modified":"2020-05-29T07:43:02","modified_gmt":"2020-05-29T05:43:02","slug":"kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali","title":{"rendered":"Wie wir einen pl\u00f6tzlichen Anstieg der Auslastung um das Zehnfache im Homeoffice bew\u00e4ltigt haben und welche Erkenntnisse wir daraus gezogen haben","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo, Habr! In den letzten Monaten haben wir eine sehr interessante Situation durchlebt, und ich m\u00f6chte unsere Geschichte \u00fcber die Skalierung der Infrastruktur teilen. In dieser Zeit hat SberMarket seine Bestellungen vervierfacht und den Service in 17 neuen St\u00e4dten gestartet. Der explosive Anstieg der Nachfrage nach Lebensmittelzustellungen hat von uns verlangt, unsere Infrastruktur zu skalieren. Lesen Sie unten mehr \u00fcber die interessantesten und n\u00fctzlichsten Erkenntnisse.<\/p>\n

\"Wie
\n<\/a><\/noindex>
\nMein Name ist Dima Bobylev, ich bin der technische Direktor von SberMarket. Da dies der erste Beitrag in unserem Blog ist, m\u00f6chte ich ein paar Worte \u00fcber mich und das Unternehmen sagen. Letzten Herbst nahm ich am Wettbewerb junger F\u00fchrungskr\u00e4fte des Runet teil. F\u00fcr den Wettbewerb habe ich eine kleine Geschichte geschrieben<\/a><\/noindex> dar\u00fcber, wie wir bei SberMarket die interne Kultur und den Ansatz zur Serviceentwicklung sehen. Und obwohl es nicht gelungen ist, den Wettbewerb zu gewinnen, habe ich dennoch die grundlegenden Prinzipien f\u00fcr die Entwicklung der IT-\u00d6kosysteme formuliert. <\/p>\n

Bei der Teamf\u00fchrung ist es wichtig, ein Gleichgewicht zwischen den Anforderungen des Unternehmens und den Bed\u00fcrfnissen jedes einzelnen Entwicklers zu finden. Derzeit w\u00e4chst \u0421\u0431\u0435\u0440\u041c\u0430\u0440\u043a\u0435\u0442 j\u00e4hrlich um das 13-fache, was sich auf das Produkt auswirkt und eine st\u00e4ndige Erh\u00f6hung der Entwicklungsvolumina und -geschwindigkeiten erfordert. Trotzdem nehmen wir uns ausreichend Zeit f\u00fcr die Entwickler, um eine gr\u00fcndliche Analyse und qualitativ hochwertige Codeerstellung zu erm\u00f6glichen. Dieser etablierte Ansatz hilft nicht nur bei der Erstellung eines funktionierenden Produkts, sondern auch bei dessen weiterer Skalierung und Entwicklung. Infolge dieses Wachstums ist \u0421\u0431\u0435\u0440\u041c\u0430\u0440\u043a\u0435\u0442 bereits zum Marktf\u00fchrer unter den Lebensmittellieferdiensten geworden: Wir liefern t\u00e4glich rund 18.000 Bestellungen, w\u00e4hrend es Anfang Februar noch etwa 3.500 waren.<\/p>\n

\"Wie
\nEinmal bat ein Kunde den Kurier von \u0421\u0431\u0435\u0440\u041c\u0430\u0440\u043a\u0435\u0442, die Lebensmittel kontaktlos direkt auf den Balkon zu liefern.<\/i><\/p>\n

Kommen wir zur Sache. In den letzten Monaten haben wir intensiv an der Skalierung der Infrastruktur unseres Unternehmens gearbeitet. Dieser Bedarf wurde durch externe und interne Faktoren bedingt. Mit der gleichzeitigen Erweiterung unseres Kundenstamms stieg die Anzahl der angeschlossenen Shops von 90 zu Beginn des Jahres auf mehr als 200 bis Mitte Mai. Nat\u00fcrlich haben wir uns vorbereitet, die Hauptinfrastruktur reserviert und auf die M\u00f6glichkeit des vertikalen und horizontalen Scalings aller in der Yandex-Cloud betriebenen virtuellen Maschinen gesetzt. Doch die Praxis hat gezeigt: \u201eAlles, was schiefgehen kann, wird schiefgehen\u201c. Heute m\u00f6chte ich die interessantesten Situationen teilen, die in diesen Wochen aufgetreten sind. Ich hoffe, unsere Erfahrungen sind f\u00fcr Sie von Nutzen.<\/p>\n

Slave ist in voller Einsatzbereitschaft<\/h3>\n

\nBereits vor Beginn der Pandemie hatten wir mit einem Anstieg der Anfragen an unsere Backend-Server zu k\u00e4mpfen. Der Trend, Produkte nach Hause liefern zu lassen, nahm zu, und mit der Einf\u00fchrung der ersten Ma\u00dfnahmen zur Selbstisolierung aufgrund von COVID-19 stieg die Last dramatisch w\u00e4hrend des gesamten Tages. Es entstand die Notwendigkeit, die Master-Server der Hauptdatenbank schnell zu entlasten und einen Teil der Leseanfragen auf Replikaserver (Slave) zu verschieben.<\/p>\n

Wir hatten uns im Vorfeld auf diesen Schritt vorbereitet und bereits 2 Slave-Server f\u00fcr manuelle Anpassungen in Betrieb genommen. Diese f\u00fchrten haupts\u00e4chlich Batch-Aufgaben zur Generierung informativer Feeds zum Datenaustausch mit Partnern durch. Diese Prozesse erzeugten zus\u00e4tzliche Last und wurden vollkommen zu Recht bereits vor ein paar Monaten \"aus dem Rahmen genommen\".\u00a0<\/p>\n

Da auf dem Slave eine Replikation stattfand, hielten wir an dem Konzept fest, dass Anwendungen nur im Nur-Lese-Modus mit ihnen arbeiten konnten. Der Disaster Recovery Plan sah vor, dass wir im Falle einer Katastrophe einfach den Slave anstelle des Masters mounten und alle Lese- und Schreibanfragen auf den Slave umschalten konnten. Allerdings wollten wir auch Replikate f\u00fcr die Bed\u00fcrfnisse der Analyseabteilung nutzen, weshalb die Server nicht vollst\u00e4ndig in den Nur-Lese-Status versetzt wurden. Auf jedem Host gab es zudem einen eigenen Satz von Benutzern, von denen einige Schreibrechte hatten, um Zwischenergebnisse der Berechnungen zu speichern.<\/p>\n

Bis zu einem bestimmten Lastlevel reichten uns der Master sowohl f\u00fcr Schreib- als auch f\u00fcr Leseanfragen bei der Bearbeitung von HTTP-Anfragen. Mitte M\u00e4rz, als Sbermarkt beschloss, vollst\u00e4ndig auf Remote-Arbeit umzustellen, erlebten wir einen exponentiellen Anstieg der RPS. Immer mehr unserer Kunden gingen in Selbstquarant\u00e4ne oder arbeiteten von zu Hause aus, was sich auf die Lastindikatoren auswirkte.<\/p>\n

Die Leistung des Master-Servers war nicht mehr ausreichend, daher haben wir begonnen, einige der schwersten Leseabfragen auf die Replik auszulagern. F\u00fcr die transparente Weiterleitung von Schreibanfragen an den Master und Leseanfragen an den Slave haben wir das Ruby Gem \"Octopus<\/a><\/noindex>\" verwendet. Wir haben einen speziellen Benutzer mit dem Suffix _readonly ohne Schreibrechte erstellt. Aufgrund eines Fehlers in der Konfiguration eines der Hosts wurden jedoch einige Schreibanfragen im Namen eines Benutzers an den Slave-Server gesendet, der \u00fcber die entsprechenden Rechte verf\u00fcgte.<\/p>\n

Das Problem trat nicht sofort auf, da die erh\u00f6hte Last das R\u00fcckstandsverhalten der Slaves verst\u00e4rkte. Die Inkonsistenz der Daten wurde am Morgen festgestellt, als die Slaves nach n\u00e4chtlichen Importen den Master nicht \"eingeholt\" hatten. Wir schrieben dies auf die hohe Last des Dienstes selbst und den Import im Zusammenhang mit der Er\u00f6ffnung neuer Gesch\u00e4fte. Allerdings war es inakzeptabel, Daten mit stundenlangen Verz\u00f6gerungen zu liefern, und wir wechselten die Prozesse auf den zweiten analytischen Slave, da dieser \u00fcber gr\u00f6\u00dfere Ressourcen verf\u00fcgte und nicht mit Leseanfragen belastet war (was wir uns als Grund f\u00fcr das Fehlen von Replikationsverz\u00f6gerungen erkl\u00e4rten).gr\u00f6\u00dften<\/strong>die gr\u00f6\u00dften Ressourcen und keine Anfragen zum Weiterlesen und (wie wir uns selbst erkl\u00e4rt haben) keine Lags bei der Replikation.<\/p>\n

Nachdem wir die Ursachen des \"Auseinanderlaufens\" des Haupt-Slave gekl\u00e4rt hatten, war der analytische bereits aus demselben Grund ausgefallen. Trotz der zwei zus\u00e4tzlichen Server, auf die wir die Last im Falle eines Master-Ausfalls umleiten wollten, stellte sich aufgrund eines \u00e4rgerlichen Fehlers heraus, dass im entscheidenden Moment keiner verf\u00fcgbar war.<\/p>\n

Da wir jedoch nicht nur ein Dump der Datenbank gemacht hatten (die Wiederherstellung dauerte zu diesem Zeitpunkt etwa 5 Stunden), sondern auch einen Snapshot des Master-Servers angefertigt hatten, gelang es uns, die Replikation innerhalb von 2 Stunden zu starten. Allerdings wartete danach noch die l\u00e4ngere Anwendung des Replikationsprotokolls auf uns (da der Prozess im Einzelthread-Modus abl\u00e4uft, aber das ist eine ganz andere Geschichte).<\/p>\n

Fazit:<\/strong> Nach einem solchen Vorfall wurde klar, dass wir von der Praxis der eingeschr\u00e4nkten Schreibrechte f\u00fcr Benutzer absehen und den gesamten Server auf read-only setzen sollten. Mit einem solchen Ansatz kann man sicher sein, dass die Replikate in kritischen Momenten verf\u00fcgbar sind.<\/p><\/blockquote>\n

<\/p>\n

Die Optimierung auch nur einer schweren Abfrage kann die Datenbank \"wieder zum Leben erwecken\".<\/h3>\n

\nObwohl wir das Katalogangebot auf der Website st\u00e4ndig aktualisieren, gab es bei den Anfragen, die wir an die Slave-Server gerichtet haben, eine leichte Verz\u00f6gerung im Vergleich zum Master. Die Zeit, die wir ben\u00f6tigten, um das Problem der \"pl\u00f6tzlich abgeschalteten\" Slaves zu identifizieren und zu beheben, \u00fcberschritt die \"psychologische Grenze\" (in dieser Zeit h\u00e4tte sich eine Preisanpassung stattfinden k\u00f6nnen, und die Kunden h\u00e4tten veraltete Daten gesehen), und wir mussten alle Anfragen auf den Haupt-Datenbankserver umleiten. Dadurch arbeitete die Website langsam ... aber sie funktionierte wenigstens. Und w\u00e4hrend sich die Slaves erholten, blieben uns nur Optimierungen.\u00a0<\/p>\n

W\u00e4hrend die Slave-Server sich erholten, zogen sich die Minuten in die L\u00e4nge, der Master blieb \u00fcberlastet, und wir konzentrierten alle Kr\u00e4fte auf die Optimierung der aktiven Aufgaben gem\u00e4\u00df dem \"Pareto-Prinzip\": Wir w\u00e4hlten die TOP-Anfragen aus, die den gr\u00f6\u00dften Teil der Last verursachten, und begannen mit der Feinabstimmung. Dies geschah direkt \"im laufenden Betrieb\".<\/p>\n

Ein interessantes Ph\u00e4nomen war, dass eine bis zur Grenze belastete MySQL-Datenbank bereits auf geringf\u00fcgige Prozessverbesserungen reagierte. Die Optimierung einiger Abfragen, die nur 5 % der Gesamtlaste ausmachten, f\u00fchrte bereits zu einer merklichen Entlastung der CPU. Dadurch konnten wir ausreichende Ressourcen f\u00fcr den Betrieb von Master mit der Datenbank sicherstellen und die n\u00f6tige Zeit f\u00fcr die Wiederherstellung der Replikate erhalten.\u00a0<\/p>\n

Fazit:<\/strong> Bereits eine kleine Optimierung erm\u00f6glicht es, mehrere Stunden bei \u00dcberlastung zu \"\u00fcberleben\". Genau das hat uns zur Wiederherstellung der Replikaserver gereicht. \u00dcbrigens werden wir die technische Seite der Abfrageoptimierung in einem der n\u00e4chsten Beitr\u00e4ge besprechen. Abonnieren Sie also unseren Blog, wenn das f\u00fcr Sie von Nutzen sein k\u00f6nnte.<\/p><\/blockquote>\n

<\/p>\n

Organisieren Sie das Monitoring der Verf\u00fcgbarkeit von Partnerdiensten.<\/h3>\n

\nWir k\u00fcmmern uns um die Bearbeitung von Kundenauftr\u00e4gen, und deshalb interagieren unsere Dienste st\u00e4ndig mit externen APIs \u2013 das sind Schnittstellen zum Versenden von SMS, Zahlungsplattformen, Routing-Systeme, Geocoder, Finanzauskunftsdienste und viele andere Systeme. Als die Last rapide zunahm, stie\u00dfen wir auf die Einschr\u00e4nkungen der APIs unserer Partnerdienste, \u00fcber die wir zuvor nie nachgedacht hatten.<\/p>\n

Unerwartete \u00dcberschreitungen der Kontingente von Partnerdiensten k\u00f6nnen zu Ausfallzeiten bei Ihrem eigenen Dienst f\u00fchren. Viele APIs blockieren Kunden, die ihre Limits \u00fcberschreiten, und in einigen F\u00e4llen kann eine \u00dcberlastung der Anfragen die Produktion bei dem Partner \u00fcberlasten.\u00a0<\/p>\n

Zum Beispiel, w\u00e4hrend der Anstieg der Lieferungen hatten die begleitenden Dienste Schwierigkeiten bei der Verteilung und der Routenbestimmung. Infolgedessen kam es vor, dass Bestellungen aufgegeben wurden, aber der Dienst zur Routenplanung nicht funktionierte. Es ist zu sagen, dass unsere Logistiker in diesen Bedingungen praktisch das Unm\u00f6gliche geleistet haben, und die klare Zusammenarbeit des Teams half, tempor\u00e4re Ausf\u00e4lle der Dienste zu kompensieren. Aber ein solches Aufkommen an Anfragen kann nicht dauerhaft manuell verarbeitet werden, und irgendwann w\u00e4ren wir mit einer unzul\u00e4ssigen Diskrepanz zwischen Bestellungen und deren Erf\u00fcllung konfrontiert.\u00a0<\/p>\n

Es wurden eine Reihe von organisatorischen Ma\u00dfnahmen ergriffen, und die reibungslose Zusammenarbeit des Teams half uns, Zeit zu gewinnen, w\u00e4hrend wir neue Bedingungen vereinbarten und auf die Modernisierung der Dienste von einigen Partnern warteten. Es gibt auch andere APIs, die sich durch hohe Zuverl\u00e4ssigkeit und wettbewerbsf\u00e4hige Tarife bei hohem Traffic auszeichnen. Zu Beginn nutzten wir beispielsweise eine bekannte Karten-API zur Bestimmung der Lieferadresse. Doch am Monatsende erhielten wir eine saftige Rechnung von fast 2 Millionen Rubel. Daraufhin entschieden wir uns schnell, sie zu ersetzen. Ich werde keine Werbung machen, aber ich kann sagen, dass unsere Ausgaben erheblich gesenkt wurden.
\n\"Wie<\/p>\n

Fazit: <\/strong>Es ist unbedingt notwendig, die Bedingungen aller Partnerdienste zu \u00fcberwachen und dabei zu ber\u00fccksichtigen. Selbst wenn es heute scheint, dass sie Ihnen \u201emit einem gro\u00dfen Puffer\u201c zur Verf\u00fcgung stehen, bedeutet das nicht, dass sie morgen nicht zum Hindernis f\u00fcr Ihr Wachstum werden. Und nat\u00fcrlich ist es besser, sich im Voraus \u00fcber die finanziellen Bedingungen gestiegener Anforderungen an den Dienst zu einigen.\u00a0<\/p><\/blockquote>\n

<\/p>\n

Manchmal stellt sich heraus, dass \u201eman mehr Gold braucht<\/a><\/noindex>\u201c (c) nicht hilft<\/h3>\n

\nWir sind von \u00abEngp\u00e4ssen\u00bb in der Hauptdatenbank oder auf Anwendungsservern gewohnt, aber beim Skalieren k\u00f6nnen Probleme an unerwarteten Stellen auftreten. F\u00fcr die volltextliche Suche auf der Website nutzen wir die Engine Apache Solr. Mit steigendem Traffic haben wir eine Verz\u00f6gerung der Antwortzeiten festgestellt, und die CPU-Auslastung des Servers erreichte bereits 100 %. Was k\u00f6nnte einfacher sein \u2014 wir geben dem Solr-Container mehr Ressourcen.<\/p>\n

Statt des erwarteten Leistungszuwachses hat der Server einfach \u00bbgestoppt\u00ab. Er war sofort auf 100 % ausgelastet und antwortete noch langsamer. Urspr\u00fcnglich hatten wir 2 Kerne und 2 GB RAM. Wir haben beschlossen, das zu tun, was normalerweise hilft \u2014 wir gaben dem Server 8 Kerne und 32 GB. Es wurde alles viel schlimmer (wie genau und warum \u2014 werden wir in einem separaten Beitrag erkl\u00e4ren).\u00a0<\/p>\n

Nach einigen Tagen haben wir die Feinheiten dieser Angelegenheit verstanden und eine optimale Leistung bei 8 Kernen und 32 GB RAM erreicht. Diese Konfiguration erm\u00f6glicht es uns auch heute, die Last weiter zu steigern, was sehr wichtig ist, da das Wachstum nicht nur bei den Kunden, sondern auch in der Zahl der angeschlossenen Gesch\u00e4fte stattfindet \u2014 innerhalb von 2 Monaten hat sich ihre Anzahl verdoppelt.\u00a0<\/p>\n

Fazit: <\/strong>Standardmethoden wie \"mehr Hardware hinzuf\u00fcgen\" funktionieren nicht immer. Daher ist es wichtig, beim Skalieren eines Dienstes gut zu verstehen, wie er Ressourcen nutzt, und seine Leistung unter neuen Bedingungen im Voraus zu testen.\u00a0\n<\/p><\/blockquote>\n

<\/p>\n

Stateless \u2014 der Schl\u00fcssel zu einfachem horizontalem Scaling<\/h3>\n

\nInsgesamt folgt unser Team einem bekannten Ansatz: Dienste sollten keinen internen Zustand (stateless) aufweisen und unabh\u00e4ngig von der Ausf\u00fchrungsumgebung sein. Dies erm\u00f6glichte es uns, einen Anstieg der Last durch einfaches horizontales Scaling zu bew\u00e4ltigen. Allerdings hatten wir einen Ausnahme-Dienst \u2013 einen Handler f\u00fcr langwierige Hintergrundaufgaben. Dieser war zust\u00e4ndig f\u00fcr das Versenden von E-Mails und SMS, die Verarbeitung von Events, die Generierung von Feeds, das Importieren von Preisen und Best\u00e4nden sowie die Bildverarbeitung. Es stellte sich heraus, dass dieser Dienst von einem lokalen Dateispeicher abh\u00e4ngig war und nur in einer Instanz existierte.\u00a0<\/p>\n

Als die Anzahl der Aufgaben in der Warteschlange des Prozessors wuchs (was nat\u00fcrlich mit der steigenden Anzahl von Bestellungen geschah), wurde die Leistung des Hosts, auf dem der Prozessor und der Speicherplatz gehostet wurden, zum begrenzenden Faktor. Infolgedessen wurde die Aktualisierung des Sortiments und der Preise, das Versenden von Benachrichtigungen an die Benutzer und viele andere kritische Funktionen, die in der Warteschlange steckten, gestoppt. Das Ops-Team migrierte schnell den Speicherplatz in eine S3-\u00e4hnliche Netzwerkablage, wodurch wir mehrere leistungsstarke Maschinen hochfahren konnten, um den Background-Job-Prozessor zu skalieren.<\/p>\n

Fazit: <\/strong>Die Stateless-Regel muss f\u00fcr alle Komponenten ohne Ausnahme eingehalten werden, auch wenn es scheint, dass \"wir hier sicherlich nicht auflaufen werden\". Es ist besser, ein wenig Zeit in die richtige Organisation der Arbeitsweise aller Systeme zu investieren, als sp\u00e4ter in Eile den Code umschreiben und den \u00fcberlasteten Dienst reparieren zu m\u00fcssen.<\/p><\/blockquote>\n

<\/p>\n

7 Prinzipien f\u00fcr intensives Wachstum<\/h2>\n

\nTrotz der Verf\u00fcgbarkeit zus\u00e4tzlicher Kapazit\u00e4ten sind wir w\u00e4hrend unseres Wachstums auf einige Stolpersteine gesto\u00dfen. In dieser Zeit hat sich die Anzahl der Bestellungen um mehr als das Vierfache erh\u00f6ht. Aktuell liefern wir bereits \u00fcber 17.000 Bestellungen t\u00e4glich in 62 St\u00e4dten und planen, unsere geografische Reichweite weiter auszubauen \u2013 im ersten Halbjahr 2020 wird ein Servicestart in ganz Russland erwartet. Um mit der steigenden Last zurechtzukommen, und basierend auf unseren bisherigen Erfahrungen, haben wir f\u00fcr uns sieben grundlegende Arbeitsprinzipien in Zeiten des kontinuierlichen Wachstums festgelegt:<\/p>\n

    \n
  1. Incident-Management<\/strong>. Wir haben ein Board in Jira erstellt, auf dem jeder Vorfall als Ticket festgehalten wird. Dies hilft, die damit verbundenen Aufgaben effektiv zu priorisieren und zu bearbeiten. Denn im Grunde genommen ist es nicht schlimm, Fehler zu machen \u2013 schlimm ist es, zwei Mal aus demselben Grund Fehler zu machen. F\u00fcr die F\u00e4lle, in denen Vorf\u00e4lle schneller wiederholt auftreten, als wir die Ursache beheben k\u00f6nnen, sollte eine Handlungsanweisung bereitstehen, da es w\u00e4hrend hoher Last wichtig ist, blitzschnell zu reagieren.<\/li>\n
  2. \u00dcberwachung <\/strong>Dies ist f\u00fcr alle Infrastrukturkomponenten ohne Ausnahme erforderlich. Dank ihm konnten wir das Wachstum der Last prognostizieren und die \u201eEngp\u00e4sse\u201c richtig ausw\u00e4hlen, um Priorit\u00e4ten f\u00fcr deren Beseitigung zu setzen. Bei hoher Last wird wahrscheinlich alles, woran Sie nicht einmal gedacht haben, kaputt gehen oder anfangen zu stocken. Daher ist es am besten, neue Alarme direkt nach den ersten Vorf\u00e4llen zu erstellen, um sie zu \u00fcberwachen und vorauszusehen.<\/li>\n
  3. Richtige Alarme<\/strong> sind bei pl\u00f6tzlichem Anstieg der Last einfach unerl\u00e4sslich. Erstens sollten sie genau berichten, was kaputt gegangen ist. Zweitens sollte es nicht zu viele Alarme geben, denn eine Vielzahl von nicht kritischen Alarmen f\u00fchrt dazu, dass alle Benachrichtigungen ignoriert werden.<\/li>\n
  4. Anwendungen sollten stateless sein. <\/strong>Wir haben best\u00e4tigt, dass es f\u00fcr diese Regel keine Ausnahmen geben sollte. Es ist eine vollst\u00e4ndige Unabh\u00e4ngigkeit von der Laufzeitumgebung erforderlich. Dazu k\u00f6nnen Sie gemeinsame Daten in einer Datenbank oder beispielsweise direkt in S3 speichern. Am besten folgen Sie den Regeln. https:\/\/12factor.net<\/a><\/noindex>. W\u00e4hrend eines pl\u00f6tzlichen Anstiegs der Nutzung bleibt keine Zeit, um den Code zu optimieren, und man muss die Belastung durch direktes Erh\u00f6hen der Rechenressourcen und horizontale Skalierung bew\u00e4ltigen.<\/li>\n
  5. Quoten und Leistung externer Dienste. <\/strong>Bei schnellem Wachstum kann das Problem nicht nur in Ihrer Infrastruktur auftreten, sondern auch bei externen Diensten. Am frustrierendsten ist es, wenn dies nicht durch einen Ausfall geschieht, sondern aufgrund von Erreichung der Quoten oder Limits. Externe Dienste m\u00fcssen daher ebenso gut skalieren wie Sie selbst.\u00a0<\/li>\n
  6. Prozesse und Warteschlangen trennen. <\/strong>Das hilft enorm, wenn es an einem der Gateways zu Engp\u00e4ssen kommt. Wir w\u00fcrden keine Verz\u00f6gerungen bei der Daten\u00fcbertragung haben, wenn \u00fcberf\u00fcllte SMS-Versandwarteschlangen den Austausch von Benachrichtigungen zwischen den Informationssystemen nicht behindern w\u00fcrden. Au\u00dferdem w\u00e4re es einfacher, die Anzahl der Worker zu erh\u00f6hen, wenn sie separat arbeiten w\u00fcrden.<\/li>\n
  7. Finanzielle Realit\u00e4ten.<\/strong> Wenn die Datenstr\u00f6me explosionsartig ansteigen, bleibt keine Zeit, \u00fcber Tarife und Abonnements nachzudenken. Aber man sollte sie im Hinterkopf behalten, insbesondere wenn man ein kleines Unternehmen ist. Eine hohe Rechnung kann von jedem API-Betreiber sowie von Ihrem Hosting-Anbieter ausgestellt werden. Daher ist es wichtig, die Vertr\u00e4ge sorgf\u00e4ltig zu lesen.<\/li>\n<\/ol>\n

    <\/p>\n

    Fazit<\/h2>\n

    \nOhne Verluste ging es nicht, aber wir haben diese Phase \u00fcberstanden und versuchen heute, alle erkannten Prinzipien einzuhalten. Jede Maschine hat die M\u00f6glichkeit, die Leistung um das Vierfache zu steigern, um mit unerwarteten Situationen umzugehen.\u00a0<\/p>\n

    In den kommenden Beitr\u00e4gen werden wir unsere Erfahrungen bei der Untersuchung von Leistungsabf\u00e4llen in Apache Solr teilen. Au\u00dferdem berichten wir \u00fcber die Optimierung von Anfragen und wie die Interaktion mit der FNS dem Unternehmen hilft, Geld zu sparen. Abonnieren Sie unseren Blog, um nichts zu verpassen, und teilen Sie uns in den Kommentaren mit, ob Sie \u00e4hnliche Probleme w\u00e4hrend eines Traffic-Wachstums erlebt haben.<\/p>\n

    \"Wie<\/p>\n

    Nur registrierte Benutzer k\u00f6nnen an der Umfrage teilnehmen. Bitte melden Sie sich an.<\/a><\/noindex>Sind Sie an Contour interessiert?<\/p>\n

    Hatten Sie eine Verlangsamung oder einen Ausfall des Dienstes bei pl\u00f6tzlich wachsendem Traffic aufgrund von:<\/h2>\n