‘Magisch project’ Twintos migreerde 10 miljoen MijnOverheid Berichtenboxen

In een villa in het midden van het land migreerden drie Twintos specialisten een database waarbij niets fout mocht gaan: de MijnOverheid Berichtenbox. Alle digitale communicatie tussen de overheid en zo’n 10 miljoen burgers. Kijk hoe we dit 100% accuraat en controleerbaar hebben gedaan. (Zonder te mogen testen met de data zelf.)

Zo’n 10 miljoen burgers vertrouwen op de MijnOverheid Berichtenbox voor al hun officiële communicatie met de overheid. 60 terabyte aan data. Het moment brak aan waarop het nodig was om al die informatie te migreren. Al snel werd duidelijk dat dit een enorm uitdagende operatie was. Een fout zou verstrekkende gevolgen hebben. Zo kwam Twintos in beeld.

Heel weinig tijd

De MijnOverheid Berichtenbox wordt dagelijks veel gebruikt. Het was dan ook zaak om de data te migreren in de kortst mogelijke tijd. Bovendien waren er maar een paar momenten in het jaar geschikt voor deze operatie, omdat er allerlei piekmomenten zijn waarop de Belastingdienst grote hoeveelheden berichten in één keer stuurt.

Testen zonder de burgergegevens

Zo’n migratie willen we natuurlijk tot op de laatste details voorbereiden en testen. Maar ook dat brengt bij een project als dit complicaties met zich mee.

Edward Dortland, medeoprichter van Twintos: “Het gaat om burgergegevens. Die mochten we niet gebruiken om onze software te bouwen en te testen – onder geen enkele voorwaarde. En ik heb er echt een groot punt van gemaakt, want ik vond het niet verantwoord om de data blind te migreren. Toch vond ik het ook charmant dat de overheid voet bij stuk hield. Voor toepassingen in het bedrijfsleven zijn er in de wet wel uitzonderingen vastgelegd om data te mogen gebruiken. Voor deze data was geen enkele uitzondering mogelijk.”

Datavulling gemaakt als testmateriaal

Als oplossing heeft Twintos eerst een compleet nieuwe datavulling gemaakt, op basis van analyses van alle mogelijke variaties in lengte en schrijfwijze van bijvoorbeeld achternamen. Edward: “Zo hebben we een dataset gecreëerd met zoveel mogelijk bijzonderheden. Daarmee hebben we heel veel testmigraties gedaan, vooral om performance-issues te verhelpen.”

Generale repetitie

Uiteindelijk heeft Twintos één proefmigratie mogen doen met de echte data, maar dan zonder de informatie zelf te kunnen inzien. Edward: “De software die we gebruikten om te migreren draaide onder een service-account. Dat account kreeg de rechten, en wij niet. Daardoor konden we één keer een generale repetitie houden met de productiedata, die daarna werd weggegooid.”

Rekening houden met fouten

Dat moest ook wel, vertelt Edward: “Ik had 100% verwacht dat er fouten in de data zouden zitten. Die zijn er nou eenmaal altijd. Daarom heb ik die proefmigratie afgedwongen. Als er geen enkele manier was om met de productiedata proef te draaien, zou het op een drama uit kunnen lopen. Omdat er maar zo weinig momenten in het jaar waren waarin we konden migreren, zou een fout direct 9 maanden uitstel opleveren. Daarom móest de migratie lukken.”

Uitvalsproces voor één speciaal teken

Wat was het resultaat van de proefmigratie? Edward: “Er was één bericht waarin één karakter stond dat door een bug in het doelsysteem niet kon worden geïmporteerd. Dat bleek toen we Logius om toestemming vroegen om dat ene record te bekijken. Van die sessie is een video-opname gemaakt, zodat de overheid later kon aantonen dat er niets was gemanipuleerd.”

Edward: “Tijdens de echte migratie konden we niet zomaar dat ene record aanpassen. De overheid moet namelijk altijd kunnen aantonen dat de berichten na aflevering niet zijn gemanipuleerd. Daarom hebben we voor dat ene bericht een apart uitvalsproces geschreven om op een gecontroleerde manier dat karakter aan te passen.”

Deltamigratie

Om de migratietijd zo kort mogelijk te houden, kozen we voor deltamigratie, een methode om grote hoeveelheden data te migreren met heel weinig downtime. We hebben eerst de grootste bulk aan data overgezet, wat twee weken duurde. Alle nieuwe mutaties kregen een timestamp, waardoor ze te herkennen waren voor de deltamigratie. Die data hebben we in het laatste weekend gemigreerd. Alleen tijdens het laatste weekend moest het systeem even uit de lucht.

9,5 gigabyte per seconde

Maar het was essentieel om de performance nog verder op te schroeven. Bij de eerste tests duurde de migratie 8 weken. Veel te lang. Burgers krijgen namelijk van elk bericht dat ze ontvangen een melding per e-mail. We wilden voorkomen dat er conflicten in de meldingen zouden ontstaan tussen het oude en het nieuwe systeem. Daarom moesten we de migratietijd terugbrengen. Van 8 weken naar 2 weken.

Wiskundegenie

Edward: “Jean-Pierre de Jong, het wiskundegenie in ons team, vond een manier om 100 parallelle threads tegelijk te laten draaien. We konden zo 100 berichtenboxen tegelijkertijd migreren. Jean-Pierre schreef een wiskundig script waarmee hij na weken testen de ultieme verdeling vond van de belasting op het netwerk, de cpu en de opslag. De datamigratie bestaat namelijk uit 3 grote stappen: de data van de RDW kopiëren over het netwerk, dan de gegevens uitpakken en ontsleutelen en daarna wegschrijven in MongoDB. In al die fasen haalde hij het maximale uit de hardware.”

Edward: “De migratieserver had 48 cpu’s, die op 100% cpu-belasting draaiden. We migreerden en valideerden met 9,5 gigabyte per seconde in totaal 60 terabyte aan data. Een belachelijk hoge performance.”

Auditable

En dan was er nog een uitdaging. Hoe maak je aantoonbaar dat alle informatie 100% correct op het nieuwe systeem staat? Edward: “Dat hebben we gedaan door hashvergelijkingen te maken. Van alle attributen – zoals het bericht zelf, de bijlagen, het bsn-nummer – hebben we een hash berekend door middel van een algoritme waarbij, als je er een bepaalde input in geeft, er ook altijd dezelfde output uitkomt.”

“Als wij de attributen van deze database invoerden, moest de hash bij het bronsysteem hetzelfde zijn als bij het doelsysteem. Zo konden we zeker zijn dat alles 100% correct in het nieuwe systeem stond.”

100 miljoen hashvergelijkingen

Edward: “Dit proces hebben we nog versneld door alle individuele berichtenhashes in grotere groepen bij elkaar op te tellen en daar ook weer één hash over te berekenen. Als er dan bij het bronsysteem en het doelsysteem dezelfde hash uitkomt, weet je in een kwestie van seconden dat alles correct is uitgevoerd.”

Live de status zien tijdens de migratie

Vervolgens hebben we nog meer zekerheid ingebouwd. Edward: “We hebben de migratiesoftware iedere stap laten wegschrijven met bijbehorende hash in een auditdatabase. Daar hebben we een dashboardingportaal voor gebouwd. Zodat Logius tijdens de migratie live kon zien wat de status was. Logius heeft daarna door Ernst & Young onze migratiesoftware en rapportageframework laten reviewen.”

Monitoren in shifts van 8 uur

En waarom gebeurde de migratie zelf in een villa in plaats van bij Twintos HQ? Edward: “De migratie liep dag en nacht door. Als er ‘s nachts iets mis zou gaan en we zouden het de volgende ochtend pas zien, zouden we vertraging oplopen. Dat konden we ons niet permitteren want we hadden maar 24 uur uitloop. Daarom zijn we met z’n drieën bij elkaar gaan zitten en hebben we in shifts van 8 uur elkaar afgewisseld om non-stop de migratie in de gaten te houden.”

Magisch project

Edward: “Bovendien wilden we hier volledig op gefocust kunnen zijn. We hadden heel veel voorbereidingen getroffen, maar er stond natuurlijk veel op het spel. Als er iets zou gebeuren, moesten we ons volledig kunnen concentreren om het op te lossen. Maar er ging niets mis. Dat we dit in totale afzondering op zo’n manier hebben kunnen doen, dat was echt magisch. Verreweg een van de leukste IT-projecten waar ik aan heb gewerkt.”

Data migreren waarbij niets, maar dan ook níets fout mag gaan?
Neem contact op en ontdek de rust die je ervaart als je met Twintos werkt.

Mail Edward Dortland, managing director Twintos