Mijn collega Johan Reitsma kwam via Meetup een sessie tegen met de titel "Umbraco Azure App: How not to autoscale!". Misschien dat hier nog een paar slimme tips genoemd worden. Deze sessie wordt georganiseerd door Umbraco Wales, start om 19.30 uur: link naar sessie.
Ik was aan de late kant, nog even een blokje om gelopen, vervolgens geen audio in de browser, dus op mijn andere laptop de Zoom-meeting geopend. Dat werkt, er zijn al een aantal personen online. Gelukkig is de sessie nog niet gestart, rond 19.50 uur gaan we los.
Rob Shaw vertelt over de ervaringen die hij zelf met zijn team heeft gehad bij een grotere website. Een Umbraco-website, gehost in Azure.
Het uitschalen van de web-applicaties stond ingesteld op het CPU gebruik van de database. Later wordt gezegd dat het om het CPU gebruik van de web-apps ging (dat klinkt ook logischer).
Eerste probleem: flapping
Bij belasting werd opgeschaald, op basis van een policy. Daarbij moet de instantie opgestart worden, de database wordt even zwaarder belast. Maar hierna daalde het CPU-gebruik weer en werd weer afgeschaald. Waardoor er weer opgeschaald moest worden. Daardoor "flapt" het heen-en-weer.
Tweede probleem: de database-tier
Volgens de Umbraco Azure aanbevelingen zou een S2-instantie als minimum voldoende zijn. Volgens Rob is duidelijk dat dit niet voldoende is, bij hun grote website met regelmatig veel bezoekers, grote database met veel nodes zijn ze overgestapt naar een S3 instantie. En dan nog is het soms kiele-kiele.
Derde probleem: verkeer
Op bepaalde momenten steeg het aantal bezoekers met zulke aantallen dat de aanvragen bijna DDOS-achtige trekken kregen.
De acties/bevindingen die hieruit kwamen;
- Het opschalen niet alleen op basis van CPU-gebruik, gebruik ook andere metrieken.
- Houd rekening met opstarttijd van een nieuwe instantie voor je een nieuwe instantie gaat opstarten.
Bij het opstarten wordt de database belast. Hierdoor duurt het even voor een instantie écht opgestart is. Hou deze tijd als marge voor er automatisch een andere instantie opgestart kan worden.
- Keuze voor de database tier.
Rob gaf aan dat ze voor het opschalen van de database zelf in de portal moesten inloggen om dit handmatig uit te voeren. Iets wat je eigenlijk niet wil. Dit kan automatisch, maar hier hangt wel een prijskaartje aan.
Een paar extra zaken die nog genoemd worden:
- Zorg voor goede communicatie met de klant. Als er extra bezoekers naar de site gaan surfen (bepaald evenement, bepaald nieuws-item) en de klant licht je van tevoren in, dan kun je extra monitoren en voorbereidingen treffen.
- Je kunt in Azure "alerts" instellen. Als je database voor 60% belast wordt, terwijl dat normaal rond de 10% of 20% is, dan is het goed dat je een melding krijgt.
- Zorg dat je database kan auto-scalen.
Hiermee is de sessie afgelopen en wordt er nog wat nagepraat. Zo wordt onder andere gesproken over "je bouwt iets, je test wat dingen, maar hoe kun je echte load testen?". In Visual Studio had je tools (maar die zijn er niet meer?). Ik heb nog even gedropt dat je hiervoor K6 zou kunnen gebruiken: link.
Wat Rob ook nog noemde dat ze zaken ingesteld en ingericht hadden, tegen problemen aanliepen, weer op de site van "best practises van Umbraco/Azure" keken en er toen allemaal extra/nieuwe dingen op die pagina stonden.
Meteen de link er nog even bij gezocht: link.
Er hadden zich iets van 10 of 12 mensen aangemeld, uiteindelijk waren we met 6 of 7 personen (waarbij een aantal van de organisatie). Na de tijd werd ook nog even gesproken over het doorzetten van online meet-ups, fysieke meet-ups (in dat geval mag ik de volgende keer afreizen naar Wales, ook niet verkeerd) of een hybride versie, een fysieke bijeenkomst, maar waar je ook online bij kunt zijn. Dan heb je misschien ook een hogere opkomst en meer interactie. In ieder geval, leuke sessie en misschien heb je nog wat aan deze informatie!