š¾Flip
DevOps Flip: "De grootste migratie die ik ooit in mijn leven uitgevoerd hebā¦"
Wat hartje zomer begon met een kleine set-up in een demo-account, groeide binnen een half jaar uit tot een drievoudig (redundant) volledig schaalbaar platform, bestaande uit meer dan 100 servers verspreid over meerdere datacenters. Tientallen terabytes aan files hebben we daarvoor binnen een week met brute rekenkracht van Amsterdam naar Frankfurt verplaatst. Honderden databases werden ās nachts geĆ«xporteerd, maar ook (bijna tegelijkertijd) weer ingeladen. Het enige wat misschien sneller was geweest, wat met een vrachtwagen vol harddisks naar Duitsland te rijden. Deze optie hebben we maar niet serieus overwogen, omdat zowel AWS (Amazon Web Services) als onze vorige hoster ons zeer waarschijnlijk hard hadden uitgelachen.
Wat deze migratie voor Zaaksysteem.nl heeft opgeleverd en hoe heb ik dit als DevOps heb ervaren, lees je in deze blog.
āZonder downtime de nieuwe infrastructuur uitrollen
Voor het configureren van ons netwerk en alle componenten en services die we bij AWS afnemen (elasticsearch, redis clusters, database machines en heel veel virtuele servers om de applicatie te hosten) gebruiken we Terraform. Ik vergelijk dit voor het gemak maar even met een stukje gereedschap waarmee je het netwerk en alle andere infrastructuur, die je nodig hebt, vastlegt in een speciaal (declaratief) computer taaltje. Dit taaltje beschrijft hoe jouw netwerk en alle andere infrastructuur eruit ziet, zodat je dit niet handmatig via de webinterface in elkaar hoeft te klikken, maar dit volledig geautomatiseerd opbouwt. Als je de beschrijving van het netwerk aanpast en de wijzigingen pusht, neemt Terraform het over en weet het precies wat er verwijdert, aangemaakt of geupdate moet worden om tot de gewenste staat te komen.
Zo gezegd, zo gedaan? Nou, in het begin vonden we het heel erg spannend om aanpassingen te maken in deze āreceptenā. EĆ©n druk op de knop en de volledige infrastructuur van Zaaksysteem.nl is aangepast (en dus ook zo stukgemaakt). Gelukkig biedt zowel AWS als Terraform veel mechanismen om je voor fouten te behoeden.
Daarnaast zijn wij er groot voorstander van om alle aanpassingen eerst grondig door meerdere mensen te laten reviewen. Is dat gedaan? Dan testen we alle wijzigingen eerst op een volledig gescheiden lab-account. Zo voeren we nu dus ook overdag (tijdens spitsuur) veilig en zonder downtime onze wijzigingen aan de infrastructuur uit.
Een ander groot voordeel aan deze manier van werken, is dat we alle recepten van onze infrastructuur op Ć©Ć©n centrale plek hebben en kunnen hergebruiken voor nieuwe omgevingen. In minder dan een uur een volledig netwerk opnieuw opbouwen (inclusief alle services en machines in een andere regio) is daardoor prima mogelijk!
Ook vinden we het heel fijn dat alle handelingen, wijzigingen en veranderingen aan de infrastructuur voor- en achteraf te controleren, maar ook makkelijk terug te draaien zijn . In de praktijk betekent dit dat we onze aanpassingen testen en reviewen zoals we dat ook met onze applicatie-code doen, en een fix uitrollen als we een ābugā constateren.
Nooit meer teveel of te weinig servers
Met de zogeheten āauto scaling groupsā (automatisch schaalbare servergroepen) van AWS, bestellen we automatisch extra servers bij als dat nodig is. Onze cluster-software weet precies hoeveel diensten er op een server passen en hoeveel die er moet opstarten. Met een slim rekensommetje verdeelt die ook zelf alle services van het zaaksysteem over de verschillende servers.
Blijkt het dat er servers te weinig zijn, bijvoorbeeld omdat het drukker dan normaal is of omdat er een server is stuk gegaan, dan willen we natuurlijk snel opschalen. De groep maakt zichzelf dan wat groter door automatisch nieuwe servers bij te bestellen. Is het na een uur rustiger op het platform waardoor al die extra servers niet meer nodig zijn? Dan verkleint de groep zichzelf en worden er wat servers weggegooid. Zo hebben we dus altijd genoeg rekenkracht, zonder dat er de hele nacht een groot aantal extra servers aanstaan die we eigenlijk op dat moment niet nodig hebben. Dat scheelt niet alleen geld, maar ook enorm veel stroomverbruik!
āStof is gedaald
De spannende tijden dat kinderziektes als paddestoelen uit de grond schoten (lees: we zondagochtend met gierende banden naar kantoor moesten om lastige verstoringen in het platform op te sporen), lijken nog zo kort geleden. Inmiddels zijn we een half jaar verder en raak ik steeds meer vertrouwd met de nieuwe technieken en de omgeving waarmee we werken. Onze database is sneller dan ooit, ons platform volledig redundant over drie verschillende datacenters en alle opslag is versleuteld in iedere mogelijke vorm.
Wel heeft het sommigen een paar extra grijze haren opgeleverd. Anderen hebben wat quality time moeten inhalen met hun vriendin of kind. Gelukkig zijn we er flink op vooruit gegaan en kunnen we er met onze nieuwe setup weer heel wat jaren tegenaan. Maar natuurlijk blijven we nieuwsgierig naar de limieten van wat technisch mogelijk is, dus die zoeken we ook gewoon nog op!
āVoor de liefhebber nog een kleine vertaling van de migratieperiode in cijfers:
š¢ 1275 dns records aangemaakt of geupdate; š¦ 800GB aan databases verplaatst; š¤ 15 TB aan bestanden naar S3 geupload; š« 300+ installaties gemigreerd; š 1 migratie rollback uitgevoerd; š« 37 candy bars gegeten; š„¤ 30 blikjes Red Bull verslonden; š„© 120 spareribs gegeten (met zn 3en).
