In de zomer nemen traditioneel zowel de inkoopactiviteit als de intensiteit van veranderingen in de infrastructuur van webprojecten af, vertelt Captain Evidence. Gewoon omdat zelfs IT'ers wel eens op vakantie gaan. En CTO ook. Hoe moeilijker het is voor degenen die in functie blijven, maar daar gaat het nu niet om: misschien is de zomer daarom de beste tijd om de bestaande reserveringsregeling te overwegen en een plan te maken om het te verbeteren. En hierin profiteert u van de ervaring van Yegor Andreev uit waar hij op de conferentie over sprak .
Bij het bouwen van reserveplaatsen, bij het reserveren, zijn er verschillende valkuilen waar u in kunt trappen. En je kunt ze niet echt raken. En ruïneert ons in dit alles, zoals in veel andere dingen, perfectionisme en ... luiheid. We proberen alles-alles-alles perfect te maken, maar je hoeft het niet perfect te doen! Je hoeft alleen bepaalde dingen te doen, maar doe ze goed, breng ze tot het einde zodat ze normaal werken.
Failover is niet een of ander leuk, leuk "laat het zijn" ding; het is iets dat precies één ding zou moeten doen: downtime verminderen, zodat de service, het bedrijf, minder geld verliest. En bij alle reserveringsmethoden stel ik voor om in de volgende context te denken: waar is het geld?
Eerste val: wanneer we grote betrouwbare systemen bouwen en redundantie toepassen, verminderen we het aantal ongevallen. Dit is een vreselijke waanidee. Als we redundantie toepassen, is de kans groot dat het aantal ongevallen toeneemt. En als we alles goed doen, zullen we samen downtime verminderen. Er zullen meer ongelukken gebeuren, maar die zullen gebeuren tegen lagere kosten. Wat is tenslotte een reservering? is een complicatie van het systeem. Elke complicatie is slecht: we hebben meer schroeven, meer tandwielen, kortom, meer elementen - en dus een grotere kans op breuk. En ze gaan echt stuk. En ze gaan vaker stuk. Een eenvoudig voorbeeld: laten we zeggen dat we een site hebben, met PHP, MySQL. En er moet dringend geboekt worden.
Shtosh (c) We nemen de tweede locatie, bouwen een identiek systeem ... De complexiteit wordt twee keer zo groot - we hebben twee entiteiten. En we rollen ook een bepaalde logica door voor het overdragen van gegevens van de ene site naar de andere van bovenaf - dat wil zeggen gegevensreplicatie, het kopiëren van statische gegevens, enzovoort. De logica van replicatie is dus meestal erg complex en daarom kan de totale complexiteit van het systeem niet 2, maar 3, 5, 10 keer meer zijn.
Tweede val: wanneer we hele grote complexe systemen bouwen, fantaseren we wat we uiteindelijk willen bereiken. Voila: we willen een superbetrouwbaar systeem dat werkt zonder enige downtime, schakelt in een halve seconde (of beter, direct) en begint dromen waar te maken. Maar ook hier is er een nuance: hoe korter de gewenste schakeltijd, hoe complexer de systeemlogica wordt. Hoe moeilijker we deze logica moeten maken, hoe vaker het systeem zal breken. En u kunt in een zeer onaangename situatie terechtkomen: we doen ons best om de downtime te verminderen, maar in feite maken we alles ingewikkeld, en als er iets misgaat, wordt de downtime uiteindelijk langer. Hier betrap je jezelf er vaak op dat je denkt: hier ... kun je beter niet reserveren. Het zou beter zijn als het alleen werkte en met een duidelijke downtime.
Hoe kun je het bestrijden? We moeten stoppen met tegen onszelf te liegen, onszelf niet vleien dat we nu een ruimteschip gaan bouwen, maar voldoende begrijpen hoe lang het project kan liggen. En onder deze maximale tijd zullen we kiezen welke methoden we in feite de betrouwbaarheid van ons systeem zullen vergroten.
Het is tijd voor "verhalen uit f" ... uit het leven natuurlijk.
Voorbeeld nummer één
Stel je een website voor op een visitekaartje voor van de pijpenwalserij nr. 1 van de stad N. Er staat in grote letters - PIJPENROLLING PLANT nr. 1. Iets lager staat de slogan: “Onze pijpen zijn de rondste pijpen in N.” En onderaan staat het telefoonnummer van de CEO en zijn naam. We begrijpen dat u moet reserveren - dit is heel belangrijk! Laten we beginnen te begrijpen waar het uit bestaat. Html-statistieken - dat wil zeggen, een paar foto's waarop de generaal, in feite, aan de tafel in het badhuis met zijn partner een volgende deal bespreekt. We beginnen na te denken over downtime. Het komt in me op: je moet daar vijf minuten blijven liggen, niet meer. En dan is de vraag: hoeveel verkopen van deze site van ons waren er in het algemeen? Hoe veel? Wat betekent "nul"? En dat betekent: omdat alle vier de transacties van het afgelopen jaar de generaal aan dezelfde tafel hebben gedaan, zitten dezelfde mensen met wie ze naar het badhuis gaan aan tafel. En we begrijpen dat zelfs als de site een dag stil ligt, er niets vreselijks zal zijn.
Op basis van de input is er een dag om dit verhaal aan de orde te stellen. We beginnen na te denken over de afvloeiingsregeling. En we kiezen voor dit voorbeeld de meest ideale regeling voor boventalligheid: we maken geen gebruik van boventalligheid. Dit hele ding wordt door elke admin in een half uur opgeworpen met rookpauzes. Zet een webserver op, plaats bestanden - dat is alles. Het zal werken. Er is niets om naar te kijken, niets om speciale aandacht aan te besteden. Dat wil zeggen, de conclusie uit voorbeeld nummer één ligt voor de hand: services waarvan geen back-up nodig is, hoeven ook geen back-up te worden gemaakt.
Voorbeeld nummer twee
Bedrijfsblog: speciaal opgeleide mensen schrijven daar nieuws, dus we hebben aan die en die tentoonstelling deelgenomen, maar we hebben weer een nieuw product uitgebracht, enzovoort. Laten we zeggen dat het standaard PHP is met WordPress, een kleine database en een beetje statisch. Natuurlijk komt het weer in me op dat je in geen geval mag gaan liggen - "niet meer dan vijf minuten!", Dat is alles. Maar laten we verder denken. Wat doet deze blog? Ze komen daar van Yandex, van Google voor sommige verzoeken, voor organische producten. Geweldig. Heeft het iets met verkopen te maken? Inzicht: niet echt. Advertentieverkeer gaat naar de hoofdsite, die zich op een andere machine bevindt. Laten we beginnen na te denken over het reserveringsschema van de blog. Op een goede manier moet het binnen een paar uur worden grootgebracht, en het zou leuk zijn om je hierop voor te bereiden. Het zou redelijk zijn om een machine in een ander datacenter te nemen, de omgeving erop te rollen, dat wil zeggen een webserver, PHP, WordPress, MySQL, en deze gedempt te laten. Op het moment dat we begrijpen dat alles kapot is, moeten we twee dingen doen: de mysql-dump uitrollen tot 50 meter, deze vliegt daar binnen een minuut naartoe en een bepaald aantal foto's uit de back-up daar uitrollen. Het is er ook niet God weet hoeveel. Dus in een half uur rijst het hele ding. Alle replicaties, of God vergeef, automatische failover'a. Conclusie: wat we snel uit een back-up kunnen uitrollen, is niet nodig om te reserveren.
Voorbeeld nummer drie, moeilijker
Online winkel. PHP met open hart is licht gearchiveerd, mysql met een solide basis. Vrij veel ruis (de online winkel heeft tenslotte prachtige HD-foto's en zo), Redis voor de sessie en Elasticsearch voor zoeken. We beginnen na te denken over downtime. En hier is het natuurlijk duidelijk dat een online winkel geen dag pijnloos kan liegen. Immers, hoe langer het ligt, hoe meer geld we verliezen. Het is de moeite waard om te versnellen. Hoe veel? Ik denk dat als we een uurtje gaan liggen, niemand gek wordt. Ja, we zullen iets verliezen, maar als we ijverig worden, wordt het alleen maar erger. We bepalen het schema van toegestane inactieve tijd per uur.
Hoe kan dit geboekt worden? Een auto is sowieso nodig: een uur tijd is nogal wat. Mysql: replicatie is hier al nodig, live replicatie, want over een uur zal hoogstwaarschijnlijk 100 GB niet in de dump zijn opgenomen. Statica, foto's: nogmaals, over een uur heeft 500 GB misschien geen tijd om mee te doen. Daarom is het beter om de foto's meteen te kopiëren. Redis: hier wordt het interessant. Sessies liggen in Redis - we kunnen het niet zomaar meenemen en begraven. Omdat het niet erg goed zal zijn: alle gebruikers worden uitgelogd, de mandjes worden geleegd, enzovoort. Mensen zullen gedwongen worden om hun gebruikersnaam en wachtwoord opnieuw in te voeren, en veel mensen kunnen breken en de aankoop niet voltooien. Nogmaals, de conversie zal dalen. Aan de andere kant is Redis up-to-date, met de laatst ingelogde gebruikers, waarschijnlijk ook niet nodig. En een goed compromis is om Redis te nemen en het te herstellen vanaf een back-up, gisteren, of, als je het elk uur doet, een uur geleden. Gelukkig is het herstellen van een back-up het kopiëren van één bestand. En het meest interessante verhaal is Elasticsearch. Wie heeft ooit MySQL-replicatie ter sprake gebracht? Heeft iemand ooit Elasticsearch-replicatie opgepikt? En voor wie werkte ze daarna normaal? Wat ik bedoel: we zien een bepaalde entiteit in ons systeem. Het is best handig, maar het is ingewikkeld.
Lastig in die zin dat onze collega-engineers er geen ervaring mee hebben. Of een slechte ervaring hebben. Of we begrijpen dat terwijl dit een vrij nieuwe technologie is met nuances of vochtigheid. Wij denken... Damn, elastiek is ook gezond, het duurt ook lang om het te herstellen vanaf een back-up, wat moet ik doen? We begrijpen dat elastiek in ons geval wordt gebruikt voor zoeken. Hoe verkoopt onze online winkel? We gaan naar marketeers en vragen waar mensen vandaan komen. Ze antwoorden: "90% van Yandex Market komt rechtstreeks op de productkaart." En ze kopen het of ze kopen het niet. Daarom heeft 10% van de gebruikers een zoekopdracht nodig. En om elastische replicatie te behouden, vooral tussen verschillende datacenters in verschillende zones, zijn er echt veel nuances. Welke uitgang? We nemen elastiek mee op een gereserveerde plek en doen er niets mee. Als de zaak voortduurt, kunnen we die later misschien aan de orde stellen, maar dat is niet zeker. Eigenlijk is de conclusie plus of min hetzelfde: diensten die geen invloed hebben op geld, reserveren we wederom niet. Om de schakeling simpel te houden.
Voorbeeld nummer vier, nog moeilijker
Integrator: bloemen verkopen, een taxi bellen, goederen verkopen, in het algemeen, alles. Een serieuze zaak die 24/7 werkt voor een groot aantal gebruikers. Met een volwaardige interessante stapel, met interessante bases, oplossingen, hoge werkdruk en vooral meer dan 5 minuten liggen doet hem pijn. Niet alleen en niet zozeer omdat mensen niet willen kopen, maar omdat mensen zullen zien dat dit ding niet werkt, ze van streek zullen raken en misschien helemaal geen tweede keer komen.
OK. Vijf minuten. Wat gaan we hiermee doen? In dit geval bouwen we op een volwassen manier een echte back-upsite met al het geld, met replicatie van alles en nog wat, en misschien zelfs het maximaal automatiseren van de overstap naar deze site. En daarnaast moet u onthouden dat u één belangrijk ding moet doen: in feite de overstapregels schrijven. De regeling kan, ook al is alles en nog wat voor je geautomatiseerd, heel simpel zijn. Uit de serie "voer dit en dat weerwoordscript uit", "druk op dat en dat selectievakje in route 53", enzovoort - maar dit zou een soort exacte lijst met acties moeten zijn.
En alles lijkt duidelijk te zijn. Schakelen tussen replicatie is een triviale taak, anders schakelt het vanzelf. Herschrijf de domeinnaam in dns - uit dezelfde serie. Het probleem is dat wanneer zo'n project mislukt, er paniek uitbreekt en zelfs de sterkste, bebaarde beheerders eraan kunnen worden onderworpen. Zonder een duidelijke instructie “open de terminal, kom hier, het adres van onze server is nog steeds zo” is de periode van 5 minuten voor reanimatie moeilijk vol te houden. Nou, plus, wanneer we deze verordening gebruiken, is het gemakkelijk om enkele wijzigingen in de infrastructuur op te lossen, bijvoorbeeld, en de verordening dienovereenkomstig aan te passen.
Welnu, als het reserveringssysteem erg ingewikkeld is en we op een gegeven moment een fout hebben gemaakt, dan kunnen we onze back-upsite neerleggen en bovendien de gegevens op beide sites in een pompoen veranderen - het zal heel triest zijn.
Voorbeeld nummer vijf volledige hardcore
Een internationale dienst met honderden miljoenen gebruikers wereldwijd. Alle tijdzones die er zijn, hoge belasting bij maximale snelheden, je kunt helemaal niet gaan liggen. Een minuut - en het zal triest zijn. Wat moeten we doen? Reserveer nogmaals volledig. We hebben alles gedaan wat in het vorige voorbeeld werd genoemd, en een beetje meer. Een ideale wereld, en onze infrastructuur is volgens alle concepten van IaaC devops. Dat wil zeggen, alles is over het algemeen in git, en druk gewoon op de knop.
Wat mist er? De ene geeft les. Je kunt niet zonder ze. Alles lijkt perfect te zijn, we hebben alles onder controle. We drukken op de knop, alles gebeurt. Zelfs als dit waar is - en we begrijpen dat dit niet het geval is - communiceert ons systeem met sommige andere systemen. Dit is bijvoorbeeld dns van route 53, s3-opslag, integratie met wat api. We kunnen niet alles voorzien in dit speculatieve experiment. En totdat we echt aan de schakelaar trekken, weten we niet of het zal werken of niet.
Dat is waarschijnlijk alles. Wees niet lui en overdrijf het niet. En moge uptime met u zijn!
Bron: www.habr.com