Het probleem: Piekbelasting op de server
Onze server verwerkt doorgaans zo'n 30 verzoeken per seconde, maar dit kon plots pieken tot 400–500 verzoeken per seconde wanneer een groot account op onze instantie werd benaderd. Dit is typisch voor de Fediverse: verschillende servers doen tegelijkertijd verzoeken aan een instantie, wat leidt tot onvoorspelbare pieken.
Ons huidige systeem, een DigitalOcean Cluster Autoscaler, kan de infrastructuur automatisch opschalen bij toenemende vraag. Maar deze reageert traag op plotselinge pieken. Door budgetbeperkingen was het niet haalbaar om altijd capaciteit voor piekverkeer beschikbaar te houden.
De eerste oplossing: caching via Cloudflare
Onze eerste poging was met Cloudflare. Cloudflare staat bekend om zijn betaalbare en effectieve content delivery netwerk (CDN), wat het tot een logische keuze maakte.
Het probleem met de Vary-header
De Vary-header in HTTP-responses is essentieel voor correcte caching. Deze header vertelt een cache om bepaalde request-headers in overweging te nemen bij het bepalen of een response hergebruikt mag worden. Mastodon, de software achter toot.community, gebruikt deze header slim, zoals te zien is in dit voorbeeld:
$ curl -vvv https://toot.community/@support/110769156286181747 -H "Accept: application/json" 2>&1 | grep --extended-regexp --ignore-case "cache-control|vary"
< cache-control: max-age=180, public
< vary: Accept, Accept-Language, CookieIn dit geval varieert de response op basis van de Accept-header. Het probleem was dat Cloudflare deze Vary-header niet ondersteunde voor API- en webverkeer. Als bijvoorbeeld een JSON-response als eerste werd gecached, kregen latere verzoeken voor HTML onterecht diezelfde JSON terug.
Deze beperking van Cloudflare is goed gedocumenteerd (Cloudflare Cache Control, Cloudflare Community Discussion). Daardoor bleek Cloudflare geen geschikte oplossing voor het cachen van dynamische content.
De overstap naar Fastly
Onze zoektocht naar een robuuste caching-oplossing bracht ons bij Fastly. Fastly ondersteunt de Vary-header wél (Best Practices Using Vary Header) en stelt ons in staat om responses correct te cachen op basis van het gevraagde formaat.
Dankzij Terraform, een tool om infrastructuur veilig en efficiënt te beheren, verliep de integratie van Fastly soepel. We maakten gebruik van een bestaand Terraform-module (mastodon/terraform-fastly-service), specifiek ontwikkeld voor Mastodon-instanties en perfect afgestemd op onze behoeften.
Sinds de implementatie van Fastly zijn onze backend-servers veel stabieler. De verkeerspieken — een vast onderdeel van de Fediverse — worden nu effectief opgevangen door de cachinglaag van Fastly. Hierdoor kunnen we onze gebruikers een constantere en betrouwbaardere service bieden.
Een blik achter de schermen
Ben je technisch aangelegd en wil je zien hoe we onze infrastructuur precies beheren? Neem dan een kijkje op onze GitHub-organisatie: toot-community op GitHub voor een diepere inkijk in ons werk achter de schermen.
Wat we hebben geleerd
Uit deze ervaring hebben we een paar waardevolle lessen getrokken:
- Ken je verkeer: De gedecentraliseerde aard van de fediverse zorgt voor onvoorspelbare belasting. Inzicht in je verkeer helpt bij het kiezen van de juiste tools.
- Kies de juiste tools: Niet elk hulpmiddel is geschikt voor elke situatie. Begrijp de beperkingen en voordelen van elke optie.
- Wees flexibel in je oplossingen: Soms moet je bijsturen als een gekozen oplossing toch niet werkt.
- Gebruik communitytools: Hulpmiddelen als Terraform en communitymodules kunnen veel werk uit handen nemen.
De reis van toot.community in het omgaan met schalingsproblemen laat zien hoe belangrijk het is om zowel technisch als operationeel inzicht te hebben in het beheren van servers in een constant veranderend landschap. Het is een leerproces — maar wel één dat loont.