's Picture

Live Data - alltid perfekt testdata

Postad av Joel Abrahamsson

Hur vi skapat en testmiljö med en exakt, alltid uppdaterad replika av produktionsmiljöns data med hjälp av RabbitMQ och dess Shovel-plugin.

Oavsett hur testdriven utveckling som man sysslar med är bra testmiljöer viktiga. Ibland behövs en miljö där man kan labba fritt och testa olika scenarion. I andra fall ser behovet annorlunda ut och det behövs en miljö som är så realistisk som möjligt. Att ha realistisk data i en testmiljö möjliggör enklare felsökning, realistiska lasttester och, kanske viktigast av allt, en realistisk miljö att testa uppgraderingar på.

En vanlig lösning är att löpande hämta backuper från produktion och återställa dem på en testmiljö.

Men, realistisk testdata är inte alltid det enklaste. En vanlig lösning är att löpande hämta backuper från produktion och återställa dem på en testmiljö. Detta ger dock inte helt realistisk data eftersom det direkt börjar bli inaktuellt. Dessutom, för en stor sajt som expressen.se kan det röra sig om tiotals, eller hundratals, gigabyte data vilket gör det omständligt att skicka backuper fram och tillbaka.

Vår lösning på problemet är en miljö som vi kallar Live Data. Miljön är inte publik utan används för internt bruk och har alltid exakt samma data som produktionsmiljöerna. Hur åstadkommer vi detta?

Som jag tidigare har bloggat om flödar innehåll från vårt CMS till en meddelande-hanterare (eller hur man nu försvenskar engelskans "message broker"), RabbitMQ. Därifrån läser vårt API meddelanden om nytt eller förändrat innehåll och lagrar det i ElasticSearch. Annan data, såsom sidvisningar och videovisningar, behandlas på liknande sätt. De tas emot av system specialiserade på att ta emot användarinteraktioner, publiceras som meddelanden på meddelande-hanteraren och går därifrån vidare till system som bygger topplistor och liknande.

I våra testmiljöer har vi samma uppsättning, dvs en testinstans av CMS:et, en meddelande-hanterare för testmiljön etc. I dessa miljöer kan vi labba fritt men här har vi inte samma data som i produktion.

Sen har vi den beryktade Live Data-miljön. På denna har vi ett antal krav:

  • Den ska vara "live" och alltid uppdaterad med samma data som i produktion.
  • Den ska kunna hantera problem och nedtid och komma ikapp produktion när den väl kommer upp igen.
  • Det ska vara enkelt att återskapa data från produktion i händelse av att testdatan blir korrupt.
  • Dataflödet från produktion ska vara enkelt att övervaka.

För att hantera ovan nämnda krav har vi en förhållandevis enkel lösning: vi använder Shovel-pluginet till RabbitMQ. Med hjälp av detta skickas meddelanden som publiceras på RabbitMQ i vår produktionsmiljö vidare till Live Datas RabbitMQ. När ett meddelande väl skickats vidare behandlas det på samma sätt som om i produktion men av de komponenter som ingår i Live Data-miljön. På detta sätt har vi bland annat ett innehålls-API för testbruk som alltid har samma data som i produktion.

Ovan bild är en aningen förenklad version av verkligheten. Den överensstämmer dock med hur det såg ut för några månader sedan. Då skyfflade vi alla meddelanden från RabbitMQ i produktion till Live Data-miljön. På senare tid har vi dock justerat detta så att det enbart handlar om meddelanden som är skapade på grund av yttre interaktioner, såsom att innehåll publiceras i CMS:et eller att en sidvisning sker. Meddelanden som genereras av våra egna system, exempelvis för att berätta att nytt innehåll finns i API:et eller för att bekräfta att ett meddelande har behandlats skippar vi. Detta åstadkommer vi genom att i Rabbit bara delegerar vissa meddelanden till Shovel-pluginet. En mer rättvisande bild där vi zoomar in på RabbitMQ-instanserna är således:

Foto toppbild: Shutterstock

PS. Missa inte vår nästa bloggpost, följ oss på Twitter!

Till startsidan