Hoe Elasticsearch te schalen om uw schaalbaarheidsproblemen op te lossen

Met de evolutie van moderne applicaties die steeds grotere behoeften hebben aan real-time gegevensverwerking en -opvraging, groeit ook de schaalbaarheid. Een dergelijke open-source, gedistribueerde zoek- en analysemotor is Elasticsearch, die zeer efficiënt is in het verwerken van gegevens in grote sets en het uitvoeren van vragen met hoge snelheid. De manier waarop Elasticsearch effectief kan worden opgeschaald, kan echter subtiel zijn, aangezien men een goed begrip nodig heeft van de architectuur erachter en van prestatieafwegingen.

Hoewel de gedistribueerde aard van Elasticsearch horizontaal schalen mogelijk maakt, brengt dit ook meer complexiteit met zich mee in hoe gegevens worden verspreid en vragen worden beantwoord. Een van de theoretische uitdagingen die gepaard gaan met het schalen van Elasticsearch is zijn inherent gedistribueerde aard. In de meeste praktijksituaties zullen leesbewerkingen op een op zichzelf staande knoop altijd beter presteren dan leesbewerkingen in een geschakeerd cluster. Dit komt doordat in een geschakeerd cluster het eigendom van gegevens over meerdere knooppunten wordt verspreid. Dat betekent dat elke query mogelijk meerdere verzoeken naar verschillende knooppunten moet sturen, de resultaten moet aggregeren bij het coördinerende knooppunt en het resultaat moet retourneren. Deze extra netwerkoverhead zal gemakkelijk leiden tot verhoogde latentie in vergelijking met een architectuur met één knooppunt waar de toegang tot gegevens eenvoudig is.

In dit opzicht zijn geschakeerde clusters fundamenteel voor het schalen van Elasticsearch naar grote gegevenssets, hoge verkeersvolumes en bijna real-time indexering. Het kennen van de juiste balans tussen het verspreiden van gegevens over knooppunten en het laag houden van de querylatentie is essentieel voor het behalen van optimale prestaties. Verderop behandelt het artikel de theoretische aspecten van de schaalbaarheid van Elasticsearch, praktische strategieën voor optimalisatie van de clustprestaties en lessen die zijn geleerd uit implementatie-ervaringen in de echte wereld.

Bij Swoo, onze live streaming en gaming-app, was Elasticsearch de ruggengraat van alles wat met zoeken te maken had, en het werkte prima naarmate onze gebruikersgroei toenam. Op het moment dat het aantal gelijktijdige gebruikers de 150.000 overschreed, begon de zoekpagina af en toe te falen, en het was vrij duidelijk dat er een bottleneck in het Elasticsearch-cluster was. Dit werd al snel onaanvaardbaar voor een live game-omgeving en leidde ons tot een reeks optimalisaties, die uiteindelijk zowel onze zoek- als startpagina-ervaringen stabiliseerden.

Begrijpen van de Elasticsearch-architectuur voor schaalbaarheid

Elasticsearch ondersteunt van nature een gedistribueerde architectuur, waardoor het systeem zeer schaalbaar is, maar tegelijkertijd complexer dan traditionele oplossingen met één knooppunt. Elasticsearch verdeelt gegevens in indices, waarbij elke index op zijn beurt in shards is verdeeld. De shard is de basis eenheid van gegevensopslag en indexering in Elasticsearch, aangezien het systeem de zoekoperaties over meerdere knooppunten van het cluster verdeelt en paralleliseert.

Een typisch cluster zou een aantal dataknooppunten bevatten die een subset van de gegevens hosten en zoekopdrachten uitvoeren. Standaard kan Elasticsearch automatisch gegevens over knooppunten verdelen, zodat elk knooppunt slechts een deel van de querylast uitvoert. Op deze manier schaalt Elasticsearch horizontaal: het verwerkt steeds meer gegevens en bedient steeds meer verzoeken door eenvoudigweg knooppunten toe te voegen.

Deze afweging tussen schaalbaarheid en query-prestaties is natuurlijk een van de belangrijkste dingen om rekening mee te houden bij het ontwerpen van Elasticsearch-clusters, vooral voor toepassingen die een hoge schrijfdoorvoer vereisen in combinatie met een lage leeslatentie. Zo’n uitdaging vraagt inderdaad om zorgvuldige configuratie van het cluster samen met een mix van optimalisatietechnieken.

Kortom, ons Elasticsearch-cluster had een paar datanodes voor het geval van Swoo en drie speciale masternodes. Elke node draaide op een 8-core CPU met 16 GB RAM, voornamelijk gericht op real-time indexering en directe zoekopdrachten van de game-evenementen die plaatsvonden. Omdat we werken met een hoge gelijktijdigheid, moeten we echt substantiële netwerkbandbreedte toewijzen om minimale latentie tussen nodes te garanderen.

Uw schalingsstrategie plannen

Met andere woorden, Elasticsearch effectief schalen vereist analyse van huidige prestatie-indicatoren, vaststelling van knelpunten en duidelijke doelen met betrekking tot schaalbaarheid. Het is bijvoorbeeld goed om query-latentie, doorvoer en clustergezondheid te monitoren om de beperkingen van uw cluster te begrijpen. U kunt een optimalisatieroute creëren door hot shards, pieken in CPU en geheugenproblemen te identificeren.

Een andere belangrijke activiteit die aandacht nodig heeft bij het opschalen van Elasticsearch is capaciteitsplanning. Het schatten van schijfgebruik, het verkeerspatroon en de retentievereisten voor gegevens zal ervoor zorgen dat uw cluster de juiste grootte heeft. Over het algemeen is horizontaal schalen (toevoeging van knooppunten aan de cluster) over het algemeen de beste aanpak voor een grotere hoeveelheid gegevens en verkeer. In dit geval kan echter verticaal schalen – het upgraden van de resources van individuele knooppunten – effectief zijn.

Onze prognoses gaven aan dat het aantal actieve gebruikers maandelijks met ongeveer 10-15% zou groeien, waarbij elke gebruiker een aanzienlijke hoeveelheid gebeurtenisgegevens genereert tijdens het spelen van het spel. Op basis van deze prognoses verwachtten we dat onze cluster een gezonde stijging van gelijktijdige query’s zou doormaken, samen met een toename van het geïndexeerde documentvolume. Daarom hebben we geanalyseerd of schalen horizontaal door meer datanodes toe te voegen of verticaal schalen door onze huidige knooppunten te upgraden meer geschikt zou zijn voor deze toename.

Kernschalingstechnieken

Optimalisatie van Elasticsearch omvat een aantal strategieën, die elk verschillende aspecten van het systeem aanpakken. Onder deze zijn de meest effectieve technieken onder andere optimalisatie van gegevensinvoer, shardbeheer en optimalisatie van geheugengebruik.

De belangrijkste aandachtsgebieden zullen gegevensinvoer zijn. Elasticsearch ondersteunt bulkindexering van nature, wat betekent dat je echt grote batches documenten in één verzoek kunt verzenden. Dat vermindert overhead en versnelt over het algemeen het indexeerproces. Ten tweede kan het fijnafstemmen van het vernieuwingsinterval alle verschil maken bij het snel invoeren van gegevens. Je kunt het standaard vernieuwingsinterval van één seconde overschrijven naar een hogere waarde, bijvoorbeeld tien seconden, omdat dat de stress van te frequente vernieuwingen op je cluster vermindert, waardoor je schrijfprocessen sneller verlopen.

Andere belangrijke redenen die bijdragen aan de schaalbaarheidsfunctie van Elasticsearch zijn shardbeheer. Hoewel Elasticsearch horizontaal kan schalen via sharding, leidt onjuiste sharddimensionering eigenlijk tot verminderde prestaties. Een te hoog of te laag aantal shards resulteert in verminderde indexeringssnelheid en/of queryprestaties. De truc zit in het vinden van de juiste balans voor optimale prestaties in Elasticsearch.

Natuurlijk is geheugenbeheer een zeer belangrijke factor bij het schalen van Elasticsearch. Je kunt zeker het verbruik van middelen verminderen en de prestaties van je queries verbeteren door de JVM heapgrootte te optimaliseren, het veldgegevenscache te configureren en de querycache in te schakelen. Het juiste gebruik van geheugen en cachinginstellingen kan out-of-memory fouten voorkomen en de overhead van garbage collection minimaliseren.

Een aanzienlijke hoeveelheid druk op Elasticsearch werd veroorzaakt door de continue invoer van real-time gamegegevens. We hebben de invoerpijplijnen geoptimaliseerd door documentbatching via de Bulk API. In periodes van bepaalde piekbelasting konden we de batchgroottes verder verhogen en de vernieuwingsperiode verlengen voor een goede balans tussen bijna real-time indexering en algemene clusterstabiliteit.

Geavanceerde Schaaloplossingen

Als de schaal enorm wordt, vereist Elasticsearch meer geavanceerde technieken om prestatiegericht te zijn. Daarbij springt query-optimalisatie eruit. U kunt ook de querylatentie aanzienlijk verminderen door efficiënte queries te schrijven die het aantal shards dat bij de zoekopdracht betrokken is minimaliseren. U kunt bijvoorbeeld aangepaste routering uitvoeren om de queries naar de specifieke shards te routeren met behulp van een sleutel, zoals klant-ID of productcategorie. Dit bespaart Elasticsearch van het doorzoeken van alle shards; daardoor worden de tijd en middelen die worden gebruikt verminderd.

ILM, of Index Lifecycle Management, is een andere geweldige functie om Elasticsearch af te stemmen naarmate uw dataset ouder wordt. U kunt oudere gegevens verplaatsen naar langzamere, goedkopere opslag terwijl u de meest relevante gegevens op snellere, meer toegankelijke opslag houdt door een hot-warm-cold-architectuur te schalen. Het houdt de clusterprestaties geweldig naarmate de cluster groeit.

De laatste onderwerpen met betrekking tot de schaalbaarheid van Elasticsearch zijn hardware-overwegingen. Naarmate uw cluster groeit, wilt u ervoor zorgen dat de hardware goed is voorzien van de toegenomen belasting. Dat betekent ervoor zorgen dat nodes over de juiste CPU, geheugen en schijf-I/O beschikken om efficiënt te kunnen werken. SSD’s of NVMe-schijven zullen de prestaties aanzienlijk verbeteren, vooral voor indexering en zoekbewerkingen, die hoge gegevenstoegangssnelheden vereisen.

Een van de moeilijke lessen die we hebben geleerd, was dat het toewijzen van alleen de standaard shard-count aan nieuwere indices ons in de problemen zou brengen met hot spotting. We vonden ook een sweet spot waar geen enkele shard echt overbelast was met het grootste deel van de real-time updates die afkomstig waren van ons gamingplatform door zware schrijf-indices die opnieuw werden verdeeld over meerdere kleinere shards, waarbij replica’s dienovereenkomstig werden aangepast.

Theoretische Inzichten en Optimalisatie Afwegingen

Naast de praktische optimalisaties hierboven, zijn er een paar interessante theoretische overwegingen bij het schalen van Elasticsearch. Een belangrijk inzicht heeft te maken met schaalbaarheid en query-prestatie-afwegingen binnen een gedistribueerd systeem. Met name wordt opgemerkt dat hoewel geschalde clusters horizontaal schaalbaar zijn, ze de query-overhead vergroten omdat resultaten van meerdere nodes moeten worden gecombineerd. Dit staat in contrast met een enkele node waar de gegevens zich op de lokale machine bevinden en vragen kunnen worden uitgevoerd zonder met andere nodes te hoeven ‘praten’. Het begrijpen van deze afweging is belangrijk als men een Elasticsearch-cluster ontwerpt die prestaties moet balanceren met schaalbaarheid.

Nog een meer theoretisch aspect van het schalen van Elasticsearch is het concept van data-localiteit. U kunt queries alleen uitvoeren tegen de lokale node die de relevante shard-gegevens host door de preference=local query-parameter te gebruiken. Dit minimaliseert de communicatie tussen nodes en verlaagt de querylatentie. Dit kan ook de uitdagingen verminderen die voortkomen uit gegevensreplicatie en load balancing. Het Elasticsearch Adaptive Replica Selection-algoritme probeert de uitvoering van queries te optimaliseren door de beste replica-node te kiezen onder de huidige omstandigheden. Het brengt echter niet per se de meest effectieve uitvoering van een query met zich mee.

De eerste golf van mislukkingen die we in onze omgeving hebben ervaren, heeft betrekking op hoge JVM heapdruk. Elasticsearch-servers draaiden aanvankelijk met minimale heaptoewijzingen, wat resulteerde in vrij frequente garbage collection-cycli onder hoge querybelasting. We hebben dit opgelost door de JVM af te stemmen, met name door de minimale en maximale heapgrootte op 8 GB af te stemmen, wat Elasticsearch voldoende ruimte gaf om queries te verwerken zonder de heap te overbelasten.

Veelvoorkomende valkuilen en oplossingen

Uiteraard is het schalen van Elasticsearch ook niet zonder uitdagingen. Onder die veelvoorkomende fouten die men zou willen vermijden, zijn slechte shardgrootte, gebrek aan monitoring, te veel vertrouwen op caching en het niet gebruiken van een goed Index Lifecycle Management. Deze besparen behoorlijk wat tijd en middelen als ze vroegtijdig worden gediagnosticeerd door proactieve configuratieafstemming.

Een van de grootste valkuilen was het niet aanpassen van de standaardinstellingen van Elasticsearch, zowel wat betreft geheugenallocatie als shardbeheer. De standaardinstellingen werkten goed onder gematigde verkeersomstandigheden, maar bezweken onder piekverkeer. Onze oplossing was gelaagd: het herzag de heapallocatie, hete indexreplicatie en kortetermijn-caching voor herhaalde queries. Al met al voorkwam het herhaalde mislukkingen in het hele cluster en verminderde het de time-outs aanzienlijk.

Implementatiehandleiding in de echte wereld

Het schalen van Elasticsearch zal planning, testen, implementatie en daarna onderhoud met zich meebrengen. Het spreekt voor zich dat goede praktijken, configuratiesjablonen en grondig testen van je cluster vóór het doorvoeren van nieuwe wijzigingen in productie zorgen voor probleemloos schalen naar een langdurig stabiel cluster.

• Verfijn JVM-parameters. We hebben zowel Xms als Xmx ingesteld op 8 GB op elke Elasticsearch-server, waarbij we een balans hebben gevonden tussen het beschikbare systeemgeheugen en de heapvereisten.
• Optimalisatie van shardverdeling. Grote indices zijn opgesplitst in kleinere shards om hotspots te voorkomen en het schalen van replica’s voor de meest actieve indices mogelijk te maken. Hierdoor werd queryverkeer gelijkmatig verdeeld over het cluster.
• Inschakelen van kortetermijn-caching. We hebben een cachevenster van 1 seconde toegepast op veelgebruikte statische queries op de homepage en gemerkt dat dit de belasting op Elasticsearch aanzienlijk vermindert voor herhaalde verzoeken zonder dat dit ten koste gaat van de realtime responsiviteit.
• Monitoring en iteratie. We hebben Kibana gebruikt, met enkele op maat gemaakte dashboards voor realtime observatie van shardgezondheid, JVM-prestaties en querylatenties. Op basis van deze metrieken zijn voortdurend finetuningen uitgevoerd.

Toekomstgerichte plannen of uitbreidingen van de technologiestapel

Bovendien willen we voor groei onderzoeken hoe we het beheer van de levenscyclus van een hot-warm-cold index kunnen verkennen door minder vaak benaderde gegevens naar goedkopere nodes te verplaatsen, terwijl we top hardware behouden voor realtime indexering en queries. We kijken naar geavanceerde monitoringsoplossingen en op AI gebaseerde anomaliedetectie om ervoor te zorgen dat pieken of vertragingen in ongebruikelijke queries ruim van tevoren worden opgemerkt voordat dit de gebruikerservaring beïnvloedt.

Conclusie

Elasticsearch schaalbaarheid vereist een begrip van de architectuur, zorgvuldige planning en het implementeren van best practices. Hoewel Elasticsearch horizontaal schaalt door middel van sharding, zijn er verschillende uitdagingen die in de gaten moeten worden gehouden voor optimale prestaties. De hoge schaalbaarheid en prestaties van een Elasticsearch-cluster kunnen worden gewaarborgd door juiste gegevensinname, shardbeheer, geheugengebruik en queryoptimalisatie.

Hoewel migratie naar Elasticsearch ook voor Solr in ons geval vereist was, was er zonder twijfel meer aan de hand dan alleen puur technische vragen; een belangrijke bijdrage was het begrip van de theoretische moeilijkheden die eigenlijk verborgen liggen in Gedistribueerde Systemen. Dit soort zorgvuldige afstemming en creatieve problemen zou kunnen bijdragen aan een enorme groei — een multivendor enkel Elasticsearch-cluster — dat miljoenen queries per dag moet ontvangen door zijn queryprestaties te verbeteren met sterk verkorte responstijden. Theoretische en praktische elementen vloeien samen bij het schalen van uw Elasticsearch-implementatie om langdurig succes te waarborgen.