all

Case study

Migracija iz clouda na on-prem: vise kontrole, bolji TTFB, bez IO zastoja

Slučaj upotrebe

Pregled migracije infrastrukture

Cloud nije uvek najbolje dugorocno resenje za stabilan sistem srednjeg opterecenja.

U ovom slucaju cilj nije bio auto-skaliranje, vise-regionalni domet ili brzo horizontalno sirenje. Radno opterecenje je bilo stabilno, predvidivo i vec dobro poznato. Vaznije je bilo upravljanje resursima, performanse skladista i operativna predvidivost.

Migracija je premestila produkcioni Laravel monolit i pratece servise sa nekoliko cloud VPS instanci na namenski on-prem server. Rezultat je bio:

  • bez downtime-a tokom migracije
  • oko 30% bolji TTFB
  • vreme generisanja strane smanjeno sa ~800 ms na ~400 ms
  • uklanjanje povremenih, ali bolnih IO zastoja
  • potpuna kontrola nad racunarskim resursima, skladistem i virtualizacijom
  • oko ista ukupna godisnja cena

Ovaj clanak ne opisuje univerzalno pravilo. Opisuje slucaj upotrebe u kome je prelazak sa cloud VPS-a na namenski server bio racionalnija opcija.

Pocetno stanje

Izvorno okruzenje je bilo izgradjeno na vise cloud VDS/VPS instanci jednog provajdera u jednom regionu.

Aplikacioni stack je ukljucivao:

  • Laravel monolit
  • Elasticsearch 7.16.3
  • MySQL 8.0 kao primarnu bazu
  • PostgreSQL 15 prisutan kao deo tekuce tranzicije
  • Memcached kao primarni cache sloj
  • Redis prisutan, ali jos ne u aktivnoj upotrebi

Radno opterecenje je bilo srednje, sa otprilike 800 konkurentnih konekcija koje su stalno bile prisutne na web sloju. Pošto je Memcached imao hit rate iznad 95%, vecina zahteva nikada nije dospela do teske putanje. To znaci da bi sirova konkurentnost sama po sebi preuvelicala pritisak na backend. U praksi, sistem je imao stabilan saobracajni profil sa relativno malim procentom skupih zahteva koji su stizali do baze i search sloja.

Ovo je upravo tip profila kod koga je predvidivost infrastrukture vaznija od elasticnosti.

Zasto se migrirati sa cloud VPS-a

Okidac nisu bili samo troskovi.

Glavni problemi su bili:

  • zastareli operativni sistemi na postojecim VPS cvorovima
  • retki, ali stvarni CPU steal problemi
  • povremena ozbiljna IO konkurencija van kontrole aplikacije

Najgori deo je bilo ponasanje skladišnog sloja pod opterecenjem od suseda. Tokom kratkih perioda povecanog disk IO-a, host provajdera je mogao efektivno da blokira VPS. Kada bi se to desilo bazi podataka, instanca je mogla da postane delimicno ili potpuno neodgovarajuca. Jedini praktican put za oporavak cesto je bio restart.

Ovo se nije desavalo svake nedelje. Dešavalo se otprilike jednom u dva ili tri meseca. Ali svaki incident je bio bolan i skup na pogresan nacin:

  • nestabilnost na strani baze
  • 7 do 15 minuta downtime-a
  • bez stvarne mogucnosti da se uzrok otkloni iznutra, iz VPS-a
  • bez garancije da se nece ponoviti

To je vazna tacka. Problem nije bio prosecan performans. Problem je bio gubitak kontrole nad ponasanjem u najgorem slucaju.

Za stabilan sistem koji generise prihod, to je vaznije od teorijske pogodnosti.

Zasto je on-prem ovde imao smisla

Ova migracija je bila dobar izbor za on-prem zato sto:

  • radno opterecenje je bilo stabilno
  • autoskaliranje nije bilo potrebno
  • sistem je vec imao poznat stabilan resursni otisak
  • namensko NVMe skladiste bi u potpunosti uklonilo problem deljenja IO-a
  • ukupni trosak pravilno dimenzionisanog namenskog servera bio je otprilike isti kao kombinovani VPS otisak

Nova platforma je bila namenski server sa:

  • Xeon Gold CPU
  • 128 GB RAM
  • 2 NVMe diska u RAID1
  • redundantno napajanje u data centru
  • duplim mreznim konekcijama
  • S3 backup-om preko Restic-a

Radna opterecenja su postavljena na libvirt/KVM, uz upravljanje kroz Ansible role.

Ovo nije “zamena za cloud” u opstем smislu. Ovo je pomeranje ka:

  • jacim garancijama za skladiste
  • boljoj kontroli na nivou hosta
  • jednostavnijem planiranju resursa
  • manjoj izlozenosti noisy-neighbor ponasanju

Dizajn migracije

  flowchart LR
    subgraph SRC["Izvorno okruzenje"]
        WEB["Web / podaci aplikacije"]
        DB["PostgreSQL 15"]
        MDB["MySQL 8.0"]
        ES["Elasticsearch"]
    end

    subgraph PHASE1["Faza 1: sinhronizacija fajlova"]
        RSYNC1["rsync 1. prolaz"]
    end

    subgraph PHASE2["Faza 2: migracija baza"]
        MDUMP["mysqldump"]
        DUMP[pgdump_all]
        MRESTORE["mysql restore"]
        RESTORE["psql"]
    end

    subgraph PHASE3["Faza 3: migracija pretrage"]
        SNAP["snapshot"]
        SNAPREST["snapshot restore"]
    end

    subgraph DST["Ciljno okruzenje"]
        WEBNEW["Podaci sajta, kod, staticki asset-i"]
        MDBNEW["MySQL 8.0"]
        DBNEW["PostgreSQL 15"]
        ESNEW["Elasticsearch"]
    end

    subgraph PHASE4["Faza 4: ponovna sinhronizacija fajlova"]
        RSYNC2["rsync 2. prolaz"]
    end

    WEB --> RSYNC1 --> WEBNEW
    DB --> DUMP --> RESTORE --> DBNEW
    MDB --> MDUMP --> MRESTORE --> MDBNEW
    ES --> SNAP --> SNAPREST --> ESNEW
    RSYNC2 --> WEBNEW
    
    CUT{"Prekid saobracaja"}
    
    PHASE1 --> PHASE2 --> CUT --> PHASE3 
    CUT --> PHASE4

Migracija je bila osmisljena za nulti downtime.

Prenos podataka je podeljen po tipu radnog opterecenja:

  • podaci sajta, kod i staticki asset-i preko rsync u dva prolaza
  • MySQL i PostgreSQL preko mysqldump / pg_dump i restore-a
  • Elasticsearch preko snapshot-a i restore-a

Ovo je konzervativan pristup, ali je za ovaj slucaj bio odgovarajuci. Cilj nije bila otmena replikaciona topologija. Cilj je bio kontrolisan prenos stanja sa predvidivim prebacivanjem.

Zasto dva prolaza rsync-a

Za fajlove aplikacije i staticki sadrzaj, dvoprolazni rsync smanjuje delta pri finalnoj sinhronizaciji:

  1. prvi prolaz unapred prenosi veci deo podataka
  2. drugi prolaz hvata poslednje izmene blizu prebacivanja

To cini finalni prelazak manjim i predvidivijim.

Zasto dump/restore za baze

Faze migracije i strategija prenosa podataka

Za ovu migraciju, dump i restore su obezbedili jednostavan i proverljiv put:

  • jasno definisane granice prenosa
  • jednostavna validacija
  • bez dodatne replikacione kompleksnosti tokom prelaska

Ovo dobro radi kada je plan migracije kontrolisan i kada je operativni prozor pazljivo pripremljen.

Zasto snapshot-i za Elasticsearch

Snapshot i restore je prirodan put za migraciju Elasticsearch-a kada su konzistentnost, mogucnost oporavka i ponovljivost vazniji od ad hoc kopiranja.

To se takodje dobro uklapa u siri cilj prebacivanja sistema na fazan i kontrolisan nacin.

Nova ciljna arhitektura

Ciljno okruzenje je konsolidovalo sistem na namenski host sa virtualizacijom.

To je donelo nekoliko prakticnih prednosti:

  • cisto odvajanje radnih opterecenja kroz KVM/libvirt
  • infrastruktura upravljana preko Ansible role
  • bez deljenja skladista sa nepoznatim susedima
  • jednostavnije razumevanje performansi
  • lakse buduce upravljanje zivotnim ciklusom

Takodje je poboljsalo granice vlasnistva. Umesto iznajmljivanja skupa apstraktnih VPS delova sa neprozirnim ponasanjem hosta, infrastruktura je postala direktno razumljiva na nivou resursa:

  • CPU je poznat
  • RAM je poznat
  • skladiste je poznato
  • granice otkaza su jasnije
  • ponasanje backup-a je jasnije

Ovakva predvidivost se cesto potcenjuje sve dok se ne dogodi prvi infrastrukturni incident koji ne moze da se debaguje iznutra, iz VPS-a.

Rezultati

Najvidljivije poboljsanje je bila stabilnost vezana za skladiste.

Na namenskom serveru sa NVMe podrskom, IO opterecenje je sada za ovo radno opterecenje prakticno zanemarljivo. Jos vaznije, nema deljenih suseda koji se takmice za isti fizicki disk podsistem. To je uklonilo tacno onu vrstu incidenta koja je ranije izazivala bolan downtime.

Izmerena poboljsanja su ukljucivala:

  • ~30% nizi TTFB
  • vreme generisanja strane smanjeno sa ~800 ms na ~400 ms
  • efektivno uklanjanje rizika od IO blokiranja na strani provajdera
  • potpunu kontrolu resursa na hostu

Ovo je korisna podsetnik: dobitak u performansama ne dolazi uvek iz podesavanja aplikacionog koda. Nekada dolazi iz uklanjanja nepredvidivosti na nivou infrastrukture.

Zasto je ovo finansijski uspelo

Migraciji je dodatno pomoglo povoljno formiranje cene servera. Sezonska ponuda za godisnje placanje omogucila je da se dobije otprilike 1.5x vise sirove server kapacitete za otprilike istu cenu kao prethodni kombinovani VPS setup.

To je vazno zato sto se cloud-to-on-prem rasprave cesto previse pojednostavljeno postavljaju:

  • cloud = fleksibilan
  • on-prem = jeftiniji ali krut

U stvarnosti, pravo poredjenje nije ideologija. To je oblik radnog opterecenja.

Za stabilan sistem sa:

  • predvidivim opterecenjem
  • bez zahteva za autoskaliranjem
  • jakom cache hit stopom
  • latencijom osetljivom na infrastrukturu
  • bolnom izlozenoscu shared-tenant IO ponasanju

namenski server moze biti bolje inzenjersko i poslovno resenje.

Kada je cloud i dalje bolji izbor

Ovo nije anti-cloud argument.

Cloud i dalje ima vise smisla kada vam treba:

  • brzo skaliranje
  • burst-heavy radna opterecenja
  • kratkotrajna okruzenja
  • ceste promene topologije
  • mnogo upravljanih servisa usko integrisanih u arhitekturu

Nijedno od toga nije bio primarni zahtev u ovom slucaju.

Radno opterecenje je bilo stabilno. Potrebe za kapacitetom su bile poznate. Glavni cilj je bio da se ukloni skrivena nestabilnost i povrati kontrola.

Sta se promenilo operativno

Najveci dugorocni dobitak nije bio samo nizi TTFB.

Bio je ovo:

infrastruktura je sada razumljiva i kontrolisana od kraja do kraja.

To znaci:

  • manje nepoznanica pod opterecenjem
  • vece poverenje u ponasanje skladista
  • manje zavisnosti od kvaliteta host scheduling-a na strani provajdera
  • predvidivije planiranje buducih promena

To je cesto prava vrednost migracije. Ne samo premestanje. Ne samo hardver. Ne samo cena.

Kontrola.

Prakticne lekcije

Nekoliko lekcija iz ove migracije je siroko primenljivo.

1. Retki incidenti i dalje vaze

Problem koji se pojavljuje jednom u dva ili tri meseca i dalje moze opravdati migraciju ako izaziva downtime u produkciji i ne moze da se otkloni sa vase strane.

2. Stabilna radna opterecenja ne profitiraju automatski od clouda

Ako je potraznja predvidiva i kapacitet je lako modelovati, fleksibilni premijum mozda nije vredan placanja.

3. Deljeni IO je stvaran rizik

Prosecni benchmark-ovi mogu sakriti ponasanje u najgorem slucaju. Deljena konkurencija na skladistu je jedan od najtezih problema za razumevanje iznutra, iz VPS-a.

4. Jednostavniji putevi migracije su cesto bolji

rsync, dump/restore i kretanje zasnovano na snapshot-ovima mozda izgledaju manje glamurozno od slozenijih replikacionih strategija, ali su cesto laksi za proveru i oporavak.

5. Kontrola je deo performansi

Niza latencija i bolji TTFB nisu dosli samo od brzeg NVMe skladista, vec i od uklanjanja neizvesnosti infrastrukture.

Vreme isporuke

Migracija je ukupno trajala malo vise od sedam radnih dana.

Raspored

  • 6 radnih dana je potroseno na pripremu i konfiguraciju ciljnog servera:

    • podesavanje hosta
    • virtualizacija
    • skladiste
    • integracija backup-a
    • osnovna konfiguracija sistema
    • provere spremnosti za migraciju

  • Preostalo vreme je iskorisceno za dva kontrolisana prebacivanja:

    • jedna grupa sajtova je migrirana tokom prve noci
    • druga grupa je migrirana tokom druge noci

Prebacivanje je namerno podeljeno u dve servisne grupe kako bi se smanjio rizik i izbeglo premestanje svega u jednom koraku.

To je pojednostavilo planiranje rollback-a i smanjilo domet bilo kog neocekivanog problema.

Isporučeni rezultati

  • Pregled postojećeg stanja infrastrukture
  • Plan migracije sa podelom servisa i pristupom smanjenja rizika
  • Priprema ciljnog namenskog servera
  • Osnovno podesavanje virtualizacije sa libvirt / KVM
  • Konfiguracija hosta upravljana preko Ansible-a
  • Podesavanje skladista na RAID1 NVMe
  • Integracija backup-a sa Restic i S3
  • Prenos koda, statickih asset-a i podataka sajta
  • Migracija MySQL i PostgreSQL preko dump-a i restore-a
  • Migracija Elasticsearch-a preko snapshot-a i restore-a
  • Kontrolisano prebacivanje u dve odvojene talasne faze
  • Post-migraciona validacija i stabilizacija

Zavrsna poruka

Ova migracija je uspela zato sto je uskladila infrastrukturu sa realnoscu radnog opterecenja.

Prelazak sa vise cloud VPS instanci na namenski on-prem server doneo je:

  • bolju latenciju
  • brze generisanje strane
  • uklanjanje IO-zastoja
  • migraciju bez downtime-a
  • potpunu kontrolu nad resursima hosta
  • slican ukupni trosak

To je kljucna tacka.

Najbolja migracija nije “ka cloudu” ili “iz clouda”.
Najbolja migracija je ona koja radno opterecenje smesta u okruzenje koje mu zaista odgovara.

Povezane usluge

FAQ

Zasto prelaziti sa clouda na on-prem ako je cena slicna?

Zato sto cena nije bila jedini problem. Vazniji problem je bilo povremeno ponasanje IO-a na strani provajdera koje je izazivalo nestabilnost u produkciji. Slicna cena uz bolju kontrolu i bolje performanse bila je jaca opcija.

Da li je ovo bio sistem sa velikim opterecenjem?

Tacnije je bilo reci da je to bio srednje opterecen sistem sa stabilnim, kontinuiranim saobracajem. Na web sloju je bilo otprilike 800 konkurentnih konekcija, ali je efikasnost cache-a bila visoka, sa Memcached hit stopom iznad 95%.

Zasto to nije reseno nadogradnjom VPS instanci?

To ne bi uklonilo rizik od suseda niti konkurenciju na strani hosta provajdera. Mozda bi poboljsalo prosecne performanse, ali ne i kontrolu nad ponasanjem IO-a u najgorem slucaju.

Da li je downtime bio potreban?

Ne. Migracija je zavrsena bez downtime-a, uz faznu sinhronizaciju i kontrolisane metode prenosa podataka.

Kada je cloud i dalje bolja opcija?

Cloud je obicno bolji izbor kada su radna opterecenja bursty, kada treba autoskaliranje ili kada se snažno koristi od upravljanih platformskih servisa.

Zatrazi ponudu Back to services