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 käyttämättömistä GPU:ista. Varaa laskentatehoa juuri ajoissa, käsittele työkuorma ja pura se – muuttaen pääomakustannukset työkohtaisiksi käyttökustannuksiksi.

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

Milloin tätä tarvitaan

Työkuormasi on purskeista – videokoodaustyöt, jotka piikkaavat sisällön lataamisen yhteydessä, ML-koulutusajot, jotka tarvitsevat 8 GPU:ta 4 tunnin ajan ja sen jälkeen eivät mitään, eräpäättelytyöt, jotka käynnistyvät liiketoimintatapahtumista, tai renderöintiputket, jotka ajetaan yön yli. Olet joko yliresursoitu (maksat käyttämättömistä resursseista 80 % ajasta) tai aliresursoitu (työt jonottavat tunteja ruuhka-aikoina). Tarvitset arkkitehtuurin, joka varaa täsmälleen tarvitsemasi laskentatehon, kun sitä tarvitset, ja vapauttaa sen työn valmistuttua – ilman kylmäkäynnistysrangaistusta, joka tekee ”skaalaa nollaan” -mallista epäkäytännöllisen 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 hallinnoi laskentaresursseja lämpimän/kylmän poolin, työjonovetoisen resurssien varauksen ja automatisoidun purkamisen avulla. Lämmin pooli ylläpitää pientä määrää esialustettuja instansseja, jotka ovat valmiina välittömään käyttöön. Kylmä pooli varaa lisäkapasiteettia spot-/preemptible-instansseista, kun kysyntä ylittää lämpimän poolin kapasiteetin. Työn orkestraattori reitittää työt saatavilla oleviin instansseihin, valvoo edistystä, käsittelee uudelleenyritykset spot-instanssien poiston sattuessa ja laukaisee alas skaalauksen, kun jono tyhjenee. Malli on erityisen kriittinen GPU-työkuormille, joissa kylmäkäynnistys (kontin haku + mallin lataus) voi kestää 3-10 minuuttia.

Viitearkkitehtuuri

Järjestelmän keskiössä on työjono (SQS, Redis tai mukautettu), joka puskuroi saapuvat työpyynnöt. Skaalausohjain valvoo jonon syvyyttä ja varaa instansseja ensin lämpimästä poolista, sitten kylmästä poolista (spot-instanssit). Jokainen työskentelyinstanssi hakee töitä jonosta, suorittaa työkuorman (koodaus, koulutus, päättely), raportoi valmistumisesta ja palaa pooliin tai päättyy. Tarkistuspisteiden hallitsija käsittelee spot-instanssin poiston tallentamalla välitilan S3:een, mikä mahdollistaa töiden jatkamisen eri instanssilla alusta aloittamatta.

Ydin komponentit
  • Työjono ja ajastin: Priorisoitu työjono, jossa on konfiguroitavissa samanaikaisuusrajat työtyypin mukaan. Tukee viivästettyä suoritusta, dead-letter-jonoja epäonnistuneille töille ja prioriteettikaistoja (express-työt saavat lämpimän poolin instansseja, vakiotyöt käyttävät kylmää poolia). AWS SQS, BullMQ Redisissä tai Temporal monimutkaisiin työnkulkuihin
  • Lämpimän poolin hallitsija: Ylläpitää N esialustettua instanssia, joissa mallit on ladattu GPU-muistiin, kontit ovat käynnissä ja terveystarkistukset on läpäisty. Instanssit käyvät läpi syklin: tyhjäkäynti → varattu → käsittely → tyhjäkäynti. Poolin koko on konfiguroitavissa kellonajan mukaan (suurempi työaikana, pienempi yön yli) ja säädettävissä historiallisten kysyntämallien perusteella
  • Kylmän poolin varaaja: Varustaa lisäkapasiteettia spot-instansseista (AWS), preemptible-virtuaalikoneista (GCP) tai palvelimettomista GPU-palveluntarjoajista (RunPod, Modal, Salad). Käsittelee spot-instanssien keskeytysilmoitukset siirtämällä töitä saatavilla oleviin instansseihin. Käyttää monipuolista instanssityyppistrategiaa (useita GPU-tyyppejä, useita AZ:eja) spot-saatavuuden maksimoimiseksi
  • Tarkistuspiste ja palautus: Pitkäkestoisissa töissä (ML-koulutus, suuri videokoodaus) säännöllinen tarkistuspisteiden tallennus tallentaa välitilan S3:een. Spot-instanssin poiston sattuessa työ asetetaan uudelleen jonoon ja jatkuu viimeisestä tarkistuspisteestä. Lyhyissä töissä (< 10 min) tarkistuspisteiden tallennuksen kustannukset ylittävät uudelleenkäynnistyksen kustannukset – nämä työt yrittävät yksinkertaisesti uudelleen alusta

Suunnittelupäätökset ja kompromissit

Lämpimän poolin koko
Lämmin pooli on kompromissi kustannusten (käyttämättömistä instansseista maksaminen) ja viiveen (ensimmäisen työn kylmäkäynnistysaika) välillä. MW mitoittaa lämpimät poolit jonoon saapumismallien perusteella: jos työt saapuvat jatkuvasti työaikana, lämmin pooli kattaa keskimääräisen läpimenon; kylmä pooli kattaa huiput. Jos työt saapuvat ennakoimattomina purskeina, pidämme pienempää lämmintä poolia ja hyväksymme kylmäkäynnistysviiveen ensimmäisten pursketöiden osalta, kun kylmä pooli varautuu.
Spot-instanssit vs. palvelimeton GPU (RunPod/Modal)
Spot-instanssit ovat edullisempia tuntikohtaisesti, mutta edellyttävät varauksen, poiston käsittelyn ja instanssin elinkaaren hallintaa. Palvelimettomat GPU-palveluntarjoajat (RunPod Serverless, Modal, Banana) hoitavat varauksen ja tarjoavat sekuntikohtaisen laskutuksen, mutta korkeammalla laskentasekunnikohdalla. MW käyttää spot-instansseja ennakoitaviin, pitkäkestoisiin työkuormiin (>30 min) ja palvelimettomia GPU:ita lyhyisiin, purskeisiin töihin (<10 min), joissa varausten yleiskustannukset olisivat hallitsevia.
Alas skaalauksen aggressiivisuus
Liian nopea alas skaalaus johtaa kylmäkäynnistysrangaistuksiin seuraavan työn saapuessa. Liian hidas alas skaalaus johtaa käyttämättömistä instansseista maksamiseen. MW toteuttaa ”jäähtymis- ja rappeutumisstrategian”: kun jono tyhjenee, instanssit pysyvät lämpiminä konfiguroitavissa olevan ajan (oletus: 10 minuuttia). Jos uusia töitä ei saavu, instanssit skaalautuvat alas asteittain (50 % 10 minuutin kohdalla, loput 30 minuutin kohdalla). Jäähtymisjakso on säädettävissä ja mukautuu automaattisesti työn saapumisaikojen tilastojen perusteella.
GPU-mallin latauksen optimointi
ML-päättelyssä kylmäkäynnistyksen pullonkaula on usein mallin lataaminen (lataaminen S3:sta + lataaminen GPU-muistiin), ei konttien käynnistys. MW optimoi tämän: (a) leipomalla mallit etukäteen konttien kuvatiedostoihin (pieniä malleja varten), (b) käyttämällä jaettua NVMe-tallennustilaa instanssien välillä mallin välimuistilla (suuria malleja varten) ja (c) pitämällä lämpimän poolin instansseja, joissa mallit on esiladattu GPU-muistiin.

Teknologiavalinnat

KerrosTeknologiat
LaskentatehoAWS EC2 Spot (G5/P4), GCP Preemptible (A2/L4), RunPod Serverless, Modal
OrkestrointiKubernetes (Karpenter for autoscaling), AWS Batch, custom job orchestrator
TyöjonoAWS SQS, BullMQ (Redis), Temporal, Celery
TallennustilaS3 (checkpoints, model artifacts), NVMe (model cache), EFS (shared workspace)
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 5-kertainen keskimääräiseen kysyntään verrattunaLiikenne on tasaista ja ennustettavaa – oikein mitoitetut varatut instanssit ovat edullisempia
GPU/paljon laskentatehoa vaativat työt, jotka ovat kalliita tyhjäkäynnilläTyökuorma on kevyttä suoritinkäsittelyä, joka sopii palvelimettomaan arkkitehtuuriin (Lambda)
Työt voivat sietää 1-5 minuutin kylmäkäynnistyksen kylmän poolin varausta vartenAlle sekunnin työtehtävän käynnistysviive vaaditaan – tarvitset aina päällä olevan infrastruktuurin
Kustannusoptimointi on ensisijainen huolenaihe ja spot-hinnoittelu tarjoaa 60-90 % säästötSpot-instanssin keskeytys aiheuttaisi tiedon katoamisen, jota tarkistuspisteiden tallennus ei voi lieventää

Lähestymistapamme

MW suunnittelee päälle/pois-skaalauksen ”työkohtaisten kustannusten” näkökulmasta – mallinnamme yhden työskentelyyksikön (yhden videon, yhden koulutusajon, yhden eräpäättelyn) kokonaiskustannukset eri skaalausstrategioilla ja valitsemme sen, joka minimoi kustannukset vaaditulla viiveen SLA:lla. Toteutuksemme sisältävät reaaliaikaiset kustannuskoontinäytöt, jotka näyttävät työkohtaiset kustannukset, infrastruktuurin käyttöasteen ja spot-säästöt. Olemme rakentaneet päälle/pois-GPU-infrastruktuurin, joka vähensi videonkäsittelykustannuksia 70 % verrattuna varattuihin instansseihin, sekä ML-koulutusklustereita, jotka varaavat 64 GPU:ta 4 tunnin koulutusajoa varten ja vapauttavat ne automaattisesti.

Aiheeseen liittyvät suunnitelmat

  • GPU-klusterin orkestrointi tekoälytyökuormille – GPU:n varaus ja orkestrointi ML-koulutusta varten
  • Reaaliaikainen tekoälyvideovalvontajärjestelmä – Purskeinen päättely videoanalyysitapahtumille
  • Suorien urheilulähetysten kohokohtageneraattori – Tapahtumavetoinen videonkäsittely purskeisella laskentateholla

Aiheeseen liittyvät tapaustutkimukset

  • Päälle/pois-kuvion videonkäsittely – GPU:n varaus lämpimillä/kylmillä pooleilla videokoodaustyökuormille
  • Videokoodausalusta – Palvelimeton ja spot-pohjainen koodaus automaattisesti skaalautuvilla työntekijäpooleilla
Related Technologies
PilviratkaisutAI-kehitys
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, havaitsevat tyypillisesti 60-80 %:n pilvikustannussäästöjä on-off skaalauksen käyttöönoton jälkeen, koska laskentaresurssit ovat käytössä vain aktiivisten käsittelyikkunoiden aikana 24/7-käytön sijaan. Suunnittelemme skaalauskäytäntöjä todellisen käyttötelemetrian perusteella – esimerkiksi tiedonkäsittelyputki, joka on käytössä 4 tuntia päivässä, maksaa vain niistä 4 tunnista koko 24 tunnin sijaan. Arkkitehtimme analysoivat työkuormamallejasi tutkimusvaiheen aikana projisoidakseen tarkat säästöt ennen kuin varsinainen käyttöönotto alkaa.

Cold-start-ajat vaihtelevat 2-3 sekunnista kontitetyille sovelluksille esilämmitetyissä node-pooleissa 5-10 minuuttiin työkuormille, jotka vaativat erikoistuneita GPU-instansseja tai suurten mallien lataamista, ja MicrocosmWorks käyttää useita tekniikoita tämän viiveen minimoimiseksi. Toteutamme ennakoivaa skaalausta, joka käynnistää resursseja ennen ennakoitua kysyntää hyödyntäen historiallisia liikennemalleja ja aikataulutettuja tapahtumia, ja käytämme konttikuvien esilatausta ja warm pool -varauksia viiveherkille työkuormille. Sovelluksille, jotka eivät siedä lainkaan cold startia, ylläpidämme minimaalista lämmintä perustasoa, joka skaalautuu aggressiivisesti ylöspäin kysynnän saapuessa.

MicrocosmWorks toteuttaa reaktiivista auto-scalingia aggressiivisilla scale-up-politiikoilla, jotka laukaistaan queue depthin, CPU utilizationin tai mukautettujen sovellusmittareiden perusteella, yhdistettynä asteittaisempiin scale-down-politiikkoihin, jotka sisältävät cooldown-jaksoja thrashingin välttämiseksi. Konfiguroimme over-provisioning-puskureita scale-up-tapahtumien aikana, jotta järjestelmä ennakoi jatkuvaa kasvua sen sijaan, että se jahtaisi kysyntää yksi instance kerrallaan. Todella ennustamattomia piikkejä varten, kuten flash sales tai viral events, esivaraamme kapasiteettia käyttämällä event-driven triggereitä markkinointi- tai operatiivisesta kalenteristasi.

MicrocosmWorks soveltaa on-off-skaalausta tietokantoihin käyttämällä serverless database offerings -palveluita, kuten Aurora Serverless, Neon tai PlanetScale, jotka skaalaavat compute-resurssit nollaan käyttämättömien jaksojen aikana pitäen storage-tilan pysyvänä ja välittömästi saatavilla. Stateful workloads -työkuormille, jotka eivät voi käyttää serverless-tietokantoja, toteutamme read-replica scaling -ratkaisun, joka lisää ja poistaa replicas-instansseja query load -kuormituksen perusteella pitäen samalla minimaalisen primary instance -instanssin aina käynnissä. Tämä hybridi lähestymistapa tarjoaa asiakkaille skaalauksen kustannushyödyt heidän data tier -tasolleen ilman database state -tilan hallinnan monimutkaisuutta sammutus- ja uudelleenkäynnistysjaksojen aikana.

MicrocosmWorks ottaa käyttöön kattavan skaalauksen observabilityn, joka seuraa instanssien määriä, skaalaustapahtumien viivettä, epäonnistuneita skaalausyrityksiä sekä toivotun ja todellisen kapasiteetin välistä eroa reaaliaikaisesti käyttäen Grafana- tai Datadog-hallintapaneeleita. Määritämme monikanavaisia hälytyksiä skaalausvirheistä, jatkuvasta korkeasta käyttöasteesta, joka viittaa liian matalaan skaalauskattoon, sekä kustannusanomalioista, jotka kertovat hallitsemattomasta skaalauksesta. Ajokirjamme (runbooks) sisältävät automatisoidun korjauksen yleisiin vikatilanteisiin, kuten pilvipalveluntarjoajan instanssirajojen saavuttamiseen tai riittämättömän kapasiteetin virheiden kohtaamiseen tietyillä saatavuusalueilla.