Älä maksa joutilaista GPU:ista. Varaa laskentatehoa juuri ajoissa, käsittele työkuorma ja pura se – muuttaen pääomakustannukset työkohtaiseksi käyttökustannukseksi.

Työkuormasi on purskeista – videokoodaustyöt, jotka piikkaavat sisällön lataamisen yhteydessä, ML-koulutusajot, jotka tarvitsevat 8 GPU:ta 4 tunnin ajan ja sitten eivät mitään, yritystapahtumien käynnistämät eräpäätelmätyöt tai renderöintiputket, jotka ajetaan yön yli. Olet joko yliresurssoitu (maksat joutilaista resursseista 80 % ajasta) tai aliresurssoitu (työt jonottavat tunteja ruuhka-aikoina). Tarvitset arkkitehtuurin, joka varaa täsmälleen tarvitsemasi laskentatehon, kun tarvitset sitä, ja vapauttaa sen työn valmistuttua – ilman kylmäkäynnistysrangaistusta, joka tekee "skaalaamisesta nollaan" epäkäytännöllistä GPU-työkuormille.
Explore more design patterns and system architectures
Arkkitehtehtemme voivat auttaa suunnittelemaan ja rakentamaan järjestelmiä käyttäen tätä mallia omiin vaatimuksiin.
Ota yhteyttäPäälle/pois-skaalausarkkitehtuuri hallitsee laskentaresursseja lämpimän/kylmän varannon (warm/cold pooling), työjono-ohjatun resursoinnin ja automatisoidun purkamisen avulla. Lämmin varanto (warm pool) ylläpitää pientä määrää valmiiksi alustettuja instansseja, jotka ovat välittömästi käyttövalmiita. Kylmä varanto (cold pool) varaa lisäkapasiteettia spot/preemptible-instansseista, kun kysyntä ylittää lämpimän varannon. Työn orkestraattori reitittää työt saatavilla oleviin instansseihin, valvoo edistymistä, käsittelee uudelleenyritykset spot-instanssien poiston sattuessa ja laukaisee skaalauksen alaspäin, kun jono tyhjenee. Malli on erityisen kriittinen GPU-työkuormille, joissa kylmäkäynnistys (kontin vetäminen + mallin lataaminen) voi kestää 3–10 minuuttia.
Järjestelmä keskittyy työjonoon (SQS, Redis tai mukautettu), joka puskuroi saapuvia työpyyntöjä. Skaalausohjain valvoo jonon syvyyttä ja varaa instansseja ensin lämpimästä varannosta ja sitten kylmästä varannosta (spot-instanssit). Jokainen työskentelyinstanssi hakee töitä jonosta, suorittaa työkuorman (koodaus, koulutus, päättely), raportoi valmistumisesta ja palaa varantoon tai päättyy. Tarkistuspisteen hallinta (checkpoint manager) käsittelee spot-instanssin poiston tallentamalla välitilan S3:een, jolloin työt voivat jatkua eri instanssissa alusta aloittamatta.
| Kerros | Teknologiat |
|---|---|
| Laskenta | AWS EC2 Spot (G5/P4), GCP Preemptible (A2/L4), RunPod Serverless, Modal |
| Orkestrointi | Kubernetes (Karpenter automaattiseen skaalaukseen), AWS Batch, mukautettu työorkestraattori |
| Työjono | AWS SQS, BullMQ (Redis), Temporal, Celery |
| Tallennustila | S3 (tarkistuspisteet, malliartifaktit), NVMe (mallivälimuisti), EFS (jaettu työtila) |
| Valvonta | CloudWatch/Prometheus (jonon syvyys, instanssin käyttöaste, työn viive), mukautetut kustannuskoontinäytöt |
| Käytä, kun | Vältä, kun |
|---|---|
| Työkuorma on purskeista – huippukysyntä on yli 5x keskimääräiseen kysyntään verrattuna | Liikenne on tasaista ja ennustettavaa – oikein mitoitetut varatut instanssit ovat edullisempia |
| GPU/suuritehoiset laskentatyöt, jotka ovat kalliita joutilaana | Työkuorma on kevyttä CPU-käsittelyä, joka sopii serverless-ratkaisuun (Lambda) |
| Työt voivat sietää 1–5 minuutin kylmäkäynnistyksen kylmän varannon resursoinnissa | Alle sekunnin työ aloitusviive on vaatimus – tarvitset aina päällä olevan infrastruktuurin |
| Kustannusoptimointi on ensisijainen huolenaihe ja spot-hinnoittelu tarjoaa 60–90 % säästöt | Spot-keskeytys aiheuttaisi tietojen menetyksen, jota tarkistuspisteiden tallennus ei voi lieventää |
MW suunnittelee päällä/pois-skaalauksen "kustannus per työ" -näkökulmasta – mallinnamme yhden työyksikön (yhden videon, yhden koulutusajon, yhden eräpäätelmän) käsittelyn kokonaiskustannukset eri skaalausstrategioiden yli ja valitsemme sen, joka minimoi kustannukset vaaditulla viiveen SLA:lla. Toteutuksiimme sisältyy reaaliaikaisia kustannuskoontinäyttöjä, jotka näyttävät työkohtaiset kustannukset, infrastruktuurin käyttöasteen ja spot-säästöt. Olemme rakentaneet päällä/pois-GPU-infrastruktuurin, joka laski videonkäsittelykustannuksia 70 % verrattuna varattuihin instansseihin, sekä ML-koulutusklustereita, jotka varaavat 64 GPU:ta 4 tunnin koulutusajoon ja vapauttavat ne automaattisesti.
Turvallisuus ei ole ominaisuus, jonka lisäät julkaisun jälkeen. Se on arkkitehtuurin ominaisuus – järjestelmä joko suunniteltiin sitä varten tai sitten ei.
MicrocosmWorksin asiakkaat, joilla on eräpainotteisia tai jaksottaisia työkuormia, saavuttavat tyypillisesti 60-80 % pilvikustannussäästöjä otettuaan käyttöön on-off scalingin, koska laskentaresurssit ovat käynnissä vain aktiivisten käsittelyikkunoiden aikana 24/7 sijaan. Suunnittelemme scaling-käytännöt todellisen käytön telemetrian perusteella – esimerkiksi tietojenkäsittelyputki, joka toimii 4 tuntia päivässä, maksaa vain näistä 4 tunnista koko 24 tunnin sijaan. Arkkitehtimme analysoivat työkuormasi malleja discovery phase -vaiheessa arvioidakseen tarkat säästöt ennen minkään toteutuksen aloittamista.
Cold-start-ajat vaihtelevat 2-3 sekunnista kontitettujen sovellusten osalta pre-warmed node pooleissa 5-10 minuuttiin työkuormilla, jotka vaativat erikoistuneita GPU-instansseja tai suurten mallien lataamista, ja MicrocosmWorks käyttää useita tekniikoita tämän viiveen minimoimiseksi. Toteutamme predictive scalingia, joka käynnistää resursseja ennen ennakoitua kysyntää hyödyntäen historiallisia liikennemalleja ja ajoitettuja tapahtumia, ja käytämme container image pre-pullingia ja warm pool reservationeja latenssiherkille työkuormille. Sovelluksille, jotka eivät siedä cold starttia, ylläpidämme minimaalista warm baselinetä, joka skaalautuu ylöspäin aggressiivisesti kysynnän saapuessa.
MicrocosmWorks toteuttaa reactive auto-scalingia aggressiivisilla scale-up-käytännöillä, jotka käynnistyvät jonon syvyyden, CPU utilizationin tai mukautettujen sovellusmittareiden perusteella, yhdistettynä asteittaisempiin scale-down-käytäntöihin, jotka sisältävät cooldown-jaksoja thrashingin välttämiseksi. Konfiguroimme over-provisioning-puskurit scale-up-tapahtumien aikana, jotta järjestelmä ennakoi jatkuvaa kasvua sen sijaan, että se tavoittelisi kysyntää yksi instanssi kerrallaan. Todella ennakoimattomille piikeille, kuten flash sales -tapahtumille tai viral events -tapahtumille, ennalta varaamme kapasiteettia käyttämällä event-driven triggereitä markkinointi- tai operatiivisesta kalenteristasi.
MicrocosmWorks soveltaa on-off scalingia tietokantoihin käyttäen serverless-tietokantaratkaisuja, kuten Aurora Serverless, Neon tai PlanetScale, jotka skaalaavat laskentaresurssit nollaan joutokäyntijaksojen aikana pitäen samalla tallennustilan persistenttinä ja välittömästi saatavilla. Stateful-työkuormille, jotka eivät voi käyttää serverless-tietokantoja, toteutamme read-replica scalingia, joka lisää ja poistaa replikoita kyselykuorman perusteella pitäen samalla minimaalisen primary instanssin aina käynnissä. Tämä hybridi lähestymistapa tarjoaa asiakkaille skaalauksen kustannushyödyt heidän data tierilleen ilman tietokannan tilan hallinnan monimutkaisuutta sammutus- ja uudelleenkäynnistysjaksojen aikana.
MicrocosmWorks ottaa käyttöön kattavan scaling observabilityn, joka seuraa instanssien määrää, scaling event latenssia, epäonnistuneita scaling-yrityksiä ja halutun ja todellisen kapasiteetin välistä eroa reaaliaikaisesti käyttäen Grafana- tai Datadog-dashboardeja. Konfiguroimme monikanavaisia hälytyksiä scaling-virheistä, pitkäkestoisesta korkeasta utilizationista, joka viittaa liian matalaan scaling-kattoon, ja kustannusanomalioista, jotka kertovat runaway scalingista. runbookimme sisältävät automaattisen korjauksen yleisille virhetilanteille, kuten cloud providerin instanssirajojen saavuttaminen tai riittämättömien kapasiteettivirheiden kohtaaminen tietyillä availability zoneilla.