{"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 Last um das 10-Fache im Homeoffice bew\u00e4ltigt haben und welche Schlussfolgerungen wir daraus gezogen haben.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo, \u0425\u0430\u0431\u0440! In den letzten paar Monaten haben wir eine sehr interessante Situation erlebt, und ich m\u00f6chte unsere Geschichte zum Thema Skalierung der Infrastruktur teilen. In dieser Zeit hat SberMarket die Bestellungen um das Vierfache gesteigert und den Dienst in 17 neuen St\u00e4dten gestartet. Der explosive Anstieg der Nachfrage nach Lebensmittellieferungen zwang uns zur Skalierung der Infrastruktur. Lesen Sie mehr \u00fcber die interessantesten und n\u00fctzlichsten Erkenntnisse im Folgenden.<\/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 der jungen Leader 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 Entwicklung des Dienstes sehen. Obwohl es nicht gelang, den Wettbewerb zu gewinnen, habe ich dennoch die wichtigsten Prinzipien f\u00fcr die Entwicklung eines IT-\u00d6kosystems formuliert. <\/p>\n

Bei der Leitung eines Teams ist es wichtig, ein Gleichgewicht zwischen den Anforderungen des Unternehmens und den Bed\u00fcrfnissen jedes einzelnen Entwicklers zu finden. SberMarket w\u00e4chst derzeit um das 13-fache im Vergleich zum Vorjahr, was sich auf das Produkt auswirkt und st\u00e4ndige Erh\u00f6hungen der Volumen und Tempi der Entwicklung erfordert. Trotz dieser Herausforderung nehmen wir uns jedoch ausreichend Zeit f\u00fcr die vorl\u00e4ufige Analyse und das qualitativ hochwertige Schreiben von Code. Der entwickelte Ansatz hilft nicht nur bei der Erstellung eines funktionierenden Produkts, sondern auch bei dessen weiterer Skalierung und Entwicklung. Infolge dieses Wachstums ist SberMarket bereits zum Marktf\u00fchrer unter den Lebensmittellieferdiensten geworden: Wir liefern t\u00e4glich etwa 18.000 Bestellungen aus, obwohl es Anfang Februar noch etwa 3.500 waren.<\/p>\n

\"Wie
\nEines Tages bat ein Kunde den Kurier von SberMarket, die Lebensmittel kontaktlos direkt auf den Balkon zu liefern.<\/i><\/p>\n

Kommen wir zu den Details. In den letzten Monaten haben wir aktiv an der Skalierung der Infrastruktur unseres Unternehmens gearbeitet. Dieser Bedarf wurde durch externe und interne Faktoren erkl\u00e4rt. Gleichzeitig mit der Erweiterung der Kundenbasis stieg die Anzahl der angeschlossenen Gesch\u00e4fte von 90 zu Beginn des Jahres auf \u00fcber 200 bis Mitte Mai. Nat\u00fcrlich haben wir uns vorbereitet, die Hauptinfrastruktur reserviert und geplant, sowohl vertikale als auch horizontale Skalierung aller virtuellen Maschinen, die in der Yandex-Cloud gehostet werden, zu erm\u00f6glichen. Doch die Praxis hat gezeigt: \u201eAlles, was schiefgehen kann, wird schiefgehen.\u201c Heute m\u00f6chte ich einige der interessantesten Situationen teilen, die in diesen Wochen aufgetreten sind. Ich hoffe, unsere Erfahrungen sind f\u00fcr Sie n\u00fctzlich.<\/p>\n

Slave ist vollst\u00e4ndig einsatzbereit<\/h3>\n

\nBereits vor Beginn der Pandemie haben wir einen Anstieg der Anfragen an unsere Backend-Server festgestellt. Der Trend, Produkte mit Lieferung nach Hause zu bestellen, nahm zu, und mit der Einf\u00fchrung der ersten Ma\u00dfnahmen zur Selbstisolierung aufgrund von COVID-19 stieg die Belastung dramatisch im Laufe des ganzen Tages. Es bestand die Notwendigkeit, die Master-Server der Hauptdatenbank schnell zu entlasten und einen Teil der Leseanfragen auf die Replikationsserver (Slave) zu verlagern.<\/p>\n

Wir hatten uns im Voraus auf diesen Schritt vorbereitet, und es wurden bereits zwei Slave-Server f\u00fcr diese Art von Man\u00f6ver in Betrieb genommen. Diese arbeiteten haupts\u00e4chlich an Batch-Aufgaben zur Generierung von Informations-Fids f\u00fcr den Datenaustausch mit Partnern. Diese Prozesse erzeugten zus\u00e4tzliche Last und wurden zu Recht bereits vor einigen Monaten \u201eausgegliedert\u201c.\u00a0<\/p>\n

Da auf dem Slave die Replikation stattfand, hielten wir uns an das Prinzip, dass Anwendungen nur im Read-Only-Modus damit arbeiten k\u00f6nnen. Der Disaster Recovery Plan sah vor, dass wir im Falle einer Katastrophe einfach den Slave an die Stelle des Masters mounten und alle Lese- und Schreibanfragen auf den Slave umschalten k\u00f6nnen. Allerdings wollten wir auch die Replikate f\u00fcr die Bed\u00fcrfnisse der Abteilung f\u00fcr Analytik nutzen, weshalb die Server nicht vollst\u00e4ndig in den Read-Only-Status versetzt wurden; jeder Host hatte seine eigene Benutzergruppe, und einige hatten Schreibrechte, um Zwischenresultate von Berechnungen zu speichern.<\/p>\n

Bis zu einem bestimmten Belastungsniveau hatten wir sowohl f\u00fcr das Schreiben als auch f\u00fcr das Lesen bei der Verarbeitung von HTTP-Anfragen genug Master. Mitte M\u00e4rz, als Sbermarket die Entscheidung traf, vollst\u00e4ndig auf Homeoffice umzusteigen, begann unser RPS sprunghaft zu steigen. Immer mehr unserer Kunden gingen in die Selbstisolation oder arbeiteten von zu Hause aus, was sich in den Lastkennzahlen niederschlug.<\/p>\n

Die Leistungsf\u00e4higkeit des \u201eMasters\u201c reichte nicht mehr aus, weshalb wir begannen, einen Teil der schwersten Leseanfragen an die Replik zu verlagern. Um die Querlenkung von Leseanfragen auf den Slave und von Schreibanfragen auf den Master transparent zu gestalten, verwendeten wir das Ruby-Gem \u201eOctopus<\/a><\/noindex>\u201c. Wir erstellten einen speziellen Benutzer mit dem Suffix _readonly ohne Schreibrechte. Aufgrund eines Fehlers in der Konfiguration eines der Hosts gingen jedoch einige Schreibanfragen im Namen eines Benutzers, der entsprechende Rechte hatte, an den Slave-Server.<\/p>\n

Das Problem trat nicht sofort auf, da die erh\u00f6hte Last das Nachziehen der Slaves verlangsamt hatte. Inkonsistenzen bei den Daten wurden am Morgen festgestellt, als nach n\u00e4chtlichen Importen die Slaves den Master nicht \u201eeingeholt\u201c hatten. Wir schoben dies auf die hohe Belastung des Dienstes selbst und den Import, der mit der Er\u00f6ffnung neuer Gesch\u00e4fte verbunden war. Aber Daten mit stundenlanger Verz\u00f6gerung bereitzustellen, war inakzeptabel, und wir wechselten die Prozesse auf den zweiten analytischen Slave, da dieser \u00fcber h\u00f6here Ressourcen verf\u00fcgte und nicht mit Leseanfragen belastet war (was wir uns ebenfalls als Erkl\u00e4rung f\u00fcr das Fehlen des Replikationslag erkl\u00e4rten).o<\/strong>Als wir die Ursachen f\u00fcr das \u201eAuseinanderlaufen\u201c des Haupt-Slaves kl\u00e4rte, war der analytische Slave bereits aus demselben Grund ausgefallen. Trotz der Verf\u00fcgbarkeit von zwei zus\u00e4tzlichen Servern, zu denen wir die Last im Falle eines Ausfalls des Masters verlagern wollten, stellte sich aufgrund eines bedauerlichen Fehlers heraus, dass im entscheidenden Moment keiner verf\u00fcgbar war.<\/p>\n

Da wir jedoch nicht nur einen Datenbank-Dump gemacht hatten (die Wiederherstellung dauerte zu diesem Zeitpunkt etwa 5 Stunden), sondern auch einen Snapshot des Master-Servers erstellt hatten, konnten wir die Replik in 2 Stunden starten. Allerdings erwartete uns danach ein l\u00e4nger dauerndes Anwachsen des Replikationsprotokolls (da der Prozess im Einzel-Thread-Modus l\u00e4uft, aber das ist eine ganz andere Geschichte).<\/p>\n

Da wir jedoch nicht nur den Dump der Datenbank erstellt haben (die Wiederherstellung dauerte zu diesem Zeitpunkt etwa 5 Stunden), sondern auch einen Snapshot des Master-Servers angefertigt haben, konnte die Replikation innerhalb von 2 Stunden gestartet werden. Allerdings wartete danach das Einspielen des Replikationsprotokolls auf uns, was eine lange Zeit in Anspruch nahm (da der Prozess im Einzelthread-Modus l\u00e4uft, aber das ist eine ganz andere Geschichte).<\/p>\n

Ausgabe:<\/strong> Nach solch einem Vorfall wurde klar, dass wir von der Praxis absehen m\u00fcssen, die Aufzeichnung f\u00fcr Benutzer einzuschr\u00e4nken, und den gesamten Server als readonly erkl\u00e4ren sollten. Bei diesem Ansatz kann man sich 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 \u00abwiederbeleben\u00bb.<\/h3>\n

\nObwohl wir den Katalog auf der Website st\u00e4ndig aktualisieren, wiesen die Abfragen, die wir auf die Slave-Server ausgelagert hatten, eine kleine Verz\u00f6gerung zum Master auf. Die Zeit, die wir ben\u00f6tigten, um das Problem der pl\u00f6tzlich ausgefallenen Slaves zu entdecken und zu beheben, \u00fcberschritt die \u00abpsychologische Grenze\u00bb (in dieser Zeit konnten Preisaktualisierungen stattfinden, w\u00e4hrend die Kunden veraltete Daten sahen), und wir mussten alle Abfragen auf den Haupt-Datenbankserver umschalten. Infolgedessen funktionierte die Website langsam... aber sie funktionierte wenigstens. W\u00e4hrend die Slave-Server wiederhergestellt wurden, blieb uns nichts anderes \u00fcbrig, als Optimierungen vorzunehmen.\u00a0<\/p>\n

W\u00e4hrend die Slave-Server sich erholten, zogen sich die Minuten langsam hin, der Master war \u00fcberlastet, und wir konzentrierten alle unsere Kr\u00e4fte auf die Optimierung aktiver Aufgaben gem\u00e4\u00df dem \u00abPareto-Prinzip\u00bb: Wir w\u00e4hlten die TOP-Abfragen aus, die den Gro\u00dfteil der Last erzeugten, und begannen mit dem Tuning. Dies geschah direkt \u00abim laufenden Betrieb\u00bb.<\/p>\n

Ein interessantes Ph\u00e4nomen war, dass ein bis zum Rand ausgelasteter MySQL-Server selbst auf geringf\u00fcgige Verbesserungen der Prozesse reagiert. Die Optimierung einiger Abfragen, die nur 5% der Gesamtlast ausmachten, zeigte bereits eine sp\u00fcrbare Entlastung der CPU. Infolgedessen gelang es uns, einen akzeptablen Ressourcenvorrat f\u00fcr die Arbeit des Masters mit der Datenbank sicherzustellen und die notwendige Zeit f\u00fcr die Wiederherstellung der Replikate zu gewinnen.\u00a0<\/p>\n

Ausgabe:<\/strong> Selbst eine kleine Optimierung erm\u00f6glicht es, w\u00e4hrend mehrerer Stunden bei \u00dcberlastung \u00abzu \u00fcberleben\u00bb. Das war genau die Zeit, die wir zur Wiederherstellung der Server mit den Replikaten ben\u00f6tigten. \u00dcbrigens werden wir die technische Seite der Optimierung von Abfragen in einem der n\u00e4chsten Beitr\u00e4ge besprechen. Also abonniert unseren Blog, wenn euch das n\u00fctzlich erscheinen k\u00f6nnte.<\/p><\/blockquote>\n

<\/p>\n

Organisieren Sie die \u00dcberwachung der Funktionsf\u00e4higkeit der Partnerdienste.<\/h3>\n

\nWir bearbeiten Kundenbestellungen, weshalb unsere Dienste st\u00e4ndig mit externen APIs interagieren \u2013 das sind Schnittstellen zum Versenden von SMS, Zahlungsplattformen, Routing-Systemen, Geocodern, dem FNS-Dienst und vielen anderen Systemen. Und als die Last schnell zunahm, stie\u00dfen wir auf die Begrenzungen der APIs unserer Partnerdienste, an die wir zuvor nicht einmal gedacht hatten.<\/p>\n

Ein unerwartetes \u00dcberschreiten der Quoten von Partnerdiensten kann zu Ausfallzeiten bei Ihrem eigenen Service f\u00fchren. Viele APIs blockieren Kunden, die die Grenzwerte \u00fcberschreiten, und in einigen F\u00e4llen kann eine \u00dcberzahl an Anfragen die Produktion beim Partner \u00fcberlasten.\u00a0<\/p>\n

Beispielsweise hatten die begleitenden Dienste im Moment des Anstiegs der Lieferungen Schwierigkeiten mit der Verteilung und der Bestimmung der Routen. Infolgedessen stellte sich heraus, dass die Bestellungen aufgegeben wurden, der Dienst zur Routenplanung jedoch nicht funktionierte. Unsere Logistiker haben unter diesen Bedingungen das Praktisch Unm\u00f6gliche geleistet, und die enge Zusammenarbeit des Teams half, zeitweilige Ausf\u00e4lle der Dienste auszugleichen. Aber so viele Antr\u00e4ge manuell zu bearbeiten, ist auf Dauer unhaltbar, und nach einiger Zeit w\u00e4ren wir mit einer unzul\u00e4ssigen L\u00fccke zwischen den Bestellungen und deren Ausf\u00fchrung konfrontiert worden.\u00a0<\/p>\n

Es wurden eine Reihe organisatorischer Ma\u00dfnahmen ergriffen, und die koordinierte Arbeit des Teams half, Zeit zu gewinnen, w\u00e4hrend wir \u00fcber neue Bedingungen verhandelten und auf die Modernisierung der Dienste einiger Partner warteten. Es gibt auch andere APIs, die durch hohe Ausdauer und wettbewerbsf\u00e4hige Preise bei hohem Verkehr erfreuen. Zu Beginn nutzten wir eine bekannte Kartographie-API zur Bestimmung der Adresse des Lieferpunkts. Am Ende des Monats erhielten wir eine Rechnung von fast 2 Millionen Rubel. Danach entschieden wir uns, es schnell zu ersetzen. Ich werde keine Werbung machen, aber ich kann sagen, dass unsere Ausgaben deutlich gesenkt wurden.
\n\"Wie<\/p>\n

Ausgabe: <\/strong>Es ist unbedingt erforderlich, die Betriebsbedingungen aller Partnerdienste zu \u00fcberwachen und sie im Hinterkopf zu behalten. Selbst wenn es heute so aussieht, als ob sie \"\u00fcberm\u00e4\u00dfig gro\u00dfz\u00fcgig\" sind, bedeutet das nicht, dass sie morgen nicht zum Hindernis f\u00fcr das Wachstum werden. Und nat\u00fcrlich ist es besser, im Voraus \u00fcber die finanziellen Bedingungen der gestiegenen Anforderungen an den Dienst zu verhandeln.\u00a0<\/p><\/blockquote>\n

<\/p>\n

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

\nWir sind es gewohnt, in der Hauptdatenbank oder auf Anwendungsservern auf \u201eEngp\u00e4sse\u201c zu sto\u00dfen, aber bei der Skalierung k\u00f6nnen Probleme dort auftreten, wo man sie nicht erwartet. F\u00fcr die Volltextsuche auf der Website verwenden wir die Engine Apache Solr. Mit zunehmender Last haben wir eine Verringerung der Antwortzeit 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

Anstelle des erwarteten Leistungszuwachses ist der Server einfach \u201egestorben\u201c. Er war sofort zu 100 % ausgelastet und reagierte noch langsamer. Urspr\u00fcnglich hatten wir 2 Kerne und 2 GB RAM. Wir beschlossen, das zu tun, was normalerweise hilft \u2014 wir gaben dem Server 8 Kerne und 32 GB. Alles wurde viel schlimmer (wie genau und warum \u2014 dazu werden wir in einem separaten Beitrag berichten).\u00a0<\/p>\n

Innerhalb weniger Tage haben wir die Feinheiten dieses Problems durchschaut und eine optimale Leistung bei 8 Kernen und 32 GB erreicht. Diese Konfiguration erm\u00f6glicht es uns auch heute, die Last weiterhin zu steigern, was sehr wichtig ist, da das Wachstum nicht nur bei den Kunden, sondern auch bei der Anzahl der angeschlossenen Gesch\u00e4fte \u2014 in den letzten 2 Monaten hat sich deren Anzahl verdoppelt.\u00a0<\/p>\n

Ausgabe: <\/strong>Standardmethoden wie \u201emehr Hardware hinzuf\u00fcgen\u201c funktionieren nicht immer. Daher ist es bei der Skalierung eines Dienstes wichtig, 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 h\u00e4lt sich unser Team an den bekannten Ansatz: Dienste sollten keinen internen Zustand (stateless) haben und unabh\u00e4ngig von der Laufzeitumgebung sein. Dies hat es uns erm\u00f6glicht, das Wachstum der Last durch einfaches horizontales Scaling zu bew\u00e4ltigen. Aber wir hatten einen Ausnahme-Service \u2014 den Verarbeiter von langwierigen Hintergrundaufgaben. Er war f\u00fcr den Versand von E-Mails und SMS, die Verarbeitung von Events, die Generierung von Feeds, den Import von Preisen und Best\u00e4nden sowie die Verarbeitung von Bildern zust\u00e4ndig. Es stellte sich heraus, dass er von einem lokalen Dateispeicher abh\u00e4ngte und nur einmal vorhanden war.\u00a0<\/p>\n

Als die Anzahl der Aufgaben in der Warteschlange des Prozessors wuchs (was mit der Anzahl der Bestellungen nat\u00fcrlich einherging), wurde die Leistung des Hosts, auf dem der Prozessor und der Datei-Speicher untergebracht waren, zum limitierenden Faktor. In der Folge blieben das Aktualisieren des Sortiments und der Preise, das Versenden von Benachrichtigungen an die Nutzer und viele andere kritische Funktionen, die in der Warteschlange feststeckten, stehen. Das Ops-Team migrierte umgehend den Datei-Speicher in einen S3-\u00e4hnlichen Cloud-Speicher, was es uns erm\u00f6glichte, mehrere leistungsstarke Maschinen hochzufahren, um den Hintergrund-Prozessor zu skalieren.<\/p>\n

Ausgabe: <\/strong>Das Stateless-Prinzip muss f\u00fcr alle Komponenten ohne Ausnahme eingehalten werden, auch wenn es scheint, dass es \"hier sicher nicht problematisch wird.\" Es ist besser, etwas Zeit in die ordnungsgem\u00e4\u00dfe Organisation der Arbeit aller Systeme zu investieren, als sp\u00e4ter in Eile den Code umzuschreiben und einen \u00fcberlasteten Service zu reparieren.<\/p><\/blockquote>\n

<\/p>\n

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

\nTrotz der Verf\u00fcgbarkeit zus\u00e4tzlicher Ressourcen sind wir w\u00e4hrend des Wachstums auf einige Schwierigkeiten gesto\u00dfen. In dieser Zeit hat sich die Anzahl der Bestellungen um mehr als das Vierfache erh\u00f6ht. Jetzt liefern wir bereits \u00fcber 17.000 Bestellungen pro Tag in 62 St\u00e4dten und planen, die geografische Reichweite noch weiter auszubauen \u2014 im ersten Halbjahr 2020 wird der Start des Service in ganz Russland erwartet. Um mit der wachsenden Belastung zurechtzukommen, unter Ber\u00fccksichtigung der bereits gemachten Erfahrungen, haben wir 7 grundlegende Arbeitsprinzipien unter Bedingungen st\u00e4ndigen Wachstums aufgestellt:<\/p>\n

    \n
  1. Incident Management<\/strong>. Wir haben ein Board in Jira erstellt, auf dem jeder Vorfall als Ticket erfasst wird. Dies wird helfen, die mit dem Vorfall verbundenen Aufgaben tats\u00e4chlich zu priorisieren und auszuf\u00fchren. Denn im Grunde ist es nicht schlimm, Fehler zu machen \u2014 schlimm ist es, zweimal denselben Fehler zu machen. F\u00fcr die F\u00e4lle, in denen Vorf\u00e4lle wiederholt auftreten, bevor die Ursache behoben werden kann, sollte eine Handlungsanweisung bereitstehen, denn in Zeiten hoher Belastung ist es wichtig, blitzschnell zu reagieren.<\/li>\n
  2. \u00dcberwachung <\/strong>Es ist f\u00fcr alle Infrastruktur-Elemente ohne Ausnahme erforderlich. Dank ihm konnten wir das Wachstum der Belastung prognostizieren und die \u201eFlaschenh\u00e4lse\u201c f\u00fcr die Priorisierung der Behebung richtig ausw\u00e4hlen. Wahrscheinlich wird bei hoher Belastung alles kaputtgehen oder anfangen zu stocken, an das Sie nicht einmal gedacht haben. Daher ist es am besten, neue Alarme sofort nach dem Auftreten der ersten Vorf\u00e4lle zu erstellen, um deren \u00dcberwachung und Vorwegnahme zu erm\u00f6glichen.<\/li>\n
  3. Die richtigen Alarme<\/strong> sind bei einem pl\u00f6tzlichen Anstieg der Last einfach unverzichtbar. Erstens m\u00fcssen sie genau berichten, was kaputtgegangen ist. Zweitens sollten es nicht zu viele Alarme geben, denn eine F\u00fclle von nicht kritischen Alarmen f\u00fchrt dazu, dass alle Benachrichtigungen v\u00f6llig ignoriert werden.<\/li>\n
  4. Anwendungen sollten zustandslos sein. <\/strong>Wir haben festgestellt, dass es f\u00fcr diese Regel keine Ausnahmen geben darf. Es ist eine vollst\u00e4ndige Unabh\u00e4ngigkeit von der Laufzeitumgebung erforderlich. Dazu k\u00f6nnen Sie gemeinsam genutzte Daten in einer Datenbank oder zum Beispiel direkt in S3 speichern. Noch besser ist es, die Regeln zu befolgen https:\/\/12factor.net<\/a><\/noindex>. W\u00e4hrend eines pl\u00f6tzlichen Anstiegs bleibt keine Zeit, um den Code zu optimieren, und man muss mit direkter Erh\u00f6hung der Rechenressourcen und horizontaler Skalierung umgehen.<\/li>\n
  5. Quoten und die Leistung externer Dienste. <\/strong>Bei schnellem Wachstum kann das Problem nicht nur in Ihrer Infrastruktur, sondern auch im externen Dienst auftreten. Das Frustrierendste ist, wenn dies nicht aufgrund eines Ausfalls geschieht, sondern weil Quoten oder Limits erreicht werden. Daher m\u00fcssen externe Dienste genauso gut skalieren wie Sie selbst.\u00a0<\/li>\n
  6. Trennen Sie Prozesse und Warteschlangen. <\/strong>Das hilft sehr, wenn es an einem der Gateways zu einem Engpass kommt. Wir h\u00e4tten keine Verz\u00f6gerungen beim Datentransfer erlebt, wenn volle Warteschlangen f\u00fcr das Versenden von SMS nicht den Austausch von Benachrichtigungen zwischen Informationssystemen behindert h\u00e4tten. Au\u00dferdem w\u00e4re es einfacher gewesen, die Anzahl der Worker zu erh\u00f6hen, wenn sie separat gearbeitet h\u00e4tten.<\/li>\n
  7. Finanzielle Realit\u00e4ten.<\/strong> Wenn die Datenstr\u00f6me explosionsartig wachsen, bleibt keine Zeit, \u00fcber Tarife und Abonnements nachzudenken. Aber man sollte daran denken, besonders wenn man ein kleines Unternehmen ist. Eine hohe Rechnung kann jeder API-Besitzer und auch Ihr Hosting-Anbieter ausstellen. Daher ist es wichtig, die Vertr\u00e4ge sorgf\u00e4ltig zu lesen.<\/li>\n<\/ol>\n

    <\/p>\n

    Fazit<\/h2>\n

    \nNicht ohne Verluste, aber wir haben diese Phase \u00fcberstanden und versuchen heute, alle gefundenen Prinzipien einzuhalten. Jede Maschine hat die M\u00f6glichkeit, die Leistung um das Vierfache zu steigern, um mit unvorhergesehenen Ereignissen umzugehen.\u00a0<\/p>\n

    In den n\u00e4chsten Beitr\u00e4gen teilen wir unsere Erfahrungen bei der Untersuchung von Leistungseinbr\u00fcchen in Apache Solr und erkl\u00e4ren, wie die Interaktion mit der FNS dem Unternehmen hilft, Geld zu sparen. Abonnieren Sie unseren Blog, um nichts zu verpassen, und erz\u00e4hlen Sie in den Kommentaren, ob Ihnen \u00e4hnliche Probleme beim Anstieg des Traffics passiert sind.<\/p>\n

    \"Wie<\/p>\n

    Nur registrierte Benutzer k\u00f6nnen an der Umfrage teilnehmen. Bitte einloggen<\/a><\/noindex>.<\/p>\n

    Hatten Sie langsame Reaktionen oder einen Ausfall des Dienstes bei pl\u00f6tzlichem Anstieg der Last aufgrund von:<\/h2>\n