Alla pratar om utvecklings- och testprocesser, utbildning av personal, ökad motivation, men dessa processer Àr fÄ nÀr en minuts stillestÄnd kostar astronomiska pengar. Vad ska man göra nÀr man hanterar finansiella transaktioner under en strikt SLA? Hur kan man öka pÄlitligheten och redundansen i dina system, utan att involvera utveckling och testning?
NÀsta konferens av HighLoad++ Àger rum den 6 och 7 april 2020 i Sankt Petersburg. Mer information och biljetter finns pÄ . Den 9 november, 18:00. HighLoad++ Moskow 2018, sal "Deli + Kalkutta". Sammanfattningar och .
Evgenij Kuzovlev (hĂ€refter EK): â Hej vĂ€nner! Jag heter Evgenij Kuzovlev. Jag kommer frĂ„n företaget EcommPay, den specifika avdelningen Ă€r EcommPay IT, IT-avdelningen inom koncernen. Idag ska vi prata om stillestĂ„nd â hur man undviker det och hur man minimerar konsekvenserna om det inte gĂ„r att undvika. Temat som presenterades Ă€r: "Vad gör man nĂ€r en minut av stillestĂ„nd kostar 100 000 dollar"? För att förvarna, siffrorna Ă€r jĂ€mförbara.
Vad sysslar EcommPay IT med?
Vem Àr vi? Varför stÄr jag hÀr framför er? Varför har jag rÀtt att berÀtta nÄgot för er hÀr? Och vad ska vi prata mer detaljerat om hÀr?
EcommPay-koncernen Ă€r en internationell förvĂ€rvare. Vi processar betalningar över hela vĂ€rlden â i Ryssland, Europa, och Sydostasien (All Around the World). Vi har 9 kontor, 500 anstĂ€llda totalt och cirka hĂ€lften av dem Ă€r IT-specialister. Allt vi gör, allt vi tjĂ€nar pengar pĂ„, har vi skapat sjĂ€lva.
Vi har utvecklat alla vĂ„ra produkter (och vi har rĂ€tt mĂ„nga â i vĂ„r serie av stora IT-produkter har vi cirka 16 olika komponenter); vi skriver sjĂ€lva, vi utvecklar sjĂ€lva. Just nu hanterar vi omkring en miljon transaktioner om dagen (miljoner Ă€r nog det rĂ€tta sĂ€ttet att sĂ€ga det). Vi Ă€r fortfarande ett ungt företag â vi har funnits i ungefĂ€r sex Ă„r.
För sex Är sedan var det en startup, nÀr grabbarna kom tillsammans med affÀrsidén. De var förenade av en idé (inget annat fanns, förutom idén), och vi sprang. Som vilken startup som helst sprang vi snabbt... För oss var hastighet viktigare Àn kvalitet.
Vid en viss tidpunkt stannade vi upp: vi insÄg att vi inte lÀngre kunde leva med den hastigheten och kvaliteten och att vi istÀllet mÄste fokusera pÄ kvalitet. I det ögonblicket beslutade vi att skriva en ny plattform som skulle vara rÀtt, skalbar och pÄlitlig. Vi började skriva denna plattform (började investera, utveckla, testa), men efter en tid insÄg vi att utvecklingen och testningen inte möjliggjorde ett nytt kvalitetslyft för tjÀnsten.
Ni skapar en ny produkt, ni slĂ€pper den pĂ„ produktion, men Ă€ndĂ„ gĂ„r nĂ„got fel nĂ„gonstans. Idag ska vi prata om hur man nĂ„r en ny kvalitetsnivĂ„ (hur vi gjorde det, om vĂ„r erfarenhet), med utveckling och testning bortsett; vi kommer att diskutera vad som Ă€r tillgĂ€ngligt för driften â vad driften kan göra sjĂ€lv, vad den kan erbjuda testningen för att pĂ„verka kvaliteten.
Nertid. Driftsprinciper.
Alltid den grundlĂ€ggande hörnstenen, om vad vi idag faktiskt kommer att prata om â nertid. Ett skrĂ€mmande ord. Om vi har en nertid â dĂ„ har vi problem. Vi springer för att Ă„terstĂ€lla, administratörer hĂ„ller servern â Gud förbjude den faller, som det sjungs i den dĂ€r lĂ„ten. Det Ă€r detta vi ska diskutera idag.
NÀr vi började Àndra vÄra angreppssÀtt formade vi fyra principer. De presenteras pÄ mina bilder:
Dessa principer Àr ganska enkla:
- Snabbt identifiera problemet.
- Ănnu snabbare bli av med det.
- HjÀlpa till att förstÄ orsaken (senare, för utvecklarna).
- Och standardisera angreppssÀtten.
Jag vill pÄpeka punkt nummer 2. Vi blir av med problemet, istÀllet för att lösa det. Att lösa Àr sekundÀrt. För oss Àr det primÀrt att anvÀndaren Àr skyddad frÄn detta problem. Det kommer att finnas i en viss isolerad miljö, men denna miljö kommer pÄ inget sÀtt att interagera med anvÀndaren. Faktiskt kommer vi att gÄ igenom dessa fyra grupper av problem (vissa mer i detalj, andra mindre), jag kommer att berÀtta vad vi anvÀnder, vilken erfarenhet vi har med lösningar.
ProblemavhjÀlpning: nÀr de intrÀffar och vad man ska göra Ät dem?
Men vi börjar inte i ordning, vi börjar med punkt nummer 2 â hur snabbt blir vi av med problemet? Det finns ett problem â vi mĂ„ste Ă„tgĂ€rda det. "Vad ska vi göra med detta?" â Ă€r den grundlĂ€ggande frĂ„gan. Och nĂ€r vi började tĂ€nka pĂ„ hur vi skulle lösa problemet, formulerade vi vissa krav som processen för att lösa problem bör följa.
För att formulera dessa krav beslutade vi oss för att stÀlla frÄgan: "NÀr uppstÄr vÄra problem?" Och problem, som det visade sig, förekommer i fyra fall:
- HĂ„rdvarufel.
- Fel pÄ externa tjÀnster.
- Byte av mjukvaruversion (den sÄ kallade deployment).
- Explosiv ökning av belastning.
Vi kommer inte att prata om de första tvĂ„. HĂ„rdvarufel Ă„tgĂ€rdas relativt enkelt: allt mĂ„ste vara duplicerat. Om det handlar om diskar â ska diskarna vara sammanstĂ€llda i RAID, om det handlar om en server â ska servern vara duplicerad, om ni har en nĂ€tverksinfrastruktur â bör ni installera en andra kopia av nĂ€tverksinfrastrukturen, det vill sĂ€ga ni tar och duplicerar. Och om nĂ„got gĂ„r sönder, vĂ€xlar ni till reservkraft. HĂ€r Ă€r det svĂ„rt att sĂ€ga mycket mer.
Det andra Àr fel pÄ externa tjÀnster. För de flesta system Àr det överhuvudtaget inget problem, men inte för oss. Eftersom vi behandlar betalningar Àr vi en aggregator som stÄr mellan anvÀndaren (som anger sina kortuppgifter) och bankerna, betalningssystemen ("Visa", "MasterCard", "Mir" osv). VÄra externa tjÀnster (betalningssystem, banker) tenderar att falla samman. Varken vi eller ni (om ni har sÄdana tjÀnster) kan pÄverka det.
Vad ska man göra dĂ„? HĂ€r finns tvĂ„ alternativ. För det första, om ni kan, bör ni pĂ„ nĂ„got sĂ€tt duplicera denna tjĂ€nst. Till exempel, om vi kan, omdirigerar vi trafiken frĂ„n en tjĂ€nst till en annan: om vi behandlade kort via "Sberbank", och "Sberbank" har problem â flyttar vi trafiken [villkorligt] till "Raiffeisen". Det andra vi kan göra â Ă€r att mycket snabbt upptĂ€cka fel pĂ„ externa tjĂ€nster, och dĂ€rför kommer vi att prata om reaktionshastighet i nĂ€sta del av presentationen.
Faktum Ă€r att av dessa fyra kan vi konkret pĂ„verka bytet av mjukvaruversioner â vidta Ă„tgĂ€rder som leder till förbĂ€ttringar i sammanhanget för distributioner och i samband med den explosiva ökningen av belastning. I sjĂ€lva verket har vi gjort detta. HĂ€r, Ă„terigen, en liten anmĂ€rkning...
Av dessa fyra problem löses flera omgÄende om du har en molntjÀnst. Om du befinner dig i molnen frÄn "Microsoft Azure", "Ozon", eller anvÀnder vÄra moln frÄn "Yandex" eller "Mail", sÄ blir Ätminstone hÄrdvarufel deras problem och du fÄr omedelbart en förbÀttrad situation nÀr det gÀller hÄrdvarufel.
Vi Ă€r ett nĂ„got okonventionellt företag. HĂ€r pratar alla om "Kubernetes" och moln â vi har varken "Kubernetes" eller moln. DĂ€remot har vi rack med hĂ„rdvara pĂ„ flera datacenter, och pĂ„ denna hĂ„rdvara mĂ„ste vi leva, vi mĂ„ste ta ansvar för allt detta. SĂ„ i detta sammanhang kommer vi att diskutera. SĂ„, angĂ„ende problemen. De första tvĂ„ tar vi bort hĂ€r.
Byte av mjukvaruversion. Grunder.
VÄra utvecklare har inte tillgÄng till produktion. Varför Àr det sÄ? Jo, vi Àr certifierade enligt PCI DSS, och vÄra utvecklare har helt enkelt inte rÀtt att grÀva i "prod". Punkt slut. Helt och hÄllet. DÀrför slutar utvecklingsansvaret exakt i det ögonblick dÄ utvecklingsavdelningen överlÀmnar byggandet för release.
VĂ„r andra grund, som vi ocksĂ„ har och som hjĂ€lper oss mycket â Ă€r att det inte finns nĂ„gra unika, dokumentationsfria kunskaper. Jag hoppas att ni har det pĂ„ samma sĂ€tt. För att om det inte Ă€r sĂ„ â kommer ni att fĂ„ problem. Problem uppstĂ„r nĂ€r dessa unika, odokumenterade kunskaper inte finns pĂ„ rĂ€tt tid och plats. LĂ„t oss sĂ€ga att en person vet hur man distribuerar en specifik komponent â om den personen inte Ă€r tillgĂ€nglig, Ă€r pĂ„ semester eller Ă€r sjuk â dĂ„ har ni problem.
Och den tredje grunden som vi har kommit fram till. Vi kom fram till den genom smĂ€rta, blod och tĂ„rar â vi kom fram till att varje byggnad innehĂ„ller fel, Ă€ven om den Ă€r utan fel. Vi har bestĂ€mt oss för att: nĂ€r vi distribuerar nĂ„got, nĂ€r vi gĂ„r live med nĂ„got â sĂ„ innebĂ€r vĂ„r byggnad fel. Vi har formulerat krav som vĂ„rt system mĂ„ste uppfylla.
Krav för byte av mjukvaruversion.
Det finns tre krav:
- Vi mÄste snabbt kunna rulla tillbaka distributionen.
- Vi mÄste minimera pÄverkan av en misslyckad distribution.
- Och vi mÄste kunna snabbt distribuera parallellt.
Precis i den ordningen! Varför? För att hastigheten vid distribution av en ny version inte Ă€r viktig i första hand, men det Ă€r viktigt för er att snabbt kunna rulla tillbaka om nĂ„got gĂ„r fel och minimera pĂ„verkan. Men om ni har en uppsĂ€ttning versioner i produktion, dĂ€r det visar sig att det finns ett fel (som snön frĂ„n klar himmel, det har inte genomförts nĂ„gon distribution, men felet finns) â sĂ„ Ă€r hastigheten pĂ„ efterföljande distribution viktig för er. Vad har vi gjort för att uppfylla dessa krav? Vi har tagit till en metodik:
Den Ă€r ganska kĂ€nd, vi har inte uppfunnit den â det Ă€r Blue/Green deployment. Vad Ă€r detta? För varje grupp av servrar som era applikationer körs pĂ„, bör det finnas en kopia. En "varm" kopia: det finns ingen trafik pĂ„ den, men vid vilken tidpunkt som helst kan denna trafik skickas till kopian. Denna kopia innehĂ„ller den tidigare versionen. Och vid distributionen rullar ni ut koden pĂ„ den inaktiva kopian. Sedan omdirigerar ni en del av trafiken (eller allt) till den nya versionen. SĂ„ för att Ă€ndra trafikflödet frĂ„n den gamla versionen till den nya, behöver ni bara göra en Ă„tgĂ€rd: ni behöver Ă€ndra lastbalanseraren upstream, Ă€ndra riktningen â frĂ„n en upstream till en annan. Det Ă€r mycket bekvĂ€mt och löser problemet med snabb omkoppling, snabb Ă„terstĂ€llning.HĂ€r Ă€r lösningen pĂ„ den andra frĂ„gan â minimering: ni kan skicka till den nya linjen, pĂ„ linjen med den nya koden, endast en del av er trafik (lĂ„t oss sĂ€ga, till exempel 2%). Och dessa 2% Ă€r inte 100%! Om ni har förlorat 100% av trafiken vid en misslyckad distribution â det Ă€r skrĂ€mmande, om ni har förlorat 2% av trafiken â det Ă€r obehagligt, men det Ă€r inte skrĂ€mmande. Dessutom kommer anvĂ€ndarna sannolikt inte ens att mĂ€rka det, eftersom i vissa fall (inte alla) hamnar samma anvĂ€ndare, nĂ€r de trycker pĂ„ F5, pĂ„ en annan, fungerande version.
Blue/Green deployment. Routing
Men allt Àr inte sÄ enkelt som att "göra Blue/Green deployment"⊠Alla vÄra komponenter kan delas in i tre grupper:
- det Àr frontend (betalningssidor som vÄra kunder ser);
- kÀrnan i bearbetningen;
- adapter för att arbeta med betalningssystem (banker, MasterCard, VisaâŠ).
Och hĂ€r finns en aspekt â aspekten handlar om routingen mellan linjerna. Om du bara vĂ€xlar 100% av trafiken har du inga problem med det. Men om du vill vĂ€xla 2% börjar frĂ„gorna dyka upp: "Hur gör man det?" Det enklaste sĂ€ttet Ă€r direkt: du kan stĂ€lla in Random Selection, Round Robin i nginx, sĂ„ att 2% gĂ„r till vĂ€nster och 98% gĂ„r till höger. Men det passar inte alltid.
Till exempel interagerar anvĂ€ndaren med systemet inte med bara en förfrĂ„gan. Det Ă€r normalt: 2, 3, 4, 5 förfrĂ„gningar â dina system kan vara desamma. Och om det Ă€r viktigt för dig att alla anvĂ€ndarförfrĂ„gningar gĂ„r till samma linje som den första förfrĂ„gan, eller (det andra momentet) att alla anvĂ€ndarförfrĂ„gningar gĂ„r till en ny linje efter vĂ€xlingen (anvĂ€ndaren kan ha börjat arbeta med systemet tidigare, innan vĂ€xlingen), â dĂ„ passar inte den slumpmĂ€ssiga fördelningen. DĂ„ finns det följande alternativ:
Det första alternativet, det enklaste â baserat pĂ„ grundlĂ€ggande parametrar frĂ„n klienten (IP Hash). Du har en IP, och du delar upp den höger-vĂ€nster baserat pĂ„ IP-adressen. DĂ„ fungerar det andra fallet som jag beskrev, nĂ€r deployment har skett, och anvĂ€ndaren redan kan ha börjat arbeta med ditt system, sĂ„ frĂ„n och med deployment gĂ„r alla förfrĂ„gningar till den nya linjen (antingen den samma, lĂ„t sĂ€ga).Om detta av nĂ„gon anledning inte passar dig, och du mĂ„ste nödvĂ€ndigtvis skicka förfrĂ„gningar till den linje dĂ€r den första, initierande anvĂ€ndarförfrĂ„gan kom, dĂ„ har du tvĂ„ alternativ...
Det första alternativet: du kan anvĂ€nda en betalversion av nginx+. DĂ€r finns det en mekanism för Sticky sessions, som vid den första förfrĂ„gan frĂ„n anvĂ€ndaren stĂ€ller in en session och kopplar den till en viss upstream. Alla efterföljande förfrĂ„gningar frĂ„n anvĂ€ndaren under sessionens livslĂ€ngd kommer att skickas till samma upstream som sessionen kopplades till.Det passade inte oss, eftersom vi redan hade en vanlig nginx. Att byta till nginx+ â det var inte nödvĂ€ndigtvis dyrt, men det var för oss nĂ„got smĂ€rtsamt och inte helt rĂ€tt. "Sticky sessions" fungerade inte för oss, till exempel av den enkla anledningen att "Sticky sessions" inte ger möjlighet att routa enligt "eller-eller". DĂ€r kan man stĂ€lla in att vi gör "Sticky sessions", till exempel baserat pĂ„ IP-adressen eller pĂ„ bĂ„de IP-adressen och cookies eller pĂ„ postparameter, men "eller-eller" â dĂ€r blir det svĂ„rare.
DĂ€rför kom vi fram till det fjĂ€rde alternativet. Vi anvĂ€nde Nginx pĂ„ 'sterioder' (detta Ă€r OpenResty) â det Ă€r samma Nginx som dessutom stödjer att inkludera last-skript. Du kan skriva ett last-skript, ge det till denna 'OpenResty', och detta last-skript kommer att köras nĂ€r en anvĂ€ndarförfrĂ„gan kommer in.
Och vi skrev faktiskt ett sÄdant litet skript, installerade 'OpenResty' och i detta skript gÄr vi igenom 6 olika parametrar genom konkatenering av 'Eller'. Beroende pÄ tillgÄngen till en viss parameter vet vi om anvÀndaren kommit till en sida eller en annan, till en linje eller en annan.
Blue/Green deploy. Fördelar och nackdelar.
SjÀlvklart hade vi kunnat göra det lite enklare (anvÀnda samma 'Sticky sessions'), men vi har dessutom den nyansen att inte bara anvÀndaren interagerar med oss inom en bearbetning av en transaktion... Utan dessutom interagerar betalningssystemen med oss: efter att vi har behandlat transaktionen (skickat en förfrÄgan till betalningssystemet) fÄr vi en callback.
Om vi sÀger att inom vÄr kontur kan vi skicka anvÀndarens IP-adress med i alla förfrÄgningar och baserat pÄ anvÀndarnas IP-adresser dela upp dem, sÄ sÀger vi inte till 'Visa': 'Grabbar, vi Àr ett retroföretag, vi Àr liksom internationella (pÄ hemsidan och i Ryssland)... Men skicka oss gÀrna anvÀndarens IP-adress i ett ytterligare fÀlt, ert standardiserade protokoll'! SjÀlvklart kommer de inte att gÄ med pÄ det.
DĂ€rför passade detta inte för oss â vi gjorde OpenResty. Följaktligen blev vĂ„r routning sĂ„ hĂ€r:Blue/Green deploy har, som sagt, fördelar och nackdelar.
Det finns tvÄ nackdelar:
- du behöver lÀgga tid pÄ routingen;
- den andra huvudsakliga nackdelen â kostnader.
Du behöver dubbelt sÄ mÄnga servrar, du behöver dubbelt sÄ mÄnga operativa resurser, du mÄste lÀgga dubbelt sÄ mycket kraft pÄ att upprÀtthÄlla hela denna djurpark.
Förresten, bland fördelarna finns ytterligare en sak jag inte nĂ€mnt tidigare: du har en reserv vid ökad belastning. Om du fĂ„r en explosionsartad ökning av trafiken, och en stor mĂ€ngd anvĂ€ndare kommer, sĂ„ sĂ€tter du bara pĂ„ den andra linjen med en 50/50-fördelning â och plötsligt har du dubbelt sĂ„ mĂ„nga servrar i din kluster tills du löser problemet med serverantalet.
Hur gör man en snabb deployment?
Vi diskuterade hur man löser problemet med minimalisering och snabb ÄterstÀllning, men frÄgan kvarstÄr: "Hur snabbt kan man deploya"?
HĂ€r Ă€r det kort och enkelt.- Du mĂ„ste ha ett CD-system (Continuous Delivery) â utan det gĂ„r det inte. Om du har en server kan du deploya manuellt. Vi har ungefĂ€r ett och ett halvt tusen servrar, sĂ„ klart kan vi inte ha ett team i storleken av det hĂ€r rummet bara för att deploya.
- Deployment mÄste ske parallellt. Om din deployment Àr sekventiell, dÄ Àr det dÄligt. En server Àr okej, men att deploya tusen fem hundra servrar kommer ta hela dagen.
- Ă
terigen, för att snabba upp processen, det hĂ€r Ă€r nog inte nödvĂ€ndigt lĂ€ngre. Vid deployment görs vanligtvis projektbyggande. Om du har ett webbprojekt finns det en frontend-del (du gör webbpaket, npm bygger â nĂ„got liknande), och den processen Ă€r i princip inte lĂ„ng â runt 5 minuter, men dessa 5 minuter kan vara kritiska. DĂ€rför gör vi till exempel sĂ„ hĂ€r: vi har tagit bort dessa 5 minuter, vi deployar artefakterna.
Vad Ă€r en artefakt? En artefakt Ă€r en byggnad som har genomgĂ„tt hela byggprocessen. Denna artefakt lagrar vi i ett artefaktlager. SĂ„dana lagrar har vi anvĂ€nt tvĂ„ stycken â det var Nexus och nu jFrog Artifactory. Vi anvĂ€nde ursprungligen "Nexus" eftersom vi började praktisera detta tillvĂ€gagĂ„ngssĂ€tt i Java-applikationer (det passade bra för det). Sedan lade vi Ă€ven in vissa applikationer skrivna i PHP dĂ€r; och "Nexus" passade inte lĂ€ngre, och vi valde dĂ€rför jFrog Artifactory, som kan hantera nĂ€stan allt. Vi har till och med kommit till den punkten att vi lagrar vĂ„ra egna binĂ€rpaket, som vi bygger för servrar.
Explosiv ökning av belastning
Vi har pratat om att byta programversion. NÀsta sak vi har Àr att det sker en explosiv ökning av belastningen. HÀr förstÄr jag kanske en felaktig sak om den explosiva ökningen av belastningen...
Vi har utvecklat ett nytt system â det Ă€r tjĂ€nsteorienterat, modernt och snyggt, med arbetare överallt, köer överallt, asynkronitet överallt. I sĂ„dana system kan data flöda genom olika kanaler. För den första transaktionen kan arbetare 1, 3 och 10 vara involverade, för den andra transaktionen â arbetare 2, 4 och 5. Och idag, lĂ„t oss sĂ€ga, pĂ„ morgonen har ni ett dataflöde som anvĂ€nder de tre första arbetarna, men pĂ„ kvĂ€llen Ă€ndras det plötsligt, och alla tre andra arbetare anvĂ€nds.
Och hÀr blir det sÄ att ni pÄ nÄgot sÀtt behöver skala arbetarna, ni behöver pÄ nÄgot sÀtt skala era tjÀnster, men utan att lÄta resurserna svÀlla.
Vi har definierat vĂ„ra krav. Dessa krav Ă€r ganska enkla: det ska finnas service discovery, parametrisering â allt standard för att bygga sĂ„dana skalbara system, förutom en punkt â resursamortisering. Vi har sagt att vi inte Ă€r redo att amortisera resurser för att lĂ„ta servrarna vĂ€rma luft. Vi har valt "Consul", vi har valt "Nomad" som hanterar vĂ„ra arbetare.Varför Ă€r detta ett problem för oss? LĂ„t oss backa lite. Just nu har vi cirka 70 betalningssystem bakom oss. PĂ„ morgonen gĂ„r trafiken genom "Sberbank", sedan kanske "Sberbank" gĂ„r ner, och vi vĂ€xlar till ett annat betalningssystem. Vi hade 100 arbetare som fungerade för "Sberbank", och efter det behöver vi plötsligt öka med 100 arbetare för det andra betalningssystemet. Och detta bör helst ske utan mĂ€nsklig medverkan. För om mĂ€nsklig medverkan Ă€r involverad mĂ„ste en ingenjör sitta tillgĂ€nglig 24/7 och bara ta hand om detta, eftersom sĂ„dana störningar, nĂ€r 70 system Ă€r kopplade till er, hĂ€nder regelbundet.
DĂ€rför tittade vi pĂ„ "Nomad", som har en öppen IP, och skrev vĂ„rt eget verktyg Scale-Nomad â ScaleNo, som gör ungefĂ€r följande: den övervakar köns tillvĂ€xt och minskar eller ökar antalet arbetare beroende pĂ„ köns dynamik. NĂ€r vi hade gjort det, tĂ€nkte vi: "Kanske vi ska open-sourcea det?" Sedan tittade vi pĂ„ det â det Ă€r sĂ„ enkelt som tvĂ„ ören.
Vi har fortfarande inte open-sourceat det, men om ni efter föredraget inser att ni behöver ett sĂ„dant verktyg, finns mina kontakter i den sista bilden â skriv gĂ€rna till mig. Om vi fĂ„r ihop 3-5 personer â vi kommer att open-sourcea det.
Hur fungerar det? LĂ„t oss ta en titt! För att sammanfatta: till vĂ€nster finns en del av vĂ„r övervakning: det Ă€r en linje, överst â behandlingstiden för hĂ€ndelser, i mitten â antalet transaktioner, lĂ€ngst ner â antalet arbetare.Om vi tittar pĂ„ denna bild finns det ett fel. I den övre grafen har en av kurvorna skjutits utanför 45 sekunder â en av betalningssystemen har kraschat. HĂ€r finns Ă€ven trafik under 2 minuter och en ökning av kön i det andra betalningssystemet, dĂ€r det inte fanns nĂ„gra arbetare (vi utnyttjade inte resurserna â tvĂ€rtom, vi utnyttjade resurserna korrekt). Vi ville inte överbelasta â dĂ€r var det minimalt, omkring 5â10 arbetare, men de klarade inte av det.
I den sista grafen syns en 'knöl' som just visar att 'Skaleno' fördubblade detta antal. Och sedan, nĂ€r grafen sjönk nĂ„got, minskade han lite â antalet arbetare Ă€ndrades automatiskt. SĂ„ hĂ€r fungerar detta. Vi pratade om punkt nummer 2 â 'Hur snabbt bli av med orsakerna'.
Ăvervakning. Hur snabbt identifierar man ett problem?
Nu Ă€r första punkten â 'Hur snabbt identifierar man ett problem?' Ăvervakning! Vi mĂ„ste snabbt förstĂ„ vissa saker. Vilka saker mĂ„ste vi snabbt förstĂ„?
Tre saker!- Vi mÄste snabbt förstÄ och snabbt bedöma funktionaliteten hos vÄra egna resurser.
- Vi mÄste snabbt förstÄ om det sker en avbrott, övervaka funktionaliteten hos system som Àr externa för oss.
- Den tredje punkten â att identifiera logiska fel. Det Ă€r nĂ€r systemet fungerar hos er, alla indikatorer Ă€r normala, men nĂ„got gĂ„r fel.
HÀr kommer jag nog inte att berÀtta nÄgot sÀrskilt fantastiskt. Jag kommer att vara kaptenen Styrdig. Vi sökte efter vad som finns pÄ marknaden. Vi har ett 'roligt zoo'. SÄ hÀr ser vÄrt zoo ut just nu:
Vi anvĂ€nder 'Zabbix' för att övervaka 'hĂ„rdvara', för att övervaka de viktigaste serverindikatorerna. 'Okmeter' anvĂ€nder vi för databaser. 'Grafana' och 'Prometheus' anvĂ€nder vi för alla andra indikatorer som inte passade under de första tvĂ„, delvis â med 'Grafana' och 'Prometheus', delvis â 'Grafana' med 'Influx' och Telegraf.För ett Ă„r sedan ville vi anvĂ€nda New Relic. En fantastisk grej, den kan göra allt. Men lika mycket som den kan, lika dyr Ă€r den. NĂ€r vi vĂ€xte till 1,5 tusen servrar kom en leverantör till oss och sa: «LĂ„t oss teckna ett avtal för nĂ€sta Ă„r». Vi sĂ„g pĂ„ priset och sa: nej, det tĂ€nker vi inte göra. Nu avstĂ„r vi frĂ„n New Relic, vi har ungefĂ€r 15 servrar kvar under New Relics övervakning. Priset visade sig vara helt galet.
Och det finns ett verktyg som vi har implementerat sjĂ€lva â det Ă€r Debugger. Först kallade vi det «Bagger», men sedan kom vĂ„r engelsklĂ€rare och skrattade sĂ„ mycket att vi bytte namn till «Debagger». Vad Ă€r det? Det Ă€r ett verktyg som i sjĂ€lva verket kör tester pĂ„ allmĂ€n funktionalitet av komponenterna pĂ„ 15-30 sekunder, som en «svart lĂ„da» av systemet.
Till exempel, om det Ă€r en extern sida (betalningssidan) â öppnar den bara sidan och ser hur den ska se ut. Om det handlar om bearbetning, skjuter den en testtransaktion â ser till att denna transaktion nĂ„r fram. Om det handlar om kopplingen till betalningssystemen â skjuter vi en testförfrĂ„gan dĂ€r vi kan och ser till att allt fungerar bra.
Vilka indikatorer Àr viktiga för övervakning?
Vad övervakar vi huvudsakligen? Vilka indikatorer Àr viktiga för oss?
- Svarstid / RPS pĂ„ framsidan â en mycket viktig indikator. Den svarar direkt pĂ„ att nĂ„got Ă€r fel.
- Antal bearbetade meddelanden i alla köer.
- Antal arbetare.
- Huvudmetrik för korrekthet.
Den sista punkten â en «affĂ€rsmĂ€ssig» metrik. Om du vill övervaka detsamma mĂ„ste du bestĂ€mma en eller tvĂ„ indikatorer som Ă€r de viktigaste för dig. VĂ„r metrik Ă€r genomströmning (det Ă€r förhĂ„llandet mellan antalet lyckade transaktioner och det totala flödet av transaktioner). Om nĂ„got förĂ€ndras inom 5-10-15 minuter â dĂ„ har vi problem (om det förĂ€ndras drastiskt).
Hur ser det ut för oss â ett exempel pĂ„ en av vĂ„ra dashboards:
Till vÀnster finns 6 grafer, som visar linjerna - antalet arbetare och antalet meddelanden i köerna. Till höger - RPS, RTS. LÀngst ner - den sÄ kallade "affÀrsmetrin". Och pÄ "affÀrsmetrin" kan vi direkt se att nÄgot har gÄtt fel pÄ de tvÄ mittersta graferna... Det Àr just nÀr det ytterligare en system har kraschat som stÄr bakom oss.Det andra vi behövde göra var att övervaka nedstÀngningarna av externa betalningssystem. HÀr anvÀnde vi OpenTracing - en mekanism, standard, paradigm, som gör det möjligt att spÄra distribuerade system; och vi modifierade det lite. Den standardiserade OpenTracing-paradigmen sÀger att vi bygger en spÄrning av varje enskild begÀran. Det var inte vad vi behövde, sÄ vi gjorde det till en total spÄrning, en aggregerad. Vi skapade ett verktyg som gör det möjligt för oss att övervaka hastigheten hos systemen som stÄr bakom oss.
Grafen visar oss att ett av betalningssystemen började svara efter 3 sekunder - vi fick problem. Samtidigt reagerar denna grej nÀr problemen började, med en tidsram pÄ 20-30 sekunder.Och den tredje klassen av övervakningsfel som finns - det Àr logisk övervakning.
Ărligt talat visste jag inte vad jag skulle rita pĂ„ den hĂ€r bilden, eftersom vi lĂ€nge letade pĂ„ marknaden efter nĂ„got som skulle passa oss. Vi hittade ingenting, sĂ„ vi var tvungna att göra det sjĂ€lva.
Vad menar jag med logisk övervakning? TĂ€nk dig: du skapar ett system (till exempel en klon av "Tinder"); du gör det, startar det. Den framgĂ„ngsrika chefen Vasya Pupkin installerade det pĂ„ sin telefon, ser en tjej, gillar henne... men like gĂ„r inte till tjejen - like gĂ„r till vakten Mikhailich i samma affĂ€rscentrum. Chefen gĂ„r ner, och undrar sen: "Varför ler den hĂ€r vakten Mikhailich sĂ„ trevligt Ă„t honom?"I sĂ„dana situationer... För oss lĂ„ter denna situation lite annorlunda, eftersom (jag har skrivit) detta Ă€r en reputationsförlust som indirekt leder till finansiella förluster. Vi har motsatt situation: vi kan drabbas av direkta finansiella förluster â till exempel om vi har genomfört en transaktion som framgĂ„ngsrik, men den var inte lyckad (eller tvĂ€rtom). Vi var tvungna att skriva vĂ„rt eget verktyg som följer antalet lyckade transaktioner i dynamik över en tidsperiod enligt affĂ€rsindikatorer. Vi hittade inget pĂ„ marknaden! Det var den hĂ€r tanken jag ville förmedla. För att lösa den hĂ€r typen av uppgifter finns det inget pĂ„ marknaden.
Detta var relaterat till frÄgan om hur man snabbt identifierar ett problem.
Hur man bestÀmmer orsakerna till deployment
Den tredje gruppen av uppgifter som vi löser â det Ă€r efter att vi har identifierat problemet, efter att vi har avfĂ€rdat det, skulle det vara bra att förstĂ„ orsaken för utveckling, för testning och att göra nĂ„got Ă„t det. DĂ€rför behöver vi forska, vi behöver samla loggar.
Om vi pratar om loggar (den huvudsakliga orsaken â loggar), sĂ„ ligger huvuddelen av loggarna hos oss i ELK Stack â nĂ€stan alla har det sĂ„. Vissa kanske inte anvĂ€nder ELK, men om du skriver loggar i gigabyte sĂ„ kommer du förr eller senare att landa i ELK. Vi skriver dem i terabyte.
Det finns ett problem hĂ€r. Vi har fixat, rĂ€ttat till ett fel för anvĂ€ndaren, började grĂ€va i vad det var, gick in i "Kibana", skrev in transaktions-ID:t och fick ut en sĂ„dan rullning (visar mycket). Och i denna rullning Ă€r ingenting klart. Varför? För att det Ă€r otydligt vilken del som tillhör vilken worker, vilken del som tillhör vilken komponent. Och i det ögonblicket insĂ„g vi att vi behövde spĂ„rning â den dĂ€r OpenTracing som jag nĂ€mnde.Vi tĂ€nkte pĂ„ detta för ett Ă„r sedan, vĂ€nde vĂ„rt fokus mot marknaden, och dĂ€r visade det sig att det fanns tvĂ„ verktyg â det Ă€r "Zipkin" och "Jaeger". "Jaeger" Ă€r i praktiken en ideologisk arvinge, en ideologisk fortsĂ€ttning pĂ„ "Zipkin". I "Zipkin" Ă€r allt bra, förutom att det inte kan aggregera, kan inte inkludera loggar i spĂ„rningen, endast tidsmĂ€ssig spĂ„rning. Och "Jaeger" stödde detta.
Vi tittade pĂ„ "Eger"; vi kan instrumentera applikationer och skriva till API:et (standarden för API:et för PHP var vid den tidpunkten, som sagt, inte godkĂ€nd â det var för ett Ă„r sedan, och nu Ă€r den redan godkĂ€nd), och det fanns absolut ingen klient. "Okej", tĂ€nkte vi, och skrev vĂ„r egen klient. Vad fick vi till? SĂ„ hĂ€r ser det ut:
I "Eger" skapas spans för varje meddelande. Det innebĂ€r att nĂ€r en anvĂ€ndare öppnar systemet ser han en eller tvĂ„ block för varje inkommande förfrĂ„gan (1-2-3 â sĂ„ mĂ„nga inkommande förfrĂ„gningar som anvĂ€ndaren hade, sĂ„ mĂ„nga block). För att underlĂ€tta för anvĂ€ndarna har vi lagt till taggar till loggar och tids spĂ„rning. DĂ€rför, i hĂ€ndelse av ett fel, kommer vĂ„r applikation att markera loggen med den relevanta taggen Error. Man kan filtrera efter taggen Error och endast de spans som innehĂ„ller detta block med fel visas. SĂ„ hĂ€r ser det ut nĂ€r vi expanderar span:
Inuti span finns ett antal spĂ„rningar. I detta fall Ă€r det tre testspĂ„rningar, och den tredje spĂ„rningen sĂ€ger oss att ett fel har intrĂ€ffat. HĂ€r ser vi ocksĂ„ tids spĂ„rningen: vi har en tidslinje högst upp, och vi kan se vid vilken tidsperiod loggen spelades in.DĂ€rför gick det mycket bra för oss. Vi skrev vĂ„rt eget tillĂ€gg och vi öppen kĂ€llkodade det. Om du vill arbeta med spĂ„rning, om du vill arbeta med "Eger" pĂ„ PHP-sprĂ„ket â hĂ€r Ă€r vĂ„rt tillĂ€gg, vĂ€lkommen till anvĂ€ndning, som man sĂ€ger:
VÄrt tillÀgg Àr en klient för att arbeta med OpenTracing API, gjort som en php-tillÀgg, sÄ att du kommer behöva samla ihop det och lÀgga in det i systemet. För ett Är sedan fanns det ingenting annat. Nu har det kommit andra klienter, som komponenter. HÀr Àr det ditt val: antingen laddar du ner komponenterna med Composer, eller sÄ anvÀnder du tillÀgget, upp till dig.Företagsstandarder
Vi talade om de tre buden. Det fjĂ€rde budet â att standardisera tillvĂ€gagĂ„ngssĂ€tten. Vad handlar detta om? Det handlar ungefĂ€r om detta:
Varför ordet "företags" hÀr? Inte för att vi Àr ett stort eller byrÄkratiskt företag, nej! Ordet "företags" ville jag anvÀnda hÀr i betydelsen att varje företag, varje produkt mÄste ha sina egna standarder, och det gÀller er ocksÄ. Vilka standarder har vi?- Vi har riktlinjer för deployment. Utan dem kan vi inte gÄ framÄt. Vi gör cirka 60 deployments i veckan, vilket innebÀr att vi stÀndigt har deploymentar. Vi har ocksÄ en regel i vÄra riktlinjer för deploymentar att vi inte fÄr göra nÄgra deploymentar pÄ fredagar - som princip gör vi inga deploymentar.
- Vi har obligatorisk dokumentation. Ingen ny komponent gÄr i produktion om det inte finns nÄgon dokumentation för den, Àven om den skapades av vÄra RnD-team. Vi krÀver en deploymentguide, en övervakningskarta och en ungefÀrlig beskrivning (ja, som programmerare kan skriva) av hur den hÀr komponenten fungerar och hur man felsöker den.
- Vi löser inte problemet, utan orsaken â som jag redan nĂ€mnt. Det Ă€r viktigt för oss att skydda anvĂ€ndaren frĂ„n problem.
- Vi har toleranser. Till exempel anser vi inte att det Àr downtime om vi under tvÄ minuter tappar 2 % av trafiken. Det rÀknas i princip inte i vÄr statistik. Om det Àr mer i procent eller tidsram, dÄ rÀknar vi det.
- Och vi skriver alltid post mortem-rapporter. Oavsett vad som hÀnder, varje situation som upptrÀder onormalt i produktion kommer att Äterspeglas i post mortem-rapporten. En post mortem Àr ett dokument dÀr du beskriver vad som hÀnde, en detaljerad tidslinje för vad du gjorde för att ÄtgÀrda det och (detta Àr en obligatorisk del!) vad du kommer att göra för att undvika det i framtiden. Detta Àr nödvÀndigt för efterföljande analys.
Vad rÀknas som downtime?
Vad ledde allt detta till?Det ledde till att (vi hade vissa stabilitetsproblem som varken kunder eller vi var nöjda med) under de senaste 6 mÄnaderna har vÄr stabilitetsnivÄ varit 99,97. Man kan sÀga att det inte Àr sÀrskilt mycket. Ja, vi har mÄlsÀttningar att strÀva efter. UngefÀr hÀlften av detta resultat Àr stabilitet som egentligen inte Àr vÄr, utan vÄr web application firewall som stÄr framför oss och anvÀnds som tjÀnst, men det spelar ingen roll för kunderna.
Vi har lĂ€rt oss att sova om natten. Ăntligen! För sex mĂ„nader sedan kunde vi inte. Och pĂ„ denna not vill jag lĂ€gga till en kommentar. IgĂ„r kvĂ€ll var det en fantastisk förelĂ€sning om systemet för att styra kĂ€rnreaktorer. Om jag hör mĂ€nniskor som har skrivit detta system â snĂ€lla, glöm det jag har sagt om "2 % â det Ă€r inte downtime". För er Ă€r 2 % downtime, Ă€ven om det bara handlar om tvĂ„ minuter!
Det Àr allt! Era frÄgor.
Om lastbalanserare och migration frÄn databasen
FrĂ„ga frĂ„n publiken (hĂ€refter â F): â God kvĂ€ll. Stort tack för en sĂ„ bra administrativ presentation! FrĂ„gan Ă€r kort, om era lastbalanserare. Ni nĂ€mnde att ni har WAF, sĂ„ jag förstĂ„r att ni anvĂ€nder nĂ„gon extern lösning som lastbalanserareâŠ
EK: â Nej, som lastbalanserare anvĂ€nder vi vĂ„ra egna tjĂ€nster. I det hĂ€r fallet Ă€r WAF enbart ett verktyg för att skydda mot DDoS-attacker.
L: â Kan ni ge nĂ„gra ord om lastbalanserare?
EK: â Som jag redan nĂ€mnt, det Ă€r en grupp servrar i openresty. Vi har just nu 5 grupper reserverade som enbart hanterar⊠det vill sĂ€ga, servern som enbart har openresty installerat, den proxyar bara trafiken. För att förstĂ„ hur mycket vi hanterar: just nu har vi en standard trafikbelastning pĂ„ flera hundra megabit. De klarar det bra, de anstrĂ€nger sig inte ens.
L: â Ănnu en enkel frĂ„ga. Det finns Blue/Green deployment. Vad gör ni till exempel med databas-migrationer?
EK: â Bra frĂ„ga! Titta, i vĂ„rt Blue/Green deployment har vi separata köer för varje linje. Det vill sĂ€ga, nĂ€r vi pratar om hĂ€ndelseköer som överförs frĂ„n arbetare till arbetare, finns det separata köer för blĂ„ linje och grön linje. NĂ€r vi pratar om sjĂ€lva databasen, har vi avsiktligt smalnat av den efter bĂ€sta förmĂ„ga, vi har nĂ€stan allt flyttat till köer, i databasen lagrar vi endast transaktionsstacken. Och transaktionsstacken Ă€r gemensam för alla linjer. NĂ€r det gĂ€ller databasen i detta sammanhang: vi delar inte upp den pĂ„ blĂ„ och grön, eftersom bĂ„da kodalternativen mĂ„ste veta vad som hĂ€nder med transaktionen.
VĂ€nner, jag har en liten prisatt som jag vill ge er â en bok. Jag behöver ge den för den bĂ€sta frĂ„gan.
L: â Hej. Tack för presentationen. HĂ€r Ă€r en frĂ„ga. Ni övervakar betalningar, ni övervakar tjĂ€nster som ni kommunicerar med⊠Men hur övervakar ni att en person pĂ„ nĂ„got sĂ€tt kommit till er betalningssida, genomfört betalningen, och projektet har krediterat pengarna? Det vill sĂ€ga, hur övervakar ni att mĂ€rket Ă€r tillgĂ€ngligt och har accepterat ert callback?
EK: â "MĂ€rket" för oss i detta fall Ă€r exakt som vilken extern tjĂ€nst som helst, sĂ„som betalningssystemet. Vi övervakar svarstiden för "mĂ€rket".
Om databasens kryptering
L: â Hej. Jag har en liten frĂ„ga bredvid. Ni har kĂ€nsliga data enligt PCI DSS. Jag ville veta hur ni lagrar PAN:er i köerna som ni behöver bearbeta? AnvĂ€nder ni nĂ„gon kryptering? Och hĂ€r Ă€r den följdfrĂ„gan: enligt PCI DSS mĂ„ste databasen krypteras om igen periodiskt vid förĂ€ndringar (till exempel uppsĂ€gning av administratörer) â hur gĂ„r det till med tillgĂ€ngligheten i sĂ„dana fall?
EK: â UtmĂ€rkt frĂ„ga! För det första lagrar vi inte PAN:er i köerna. Vi har egentligen inte rĂ€tt att lagra PAN överhuvudtaget i okrypterad form, sĂ„ vi anvĂ€nder en speciell tjĂ€nst (vi kallar den "Keydemon") â det Ă€r en tjĂ€nst som gör en enda sak: den tar emot ett meddelande och ger ett krypterat meddelande i utbyte. Och vi lagrar allt med detta krypterade meddelande. DĂ€rför Ă€r nyckellĂ€ngden under en kilobyte för att det ska vara riktigt sĂ€kert och pĂ„litligt.L: â Behövs det redan 2 kilobyte nu?
EK: â Det var vĂ€l 256 igĂ„r⊠Hur mycket mer kan man behöva?!
Detta Ă€r det första. För det andra stöder lösningen en procedur för ny kryptering â det finns tvĂ„ nyckelpĂ€rsar (kekar) som ger dek som krypterar (key Ă€r nycklar, dek Ă€r derivat av nycklar som krypterar). Och vid initiering av proceduren (den genomförs regelbundet, frĂ„n 3 mĂ„nader till ± nĂ„got) laddar vi en ny nyckelpĂ€rs, och vi genomför krypteringen pĂ„ nytt. Vi har separata tjĂ€nster som drar ut alla data, krypterar dem pĂ„ nytt; varje data har en identifierare för den nyckel som de Ă€r krypterade med. SĂ„ snart vi har krypterat data med de nya nycklarna raderar vi de gamla nycklarna.
Ibland behöver betalningar genomföras manuelltâŠ
L: â SĂ„ om det har kommit en Ă„terbetalning för nĂ„gon transaktion, krypterar ni med den gamla nyckeln?
EK: â Ja.
L: â DĂ„ har jag en liten frĂ„ga till. NĂ€r det intrĂ€ffar nĂ„got fel, ett haveri, en incident, mĂ„ste transaktionen drivas igenom manuellt. SĂ„dana situationer uppstĂ„r.
EK: â Ja, det hĂ€nder.
L: â Var fĂ„r ni dessa data ifrĂ„n? Eller gĂ„r ni sjĂ€lva manuellt in i detta lagringsutrymme?
EK: â Nej, det Ă€r klart â vi har ett slags backoffice-system som innehĂ„ller ett grĂ€nssnitt för vĂ„r support. Om vi inte vet vilket status en transaktion har (till exempel om betalningssystemet har svarat med timeout) â sĂ„ vet vi per automatik inte, det vill sĂ€ga vi tilldelar det slutliga statusen först nĂ€r vi Ă€r helt sĂ€kra. I det fallet klassificerar vi transaktionen i ett speciellt status för manuell behandling. PĂ„ morgonen nĂ€sta dag, sĂ„ snart supporten fĂ„r information om att det finns sĂ„dana transaktioner kvar i betalningssystemet, behandlar de dem manuellt i detta grĂ€nssnitt.
L: â Jag har ett par frĂ„gor. En av dem handlar om fortsĂ€ttningen av PCI DSS-zonen: hur extraherar ni loggar frĂ„n deras kontur? Jag stĂ€ller denna frĂ„ga eftersom utvecklaren kan ha lagt vad som helst i loggarna! Den andra frĂ„gan: hur implementerar ni hotfixar? Att göra det manuellt i databasen Ă€r ett alternativ, men kan det finnas gratis hotfixar â vad Ă€r dĂ„ rutinen? Och den tredje frĂ„gan, som nog handlar om RTO och RPO. Ni hade en tillgĂ€nglighet pĂ„ 99,97, nĂ€stan fyra nollor, men jag förstĂ„r att ni har en andra datacenter och en tredje datacenter och en femte datacenter⊠Hur synkroniserar ni dem, replikationen och allt annat?EK: â LĂ„t oss börja med den första. Var den första frĂ„gan om loggar? NĂ€r loggar skrivs finns det ett lager som maskerar alla kĂ€nsliga data. Det ser pĂ„ mönstret och pĂ„ ytterligare fĂ€lt. Följaktligen kommer vĂ„ra loggar ut med redan maskerade uppgifter och PCI DSS-konturen. Detta Ă€r en av de regelbundna uppgifterna som tilldelas testavdelningen. De Ă€r skyldiga att kontrollera varje uppgift, inklusive de loggar de skriver, och detta Ă€r en av de regelbundna uppgifterna vid kodgranskning, för att sĂ€kerstĂ€lla att utvecklaren inte har registrerat nĂ„got oönskat. Den efterföljande kontrollen genomförs regelbundet av informationssĂ€kerhetsavdelningen ungefĂ€r en gĂ„ng i veckan: loggar frĂ„n den senaste dagen vĂ€ljs slumpmĂ€ssigt och körs genom en speciell skanner-analysator frĂ„n testservrar för att kontrollera allt detta.
Om hotfixar. Det Ă€r inkluderat i vĂ„r utplacering av regler. Vi har en separat punkt angĂ„ende hotfixar. Vi anser att vi distribuerar hotfixar dygnet runt nĂ€r vi behöver det. SĂ„ snart versionen Ă€r byggd, sĂ„ snart den har körts, sĂ„ snart vi har artefakten â sĂ„ tillkallas en jouransvarig systemadministratör frĂ„n supporten, och han distribuerar det i det ögonblick som det behövs.Om "fyra nior". Den siffra vi har nu har verkligen uppnĂ„tts, och vi har strĂ€vat efter den Ă€ven med ett annat datacenter. Nu har vi ett andra datacenter, och vi börjar routa mellan dem, och frĂ„gan om replikering mellan datacentren Ă€r verkligen en icke-trivial frĂ„ga. Vi har försökt lösa det pĂ„ olika sĂ€tt: vi försökte anvĂ€nda "Tarantul" â vi lyckades inte, det sĂ€ger jag direkt. DĂ€rför kom vi fram till att vi gör en "senza" bestĂ€llning manuellt. Varje applikation kör faktiskt den nödvĂ€ndiga synkroniseringen av "change â done" asynkront mellan datacentren.
L: â Om ni har fĂ„tt en andra, varför har ni inte fĂ„tt en tredje? För att Split-brain ingen...
EK: â Och vi har inget "Split-brain". Eftersom varje applikation kör multimaster, spelar det ingen roll till vilket centrum förfrĂ„gan kom. Vi Ă€r beredda pĂ„ att om vĂ„rt ena datacenter faller (det planerar vi för) och mitt i en anvĂ€ndarförfrĂ„gan vĂ€xlar till det andra datacentret, Ă€r vi beredda att förlora den anvĂ€ndaren, verkligen; men det kommer att vara fĂ„, absolut fĂ„.
L: â God kvĂ€ll. Tack för presentationen. Ni pratade om er debugger som kör vissa testtransaktioner i produktion. Men berĂ€tta om testtransaktionerna! Hur djupt gĂ„r det?
EK: â Det gĂ„r igenom hela cykeln av hela komponenten. För komponenten finns ingen skillnad mellan testtransaktion och produktionstransaktion. Ur logikens synvinkel Ă€r det helt enkelt ett separat projekt i systemet, dĂ€r endast testtransaktioner körs.
L: â Och var avskĂ€r ni den? HĂ€r skickade Core...
EK: â Vi följer "Core" i det hĂ€r fallet för testtransaktioner... Vi har ett begrepp som heter routing: "Core" vet till vilket betalningssystem det ska skicka â vi skickar till ett falskt betalningssystem som helt enkelt ger en http-respons och inget mer.
L: â Kan ni berĂ€tta, Ă€r ert program skrivet som en stor monolit, eller har ni delat upp det i nĂ„gra tjĂ€nster eller till och med mikrotjĂ€nster?
EK: â Det Ă€r inte en monolit, sjĂ€lvklart, vi har en tjĂ€nsteorienterad applikation. Vi har ett skĂ€mt om att vi har tjĂ€nster bestĂ„ende av monoliter â de Ă€r faktiskt ganska stora. Att kalla det för mikrotjĂ€nster kĂ€nns inte riktigt rĂ€tt, men det Ă€r trots allt tjĂ€nster dĂ€r arbetare frĂ„n distribuerade maskiner arbetar.
Om en tjÀnst pÄ servern har blivit komprometterad...
L: â DĂ„ har jag en följdfrĂ„ga. Ăven om det skulle vara en monolit, har ni fortfarande mĂ„nga av dessa instant-servrar, alla hanterar i princip data, och frĂ„gan Ă€r: "Vid en kompromiss av en av instant-servrarna eller applikationen, av en specifik del, finns det nĂ„got slags Ă„tkomstkontroll? Vem kan göra vad? Vem ska man vĂ€nda sig till för att fĂ„ nĂ„gon information?
EK: â Ja, utan tvekan. SĂ€kerhetskraven Ă€r ganska strikta. För det första har vi öppna datarörelser, och portar Ă€r endast de som vi i förvĂ€g förutser kommer att hantera trafik. Om en komponent kommunicerar med databasen (sĂ€g, med MySQL) via 5-4-3-2, kommer den endast att ha 5-4-3-2 öppna, och andra portar, andra trafikriktningar kommer inte att vara tillgĂ€ngliga. Dessutom bör man förstĂ„ att vi i produktion har cirka 10 olika sĂ€kerhetszoner. Och Ă€ven om applikationen pĂ„ nĂ„got sĂ€tt skulle blivit komprometterad, Gud förbjude, sĂ„ kan angriparen inte fĂ„ Ă„tkomst till serveradministrationskonsolen, eftersom det Ă€r en annan sĂ€kerhetszon.L: â I det hĂ€r sammanhanget Ă€r jag mer intresserad av den punkt att ni har vissa avtal med tjĂ€nster â vad de kan göra, genom vilka "Ă„tgĂ€rder" de kan kommunicera med varandra... Och i ett normalt flöde begĂ€r vissa specifika tjĂ€nster en viss rad av "Ă„tgĂ€rder" frĂ„n den andra. De vĂ€nder sig normalt sett inte till andra, och har andra ansvarsomrĂ„den. Om en av dem skulle bli komprometterad, kan den dĂ„ dra nytta av "Ă„tgĂ€rderna" frĂ„n den tjĂ€nsten?
EK: â Jag förstĂ„r. Om kommunikation generellt var tillĂ„ten med en annan server i en normal situation, ja. Enligt SLA-kontraktet övervakar vi inte att du bara har tillĂ„telse för de första 3 "Ă„tgĂ€rderna", medan den fjĂ€rde "Ă„tgĂ€rden" inte Ă€r tillĂ„ten. Det skulle nog vara överflödigt för oss, eftersom vi redan har ett 4-nivĂ„ skyddssystem för konturer. Vi föredrar att skydda oss pĂ„ konturnivĂ„ snarare Ă€n pĂ„ nivĂ„ med interna komponenter.
Hur Visa, MasterCard och "Sberbank" fungerar
L: â Jag vill förtydliga en punkt om anvĂ€ndarens vĂ€xling frĂ„n ett datacenter till ett annat. SĂ„vitt jag vet arbetar "Visa" och "MasterCard" enligt det binĂ€ra synkrona protokollet 8583, dĂ€r finns mixar. Jag ville veta, menar vi nu vĂ€xlingen â Ă€r det direkt med "Visa" och "MasterCard" eller till betalningssystemen, till processorer?
EK: â Det handlar om mixarna. Mixarna har vi i ett datacenter.
L: â Grovt sagt, har ni en anslutningspunkt?
EK: â För "Visa" och "MasterCard" â ja. Bara för att "Visa" och "MasterCard" krĂ€ver ganska stora investeringar i infrastruktur för att ingĂ„ separata kontrakt för att fĂ„ ett andra par mixar, till exempel. De Ă€r reserverade inom ett datacenter, men om vĂ„rt datacenter, Gud förbjude, kraschar dĂ€r mixarna för anslutning till "Visa" och "MasterCard" stĂ„r, sĂ„ kommer vi att förlora kontakten med "Visa" och "MasterCard"âŠ
L: â Hur kan de vara reserverade? Jag vet att "Visa" tillĂ„ter att hĂ„lla bara en anslutning i princip!
EK: â De levererar sjĂ€lva utrustningen. Hur som helst, vi har fĂ„tt utrustning som Ă€r hĂ„rdvarumĂ€ssigt reserverad.
L: â SĂ„ det Ă€r rack frĂ„n deras Connects Orange..?
EK: â Ja.
L: â Men hur Ă€r det i det hĂ€r fallet: om ert datacenter försvinner, hur kan ni anvĂ€nda det framöver? Eller stannar helt enkelt trafiken?
EK: â Nej. I det hĂ€r fallet kommer vi helt enkelt att vĂ€xla trafiken till en annan kanal som, naturligtvis, blir dyrare för oss, dyrare för kunderna. Men trafiken kommer inte att gĂ„ genom vĂ„rt direkta anslutning till "Visa", "MasterCard", utan genom villkorlig "Sberbank" (mycket förenklat).
Jag ber om ursÀkt om jag har berört anstÀllda pÄ "Sberbank". Men enligt vÄr statistik, av ryska banker, kraschar "Sberbank" oftast. Det gÄr knappt en mÄnad utan att "Sberbank" skulle ha nÄgot som gÄr ner.
Lite reklam đ
Tack för att ni stannar kvar hos oss. Gillar ni vÄra artiklar? Vill ni se fler intressanta material? Stöd oss genom att göra en bestÀllning eller rekommendera oss till era vÀnner, , en unik motsvarighet till entry-level servrar som vi har skapat för er: (alternativ med RAID1 och RAID10 finns tillgÀngliga, upp till 24 kÀrnor och upp till 40GB DDR4).
Dell R730xd Ă€r tvĂ„ gĂ„nger billigare i datacentret Equinix Tier IV i Amsterdam? Bara hos oss i NederlĂ€nderna! Dell R420 â 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB â frĂ„n $99! LĂ€s om
KĂ€lla: habr.com
