Toteutimme Hankenin datamigraation osa 2: versionhallinta ja migraatiologiikka

Tuotteet ja palvelut
24.8.2022
Toteutimme Hankenin datamigraation osa 2: versionhallinta ja migraatiologiikka

Blogisarjan toisessa osassa kerromme Hankenin datamigraation versiohallinnasta ja migraatiologiikasta.

Kerroimme keväällä blogissamme Hankenin datamigraatiosta, joka oli ensimmäinen migraatio, jonka toteutimme asiakaskorkeakoulullemme. Hanken otti Sisun onnistuneesti käyttöön helmikuussa, ja saimme viimeisetkin migraatiot maaliin kesällä. Tässä kirjoituksessa paneudumme syvällisemmin migraation tekniseen toteutukseen. Lukaise myös aiempi blogikirjoituksemme migraation perusperiaatteista!  

Migraatio rakentui versiohallinnan päälle

Toteutimme jokaisen migraation muutoksen feature-haaroin. Hyödynsimme Hankenin tarpeiden pohjalta hybridimallista versionhallintaa, joka muistutti osin git-flow-, continuous release- ja environment branch -malleja. Lopputuloksena pystyimme viemään uusia migraatioita Hankenin testi-, demo- ja tuotantoympäristöihin eri järjestyksessä, jolloin asiakas pystyi priorisoimaan testaamistaan ja migraatioiden tuotantoviennin järjestystä. Synkronoimme Python-koodin suoraan AWS:ssä pyöriville EC2-instansseille.

Datan siirto kohdejärjestelmien välillä

Kehitimme Hankenia varten järjestelmän, jolla pystyimme hakemaan tuotannon datat ja viemään ne testi- ja demoympäristöihin tarvittaessa ympäristökohtaisesti sekoittaen. Täten Hanken pystyi esimerkiksi harjoittelemaan koulutusten rakenteiden luomista testiympäristössään ja rakentamaan ne lopullisiin muotoihinsa demoympäristössään. Veimme lopulliset koulutukset migraation kautta demolta testi- ja tuotantoympäristöihin, jolloin asiakkaan ei tarvinnut luoda asioita jokaiseen ympäristöönsä erikseen ja esimerkiksi id-viitteet ovat kaikissa ympäristöissä samat.

Rakensimme mekanismin käyttämällä kustomoitua exhaustive tree traversal -algoritmia (BFT), jotta esimerkiksi koulutusta siirtäessä myös sen rakenteen mukaiset kokonaisuudet ja opintojaksot siirtyivät. Näin vältimme eheysviitteiden ongelmat ja saimme kerralla migroitua muun muassa rakenteen koostavat säännöt ja opintopisterajoitteet.

Migraatiologiikka Airflow’ssa

Migraatiologiikka pyöri Airflow’ssa, joka hoitaa tehtävien suoritusjärjestyksen ja ajastuksen niiden konfiguraation perusteella. Airflow’n käytössä oli muun muassa seuraavia hyötyjä:

  • Historiaseuranta: Kehittäjien ei tarvinnut kerätä historiadataa, koska Airflow tallensi jokaisesta ajetusta migraatiosta omat historiatiedot sekä ajon aikaiset logitukset. Ajoista tallentui aikaleimoja ajokohtaisesti sekä jokaisen taskin ajoitus yksittäisen ajon sisältä. Näin seurasimme esimerkiksi eri taskien aikavaativuuden muuttumista migraation aikajanan yli.
  • Riippuvuushallinta: Eri migraatioiden välille määriteltyjen riippuvuuksien kautta oli helppo siirtää yhden migraation tulos migraation seuraavalle askeleelle. Jokainen Airflow'n task palautti suoritettuaan xcom-viitteen, joka tallennettiin Airflow'n sisäisesti PostgreSQL-tietokantaan, jonka kautta seuraava task luki tarvittaessa edellisen tuloksia. Airflow varmisti automaattisesti graafin syklittömyyden, jolloin migraation jumittavia loputtomia syklejä ei päässyt syntymään.
  • Virhetilanteiden käsittely: Yksittäiselle taskille oli mahdollista konfiguroida retry policy, jotta esimerkiksi sen hetkellinen aikakatkaisu lähdejärjestelmässä ei aiheuttanut automaattisesti koko migraatioajon keskeytymistä.
  • Ajastettujen ajojen ja integraatioiden ajaminen: Airflow’n sisäänrakennetulla implementaatiolla ajastimme ja automatisoimme ajoja. Näin migraatioiden ja integraatioiden automatisointi hoitui samalla työkalulla. Esimerkiksi opiskelijoiden läsnäoloilmoittautuminen oli integroitu lähdejärjestelmästä Sisuun masterin vaihtoon asti, jotta opiskelijat pystyivat hallinnoimaan opintosuunnitelmiaan Sisussa ennen virallista käyttöönottoa.
  • Migraatioiden samanaikaisuus: Pystyimme ajamaan useita ajoja yhtä aikaa. Konfiguraation mukaan oli mahdollista määritellä, kuinka monia samanaikaisia prosesseja ajojen sisäisesti voitiin käynnistää. Rajoitteina oli ainoastaan palvelimen prosessorin säikeiden määrä ja käytettävissä oleva hajapääsymuistin määrä. Toisistaan riippumattomien migraatioiden ajo samanaikaisesti nopeutti läpimenoaikoja.

Miten AWS S3 hyödytti migraatiota?

Paneudumme lähiviikkoina Hankenin datamigraatioon vielä kolmannessa blogitekstissä, jossa kerromme muun muassa AWS S3:n hyödyistä migraatiossa sekä Pythonista migraation ohjelmointikielenä. Ajankuluksi voit tutustua upouusiin nettisivuihimme ja lukea aiempia blogipostauksiamme ohjelmistokehityksen pyörteistä!

HDM-tiimin kehittäjät
Jaa artikkeli