Skip to main content

29 Tekniikkaa

29Tekniikkaa
29Tekniikka logo
29Tekniikkaa

Recent Post

Google Cloud -migraatio: cutover-ongelmat ja niiden ratkaiseminen

Pilvimigraatio voi näyttää projektin alussa varsin yksinkertaiselta. Sovellus siirretään Google Cloudiin, data kopioidaan, liikenne ohjataan uuteen ympäristöön ja vanha palvelin voidaan lopulta sulkea.
Käytännössä vaikein hetki ei usein ole datan ensimmäinen siirto. Se on cutover, eli vaihe, jossa tuotantoliikenne siirtyy vanhasta ympäristöstä Google Cloudiin.
Siinä kohtaa huomataan nopeasti, ovatko yhteydet todella kunnossa, löytyvätkö kaikki riippuvuudet, toimivatko tunnistautuminen ja salaisuudet, ja näkevätkö käyttäjät saman datan kuin ennenkin.
Hyvin valmisteltu migraatio voi silti kompastua pieneen asiaan. DNS-muutos ei leviä odotetusti. Sovellus saa yhteyden tietokantaan vain osasta instansseja. Yksi taustaprosessi käyttää vielä vanhaa endpointia. Sertifikaatti on voimassa väärässä ympäristössä. Tai vanhan järjestelmän kellonaika poikkeaa uudesta sen verran, että tokenin validointi alkaa epäonnistua.
Siksi cutoveria ei kannata ajatella pelkkänä liikenteen siirtona. Se on tuotantoympäristön vaihtaminen, jossa usean asian pitää onnistua samanaikaisesti.

Cutover ei ole sama asia kuin datan migraatio

➢ Näillä kahdella asialla on käytännössä suuri ero.
➢ Datan migraatio tarkoittaa esimerkiksi tietokannan, tiedostojen tai muun pysyvän tiedon siirtämistä uuteen ympäristöön. Cutoverissa taas päätetään, mikä ympäristö on tästä hetkestä lähtien tuotannon lähde.
➢ Jos vanha järjestelmä käsittelee edelleen tilauksia samalla kun uusi järjestelmä vastaanottaa uusia tilauksia, syntyy helposti kaksi eri totuutta.
➢ Tilanne voi näyttää tältä:
  • vanhassa järjestelmässä on 12 450 tilausta
  • data kopioidaan Google Cloudiin
  • kopioinnin aikana vanhaan järjestelmään tulee vielä 37 uutta tilausta
  • liikenne vaihdetaan uuteen ympäristöön
  • uudet tilaukset puuttuvat uudesta tietokannasta
➢ Teknisesti migraatio on voinut onnistua lähes täydellisesti. Silti tuotannossa on ongelma.
➢ Tämän vuoksi ennen cutoveria pitää päättää, miten viimeiset muutokset siirretään. Käytetäänkö jatkuvaa replikointia? Tehdäänkö lopullinen delta-siirto? Pysäytetäänkö vanha sovellus hetkeksi? Vai voidaanko järjestelmät pitää hetken rinnakkain?
➢ Ratkaisu riippuu sovelluksesta ja siitä, kuinka paljon käyttökatkoa liiketoiminta kestää.

Suurin riski on usein riippuvuuksissa

Sovellus ei elä yksin.
Tuotantopalvelu voi käyttää tietokantaa, ulkoisia API-rajapintoja, viestijonoja, identiteettipalvelua, objektitallennusta, DNS:ää, sertifikaatteja, lokipalveluita ja useita sisäisiä palveluita.
Kun sovellus siirretään Google Cloudiin, kaikki nämä yhteydet pitää käydä läpi.
Yksi käytännön ongelma on se, että kehitysympäristössä kaikki näyttää toimivan. Cutoverin jälkeen jokin tietty toiminto kuitenkin epäonnistuu.
Esimerkiksi sovellus käynnistyy normaalisti ja käyttäjät voivat kirjautua sisään. Tuotteen luonti onnistuu. Hakutoiminto toimii.
Mutta raportin muodostaminen epäonnistuu.
Syy voi olla hyvin pieni: raportointipalvelun osoite on määritelty vanhassa ympäristössä ympäristömuuttujalla, jota uudessa ympäristössä ei ole.
Tällaista ongelmaa ei välttämättä löydetä tavallisella smoke-testillä.
Siksi cutover-testauksen pitäisi perustua oikeisiin liiketoimintatoimintoihin eikä vain siihen, että palvelu palauttaa HTTP 200 -vastauksen.

DNS-muutokset aiheuttavat helposti väärän kuvan

☑️ DNS on yksi niistä asioista, joiden toiminta tuntuu yksinkertaiselta siihen asti, kun tuotanto pitäisi oikeasti vaihtaa.
☑️ Kun verkkotunnuksen osoite muutetaan, kaikki käyttäjät eivät välttämättä siirry uuteen ympäristöön samalla hetkellä. Välimuistit ja resolverit vaikuttavat siihen, kuinka nopeasti muutos näkyy eri verkoissa.
☑️ Tästä seuraa erikoinen tilanne.
☑️ Osa käyttäjistä käyttää jo Google Cloudissa olevaa palvelua. Osa päätyy edelleen vanhaan ympäristöön.
☑️ Jos molemmat ympäristöt ovat aktiivisia, niiden täytyy olla riittävän hyvin yhteensopivia tämän siirtymäajan kanssa.
☑️ Erityisen hankala tilanne syntyy, jos käyttäjän tekemä muutos tallentuu vanhaan ympäristöön, mutta seuraava pyyntö menee uuteen.
☑️ Siksi DNS:n TTL-arvoa voidaan pienentää ennen suunniteltua muutosta, mutta TTL ei yksin ratkaise cutoveria. Ennen liikenteen vaihtamista pitää tietää, mitä tapahtuu niille pyynnöille, jotka vielä päätyvät vanhaan ympäristöön.

Tietokannan viimeinen synkronointi ratkaisee paljon

➢ Monissa migraatioissa juuri tietokanta on kohta, jossa cutover muuttuu teoriasta käytännöksi.
➢ Pelkkä täydellinen kopio ei riitä, jos lähdejärjestelmässä syntyy jatkuvasti uusia muutoksia.
➢ Jos tietokanta on suuri, täydellinen siirto voidaan tehdä etukäteen ja myöhemmin siirtää vain muuttunut data. Menetelmä voi perustua esimerkiksi replikointiin, muutoslokeihin tai sovelluksen omiin tapahtumatietoihin.
➢ Oleellista on, että viimeiselle synkronoinnille on selkeä tarkistus.
➢ Ei riitä, että työkalu ilmoittaa:
Replication completed.
➢ Pitää myös tarkistaa, että uuden ympäristön data vastaa sitä tilannetta, jossa vanha ympäristö otetaan pois tuotannosta.
➢ Tarkistuksia voivat olla esimerkiksi:
  • tietueiden määrät
  • viimeisimmät tapahtumat
  • kriittisten taulujen sisältö
  • tilaus- ja maksutapahtumat
  • käyttäjien tunnisteet
  • aikaleimat
  • viite-eheys
  • sovelluksen tekemät kirjoitukset
➢ Kaikkea dataa ei tarvitse verrata rivi riviltä. Sen sijaan kannattaa tunnistaa liiketoiminnan kannalta tärkeät tiedot ja rakentaa niille täsmälliset tarkistukset.

IAM-oikeudet näkyvät usein vasta tuotannossa

Google Cloud -ympäristössä käyttöoikeudet perustuvat muun muassa IAM-rooleihin ja palvelutileihin. Tämä on hyvä asia, mutta migraatiossa se tarkoittaa myös yhtä uutta tarkistettavaa kokonaisuutta.
Vanha ympäristö on voinut käyttää tunnuksia tai palveluita, joiden käyttöoikeudet ovat muodostuneet vuosien aikana. Uudessa ympäristössä samaa pääsyä ei välttämättä ole tarkoituksella annettu.
Sovellus toimii muuten hyvin, mutta tietty taustatoiminto palauttaa esimerkiksi permission denied -virheen.
Tässä kohtaa ei kannata antaa palvelulle nopeasti liian laajoja oikeuksia vain siksi, että tuotanto saadaan toimimaan.
Parempi tapa on selvittää:
  • mikä palvelu tekee pyynnön
  • millä identiteetillä pyyntö tehdään
  • mihin Google Cloud -resurssiin pääsyä tarvitaan
  • mikä IAM-oikeus puuttuu
  • tarvitaanko oikeutta jatkuvasti vai vain migraation aikana
Näin cutoverissa syntyvä käyttöoikeusongelma ei johda uuteen tietoturvariskiin.

Secretit ja ympäristömuuttujat unohtuvat yllättävän helposti

☑️ Sovelluksen asetuksia on usein enemmän kuin dokumentaatio kertoo.
☑️ Tietokannan osoite on helppo muistaa. Sen sijaan jokin vähemmän käytetty API-avain, webhookin salaisuus tai taustajärjestelmän tunnus voi jäädä siirtämättä.
☑️ Siksi asetuksia ei kannata tarkistaa vain tiedostojen perusteella.
☑️ Parempi lähtökohta on käydä läpi sovelluksen todelliset riippuvuudet:
  • tietokantayhteydet
  • ulkoiset API-avaimet
  • OAuth- ja muut tunnukset
  • webhook-salaisuudet
  • palvelutilit
  • sertifikaatit
  • salatut asetukset
  • bucket- ja objektitallennuksen nimet
  • viestijonojen osoitteet
☑️ Google Cloudissa salaisuuksien hallintaan voidaan käyttää esimerkiksi Secret Manageria. Olennaista ei kuitenkaan ole pelkkä palvelun käyttöönotto, vaan se, että sovellus hakee oikean salaisuuden oikeassa ympäristössä.

Verkko toimii paperilla, mutta yhteys ei toimi käytännössä

➢ Google Cloudiin siirtyessä verkkoarkkitehtuuri voi muuttua merkittävästi.
➢ Sovellus voi esimerkiksi sijaita yhdessä VPC-verkossa ja tietokanta toisessa ympäristössä. Yhteyksiä voidaan joutua rakentamaan VPN:n, Cloud Interconnectin, palomuurisääntöjen, reitityksen tai muiden verkkoratkaisujen avulla.
➢ Tässä syntyy helposti tilanne, jossa:
palvelin on käynnissä, mutta palvelu ei pääse tarvittavaan resurssiin.
➢ Pelkkä ping-testi ei tällaisessa tilanteessa kerro kovin paljon. Olennaisempaa on testata juuri se yhteys, jota sovellus tarvitsee.
➢ Jos sovellus käyttää tietokantaa TCP-yhteydellä tietyssä portissa, testataan se yhteys. Jos palvelu tarvitsee DNS-nimen kautta ulkoisen API:n, testataan nimiresoluutio ja HTTPS-yhteys. Jos yhteys kulkee yksityisen verkon kautta, tarkistetaan myös reititys.
➢ Verkko-ongelmaa ei kannata yrittää ratkaista arvaamalla. Reitti, DNS, firewall ja kohde pitää erottaa toisistaan.

Sertifikaatti voi olla kunnossa – mutta väärässä paikassa

HTTPS toimii vanhassa ympäristössä, joten sertifikaattien pitäisi olla kunnossa.
Sitten liikenne vaihdetaan Google Cloudiin ja osa pyynnöistä alkaa epäonnistua.
Syynä voi olla esimerkiksi väärä sertifikaatti, puuttuva intermediate certificate tai se, että uusi endpoint ei vastaa samalla tavalla kuin vanha.
Myös automaattinen sertifikaattien uusinta kannattaa testata ennen cutoveria. Tuotantoon ei ole järkevää siirtyä tilanteessa, jossa sertifikaatin elinkaarta ei tunneta.

Kaikki tuotanto-ongelmat eivät näy heti

☑️ Yksi vaarallisimmista ajatuksista cutoverin jälkeen on:
“Kaikki näyttää toimivan, joten migraatio onnistui.”
☑️ Ensimmäinen tunti voi näyttää hyvältä, vaikka ongelma syntyy vasta myöhemmin.
☑️ Taustalla voi olla esimerkiksi:
  • ajastettu työ
  • yön yli ajettava raportti
  • kuukausittainen laskutus
  • suurempi tiedostosiirto
  • hitaasti kasvava muistinkäyttö
  • viestijonon kasaantuminen
  • tietokannan kuormituksen nousu
☑️ Siksi seuranta pitää suunnitella myös cutoverin jälkeiselle ajalle.
☑️ Google Cloudissa käytettävät Cloud Monitoring ja Cloud Logging ovat tässä hyödyllisiä, mutta yhtä tärkeää on tietää, mitä pitää seurata.
☑️ Pelkkä palvelimen CPU ei riitä.
☑️ Seurannassa voivat olla esimerkiksi:
  • HTTP-virheiden määrä
  • vasteajat
  • liikennemäärä
  • tietokantayhteyksien määrä
  • viestijonojen pituus
  • sovelluksen poikkeukset
  • resurssien käyttö
  • ulkoisten API-kutsujen epäonnistumiset
☑️ Liiketoiminnan mittarit ovat yhtä tärkeitä. Jos esimerkiksi tilausten määrä putoaa normaalista, kyseessä voi olla tekninen ongelma, vaikka kaikki infrastruktuurimittarit näyttäisivät vihreää.

Rollback pitää päättää ennen cutoveria

➢ Rollbackista puhutaan usein projektin lopussa, vaikka sen pitäisi olla yksi ensimmäisistä päätöksistä.
➢ Mitä tehdään, jos uusi ympäristö toimii teknisesti, mutta kriittinen liiketoimintatoiminto ei toimi?
➢ Voidaanko liikenne palauttaa vanhaan ympäristöön?
➢ Jos voidaan, mitä tapahtuu sen jälkeen syntyneille tiedoille?
➢ Tämä on erityisen tärkeää silloin, kun uusi ympäristö on jo alkanut vastaanottaa kirjoituksia.
➢ Rollback ei siis aina tarkoita yksinkertaisesti:
“Vaihdetaan DNS takaisin.”
➢ Jos käyttäjä on tehnyt muutoksen uudessa ympäristössä, muutos pitää saada myös vanhan ympäristön saataville, jos liikenne palautetaan sinne.
➢ Siksi rollback-suunnitelmassa pitää huomioida myös data.
  • millä ehdolla rollback tehdään
  • kuka tekee päätöksen
  • miten liikenne palautetaan
  • miten uusi data käsitellään
  • miten käyttäjille ilmoitetaan tilanteesta
  • miten uusi yritys tehdään myöhemmin
Hyvä suunnitelma kertoo konkreettisesti:

Cutover kannattaa tehdä mahdollisimman tylsästi

➢ Tuotannon siirrossa ei oikeastaan tavoitella näyttävää teknistä suoritusta.
➢ Parasta on, että mitään yllättävää ei tapahdu.
➢ Ennen vaihtoa pitäisi olla selvillä ainakin:
  • uusi ympäristö on testattu
  • data on synkronoitu
  • riippuvuudet on tunnistettu
  • DNS-muutoksen vaikutukset tunnetaan
  • käyttöoikeudet on tarkistettu
  • salaisuudet ja sertifikaatit ovat kunnossa
  • seuranta toimii
  • rollback on testattu tai ainakin käytännössä läpikäyty
  • vastuuhenkilöt tietävät oman tehtävänsä
Ennen cutoveria
  • liikenne vaihdetaan sovitulla tavalla
  • kriittiset toiminnot testataan
  • virhelokeja seurataan
  • tietokannan tila tarkistetaan
  • liikennemäärää verrataan normaaliin
  • vanhaa ympäristöä ei suljeta liian nopeasti
Cutoverin aikana
  • seurataan virheitä ja vasteaikoja
  • tarkistetaan taustatyöt
  • varmistetaan datan syntyminen
  • seurataan ulkoisia integraatioita
  • pidetään vanha ympäristö tarvittaessa palautusvalmiina
Cutoverin jälkeen
➢ Tämä kuulostaa ehkä varovaiselta. Tuotantojärjestelmän kanssa se on yleensä hyvä asia.

Yksi testi ei riitä

Cutoverin testaamisessa kannattaa erottaa kolme asiaa toisistaan.
Ensimmäinen on tekninen toimivuus.
Palvelu käynnistyy. Tietokantaan saadaan yhteys. DNS toimii. TLS-yhteys muodostuu.
Toinen on toiminnallinen toimivuus.
Käyttäjä pystyy kirjautumaan, tekemään tilauksen, maksamaan, lataamaan tiedoston tai käyttämään muuta järjestelmän keskeistä toimintoa.
Kolmas on liiketoiminnan toimivuus.
Tilaus päätyy oikeaan järjestelmään. Maksutapahtuma kirjautuu. Raportti muodostuu. Viesti lähtee oikealle vastaanottajalle.
Vasta näiden kolmen jälkeen voidaan sanoa, että cutover on oikeasti onnistunut.

Mikä tekee Google Cloud -cutoverista vaikean?

☑️ Vaikeus ei yleensä ole yhdessä Google Cloud -palvelussa.
☑️ Ongelma syntyy siitä, että tuotantoympäristö muodostuu useista toisiinsa liittyvistä osista. Kun yksi osa vaihtuu, myös sen ympärillä olevat oletukset voivat muuttua.
☑️ Vanha ympäristö on saattanut sisältää vuosien aikana syntyneitä riippuvuuksia, joita kukaan ei ole enää tullut ajatelleeksi. Migraatio pakottaa tuomaan ne näkyviin.
☑️ Se on yksi syy siihen, miksi migraatio kannattaa nähdä myös teknisenä inventaariona.
☑️ Kun järjestelmä siirretään uuteen ympäristöön, voidaan samalla löytää:
  • vanhoja integraatioita
  • käyttämättömiä tunnuksia
  • dokumentoimattomia palveluita
  • tarpeettomia riippuvuuksia
  • epäselviä ympäristöasetuksia
  • liian laajoja käyttöoikeuksia
  • prosesseja, joita kukaan ei enää oikein tunne
☑️ Kaikkea ei tarvitse korjata juuri migraation aikana. Joskus on järkevämpää siirtää toimiva kokonaisuus ensin ja tehdä suuremmat muutokset myöhemmin.

Lopuksi

➢ Google Cloud -migraation onnistuminen ei ratkea sillä, että uusi ympäristö saadaan rakennettua.
➢ Ratkaiseva hetki on silloin, kun oikea liikenne ja oikeat käyttäjät siirtyvät uuteen ympäristöön.
➢ Silloin DNS:n, verkon, käyttöoikeuksien, datan, sertifikaattien, integraatioiden ja sovelluksen pitää toimia yhdessä. Yksittäinen palvelu voi olla täysin kunnossa ja koko järjestelmä silti rikki.
➢ Hyvä cutover-suunnitelma ei yritä ennustaa jokaista mahdollista virhettä. Se tekee tärkeimmät riippuvuudet näkyviksi, määrittelee testit etukäteen ja kertoo, mitä tehdään, jos jokin menee pieleen.
➢ Erityisesti tuotantoympäristössä tämä on tärkeä ero. Migraatiota ei mitata sillä, kuinka nopeasti palvelimet saadaan käyntiin. Se mitataan sillä, pystyykö liiketoiminta jatkamaan normaalisti myös ympäristön vaihtumisen jälkeen.
➢ Jos cutoverin jälkeen ensimmäinen kysymys on “toimiiko kaikki?”, kysymys on liian laaja.
➢ Parempi kysymys on:
Mitkä tuotannon toiminnot pitää todistaa toimiviksi ennen kuin vanhasta ympäristöstä voidaan luopua?
➢ Siitä kannattaa rakentaa koko cutover-suunnitelma.