Vraag


Acties:
  • 0 Henk 'm!

  • ouweklimgeit
  • Registratie: Juni 2014
  • Niet online
Ik ben op zoek naar wat advies aangaande het opzetten van een schaalbare oplossing in (bijvoorbeeld) kubernetes of soortgelijks.

De situatie is dat ik een SAAS pakket aanbied waarbij ik gebruik maak van ca 25 webservers. Een paar voor de frontend, mysql server, redis en ca 20 'workers' die op de achtergrond informatie verzamelen en verwerken. Die 20 servers draaien allemaal op Ubuntu en via de cron starten ze elke minuut een set taken (python en php) die ze via een API endpoint binnenhalen. Qua schaal moet je denken aan 2.5 miljoen taken per uur die via de API verdeeld worden zodat elke worker elke minuut hetzelfde aantal taken toegewezen krijgt. Als het druk is (taken duren langer dan een minuut) dan moet ik handmatig extra workers inschakelen wat niet handig is. Als het rustig is, stel de 20 servers voltooien hun taken structureel binnen 25 seconden, dan kan ik er gewoon een paar uitschakelen. Gebeurt niet vaak en ik qua kosten boeit het ook niet, maar ik wil hier het liefst geen omkijken naar hebben.

Het huidige proces werkt in principe probleemloos, maar, het zijn wel 20 servers die af en toe een update nodig hebben en ook van dat beheer wil ik af. Het gros van de servers draait bij DigitalOcean, al jaren, en daar ben ik zeer tevreden mee. Vanmorgen voor het eerst een 'platform-app' voorzien van een git repo waar de code voor de statische website in staat. Werkt tadeloos, maar is niet geschikt voor backend applicaties.

Concreet zoek ik een oplossing die (vrijwel) automatisch 'servers' kan toevoegen en verwijderen naar mate de workload toe- of afneemt en git commits automatisch overneemt. De 'servers' moeten daarnaast (statisch) identificeerbaar zijn zodat de API de juiste taken kan toedelen.

Wat is jullie ervaring met dit soort scaling?

Alle reacties


Acties:
  • 0 Henk 'm!

Anoniem: 80910

Ik denk dat je de vraag in het verkeerde subforum geplaatst heb, maar hier moet plaatsen.

Serversoftware en clouddiensten

Acties:
  • 0 Henk 'm!

  • xFeverr
  • Registratie: Juni 2011
  • Laatst online: 17:53
In principe zal elke cloud-aanbieder dat wel moeten kunnen. Je kunt in azure met verschillende diensten aan de slag bijvoorbeeld, en die kunnen ook op- en afschalen. Een Azure App Service regelt voor jou je PHP-omgeving, updates en heel de rambam, jij verzorgt de applicatiecode. En die kun je zo op en afschalen en automatisch van een git repo laten pullen. Heb je geen Kubernetes-cluster voor nodig.

Of je draait een docker container op Azure, ook vrij makkelijk te doen. Er zijn zoveel mogelijkheden. En je kunt stap voor stap overstappen. Of gewoon eens proberen.

[ Voor 17% gewijzigd door xFeverr op 03-06-2023 21:34 ]


Acties:
  • 0 Henk 'm!

  • Merethil
  • Registratie: December 2008
  • Laatst online: 16:47
ouweklimgeit schreef op zaterdag 3 juni 2023 @ 11:12:
Ik ben op zoek naar wat advies aangaande het opzetten van een schaalbare oplossing in (bijvoorbeeld) kubernetes of soortgelijks.

De situatie is dat ik een SAAS pakket aanbied waarbij ik gebruik maak van ca 25 webservers. Een paar voor de frontend, mysql server, redis en ca 20 'workers' die op de achtergrond informatie verzamelen en verwerken. Die 20 servers draaien allemaal op Ubuntu en via de cron starten ze elke minuut een set taken (python en php) die ze via een API endpoint binnenhalen. Qua schaal moet je denken aan 2.5 miljoen taken per uur die via de API verdeeld worden zodat elke worker elke minuut hetzelfde aantal taken toegewezen krijgt. Als het druk is (taken duren langer dan een minuut) dan moet ik handmatig extra workers inschakelen wat niet handig is. Als het rustig is, stel de 20 servers voltooien hun taken structureel binnen 25 seconden, dan kan ik er gewoon een paar uitschakelen. Gebeurt niet vaak en ik qua kosten boeit het ook niet, maar ik wil hier het liefst geen omkijken naar hebben.

Het huidige proces werkt in principe probleemloos, maar, het zijn wel 20 servers die af en toe een update nodig hebben en ook van dat beheer wil ik af. Het gros van de servers draait bij DigitalOcean, al jaren, en daar ben ik zeer tevreden mee. Vanmorgen voor het eerst een 'platform-app' voorzien van een git repo waar de code voor de statische website in staat. Werkt tadeloos, maar is niet geschikt voor backend applicaties.

Concreet zoek ik een oplossing die (vrijwel) automatisch 'servers' kan toevoegen en verwijderen naar mate de workload toe- of afneemt en git commits automatisch overneemt. De 'servers' moeten daarnaast (statisch) identificeerbaar zijn zodat de API de juiste taken kan toedelen.

Wat is jullie ervaring met dit soort scaling?
toon volledige bericht
Kubernetes kan dit inderdaad maar binnen AWS (ja, da's dan weer mijn voorkeur :+) zou ik dit oplossen met Fargate; alle taken in containers gooien en in een cluster je taken verdelen onder frontend, backend en worker tasks. Via AWS cloudmap kan je dan automatisch de taken eigen DNS-records geven zodat je simpel elke "server" een eigen herleidbare naam kan geven.
Opschalen kan dan via de CLI, of je laat het de Fargate Service zelf uitzoeken op basis van cpu usage. Eventueel kan je nog ontkoppelen en de taken laten starten vanuit een SQS queue, dan kan Fargate op basis van de SQS queue length bepaalde op- en afschaling laten plaatsvinden.

Omdat het Serverless is zit je niet langer met onderhoud van OSen en kan je het cluster zelf alle updates laten uitvoeren zonder er verder naar om te hoeven kijken. Nieuwe code kan je laten pushen vanuit een CICD pipeline; Github, Gitlab en Bitbucket hebben hier iig ingebouwde actions voor en AWS zelf heeft codepipeline die je hier ook zou kunnen inzetten.

Dit concept bestaat trouwens bij allerlei cloud providers, en ook iets als EKS, of Digital Ocean's managed Kubernetes kan natuurlijk prima werken in jouw geval.

[ Voor 3% gewijzigd door Merethil op 03-06-2023 22:05 ]


Acties:
  • 0 Henk 'm!

  • retoohs
  • Registratie: April 2019
  • Laatst online: 14:21
Dit moet met elke cloud provider we lukken. Met Kubernetes kan dit ook. Je kan dan pods / conainers laten op of af laten schalen. Je kan ook een pods starten die een enkele task uitvoeren en daarna weer stoppen.
Het voordeel van Kubernetes is dat je niet vast zit aan een enkele cloud provider. Je zou zo de hele boel kunnen verhuizen naar cloudprovider b wanneer je niet tevreden bent bij cloudprovider a.

Ik zou wel een onderzoekje starten naar de kosten. Wie weet betaal je op de cloud structureel meer dan wat je nu met piek belasting op on prem doet. Ik zeg niet dat het zo is maar het zou wel een beetje zonde zijn om alles te migreren met de bijbehorende steile leercurve om er vervolgense achter te komen dat het niet de moeite waard blijkt.
Het is interessant als je veel variantie hebt in benodigde resources. Bijvoorbeeld als je in het weekend niks doet, dan zou je in de cloud alles af kunnen schalen en op die manieren veel kosten kunnen besparen. Of wanneer je services hebt die je alleen af en toe nodig hebt. Je kan dan serverless functions gebruiken die niks kosten wanneer ze niet gebruikt worden.
Of denk aan een test / acceptatie omgeving. Deze zou je dan op kunnen starten alleen wanneer je een test gaat uitvoeren.

Acties:
  • 0 Henk 'm!

  • Falcon
  • Registratie: Februari 2000
  • Laatst online: 17:01

Falcon

DevOps/Q.A. Engineer

Je knelpunt zit dus in de distributie van die taken en daarbij hoeveelheid resources die daarvoor nodig zijn om dit te verwerken.

Ik denk dat een combinatie van KEDA en Kubernetes cluster jou kan helpen. Maar daarvoor heb ik eigenlijk veel meer informatie voor nodig.

Maar als je Kubernetes wilt gaan doen, zou je eerst jouw applicaties beschikbaar moeten maken in een container image binnen een container registry (bijv. Docker/Docker Desktop/Dockerhub).

Waar je misschien ook over kunt nadenken is een asynchrone interface naar de Workers toe op basis van een pub/sub systeem. Daarop zou dan bijv. KEDA weer ook kunnen reageren, als een queue met messages vol loopt en meer instanties nodig zijn van een Worker.

Onderstaande kan je op diverse manieren organiseren op cloud providers (al vermoed ik dat dit weleens heel prijzig kan worden met de aantallen die jij noemt), maar ook prima op een eigen server. Maar begrijp wel dat het een flinke cognitieve load met zich meebrengt en extra infra beheer.

Afbeeldingslocatie: https://symphony.is/_next/image?url=https%3A%2F%2Fprod-api.symphony.is%2Fassets%2Fimage1-3.webp&w=1920&q=75

[ Voor 12% gewijzigd door Falcon op 17-07-2023 20:11 ]

"We never grow up. We just learn how to act in public" - "Dyslexie is a bitch"

Pagina: 1