Dit artikel bevat enkele algemene patronen om technici te helpen werken met grootschalige services waartoe miljoenen gebruikers toegang hebben.
In de ervaring van de auteur is dit geen uitputtende lijst, maar inderdaad effectief advies. Dus laten we beginnen.
Met ondersteuning vertaald .
Instapniveau
Onderstaande maatregelen zijn relatief eenvoudig uit te voeren, maar hebben een grote impact. Als u ze nog niet eerder hebt geprobeerd, zult u verrast zijn door de aanzienlijke verbeteringen.
Infrastructuur als code
Het eerste deel van het advies is om infrastructuur als code te implementeren. Dit betekent dat u een programmatische manier moet hebben om de gehele infrastructuur in te zetten. Het klinkt ingewikkeld, maar we hebben het eigenlijk over de volgende code:
Implementatie van 100 virtuele machines
- met Ubuntu
- 2 GB RAM elk
- ze hebben de volgende code
- met deze parameters
U kunt wijzigingen in uw infrastructuur volgen en er snel naar terugkeren met behulp van versiebeheer.
De modernist in mij zegt dat je Kubernetes/Docker kunt gebruiken om al het bovenstaande te doen, en hij heeft gelijk.
Daarnaast kunt u automatisering verzorgen met behulp van Chef, Puppet of Terraform.
Continue integratie en levering
Om een schaalbare service te creëren, is het belangrijk om voor elke pull-aanvraag een build- en testpijplijn te hebben. Zelfs als de test heel eenvoudig is, zorgt deze er in ieder geval voor dat de code die u implementeert, compileert.
Elke keer beantwoord je in deze fase de vraag: Zal mijn assemblage compileren en testen doorstaan, is deze geldig? Dit lijkt misschien een lage lat, maar het lost veel problemen op.
Er is niets mooier dan het zien van deze teken
Voor deze technologie kunt u Github, CircleCI of Jenkins evalueren.
Loadbalancers
We willen dus een load balancer uitvoeren om verkeer om te leiden en een gelijke belasting op alle knooppunten te garanderen, anders blijft de service doorgaan in geval van een storing:
Een load balancer kan het verkeer doorgaans goed distribueren. De beste praktijk is om uit balans te komen, zodat er geen enkel punt van mislukking is.
Normaal gesproken worden load balancers geconfigureerd in de cloud die u gebruikt.
RayID, correlatie-ID of UUID voor verzoeken
Bent u ooit een toepassingsfout tegengekomen met een bericht als dit: "Er is iets fout gegaan. Bewaar deze ID en stuur deze naar ons ondersteuningsteam"?
Een unieke identificatiecode, correlatie-ID, RayID of een van de varianten ervan is een unieke identificatiecode waarmee u een verzoek gedurende de gehele levenscyclus ervan kunt volgen. Hierdoor kunt u het volledige verzoekpad in de logboeken volgen.
De gebruiker doet een verzoek aan systeem A, waarna A contact opneemt met B, die contact opneemt met C, het opslaat in X, en vervolgens wordt het verzoek teruggestuurd naar A
Als je op afstand verbinding zou maken met virtuele machines en zou proberen het verzoekpad te traceren (en handmatig te correleren welke oproepen worden gedaan), zou je gek worden. Het hebben van een unieke identificatie maakt het leven veel gemakkelijker. Dit is een van de eenvoudigste dingen die u kunt doen om tijd te besparen naarmate uw service groeit.
Gemiddeld niveau
Het advies hier is complexer dan de vorige, maar de juiste hulpmiddelen maken de taak eenvoudiger en bieden zelfs voor kleine en middelgrote bedrijven rendement op hun investering.
Gecentraliseerde logboekregistratie
Gefeliciteerd! U hebt 100 virtuele machines geïmplementeerd. De volgende dag komt de CEO en klaagt over een fout die hij heeft ontvangen tijdens het testen van de dienst. Het rapporteert de overeenkomstige ID waar we het hierboven over hadden, maar je zult door de logs van 100 machines moeten kijken om degene te vinden die de crash veroorzaakte. En het moet gevonden worden vóór de presentatie van morgen.
Hoewel dit klinkt als een leuk avontuur, kun je er het beste voor zorgen dat je alle tijdschriften op één plek kunt doorzoeken. Ik heb het probleem van het centraliseren van logboeken opgelost met behulp van de ingebouwde functionaliteit van de ELK-stack: het ondersteunt doorzoekbare logboekverzameling. Dit zal echt helpen het probleem van het vinden van een specifiek tijdschrift op te lossen. Als bonus kun je grafieken en andere leuke dingen maken.
ELK-stapelfunctionaliteit
Toezichthoudende agenten
Nu uw service actief is, moet u ervoor zorgen dat deze soepel verloopt. De beste manier om dit te doen is door er meerdere uit te voeren agenten, die parallel werken en controleren of het werkt en de basisbewerkingen worden uitgevoerd.
Op dit punt controleer je dat de running build voelt goed aan en werkt prima.
Voor kleine tot middelgrote projecten raad ik Postman aan voor het monitoren en documenteren van API's. Maar over het algemeen wilt u er gewoon zeker van zijn dat u weet wanneer er een storing heeft plaatsgevonden en dat u er tijdig van op de hoogte wordt gesteld.
Automatisch schalen afhankelijk van de belasting
Het is heel simpel. Als u onderhoudsaanvragen voor een VM hebt en het geheugengebruik bijna 80% bedraagt, kunt u de bronnen ervan vergroten of meer VM's aan het cluster toevoegen. Automatische uitvoering van deze bewerkingen is uitstekend geschikt voor elastische vermogensveranderingen onder belasting. Maar u moet altijd voorzichtig zijn met hoeveel geld u uitgeeft en redelijke limieten stellen.
Bij de meeste cloudservices kunt u deze configureren om automatisch te schalen met behulp van meer servers of krachtigere servers.
Experimenteer systeem
Een goede manier om updates veilig uit te rollen is om voor 1% van de gebruikers een uur lang iets te kunnen testen. Je hebt dergelijke mechanismen natuurlijk in actie gezien. Facebook toont bijvoorbeeld delen van het publiek een andere kleur of verandert de lettergrootte om te zien hoe gebruikers de veranderingen waarnemen. Dit heet A/B-testen.
Zelfs het uitbrengen van een nieuwe functie kan als experiment worden gestart en vervolgens worden bepaald hoe deze moet worden vrijgegeven. U krijgt ook de mogelijkheid om de configuratie direct te ‘onthouden’ of te wijzigen op basis van de functie die verslechtering van uw service veroorzaakt.
gevorderden
Hier zijn tips die vrij moeilijk te implementeren zijn. Je hebt waarschijnlijk wat meer middelen nodig, dus een klein of middelgroot bedrijf zal hier moeite mee hebben.
Blauw-groene implementaties
Dit is wat ik de ‘Erlang’-manier van ontvouwen noem. Erlang werd op grote schaal gebruikt toen telefoonbedrijven verschenen. Softswitches werden gebruikt om telefoongesprekken door te sturen. Het belangrijkste doel van de software op deze switches was om geen oproepen te laten vallen tijdens systeemupgrades. Erlang heeft een leuke manier om een nieuwe module te laden zonder de vorige te laten crashen.
Deze stap is afhankelijk van de aanwezigheid van een load balancer. Stel dat u versie N van uw software heeft en vervolgens versie N+1 wilt implementeren.
U we konden stop gewoon de service en rol de volgende versie uit op een tijdstip dat voor uw gebruikers werkt en wat downtime krijgt. Maar stel dat je dat wel hebt echt strikte SLA-voorwaarden. SLA 99,99% betekent dus dat u offline kunt gaan alleen met 52 minuten per jaar.
Als je dergelijke indicatoren echt wilt bereiken, heb je twee implementaties tegelijkertijd nodig:
- degene die nu is (N);
- volgende versie (N+1).
U vertelt de load balancer om een percentage van het verkeer om te leiden naar de nieuwe versie (N+1), terwijl u actief controleert op regressies.
Hier hebben we een groene N-implementatie die prima werkt. We proberen over te gaan naar de volgende versie van deze implementatie
Eerst sturen we een heel kleine test om te zien of onze N+1-implementatie werkt met een kleine hoeveelheid verkeer:
Ten slotte hebben we een reeks geautomatiseerde controles die we uiteindelijk uitvoeren totdat onze implementatie voltooid is. als jij heel erg Let op, u kunt uw N-implementatie ook voor altijd opslaan voor een snelle terugdraaiing in geval van slechte regressie:
Wil je naar een nog geavanceerder niveau, laat dan alles in de blauw-groene implementatie automatisch verlopen.
Afwijkingsdetectie en automatische beperking
Aangezien u over gecentraliseerde logboekregistratie en een goede logboekverzameling beschikt, kunt u al hogere doelen stellen. Voorspel bijvoorbeeld proactief storingen. Functies worden bijgehouden op monitoren en in logs en er worden diverse diagrammen gebouwd – en je kunt vooraf voorspellen wat er mis gaat:
Zodra afwijkingen worden gedetecteerd, begint u enkele aanwijzingen te onderzoeken die de dienst biedt. Een piek in de CPU-belasting kan er bijvoorbeeld op duiden dat een harde schijf defect raakt, terwijl een piek in verzoeken erop kan wijzen dat u moet opschalen. Met dit soort statistische gegevens kunt u de service proactief maken.
Met deze inzichten kunt u in elke dimensie schalen en proactief en reactief de kenmerken van machines, databases, verbindingen en andere bronnen wijzigen.
Dat is alles!
Deze prioriteitenlijst bespaart u een hoop problemen als u een clouddienst aan het opzetten bent.
De auteur van het originele artikel nodigt lezers uit om hun opmerkingen achter te laten en wijzigingen aan te brengen. Het artikel wordt verspreid als open source, pull-requests van de auteur .
Wat kun je nog meer lezen over dit onderwerp:
Bron: www.habr.com