{"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\/sv\/blog\/administrirovanie\/kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali","title":{"rendered":"Hur vi hanterade en pl\u00f6tslig last\u00f6kning med x10 p\u00e5 distans och vilka slutsatser vi drog","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej, Habr! De senaste m\u00e5naderna har vi befunnit oss i en v\u00e4ldigt intressant situation, och jag skulle vilja dela med mig av v\u00e5r historia om hur vi skalade v\u00e5r infrastruktur. Under denna tid har SberMarket \u00f6kat sina best\u00e4llningar med fyra g\u00e5nger och lanserat sin tj\u00e4nst i 17 nya st\u00e4der. Den explosiva efterfr\u00e5gan p\u00e5 livsmedelsleveranser har kr\u00e4vt att vi skalar upp v\u00e5r infrastruktur. L\u00e4s mer om de mest intressanta och anv\u00e4ndbara slutsatserna efter br\u00e5kdelen.<\/p>\n

\"Hur
\n<\/a><\/noindex>
\nJag heter Dima Bobylev, jag \u00e4r teknisk direkt\u00f6r f\u00f6r SberMarket. Eftersom det h\u00e4r \u00e4r det f\u00f6rsta inl\u00e4gget i v\u00e5r blogg, vill jag s\u00e4ga n\u00e5gra ord om mig sj\u00e4lv och f\u00f6retaget. F\u00f6rra h\u00f6sten deltog jag i en t\u00e4vling f\u00f6r unga ledare inom Runet. F\u00f6r t\u00e4vlingen skrev jag en kort ber\u00e4ttelse<\/a><\/noindex> om hur vi p\u00e5 SberMarket ser p\u00e5 v\u00e5r interna kultur och tillv\u00e4gag\u00e5ngss\u00e4ttet f\u00f6r tj\u00e4nsteutveckling. \u00c4ven om jag inte lyckades vinna t\u00e4vlingen, formulerade jag \u00e4nd\u00e5 de grundl\u00e4ggande principerna f\u00f6r utvecklingen av IT-ekosystemet. <\/p>\n

N\u00e4r man leder ett team \u00e4r det viktigt att f\u00f6rst\u00e5 och hitta balansen mellan vad som beh\u00f6vs f\u00f6r aff\u00e4ren och behoven hos varje enskild utvecklare. Just nu v\u00e4xer SberMarket 13 g\u00e5nger \u00e5r f\u00f6r \u00e5r, och det p\u00e5verkar produkten, vilket kr\u00e4ver st\u00e4ndigt \u00f6kande volymer och hastighet i utvecklingen. Trots detta ger vi tillr\u00e4ckligt med tid \u00e5t utvecklarna f\u00f6r f\u00f6ranalys och kvalitativ kodning. Denna etablerade metod hj\u00e4lper inte bara till att skapa en fungerande produkt utan ocks\u00e5 till dess fortsatta skalning och utveckling. Som ett resultat av denna tillv\u00e4xt har SberMarket redan blivit ledande inom tj\u00e4nster f\u00f6r livsmedelsleverans: vi levererar dagligen omkring 18 000 best\u00e4llningar, \u00e4ven om det i b\u00f6rjan av februari var omkring 3 500.<\/p>\n

\"Hur
\nEn g\u00e5ng bad en kund SberMarkets kurir att leverera livsmedel p\u00e5 ett kontaktl\u00f6st s\u00e4tt \u2014 direkt till balkongen.<\/i><\/p>\n

Men l\u00e5t oss g\u00e5 p\u00e5 konkreta punkter. Under de senaste m\u00e5naderna har vi aktivt arbetat med att skala v\u00e5r f\u00f6retagsinfrastruktur. Behovet av detta f\u00f6rklarades av b\u00e5de externa och interna faktorer. Samtidigt som v\u00e5r kundbas v\u00e4xte, \u00f6kade antalet anslutna butiker fr\u00e5n 90 i b\u00f6rjan av \u00e5ret till mer \u00e4n 200 i mitten av maj. Vi f\u00f6rberedde oss naturligtvis, reserverade huvudinfrastrukturen och planerade f\u00f6r m\u00f6jligheten till vertikal och horisontell skalning av alla virtuella maskiner som var placerade i Yandex moln. Men verkligheten visade: \"Allt som kan g\u00e5 snett, kommer att g\u00e5 snett\". Idag vill jag dela med mig av de mest intressanta situationerna som intr\u00e4ffade under dessa veckor. Jag hoppas att v\u00e5r erfarenhet kommer att vara till nytta f\u00f6r er.<\/p>\n

Slave \u00e4r i full beredskap<\/h3>\n

\nRedan innan pandemin b\u00f6rjade m\u00e4rkte vi en \u00f6kning av antalet f\u00f6rfr\u00e5gningar till v\u00e5ra backend-servrar. Tendensen att best\u00e4lla produkter med hemleverans b\u00f6rjade ta fart, och med inf\u00f6randet av de f\u00f6rsta \u00e5tg\u00e4rderna f\u00f6r sj\u00e4lvisolering p\u00e5 grund av COVID-19, \u00f6kade belastningen dramatiskt under hela dagen. Det uppstod ett behov av att snabbt avlasta masterservrarna f\u00f6r huvuddatabasen och flytta en del av l\u00e4sf\u00f6rfr\u00e5gningarna till replikservrar (slave).<\/p>\n

Vi f\u00f6rberedde oss f\u00f6r det h\u00e4r steget i f\u00f6rv\u00e4g, och f\u00f6r liknande man\u00f6vrer hade redan tv\u00e5 slave-servrar startats. De arbetade huvudsakligen med batch-uppgifter f\u00f6r att generera informationsfl\u00f6den f\u00f6r datadelning med partner. Dessa processer skapade on\u00f6dig belastning och var helt rimligt uteslutna \"utanf\u00f6r parenteserna\" ett par m\u00e5nader tidigare.\u00a0<\/p>\n

Eftersom replikation skedde p\u00e5 Slave, h\u00f6ll vi oss till konceptet att applikationerna bara fick arbeta med dem i read only-l\u00e4ge. Disaster Recovery Plan f\u00f6reskrev att vid en katastrof skulle vi helt enkelt kunna montera Slave som Master och rikta alla skriv- och l\u00e4sf\u00f6rfr\u00e5gningar till Slave. Vi ville dock ocks\u00e5 anv\u00e4nda replikorna f\u00f6r analytiska avdelningens behov, s\u00e5 servrarna blev inte helt \u00f6verf\u00f6rda till read only-status, och varje v\u00e4rd hade sin egen upps\u00e4ttning anv\u00e4ndare, av vilka vissa hade skrivbeh\u00f6righet f\u00f6r att spara mellanresultat fr\u00e5n ber\u00e4kningar.<\/p>\n

Vi hade tillr\u00e4ckligt med kapacitet fr\u00e5n master b\u00e5de f\u00f6r skriv- och l\u00e4sfunktioner vid hantering av http-f\u00f6rfr\u00e5gningar upp till en viss belastning. I mitten av mars, precis n\u00e4r Sbermarket beslutade att helt \u00f6verg\u00e5 till distansarbete, b\u00f6rjade vi se en exponentiell \u00f6kning av RPS. Fler och fler av v\u00e5ra kunder gick in i sj\u00e4lvkarant\u00e4n eller arbetade hemifr\u00e5n, vilket p\u00e5verkade belastningssiffrorna.<\/p>\n

Prestandan hos \"mastern\" r\u00e4ckte inte l\u00e4ngre, s\u00e5 vi b\u00f6rjade avlasta n\u00e5gra av de tyngsta l\u00e4sf\u00f6rfr\u00e5gningarna till replikan. F\u00f6r att transparent styra skrivf\u00f6rfr\u00e5gningar till master och l\u00e4sningar till slaven anv\u00e4nde vi ruby-gemmet \"Octopus<\/a><\/noindex>\". Vi skapade en s\u00e4rskild anv\u00e4ndare med suffixet _readonly utan skrivbeh\u00f6righet. Men p\u00e5 grund av ett konfigurationsfel p\u00e5 en av v\u00e4rdarna skickades vissa skrivf\u00f6rfr\u00e5gningar till slave-servern under namnet p\u00e5 en anv\u00e4ndare som hade de n\u00f6dv\u00e4ndiga r\u00e4ttigheterna.<\/p>\n

Problemet visade sig inte direkt, eftersom den \u00f6kade belastningen fakturerade slaven. Inkonsistens i data uppdagades p\u00e5 morgonen, n\u00e4r slaven inte hade \"kommit ikapp\" mastern efter nattens importer. Vi skyllde p\u00e5 det h\u00f6ga trycket p\u00e5 tj\u00e4nsten och importen kopplad till lanseringen av nya butiker. Men att leverera data med flera timmars f\u00f6rdr\u00f6jning var oacceptabelt, s\u00e5 vi skiftade processerna till den andra analytiska slaven, eftersom den hade bb\u00e4sta resultatet (subjektiv \u00e5sikt).<\/strong>\u00e4ttre resurser och inte var belastad med l\u00e4sf\u00f6rfr\u00e5gningar (vilket var hur vi f\u00f6rklarade f\u00f6r oss sj\u00e4lva att det inte fanns n\u00e5gon replikationsf\u00f6rdr\u00f6jning).<\/p>\n

N\u00e4r vi hade reda p\u00e5 orsakerna till \"spridningen\" av huvudsakliga slaven, hade den analytiska redan g\u00e5tt ner av samma anledning. Trots att vi hade tv\u00e5 ytterligare servrar som vi hade planerat att flytta belastningen till i h\u00e4ndelse av att mastern skulle krascha, visade det sig p\u00e5 grund av ett olyckligt misstag att vi inte hade n\u00e5gon i kritiska \u00f6gonblick.<\/p>\n

Men eftersom vi gjorde mer \u00e4n bara dump av databasen (\u00e5terst\u00e4llningen vid den tidpunkten tog cirka 5 timmar), utan \u00e4ven en snapshot av master-servern, lyckades vi starta repliken inom 2 timmar. Dock v\u00e4ntade oss ett l\u00e5ngt loggning av replikation f\u00f6r en l\u00e5ng tid efter detta (eftersom processen k\u00f6rs i en tr\u00e5d, men det \u00e4r redan en helt annan historia).<\/p>\n

Slutsats:<\/strong> Efter den h\u00e4r incidenten blev det klart att vi m\u00e5ste \u00f6verge praktiken att begr\u00e4nsa skriv\u00e5tkomst f\u00f6r anv\u00e4ndare och g\u00f6ra hela servern readonly. Med en s\u00e5dan strategi kan man vara s\u00e4ker p\u00e5 att replikerna kommer att vara tillg\u00e4ngliga vid kritiska tillf\u00e4llen.<\/p><\/blockquote>\n

<\/p>\n

Optimering av \u00e4ven en tung f\u00f6rfr\u00e5gan kan \"\u00e5teruppliva\" databasen.<\/h3>\n

\n\u00c4ven om vi st\u00e4ndigt uppdaterar katalogen p\u00e5 webbplatsen, fanns det en liten f\u00f6rdr\u00f6jning i f\u00f6rfr\u00e5gningarna som vi k\u00f6rde p\u00e5 Slave-servrarna j\u00e4mf\u00f6rt med Master. Tiden vi tog f\u00f6r att uppt\u00e4cka och \u00e5tg\u00e4rda problemet med \"pl\u00f6tsligt avbrutna\" slavar var l\u00e4ngre \u00e4n den \"psykologiska barri\u00e4ren\" (under denna tid kan pris\u00e4ndringar ha intr\u00e4ffat, och kunderna skulle ha sett f\u00f6r\u00e5ldrad information), och vi var tvungna att omdirigera alla f\u00f6rfr\u00e5gningar till huvuddatabasen. Som ett resultat fungerade webbplatsen l\u00e5ngsamt... men \u00e5tminstone fungerade den. Och medan Slavarna \u00e5terh\u00e4mtade sig hade vi inget annat val \u00e4n att optimera.\u00a0<\/p>\n

Medan Slave-servrarna \u00e5terh\u00e4mtade sig, drog minuterna ut p\u00e5 tiden, Master var \u00f6verbelastad, och vi lade all v\u00e5r energi p\u00e5 att optimera aktiva uppgifter enligt \"Pareto-principen\": vi valde TOP-f\u00f6rfr\u00e5gningar som orsakade den st\u00f6rsta belastningen och b\u00f6rjade finjustera. Detta gjordes direkt \"i processen\".<\/p>\n

En intressant effekt var att en helt \u00f6verbelastad MySQL reagerar p\u00e5 \u00e4ven sm\u00e5 f\u00f6rb\u00e4ttringar av processerna. Optimering av ett par f\u00f6rfr\u00e5gningar som orsakade endast 5% av den totala belastningen visade redan en m\u00e4rkbar avlastning av CPU. Som ett resultat lyckades vi skapa en acceptabel resursmarginal f\u00f6r att f\u00e5 Master att arbeta med databasen och fick den n\u00f6dv\u00e4ndiga tiden f\u00f6r att \u00e5terst\u00e4lla repliker.\u00a0<\/p>\n

Slutsats:<\/strong> \u00c4ven en liten optimering kan g\u00f6ra att man \"\u00f6verlever\" vid \u00f6verbelastning i flera timmar. Det var precis vad vi beh\u00f6vde under \u00e5terst\u00e4llningstiden f\u00f6r servrarna med repliker. F\u00f6r \u00f6vrigt kommer vi att diskutera den tekniska sidan av f\u00f6rfr\u00e5geoptimering i ett av de kommande inl\u00e4ggen. S\u00e5 prenumerera g\u00e4rna p\u00e5 v\u00e5r blogg om detta kan vara till nytta f\u00f6r dig.<\/p><\/blockquote>\n

<\/p>\n

Organisera \u00f6vervakning av partner-tj\u00e4nsternas tillg\u00e4nglighet.<\/h3>\n

\nVi hanterar best\u00e4llningar fr\u00e5n kunder, och d\u00e4rf\u00f6r interagerar v\u00e5ra tj\u00e4nster st\u00e4ndigt med externa API:er - detta inkluderar gateway som skickar SMS, betalningsplattformar, routing-system, geokodare, skatteverket och m\u00e5nga andra system. N\u00e4r belastningen b\u00f6rjade \u00f6ka snabbt, b\u00f6rjade vi m\u00f6ta begr\u00e4nsningar fr\u00e5n API:erna hos v\u00e5ra partner som vi tidigare inte ens hade t\u00e4nkt p\u00e5.<\/p>\n

Ett ov\u00e4ntat \u00f6verskridande av kvoter hos partner-tj\u00e4nster kan leda till stillest\u00e5nd i din egen verksamhet. M\u00e5nga API:er blockerar klienter som \u00f6verstiger sina begr\u00e4nsningar, och i vissa fall kan ett \u00f6verskott av f\u00f6rfr\u00e5gningar \u00f6verbelasta produktionen hos partnern.\u00a0<\/p>\n

Till exempel, vid en \u00f6kning av antalet leveranser hade de medf\u00f6ljande tj\u00e4nsterna sv\u00e5rt att hantera f\u00f6rdelning och ruttbest\u00e4mning. Resultatet blev att best\u00e4llningar genomf\u00f6rdes, men tj\u00e4nsten som skapade rutten fungerade inte. V\u00e5ra logistikteam gjorde det som n\u00e4stan verkade om\u00f6jligt under dessa omst\u00e4ndigheter, och ett tydligt samarbete inom teamet bidrog till att kompensera f\u00f6r tillf\u00e4lliga avbrott i tj\u00e4nsterna. Men en s\u00e5dan m\u00e4ngd best\u00e4llningar g\u00e5r inte att hantera manuellt p\u00e5 en kontinuerlig basis, och efter ett tag skulle vi ha st\u00f6tt p\u00e5 en oacceptabel klyfta mellan best\u00e4llningarna och deras genomf\u00f6rande.\u00a0<\/p>\n

En rad organisatoriska \u00e5tg\u00e4rder vidtogs och det samordnade arbetet i teamet hj\u00e4lpte oss att vinna tid medan vi f\u00f6rhandlade om nya villkor och v\u00e4ntade p\u00e5 uppgraderingar av tj\u00e4nster fr\u00e5n vissa partner. Det finns \u00e4ven andra API:er som imponerar med h\u00f6g uth\u00e5llighet och ogynnsamma avgifter vid h\u00f6g trafik. Till exempel, i b\u00f6rjan anv\u00e4nde vi en k\u00e4nd karttj\u00e4nst API f\u00f6r att best\u00e4mma leveransadress. Men efter en m\u00e5nad fick vi en r\u00e4kning p\u00e5 n\u00e4stan 2 miljoner rubel. Efter det best\u00e4mde vi oss f\u00f6r att snabbt byta ut den. Jag kommer inte att g\u00f6ra reklam, men jag kan s\u00e4ga att v\u00e5ra kostnader minskade betydligt.
\n\"Hur<\/p>\n

Slutsats: <\/strong>Det \u00e4r viktigt att \u00f6vervaka villkoren f\u00f6r alla partner-tj\u00e4nster och ha dem i \u00e5tanke. \u00c4ven om det idag verkar som om de har \"god marginal\", s\u00e5 betyder det inte att de inte kan bli ett hinder f\u00f6r tillv\u00e4xt i morgon. Och sj\u00e4lvklart \u00e4r det b\u00e4st att f\u00f6rhandla om de ekonomiska villkoren f\u00f6r \u00f6kade f\u00f6rfr\u00e5gningar till tj\u00e4nsten i f\u00f6rv\u00e4g.\u00a0<\/p><\/blockquote>\n

<\/p>\n

Ibland visar det sig att \u201cmer guld beh\u00f6vs<\/a><\/noindex>\u201d (c) inte hj\u00e4lper<\/h3>\n

\nVi \u00e4r vana vid \"flaskhalsar\" i den prim\u00e4ra databasen eller p\u00e5 applikationsservrar, men n\u00e4r vi skalar upp kan problem dyka upp d\u00e4r man minst anar det. F\u00f6r fulltexts\u00f6kning p\u00e5 v\u00e5r webbplats anv\u00e4nder vi motorn Apache Solr. Med \u00f6kande belastning har vi noterat en minskning av svarstiden, samtidigt som serverns CPU-belastning n\u00e5dde 100%. Vad kan vara enklare \u2014 vi ger containern med Solr mer resurser.<\/p>\n

Ist\u00e4llet f\u00f6r den f\u00f6rv\u00e4ntade prestanda\u00f6kningen lade servern helt enkelt av. Den laddades omedelbart till 100% och svarade \u00e4nnu l\u00e5ngsammare. Ursprungligen hade vi 2 k\u00e4rnor och 2 GB RAM. Vi besl\u00f6t att g\u00f6ra det som vanligtvis hj\u00e4lper \u2014 vi gav servern 8 k\u00e4rnor och 32 GB. Allt blev mycket s\u00e4mre (hur och varf\u00f6r detta skedde kommer vi att ber\u00e4tta om i ett separat inl\u00e4gg).\u00a0<\/p>\n

Inom n\u00e5gra dagar satte vi oss in i detaljerna kring denna fr\u00e5ga, och vi uppn\u00e5dde optimal prestanda med 8 k\u00e4rnor och 32 GB. Denna konfiguration g\u00f6r det m\u00f6jligt att forts\u00e4tta \u00f6ka belastningen, vilket \u00e4r mycket viktigt, eftersom tillv\u00e4xten inte bara handlar om antalet kunder utan ocks\u00e5 om antalet anslutna butiker \u2014 under de senaste 2 m\u00e5naderna har deras antal f\u00f6rdubblats.\u00a0<\/p>\n

Slutsats: <\/strong>Standardmetoder som \"l\u00e4gg till mer h\u00e5rdvara\" fungerar inte alltid. S\u00e5 vid skalning av vilken tj\u00e4nst som helst \u00e4r det viktigt att f\u00f6rst\u00e5 hur den anv\u00e4nder resurser och testa dess funktion i de nya f\u00f6rh\u00e5llandena i f\u00f6rv\u00e4g.\u00a0\n<\/p><\/blockquote>\n

<\/p>\n

Stateless \u2014 nyckeln till enkel horisontell skalning<\/h3>\n

\n\u00d6verlag f\u00f6ljer v\u00e5rt team en v\u00e4lk\u00e4nd princip: tj\u00e4nster ska vara stateless och oberoende av k\u00f6rmilj\u00f6n. Detta har gjort det m\u00f6jligt f\u00f6r oss att hantera \u00f6kad belastning genom enkel horisontell skalning. Men vi hade en tj\u00e4nst som var ett undantag \u2013 hanteraren av l\u00e5nga bakgrundsuppgifter. Denna sk\u00f6tte utskick av e-post och sms, bearbetning av h\u00e4ndelser, generering av fl\u00f6den, import av priser och lager, samt bildbearbetning. Det visade sig att den var beroende av ett lokalt filsystem och fanns i en enda instans.\u00a0<\/p>\n

N\u00e4r antalet uppgifter i k\u00f6 f\u00f6r hanteraren v\u00e4xte (vilket naturligtvis h\u00e4nde med \u00f6kningen av antalet best\u00e4llningar) blev prestandan p\u00e5 v\u00e4rden d\u00e4r hanteraren och fillagret var placerade en begr\u00e4nsande faktor. Som resultat stannade uppdateringen av sortiment och priser, utskicken av notifieringar till anv\u00e4ndare och m\u00e5nga andra kritiska funktioner upp i k\u00f6n. Ops-teamet migrerade snabbt filagret till ett S3-liknande n\u00e4tverkslager, vilket gjorde att vi kunde starta flera kraftfulla maskiner f\u00f6r att skala hanteraren av bakgrundsuppgifter.<\/p>\n

Slutsats: <\/strong>Regeln f\u00f6r Stateless m\u00e5ste f\u00f6ljas f\u00f6r alla komponenter utan undantag, \u00e4ven om det verkar som \"h\u00e4r kommer vi definitivt inte att st\u00f6ta p\u00e5 problem\". Det \u00e4r b\u00e4ttre att l\u00e4gga lite tid p\u00e5 att organisera hur alla system fungerar r\u00e4tt \u00e4n att i panik beh\u00f6va skriva om koden och fixa en tj\u00e4nst som lider av \u00f6verbelastning.<\/p><\/blockquote>\n

<\/p>\n

7 principer f\u00f6r intensiv tillv\u00e4xt<\/h2>\n

\nTrots tillg\u00e5ngen p\u00e5 extra resurser trampade vi under tillv\u00e4xten p\u00e5 n\u00e5gra minor. Under denna tid har antalet best\u00e4llningar \u00f6kat med mer \u00e4n fyra g\u00e5nger. Nu levererar vi redan mer \u00e4n 17 000 best\u00e4llningar om dagen i 62 st\u00e4der och planerar att ytterligare ut\u00f6ka geografiskt \u2014 under f\u00f6rsta halvan av 2020 f\u00f6rv\u00e4ntas lanseringen av tj\u00e4nsten \u00f6ver hela Ryssland. F\u00f6r att hantera den v\u00e4xande belastningen, med tanke p\u00e5 de misstag vi redan har l\u00e4rt oss av, har vi identifierat 7 grundl\u00e4ggande principer f\u00f6r arbete under konstant tillv\u00e4xt:<\/p>\n

    \n
  1. Incidenthantering<\/strong>. Vi skapade en tavla i Jira d\u00e4r varje incident \u00e5terspeglas som en ticket. Detta hj\u00e4lper oss faktiskt att prioritera och utf\u00f6ra uppgifter relaterade till incidenten. Det \u00e4r ju i grunden inte farligt att g\u00f6ra misstag \u2014 det \u00e4r farligt att g\u00f6ra samma misstag tv\u00e5 g\u00e5nger. F\u00f6r de fall d\u00e4r incidenter upprepas innan vi har m\u00f6jlighet att \u00e5tg\u00e4rda orsaken, b\u00f6r en handlingsplan vara redo, eftersom det \u00e4r viktigt att reagera blixtsnabbt under h\u00f6g belastning.<\/li>\n
  2. \u00d6vervakning <\/strong>kr\u00e4vs f\u00f6r alla infrastrukturens komponenter utan undantag. Tack vare det kunde vi f\u00f6ruts\u00e4ga belastnings\u00f6kningen och korrekt v\u00e4lja \"flaskhalsar\" f\u00f6r prioritering av \u00e5tg\u00e4rder. Sannolikt kommer allt som du inte ens t\u00e4nkte p\u00e5 att bryta ihop eller b\u00f6rja bromsa vid h\u00f6g belastning. D\u00e4rf\u00f6r \u00e4r det b\u00e4st att skapa nya varningar direkt efter att de f\u00f6rsta incidenterna intr\u00e4ffat, f\u00f6r att \u00f6vervaka och f\u00f6rutse dem.<\/li>\n
  3. Korrekt varningar<\/strong> \u00e4r helt n\u00f6dv\u00e4ndiga vid en pl\u00f6tslig belastnings\u00f6kning. F\u00f6r det f\u00f6rsta ska de rapportera exakt vad som har g\u00e5tt s\u00f6nder. F\u00f6r det andra f\u00e5r det inte finnas f\u00f6r m\u00e5nga varningar, eftersom en \u00f6verfl\u00f6d av icke-kritiska varningar leder till att alla meddelanden ignoreras.<\/li>\n
  4. Applikationer m\u00e5ste vara stateless. <\/strong>Vi har insett att det inte f\u00e5r finnas n\u00e5gra undantag fr\u00e5n denna regel. Fullst\u00e4ndig oberoende fr\u00e5n k\u00f6rningsmilj\u00f6n beh\u00f6vs. F\u00f6r detta kan du lagra delade data i en databas eller, till exempel, direkt i S3. Det \u00e4r ocks\u00e5 b\u00e4ttre att f\u00f6lja reglerna https:\/\/12factor.net<\/a><\/noindex>. Vid en pl\u00f6tslig \u00f6kning finns det helt enkelt ingen tid f\u00f6r att optimera koden, och du m\u00e5ste hantera belastningen genom att direkt \u00f6ka datorkapaciteten och till\u00e4mpa horisontell skalning.<\/li>\n
  5. Kvoter och prestanda f\u00f6r externa tj\u00e4nster. <\/strong>Vid snabb tillv\u00e4xt kan problemet uppst\u00e5 inte bara i din infrastruktur, utan \u00e4ven i den externa tj\u00e4nsten. Det mest frustrerande \u00e4r n\u00e4r det h\u00e4nder inte p\u00e5 grund av ett fel, utan p\u00e5 grund av att kvoter eller gr\u00e4nser n\u00e5s. S\u00e5 externa tj\u00e4nster m\u00e5ste skala lika bra som du sj\u00e4lv.\u00a0<\/li>\n
  6. Separera processer och k\u00f6er. <\/strong>Detta hj\u00e4lper mycket n\u00e4r det uppst\u00e5r en blockering vid en av gatewayarna. Vi skulle inte ha st\u00f6tt p\u00e5 n\u00e5gra f\u00f6rseningar i data\u00f6verf\u00f6ringen om de fulla SMS-s\u00e4ndningsk\u00f6erna inte hade hindrat kommunikationen mellan informationssystemen. Och det skulle ha varit l\u00e4ttare att \u00f6ka antalet arbetare om de hade arbetat separat.<\/li>\n
  7. Finansiella realiteter.<\/strong> N\u00e4r datavolymerna \u00f6kar explosionsartat finns det ingen tid att t\u00e4nka p\u00e5 taxor och prenumerationer. Men man m\u00e5ste komma ih\u00e5g dem, s\u00e4rskilt om man \u00e4r ett litet f\u00f6retag. En stor r\u00e4kning kan utf\u00e4rdas av \u00e4garen av vilket API som helst, liksom av din hostingleverant\u00f6r. S\u00e5 det \u00e4r viktigt att l\u00e4sa avtalen noga.<\/li>\n<\/ol>\n

    <\/p>\n

    Slutsats<\/h2>\n

    \nInte utan f\u00f6rluster, men vi klarade av det steget, och idag f\u00f6rs\u00f6ker vi f\u00f6lja alla hittade principer, och varje maskin har m\u00f6jlighet att enkelt \u00f6ka prestandan fyra g\u00e5nger f\u00f6r att hantera ov\u00e4ntade situationer.\u00a0<\/p>\n

    I kommande inl\u00e4gg kommer vi att dela med oss av v\u00e5r erfarenhet av att unders\u00f6ka prestandafall i Apache Solr, samt ber\u00e4tta om optimering av fr\u00e5gorna och hur samarbetet med skattemyndigheten hj\u00e4lper f\u00f6retaget att spara pengar. Prenumerera p\u00e5 v\u00e5r blogg s\u00e5 att du inte missar n\u00e5got och ber\u00e4tta i kommentarerna om du har st\u00f6tt p\u00e5 liknande problem under trafik\u00f6kningar.<\/p>\n

    \"Hur<\/p>\n

    Endast registrerade anv\u00e4ndare kan delta i omr\u00f6stningen. Logga in<\/a><\/noindex>, tack.<\/p>\n

    Har du upplevt f\u00f6rdr\u00f6jning eller nedg\u00e5ng i service vid en pl\u00f6tslig \u00f6kning av belastningen p\u00e5 grund av:<\/h2>\n