Skip to main content

29 Tekniikkaa

29Tekniikkaa
29Tekniikka logo
29Tekniikkaa

Recent Post

Pilvimigraation tietojen synkronointi ei toimi – yleiset syyt ja ratkaisut

Pilvimigraatiossa puhutaan paljon palvelimista, verkoista, tietokannoista ja siitä, miten uusi ympäristö rakennetaan. Käytännössä yksi hankalimmista asioista voi olla paljon pienempi kysymys:

Mitä tapahtuu datalle sillä aikaa, kun vanha järjestelmä on vielä käytössä?

Tämä jää helposti alkuvaiheessa taka-alalle. Vanha tietokanta kopioidaan uuteen ympäristöön ja ensimmäinen tarkistus näyttää hyvältä. Rivimäärät täsmäävät, sovellus käynnistyy ja muutama testi menee läpi.

Sitten joku muuttaa tuotteen hintaa vanhassa järjestelmässä.

Uudessa ympäristössä on edelleen vanha hinta.

Siitä alkaa varsinainen migraatio-ongelma.

Tietojen siirtäminen kerran on eri asia kuin kahden ympäristön pitäminen ajan tasalla toistensa kanssa. Jälkimmäisessä pitää tietää, mitä muuttui, milloin muutos tapahtui, missä se käsiteltiin ja mitä tehdään, jos sama muutos epäonnistuu matkalla.

Juuri näissä kohdissa pilvimigraatioissa tulee yleensä eniten yllätyksiä.

Ensimmäinen kopio ei ole synkronointi

➠ Otetaan tavallinen tilanne.
➠ Yrityksellä on vanha tuotantojärjestelmä ja uusi pilviympäristö. Vanhan tietokannan sisältö siirretään uuteen tietokantaan viikonlopun aikana.
➠ Siirron jälkeen molemmissa on esimerkiksi 850 000 asiakasta ja 4,2 miljoonaa tilausta.
➠ Paperilla kaikki näyttää hyvältä.
➠ Mutta maanantaina vanhassa järjestelmässä tapahtuu taas tuhansia muutoksia.
➠ Uusia asiakkaita tulee. Osoitteita korjataan. Tilauksia perutaan. Maksujen tiloja muuttuu. Tuotteita poistetaan käytöstä.
➠ Jos uuteen ympäristöön ei saada näitä muutoksia, maanantaina aamulla tehty datavertailu ei enää vastaa todellisuutta.
➠ Tässä kohtaa kannattaa erottaa kaksi asiaa toisistaan:
  • initial load, jossa olemassa oleva data siirretään
  • change synchronisation, jossa myöhemmät muutokset viedään uuteen ympäristöön
➠ Ensimmäinen on yleensä kertaluonteinen työ. Toinen on jatkuva prosessi.
➠ Moni migraatiohanke käyttää paljon aikaa ensimmäiseen ja liian vähän toiseen.

Data voi muuttua useammin kuin luullaan

Ennen synkronointiratkaisun valintaa kannattaa selvittää, mistä muutokset oikeasti tulevat.

Tämä kuulostaa itsestään selvältä, mutta yrityksen järjestelmäympäristössä vastaus ei välttämättä ole “käyttäjä muuttaa tiedon tässä sovelluksessa”.

Asiakastieto voi tulla verkkopalvelusta. Myynti voi päivittää sitä CRM-järjestelmässä. Taloushallinto voi muuttaa laskutustietoa. Taustalla voi olla vielä integraatio, joka tuo tietoja toisesta järjestelmästä.

Jos uusi pilvijärjestelmä ottaa yhden näistä rooleista itselleen, samalla pitää päättää, mitä vanhoille kirjoituspoluille tapahtuu.

Muuten päädytään helposti tilanteeseen, jossa sama asiakas muuttuu kahdessa paikassa.

Esimerkiksi:

  • Vanha järjestelmä muuttaa asiakkaan tilaksi active.
  • Uusi järjestelmä muuttaa sen hetkeä myöhemmin tilaan blocked.

Mikä on lopullinen arvo?

Jos tähän ei ole vastausta, tekninen synkronointiratkaisu ei ratkaise ongelmaa. Se vain siirtää epäselvyyden järjestelmästä toiseen.

Kaikkea ei tarvitse synkronoida kahteen suuntaan

Kaksisuuntainen synkronointi kuulostaa aluksi joustavalta.

Todellisuudessa se voi tehdä migraatiosta huomattavasti vaikeamman.

Jos vanha järjestelmä kirjoittaa uuteen ympäristöön ja uusi ympäristö kirjoittaa takaisin vanhaan, jokaiselle tietotyypille pitää pystyä vastaamaan esimerkiksi seuraaviin kysymyksiin:

  • Kumpi saa muuttaa tiedon?
  • Miten ristiriita ratkaistaan?
  • Miten tunnistetaan oma aiemmin lähetetty muutos?
  • Mitä tapahtuu, jos sama tapahtuma tulee kahdesti?
  • Ja mitä tehdään, jos yhteys katkeaa juuri muutoksen käsittelyn jälkeen?

Jos liiketoiminta sallii sen, yksisuuntainen malli on usein helpompi hallita. Vanha järjestelmä voi olla jonkin aikaa ainoa kirjoittaja ja uusi ympäristö vastaanottaa muutokset. Myöhemmin kirjoitukset voidaan siirtää uuteen järjestelmään.

Se ei sovi jokaiseen ympäristöön, mutta se on usein helpompi kuin rakentaa heti täysi kaksisuuntainen synkronointi.

Change Data Capture ratkaisee vain osan ongelmasta

➠ Tietokannan muutosten seuraamiseen voidaan käyttää Change Data Capture -ratkaisua eli CDC:tä.
➠ Perusidea on järkevä: koko tietokantaa ei tarvitse jatkuvasti verrata keskenään. Sen sijaan seurataan lisäyksiä, päivityksiä ja poistoja.
➠ Tämä voi olla hyvä ratkaisu esimerkiksi tilanteessa, jossa vanhaa tietokantaa ei voida pysäyttää migraation ajaksi.
➠ Mutta CDC:n käyttöönotto ei vielä tarkoita, että synkronointi olisi valmis.
➠ Pitää tietää, mitä tapahtumalle tehdään vastaanottavassa päässä.
➠ Entä jos uusi järjestelmä ei hyväksy vanhan järjestelmän arvoa?
➠ Entä jos tapahtuma tulee kahdesti?
➠ Entä jos tapahtumat tulevat eri järjestyksessä?
➠ Entä jos kohdejärjestelmä on poissa käytöstä kaksi tuntia?
➠ Näihin kysymyksiin vastaaminen on paljon tärkeämpää kuin se, mikä teknologia näkyy arkkitehtuurikaaviossa.

Tapahtumien järjestys voi rikkoa muuten toimivan ratkaisun

Tämä on yksi niistä ongelmista, joita ei välttämättä huomata pienessä testissä.

Asiakkaan tila muuttuu näin: pending → approved → completed

Jos nämä kolme muutosta käsitellään samassa järjestyksessä, ongelmaa ei ole.

Mutta jos completed saapuu ensin ja approved vasta sen jälkeen, uusi järjestelmä voi kirjoittaa asiakkaalle vanhemman tilan.

Siksi tapahtuman mukana tarvitaan usein jonkinlainen järjestystä kuvaava tieto.

Se voi olla versionumero, sequence number, tietokannan oma muutosjärjestys tai muu lähdejärjestelmän tarjoama mekanismi.

Aikaleimaan kannattaa suhtautua varauksella. Se ei yksinään välttämättä kerro tapahtumien todellista järjestystä, varsinkaan jos mukana on useita palvelimia tai järjestelmiä.

Sama tapahtuma voi tulla uudestaan

Viesti- ja tapahtumapohjaisissa järjestelmissä kannattaa olettaa, että viesti voidaan vastaanottaa uudelleen.

Tämä ei ole välttämättä virhe.

Jos käsittely on esimerkiksi: lisää tilaukseen 100 euroa

sama tapahtuma kahdesti voi aiheuttaa ongelman.

Jos käsittely taas on: aseta tilauksen kokonaissummaksi 100 euroa

toinen käsittely ei välttämättä muuta lopputulosta.

Tässä on idempotenssin käytännön merkitys.

Migraation aikana tätä ei kannata jättää myöhemmäksi. Kun vanhaa ja uutta järjestelmää ajetaan rinnakkain, uudelleenlähetyksiä ja korjaustilanteita tulee ennemmin tai myöhemmin vastaan.

Yksi yleinen tapa on käyttää tapahtuman yksilöllistä tunnistetta ja säilyttää tieto jo käsitellyistä tapahtumista. Toteutus riippuu järjestelmästä, mutta periaate on sama: vastaanottajan pitää pystyä tunnistamaan, että sama asia on jo käsitelty.

Tietomalli ei aina siirry sellaisenaan

➠ Pilvimigraatio ei välttämättä tarkoita vain sitä, että sama tietokanta sijaitsee uudessa paikassa.
➠ Usein samalla tehdään muutoksia rakenteeseen.
➠ Vanhan järjestelmän yksi taulu voi jakautua useaksi tauluksi. Kenttien nimet voivat muuttua. Jotkin vanhat arvot voidaan korvata uusilla koodeilla. Jokin tieto voi jopa poistua kokonaan.
➠ Esimerkiksi vanhassa järjestelmässä asiakkaalla voi olla:
status = “customer”
➠ Uudessa mallissa sama tieto voi muodostua useasta asiasta:
  • asiakkuuden tila
  • sopimuksen tila
  • käyttöoikeuden tila
➠ Silloin kyse ei ole enää suorasta synkronoinnista.
➠ Välissä tarvitaan muunnos.
➠ Tässä kannattaa olla tarkkana. Jos muunnossäännöt ovat epäselviä, sama vanha arvo voi päätyä eri tilanteissa eri uudeksi arvoksi. Silloin teknisesti onnistunut siirto voi tuottaa liiketoiminnallisesti väärän tuloksen.

Suuret taulukot tuovat toisenlaisen ongelman

Pienen tietokannan kanssa lähes mikä tahansa järkevä siirtotapa voi tuntua toimivalta.

Kun rivejä on kymmeniä tai satoja miljoonia, tilanne muuttuu.

Kaikkea ei ehkä voida siirtää yhdellä kertaa. Siirto voidaan joutua tekemään erissä esimerkiksi tunnisteen, päivämäärän tai muun avaimen perusteella.

Tällöin pitää myös tietää, missä kohtaa siirto on menossa.

Jos prosessi pysähtyy 67 prosentin kohdalla, sen pitäisi pystyä jatkamaan siitä eikä aloittaa kaikkea alusta.

Myös tämä vaikuttaa synkronointiin. Samaan aikaan kun vanhaa dataa kopioidaan, uutta dataa syntyy jatkuvasti.

Siksi alkuperäinen siirto ja muuttuneiden tietojen seuranta pitää sovittaa yhteen.

“Kaikki rivit täsmäävät” ei tarkoita, että data on oikein

Tämä on tärkeä ero.

Kuvitellaan, että molemmissa järjestelmissä on miljoona tilausta.

Rivimäärä täsmää.

Silti yksi tilaus voi olla väärässä tilassa, yhden asiakkaan laskutustiedot voivat puuttua ja joidenkin tuotteiden hinnat voivat olla vanhoja.

Siksi täsmäytyksessä kannattaa verrata myös sisältöä.

Kaikkea ei tarvitse vertailla joka kerta yksittäinen kenttä kerrallaan. Käytännössä voidaan käyttää esimerkiksi tarkistussummia, aggregaatteja, versiotietoja tai valittuja liiketoimintakriittisiä kenttiä.

Talousdatassa voidaan verrata summia. Varastotiedoissa saldoja. Tilauksissa tilajakaumaa. Asiakasdatassa tietueiden määrää ja viimeisimpien muutosten ajankohtaa.

Tarkistus pitää valita datan mukaan.

Tuotantovirhe ei saa kadottaa muutosta

Yksi huonoimmista vaihtoehdoista on tämä:

  • muutos luetaan
  • lähetys uuteen ympäristöön epäonnistuu
  • virhe kirjataan lokiin
  • tapahtuma unohtuu

Lokissa voi näkyä virhe, mutta data on silti kadonnut synkronoinnista.

Parempi ratkaisu on pitää epäonnistunut tapahtuma tallessa, jotta se voidaan käsitellä uudelleen.

Tässä viestijono tai muu pysyvä välityskerros voi olla hyödyllinen. Myös dead-letter-mekanismi voi olla tarpeen, jos tietty tapahtuma epäonnistuu toistuvasti.

Mutta myöskään dead-letter-jono ei ole paikka, johon ongelmat voidaan vain unohtaa.

Jonossa pitää olla seuranta. Muuten siellä voi olla kuukausien ajan vanhoja tapahtumia, joita kukaan ei huomaa.

Synkronoinnin viive on oma tuotantomittarinsa

➠ Kaikki yritykset eivät tarvitse reaaliaikaista synkronointia.
➠ Jos raportointidata saa olla viisi minuuttia vanhaa, sitä ei kannata rakentaa samalla tavalla kuin maksutapahtumia.
➠ Siksi yksi ensimmäisistä päätöksistä pitäisi olla hyväksyttävä viive.
➠ Jos tavoitteena on alle minuutti, sitä pitää mitata.
➠ Ei riitä, että “yleensä tieto tulee nopeasti”.
➠ Seurattava asia voi olla esimerkiksi aika lähdejärjestelmän muutoksesta siihen hetkeen, kun muutos on varmasti käytettävissä kohdejärjestelmässä.
➠ Kun viive alkaa kasvaa, ongelma voidaan havaita ennen kuin käyttäjät alkavat ilmoittaa siitä.

Pilvimigraatiossa ympäristöjen erot näkyvät nopeasti

Kehitysympäristössä synkronointi voi toimia hyvin, koska dataa on vähän ja tapahtumia tulee harvoin.

Tuotannossa sama putki voi joutua käsittelemään tuhansia muutoksia minuutissa.

Lisäksi tuotannossa mukana ovat oikeat integraatiot, oikeat käyttäjät ja kaikki ne pienet poikkeamat, joita testidatassa ei ollut.

Siksi synkronointia pitäisi testata myös kuormalla.

Esimerkiksi:

  • mitä tapahtuu, jos tapahtumamäärä kolminkertaistuu?
  • mitä tapahtuu, jos kohdejärjestelmä on poissa 30 minuuttia?
  • pysyvätkö tapahtumat tallessa?
  • palautuuko käsittely automaattisesti?
  • mitä tapahtuu, jos sama viesti tulee kahdesti?
  • pystytäänkö tapahtumajono purkamaan ilman, että uusia muutoksia menetetään?

Näihin testeihin kannattaa käyttää aikaa ennen varsinaista siirtymää.

Kaikkea ei tarvitse tehdä reaaliajassa

Reaaliaikaisuudesta on tullut monessa arkkitehtuurissa oletus.

Migraatiossa se ei aina ole tarpeen.

Jos esimerkiksi vanhaa raportointijärjestelmää käytetään kerran tunnissa, jatkuva sekuntitason synkronointi voi tuoda enemmän teknistä monimutkaisuutta kuin hyötyä.

Toisaalta tilaustenkäsittelyssä tai maksamiseen liittyvässä tiedossa muutaman tunnin viive voi olla täysin mahdoton.

Synkronointivaatimus kannattaa siis johtaa liiketoiminnasta.

Ei siitä, mitä pilviarkkitehtuurissa sattuu olemaan tarjolla.

Entä jos synkronointi menee väärin?

➠ Tämä kysymys kannattaa esittää ennen tuotantosiirtoa.
➠ Ei sen jälkeen.
➠ Jos uuteen järjestelmään siirtyy väärää dataa, miten palataan takaisin? Voidaanko kirjoitukset ohjata hetkeksi vanhaan järjestelmään? Voidaanko epäonnistuneet muutokset korjata ilman koko tietokannan palauttamista?
➠ Rollback ei aina tarkoita koko migraation peruuttamista.
➠ Jos esimerkiksi uusi ympäristö on ollut käytössä kuusi tuntia ja sinne on syntynyt uusia tilauksia, vanhaan järjestelmään palaaminen ei ole enää yksinkertainen “palauta varmuuskopio” -operaatio.
➠ Uudet tapahtumat pitää myös saada talteen.
➠ Tämän vuoksi siirtymästrategia ja synkronointi kannattaa suunnitella yhdessä. Niitä ei ole järkevää käsitellä kahtena erillisenä projektina.

Käytännössä ongelma on usein prosessissa

Teknologia voi olla kunnossa ja synkronointi silti epäonnistua.

Syynä voi olla esimerkiksi se, ettei kukaan tiedä, kuka tarkistaa täsmäytyksen. Tai virhejonossa oleville tapahtumille ei ole sovittu omistajaa.

Tuotantoon siirryttäessä pitäisi olla selvää:

  • kuka seuraa synkronoinnin tilaa
  • kuka reagoi kasvavaan viiveeseen
  • kuka käsittelee epäonnistuneet tapahtumat
  • kuka hyväksyy datan täsmäytyksen
  • kuka tekee päätöksen siirtymisestä uuteen ympäristöön
  • mitä tehdään, jos tulokset eivät täsmää

Nämä eivät ole vain projektinhallinnan kysymyksiä. Ne vaikuttavat suoraan siihen, voidaanko migraatio tehdä turvallisesti.

Milloin kannattaa käyttää yksinkertaisempaa ratkaisua?

Jos tietokanta voidaan pysäyttää lyhyeksi aikaa ja koko siirto voidaan tehdä hallitusti, jatkuvan synkronoinnin rakentaminen ei välttämättä ole järkevää.

Jos käyttökatkoa ei voida hyväksyä, tilanne on toinen.

Silloin voidaan käyttää esimerkiksi vaiheittaista migraatiota, CDC:tä, tapahtumapohjaista siirtoa tai näiden yhdistelmää.

Joskus paras ratkaisu on aloittaa pienestä osasta dataa. Ensin siirretään yksi liiketoimintakokonaisuus, seurataan sitä tuotannossa ja vasta sen jälkeen laajennetaan.

Tämä antaa myös mahdollisuuden löytää virheitä silloin, kun niiden vaikutus on vielä rajallinen.

Mitä hyvä synkronointi lopulta tarkoittaa?

➠ Hyvä ratkaisu ei tarkoita sitä, ettei koskaan tule virheitä.
➠ Virheitä tulee.
➠ Parempi tavoite on, että virhe voidaan havaita, sen vaikutus voidaan rajata ja tapahtuma voidaan käsitellä uudelleen ilman datan rikkoutumista.
➠ Jos viesti tulee kahdesti, järjestelmä kestää sen.
➠ Jos yhteys katkeaa, tapahtuma ei katoa.
➠ Jos tietomalli muuttuu, muunnos on määritelty.
➠ Jos järjestelmät ovat hetken eri tilassa, ero voidaan mitata.
➠ Ja kun migraatio lopulta päättyy, tiedetään varmasti, milloin vanha järjestelmä voidaan ottaa pois käytöstä.
➠ Se on paljon olennaisempaa kuin se, kuinka hienolta itse migraatioarkkitehtuuri näyttää.

Lopuksi

Pilvimigraation datan synkronointi on ennen kaikkea jatkuvan muutoksen hallintaa.

Alkuperäinen datasiirto on vain yksi vaihe. Sen jälkeen järjestelmien pitää selvitä päivityksistä, virheistä, katkoista, järjestysongelmista ja mahdollisesti muuttuvasta tietomallista.

Jos nämä asiat suunnitellaan vasta migraation loppuvaiheessa, vaihtoehdot ovat usein jo vähissä.

Parempi hetki on silloin, kun päätetään, miten vanha ja uusi ympäristö toimivat rinnakkain.

Silloin voidaan vielä päättää, kumpi järjestelmä kirjoittaa, miten muutokset havaitaan, kuinka niitä voidaan palauttaa ja miten tiedetään, että data on lopulta sama.

Se tekee migraatiosta paljon rauhallisemman myös tuotantopäivänä.