Historisch gezien is de IT-industrie op de een of andere manier verdeeld in twee voorwaardelijke kampen: degenen die "voor" zijn en degenen die "tegen" zijn. Het onderwerp van de discussies kan volledig willekeurig zijn. Welk besturingssysteem is beter: Windows of Linux? Een smartphone met Android of iOS? Alles in de cloud opslaan of op koude RAID-opslagsystemen zetten en de schijven in een kluis stoppen? Hebben PHP-ontwikkelaars het recht om programmeurs genoemd te worden? Deze discussies zijn soms puur existentiëel en hebben geen andere basis dan sportieve interesse.
Het is zo gebeurd dat met de komst van containers en al die favoriete technologieën zoals Docker en Kubernetes, de discussies "voor" en "tegen" het gebruik van nieuwe mogelijkheden in verschillende gebieden van de backend zijn begonnen. (Laat ik vooraf zeggen dat hoewel in deze bespiegeling vaak Kubernetes als orchestrator wordt genoemd, de keuze voor dit specifieke hulpmiddel niet van principieel belang is. Je kunt het vervangen door elk ander dat je het meest handig en vertrouwd vindt.)
En, het lijkt erop, zou het een simpele discussie zijn tussen twee kanten van dezelfde medaille. Even zinloos en genadeloos als de eeuwige tegenstelling tussen Windows en Linux, waarin redelijke mensen ergens in het midden bestaan. Maar in het geval van containerisatie ligt het niet zo eenvoudig. Gewoonlijk is er in dit soort discussies geen juiste kant, maar in het geval van "containers gebruiken" of "geen containers gebruiken" voor de opslag van databases wordt alles op zijn kop gezet. Want in zekere zin hebben zowel de voorstanders als de tegenstanders van deze aanpak gelijk.
De Lichtzijde
De argumentatie van de Lichtzijde kan kort worden samengevat in één zin: “Hallo, 2k19 staat voor de deur!” Het klinkt als populisme, dat is zeker waar, maar als je in detail naar de situatie kijkt, zijn er voordelen. Laten we die nu eens doornemen.
Stel je voor dat je een groot webproject hebt. Het maakt niet zo veel uit of het aanvankelijk is opgebouwd volgens een microservices-aanpak, of dat het op een bepaald moment daar evolutionair naartoe is gegroeid. Je hebt ons project onderverdeeld in afzonderlijke microservices, de orkestratie, load balancing en schaalvergroting ingesteld. En nu geniet je met een gerust geweten van een mojito in een hangmat tijdens de Habr-effecten in plaats van gevallen servers weer op te starten. Maar in al deze handelingen is consistentie essentieel. Vaak wordt alleen de applicatie zelf - de code - in containers geplaatst. En wat hebben we nog meer naast de code?
Juist, de gegevens. Het hart van elk project zijn de gegevens: dit kan een typische database zijn zoals MySQL, Postgre, MongoDB, of opslagplaatsen die worden gebruikt voor zoekopdrachten (ElasticSearch), key-value opslag voor caching - zoals Redis, enzovoort. We zullen het nu niet hebben over de kromme implementaties van de backend, waarbij de database uitvalt door slecht geschreven queries, maar in plaats daarvan praten over het waarborgen van de fouttolerantie van deze database onder klantbelasting. Want wanneer we onze applicatie containeriseren en deze vrij laten schalen om een onbeperkt aantal inkomende verzoeken te verwerken, verhoogt dit logischerwijs ook de belasting op de database.
Feitelijk wordt de toegangskanaal tot de database en de server waar deze draait een bottleneck in onze prachtige gecontaineriseerde backend. Het belangrijkste motief achter containervirtualisatie is de mobiliteit en flexibiliteit van de structuur, waardoor het mogelijk is om de piekbelasting zo efficiënt mogelijk over onze beschikbare infrastructuur te verdelen. Dat betekent, als we niet containeriseren en niet alle onderdelen van het systeem over het cluster verspreiden, maken we een zeer ernstige fout.
Het is veel logischer om niet alleen de applicatie te clusteren, maar ook de services die verantwoordelijk zijn voor gegevensopslag. Bij het clusteren en uitrollen van onafhankelijk werkende en de belasting onderling verdelende webservers in k8s lossen we al het probleem van gegevenssynchronisatie op — dezelfde opmerkingen over berichten, als we een bepaalde media of blogplatform als voorbeeld nemen. We creëren in ieder geval een intra-cluster, zij het virtuele, weergave van de database als ExternalService. Het probleem is dat de database zelf nog niet geclusterd is — de in de cluster uitgerolde webservers halen informatie over wijzigingen uit onze statische productie-database, die apart draait.
Voelt het alsof er een addertje onder het gras zit? We gebruiken k8s of Swarm om de belasting te verdelen en te voorkomen dat de hoofdsysteem crasht, webserver, maar we doen dit niet voor de database. Maar als de database uitvalt, heeft onze geclusterde infrastructuur geen zin — wat hebben we aan lege webpagina's die een foutmelding over database-toegang teruggeven?
Daarom moet niet alleen de webserver geclusterd worden, zoals gebruikelijk is, maar ook de database-infrastructuur. Alleen zo kunnen we een volledig operationeel systeem in één setup garanderen, maar dat toch onafhankelijk van elkaar functioneert. Zelfs als de helft van onze backend onder belasting ‘instort’ — de rest overleeft en het synchronisatiesysteem van de database binnen het cluster, evenals de onbegrensde schaalbaarheid en het uitrollen van nieuwe clusters, helpt ons snel het benodigde vermogen te bereiken — zolang we maar servers in het datacenter hebben.
Bovendien maakt het gedistribueerde model van de database in clusters het mogelijk om deze database te plaatsen waar deze nodig is; als we het hebben over een mondiale service, is het behoorlijk onlogisch om een webcluster ergens in de buurt van San Francisco te draaien en vervolgens gegevenspakketten van de database in de regio Moskou heen en weer te sturen.
Daarnaast stelt het containeriseren van databases ons in staat om alle systeemcomponenten op hetzelfde abstractieniveau te schalen. Dit maakt het op zijn beurt mogelijk om dit systeem rechtstreeks vanuit de code te beheren, door ontwikkelaars, zonder actieve betrokkenheid van beheerders. De ontwikkelaars dachten dat er een aparte DBMS nodig was voor een nieuw subproject — geen probleem! ze schreven een yaml-bestand, lieten het in de cluster uploaden en het was klaar.
En dat is natuurlijk, de interne exploitatie wordt enorm vereenvoudigd. Zeg eens, hoeveel keer heb je je ogen dichtgeknepen op momenten dat een nieuw teamlid zijn handen in de productie-database stopte? De enige die jullie hebben die op dit moment actief is? Natuurlijk, we zijn allemaal volwassen mensen hier, en ergens hebben we een recente back-up, en nog verder — achter de plank met oma's augurken en oude skies — nog een back-up, misschien zelfs op cold storage, omdat jullie kantoor ooit in brand heeft gestaan. Maar toch, elke toevoeging van een nieuw teamlid met toegang tot de productie-infrastructuur en natuurlijk de productie-database is een emmer valium voor de omgeving. Wie kent die nieuwkomer? Misschien is hij onhandig? Eng, dat moet je toegeven.
Containerisatie en, in wezen, de gedistribueerde fysieke topologie van de database van jouw project helpt dergelijke stressmomenten te voorkomen. Vertrouw je de nieuwkomer niet? Oké! We richten een eigen cluster voor hem op en koppelen hem los van de andere database-clusters — synchronisatie alleen via handmatige push en synchrone omkering van twee sleutels (één voor de teamleider, de andere voor de admin). En iedereen is blij.
En nu is het tijd om over te schakelen naar tegenstanders van database-clusterisatie.
De Donkere Kant
Laten we bespreken waarom je de database niet zou moeten containeriseren en deze op één centrale plek zou moeten draaien. de server, laten we niet vervallen in de retoriek van de orthodoxen en stellingen zoals 'voorouders draaide de database op hardware, en wij ook!'. Laten we in plaats daarvan proberen een situatie te bedenken waarin containerisatie daadwerkelijk voelbare voordelen zou opleveren.
Je moet toegeven dat het aantal projecten dat echt een database in een container nodig heeft, kan worden geteld op de vingers van één hand van een niet zo geweldige frezer. In de meeste gevallen is het gebruik van k8s of Docker Swarm zelfs overbodig — vaak worden deze tools ingeschakeld vanwege de algemene hype van technologieën en het beleid van de 'hoogste' om alles in de cloud en containers te krijgen. Omdat dat nu eenmaal in de mode is en iedereen dat doet.
In ongeveer de helft van de gevallen is het gebruik van Kubernetes of gewoon Docker in een project overbodig. De vraag is dat niet alle teams of externe bedrijven die zijn ingehuurd om de infrastructuur van de klant te onderhouden, dit beseffen. Nog slechter is het wanneer containers gedwongen worden, omdat dit de klant een bepaald aantal munten kost.
Er heerst een mening dat de Docker/Kubernetes-maffia klanten gewoon onderdrukt die hun infrastructuurkwesties uitbesteden. Om met clusters te werken, zijn er ingenieurs nodig die dit kunnen en de architectuur van de geïmplementeerde oplossing begrijpen. We hebben al eens ons geval met het tijdschrift Republic beschreven - daar hebben we het team van de klant geleerd om te werken in de realiteit van Kubernetes, en iedereen was tevreden. En dat was behoorlijk. Vaak houden de ‘implementators’ van k8s de infrastructuur van de klant als gijzelaar - want nu begrijpen alleen zij hoe alles daar werkt, er zijn geen specialisten aan de klantzijde.
Stel je nu voor dat we niet alleen het webservergedeelte aan het uitbesteden zijn, maar ook het onderhoud van de database. We zeiden dat de database het hart is, en het verliezen van het hart is fataal voor elk levend organisme. Kortom, de vooruitzichten zijn niet de beste. Dus in plaats van de hype rond Kubernetes, zouden veel projecten gewoon niet zuinig moeten zijn op een normaal tarief op AWS, dat alle problemen met de belasting op hun site/project oplost. Maar AWS is al niet meer trendy, en uiterlijk vertoon is duurder dan geld - helaas, ook in de IT-wereld.
Oké. Misschien is clustering werkelijk nodig voor het project, maar als het met stateless-applicaties duidelijk is, hoe kunnen we dan zorgen voor een degelijke netwerkconnectiviteit van de geclusterde database?
Als we het hebben over de naadloze technische oplossing die de overstap naar k8s vormt, is onze grootste zorg de replicatie van gegevens in de geclusterde database. Sommige databasesystemen staan van nature vrij soepel om data te verdelen over hun afzonderlijke instanties. Veel andere zijn echter minder vergevend. En heel vaak is het belangrijkste argument bij de keuze van een database voor ons project helemaal niet de mogelijkheid om te repliceren met minimale middelen en technische kosten. Vooral als het project oorspronkelijk niet als microservices was gepland, maar gewoon in die richting is geëvolueerd.
We hoeven de snelheid van netwerkschijven waarschijnlijk niet te bespreken — ze zijn traag. Dat betekent dat we in geval van nood de instantie van de database niet kunnen opzetten op een plek waar bijvoorbeeld meer rekenkracht of vrije RAM beschikbaar is. We zullen al snel tegen de prestaties van het gevirtualiseerde schijfsysteem aanlopen. Zodoende moet de database aan haar eigen persoonlijke set machines zijn gekoppeld, die zich in directe nabijheid bevinden. Of we moeten op een of andere manier zorgen voor voldoende snelle synchronisatie van gegevens naar de verwachte reserves.
Om verder te gaan met het onderwerp van virtuele bestandssystemen: Docker Volumes zijn helaas niet probleemloos. Over het algemeen zouden we in een kwestie als langdurige betrouwbare gegevensopslag maximale eenvoud in technische schema's willen aanhouden. Het toevoegen van een nieuwe abstractielaag van het bestandssysteem van de container naar het bestandssysteem van de host is op zich al een risico. Maar wanneer er ook nog problemen optreden bij het vertalen van gegevens tussen deze lagen in de containerbeheersystemen, dan is het echt slecht. Tot nu toe lijken de meeste bekende problemen die de mensheid heeft gekend, te zijn opgelost. Maar begrijpt u, hoe ingewikkelder het mechanisme, hoe makkelijker het kapotgaat.
In het licht van al deze «avonturen» is het veel voordeliger en makkelijker om de database op één plek te houden. Zelfs als u containerisatie van de applicatie nodig heeft, laat het dan op zichzelf draaien en verkrijg gelijktijdige toegang tot de database via een distributiegateway, die slechts op één plek gelezen en geschreven zal worden. Deze aanpak vermindert de kans op fouten en desynchronisaties tot een minimum.
Waar willen we naartoe? Naar het feit dat database-containerisatie gepast is waar er een echte noodzaak voor is. Je kunt niet een volledige app-database proppen en deze draaien alsof je twee dozijn microservices hebt—dat werkt gewoon niet. Dit moet duidelijk zijn.
In plaats van output
Als je een duidelijk antwoord verwacht op de vraag «virtualiseer je de database of niet», dan moeten we je teleurstellen: dat zal hier niet komen. Omdat je bij het creëren van elke infrastructurele oplossing niet geleid moet worden door mode en vooruitgang, maar in de eerste plaats door gezond verstand.
Er zijn projecten waarvoor de principes en tools die met Kubernetes komen perfect passen, en in zulke projecten heerst er in ieder geval vrede in het backend-gebied. En er zijn projecten die geen containerisatie nodig hebben, maar een normale serverinfrastructuur, omdat ze fundamenteel niet kunnen opschalen naar een microservices-cluster model, anders vallen ze om.
Bron: habr.com
