MicrocosmWorksInnovoimassa ja Arkkitehtuuria Digitaalisessa Kosmoksessa
TietoaYhteystiedot
MicrocosmWorksInnovoimassa ja suunnittelemassa digitaalista kosmosta

Toimitamme IT-ratkaisuja, joilla on merkitystä. Olemme intohimoisia teknologiasta, turvallisuudesta ja autamme yrityksiä kasvamaan luotettavan, innovatiivisen IT-infrastruktuurin kautta.

[email protected]
+91 7011868196
New Delhi, India

AI Kasvuhubi

AI HubStartup-innovaatiotYrityskiihdyttämö

Ratkaisut

Kaikki ratkaisutHyvinvointi- ja kuntoilusovelluksetAI-videoplatformiAI-agenttikehitys

Resurssit

OivalluksetToimialan oppaatKäyttötapausmallitArkkitehtuurimallitTapaustutkimukset

Yritys

Tietoa meistäYhteystiedotTyömme

Palvelut

Digitaalinen konsultointiPilvi-infrastruktuuriSaaS-kehitysAI-kehitysVideoteknologia
ERP-kehitysZoho-mukautusOdoo-kehitysSalesforce-integraatioMukautettu CRM-kehitys
QuickBooks-integraatioIoT-ratkaisutLohkoketjukehitys
KyberturvallisuuskonsultointiIT-tuki - L3

© 2026 MicrocosmWorks. Kaikki oikeudet pidätetään.

TietosuojakäytäntöKäyttöehdot
Takaisin arkkitehtuurikuvioihin
InfrastructureAdvanced

Päälle/pois-skaalausarkkitehtuuri

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

June 18, 2026
|
2 topics covered
Keskustele tästä arkkitehtuurista
on-off-scaling-architecture.webp
Infrastructure
Category
Advanced
Complexity
AI/ML, Media & Entertainment
Industries
2+
Technologies

Milloin tarvitset tätä

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.

Related Architecture Patterns

Explore more design patterns and system architectures

cloud-native-infrastructure.webp
Infrastructure

Pilvinatiivi infrastruktuuri

Infrastruktuuri, joka versioidaan, testataan ja käyttöönotetaan kuten sovelluskoodi – sillä alustasi on vain niin luotettava kuin sen perustana oleva tekniikka.

EnterpriseView
security-first-architecture.webp

Tarvitsetko apua tämän arkkitehtuurin toteuttamisessa?

Arkkitehtehtemme voivat auttaa suunnittelemaan ja rakentamaan järjestelmiä käyttäen tätä mallia omiin vaatimuksiin.

Ota yhteyttä

Mallin yleiskatsaus

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.

Viitearkkitehtuuri

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.

Ydinkomponentit
  • Työjono ja ajastin: Priorisoitu työjono, jossa on konfiguroitavissa samanaikaisuusrajat tyypin mukaan. Tukee viivästettyä suoritusta, dead-letter-jonoja epäonnistuneille töille ja prioriteettikaistoja (pikatyöt saavat lämpimän varannon instansseja, tavalliset työt käyttävät kylmää varantoa). AWS SQS, BullMQ Redisissä tai Temporal monimutkaisiin työnkulkuihin
  • Lämpimän varannon hallinta: Ylläpitää N valmiiksi alustettua instanssia, joiden mallit on ladattu GPU-muistiin, kontit ovat käynnissä ja terveystarkastukset läpäisty. Instanssit kiertävät tilojen läpi: joutilas → osoitettu → käsittelyssä → joutilas. Varannon koko on konfiguroitavissa kellonajan mukaan (suurempi työaikana, pienempi yön yli) ja säädettävissä historiallisen kysyntäkuvion perusteella
  • Kylmän varannon resurssoija: Varaa lisäkapasiteettia spot-instansseista (AWS), preemptible-VM:istä (GCP) tai serverittömistä GPU-palveluntarjoajista (RunPod, Modal, Salad). Käsittelee spot-keskeytysilmoitukset siirtämällä töitä käytettävissä oleviin instansseihin. Hyödyntää monipuolista instanssityyppistrategiaa (useita GPU-tyyppejä, useita AZ:ja) spot-saatavuuden maksimoimiseksi
  • Tarkistuspiste ja palautus: Pitkäkestoisissa töissä (ML-koulutus, suurikokoinen videokoodaus) säännöllinen tarkistuspisteiden tallennus (checkpointing) tallentaa välitilan S3:een. Spot-instanssin poiston sattuessa työ asetetaan takaisin jonoon ja jatkuu viimeisimmästä tarkistuspisteestä. Lyhyissä töissä (< 10 min) tarkistuspisteiden tallentamisen kustannukset ylittävät uudelleenkäynnistyksen kustannukset – nämä työt yritetään yksinkertaisesti uudelleen alusta alkaen

Suunnittelupäätökset ja kompromissit

Lämpimän varannon koko
Lämmin varanto on kompromissi kustannusten (joutilaista instansseista maksaminen) ja viiveen (ensimmäisen työn kylmäkäynnistysaika) välillä. MW mitoittaa lämpimät varannot jonoon saapumiskuvioiden perusteella: jos töitä saapuu jatkuvasti työaikana, lämmin varanto kattaa keskimääräisen läpimenon; kylmä varanto kattaa piikit. Jos töitä saapuu ennakoimattomina purskeina, pidämme pienemmän lämpimän varannon ja hyväksymme kylmäkäynnistysviiveen ensimmäisille purskeajoille, kun kylmä varanto varaa resursseja.
Spot-instanssit vs. Serverless GPU (RunPod/Modal)
Spot-instanssit ovat edullisempia tuntikohtaisesti, mutta edellyttävät sinun hallinnoivan resursointia, poiston käsittelyä ja instanssin elinkaarta. Serverless GPU -palveluntarjoajat (RunPod Serverless, Modal, Banana) hoitavat resursoinnin ja tarjoavat sekuntikohtaisen laskutuksen, mutta korkeammalla laskentasekunnikohtaisella hinnalla. MW käyttää spot-instansseja ennustettaviin, pitkäkestoisiin työkuormiin (>30 min) ja serverless GPU:ta lyhyisiin, purskeisiin töihin (<10 min), joissa resursoinnin ylikuormitus olisi hallitseva.
Skaalauksen alaspäin aggressiivisuus
Jos skaalaat alaspäin liian nopeasti, maksat kylmäkäynnistysrangaistuksia seuraavan työn saapuessa. Jos skaalaat alaspäin liian hitaasti, maksat joutilaista instansseista. MW toteuttaa "jäähtymisen vaimennuksella" -strategian: jonon tyhjennyttyä instanssit pysyvät lämpiminä konfiguroitavan ajan (oletus: 10 minuuttia). Jos uusia töitä ei saavu, instanssit skaalautuvat progressiivisesti alaspäin (50 % 10 minuutin kohdalla, loput 30 minuutin kohdalla). Jäähtymisaika on säädettävissä ja mukautuu automaattisesti työjonon saapumisväliaikojen tilastojen perusteella.
GPU-mallien latauksen optimointi
ML-pääteltäessä kylmäkäynnistyksen pullonkaulana on usein mallin lataaminen (lataaminen S3:sta + lataaminen GPU-muistiin), ei kontin käynnistys. MW optimoi tämän: (a) leipomalla mallit etukäteen konttikuviin (pienille malleille), (b) käyttämällä jaettua NVMe-tallennustilaa instanssien välillä mallivälimuistilla (suurille malleille) ja (c) pitämällä lämpimän varannon instansseja, joissa mallit on esiladattu GPU-muistiin.

Teknologiavalinnat

KerrosTeknologiat
LaskentaAWS EC2 Spot (G5/P4), GCP Preemptible (A2/L4), RunPod Serverless, Modal
OrkestrointiKubernetes (Karpenter automaattiseen skaalaukseen), AWS Batch, mukautettu työorkestraattori
TyöjonoAWS SQS, BullMQ (Redis), Temporal, Celery
TallennustilaS3 (tarkistuspisteet, malliartifaktit), NVMe (mallivälimuisti), EFS (jaettu työtila)
ValvontaCloudWatch/Prometheus (jonon syvyys, instanssin käyttöaste, työn viive), mukautetut kustannuskoontinäytöt

Milloin käyttää / Milloin välttää

Käytä, kunVältä, kun
Työkuorma on purskeista – huippukysyntä on yli 5x keskimääräiseen kysyntään verrattunaLiikenne on tasaista ja ennustettavaa – oikein mitoitetut varatut instanssit ovat edullisempia
GPU/suuritehoiset laskentatyöt, jotka ovat kalliita joutilaanaTyökuorma on kevyttä CPU-käsittelyä, joka sopii serverless-ratkaisuun (Lambda)
Työt voivat sietää 1–5 minuutin kylmäkäynnistyksen kylmän varannon resursoinnissaAlle sekunnin työ aloitusviive on vaatimus – tarvitset aina päällä olevan infrastruktuurin
Kustannusoptimointi on ensisijainen huolenaihe ja spot-hinnoittelu tarjoaa 60–90 % säästötSpot-keskeytys aiheuttaisi tietojen menetyksen, jota tarkistuspisteiden tallennus ei voi lieventää

Lähestymistapamme

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.

Aiheeseen liittyvät suunnitelmat

  • GPU-klusterin orkestrointi AI-työkuormille — GPU-resursointi ja orkestrointi ML-koulutukseen
  • Reaaliaikainen AI-videovalvontajärjestelmä — Purskepäättelyä videoanalyysitapahtumiin
  • Live-urheilun kohokohtien generaattori — Tapahtumakäyttöinen videonkäsittely purskelaskennalla

Aiheeseen liittyvät tapaustutkimukset

  • Päälle/pois-kuvion videonkäsittely — GPU-resursointi lämpimillä/kylmillä varannoilla videokoodaustyökuormille
  • Videokoodauksen jakelualusta — Serverless- ja spot-pohjainen koodaus automaattisesti skaalautuvilla työskentelyvarannoilla
Related Technologies
Cloud SolutionsAI Development
Infrastructure

Turvallisuuslähtöinen arkkitehtuuri

Turvallisuus ei ole ominaisuus, jonka lisäät julkaisun jälkeen. Se on arkkitehtuurin ominaisuus – järjestelmä joko suunniteltiin sitä varten tai sitten ei.

EnterpriseView
serverless-first-architecture.webp
Infrastructure

Palvelimeton ensin -arkkitehtuuri

Maksa vain siitä, mitä käytät, skaalaa nollaan, kun et käytä, ja lopeta palvelimien hallinta kokonaan – mutta tiedä, milloin taloudellinen hyöty loppuu.

AdvancedView

Usein kysytyt kysymykset

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.