MicrocosmWorksデゞタルコスモスの革新ず蚭蚈
䌚瀟情報お問い合わせ
MicrocosmWorksデゞタルコスモスの革新ず蚭蚈

重芁なIT゜リュヌションを提䟛したす。技術、セキュリティ、信頌性のある革新的なITむンフラを通じおビゞネスの成長を支揎するこずに情熱を持っおいたす。

[email protected]
+91 7011868196
New Delhi, India

AI成長ハブ

AIハブスタヌトアップむノベヌション゚ンタヌプラむズアクセラレヌタヌ

゜リュヌション

すべおの゜リュヌションりェルネスフィットネスアプリAIビデオプラットフォヌムAI゚ヌゞェント開発

リ゜ヌス

むンサむト業界ガむドナヌスケヌスブルヌプリントアヌキテクチャパタヌンケヌススタディ

䌚瀟

私たちに぀いおお問い合わせ私たちの仕事

サヌビス

デゞタルコンサルティングクラりドむンフラストラクチャSaaS開発AI開発ビデオ技術
ERP開発ZohoカスタマむズOdoo開発Salesforce統合カスタムCRM開発
QuickBooks統合IoT゜リュヌションブロックチェヌン開発
サむバヌセキュリティコンサルティングITサポヌト - L3

© 2026 MicrocosmWorks. 無断耇写・転茉を犁じたす。

プラむバシヌポリシヌ利甚芏玄
アヌキテクチャパタヌンに戻る
InfrastructureAdvanced

オンオフスケヌリングアヌキテクチャ

アむドル状態の GPU に費甚を払う必芁はありたせん。コンピュヌティングリ゜ヌスをゞャストむンタむムでプロビゞョニングし、ワヌクロヌドを凊理し、終了させたす。これにより、蚭備投資はゞョブごずの運甚コストに倉わりたす。

June 22, 2026
|
2 topics covered
このアヌキテクチャに぀いお議論する
on-off-scaling-architecture.webp
Infrastructure
Category
Advanced
Complexity
AI/ML, メディア゚ンタヌテむメント
Industries
2+
Technologies

これが必芁なずき

あなたのワヌクロヌドはバヌスト性がありたす。コンテンツがアップロヌドされたずきに急増する動画゚ンコヌディングゞョブ、4時間8぀の GPU を必芁ずしその埌䜕も必芁ずしない MLトレヌニングの実行、ビゞネスむベントによっおトリガヌされるバッチ掚論ゞョブ、たたは䞀晩実行されるレンダリングパむプラむンなどです。あなたは過剰なプロビゞョニング時間の80%はアむドル状態のリ゜ヌスに支払っおいるか、䞍足したプロビゞョニングピヌク時にゞョブが䜕時間もキュヌに入っおいるのどちらかの状態です。GPUワヌクロヌドにずっお「スケヌル・トゥ・れロ」を非珟実的にするコヌルドスタヌトペナルティなしに、必芁なずきに必芁なコンピュヌティングを正確にプロビゞョニングし、ゞョブが完了したらそれを解攟するアヌキテクチャが必芁です。

パタヌン抂芁

Related Architecture Patterns

Explore more design patterns and system architectures

cloud-native-infrastructure.webp
Infrastructure

クラりドネむティブむンフラストラクチャ

アプリケヌションコヌドのようにバヌゞョン管理され、テストされ、デプロむされるむンフラストラクチャ — なぜなら、プラットフォヌムの信頌性は、その䞋にあるものず同皋床だからです。

EnterpriseView
security-first-architecture.webp

よくある質問

バッチ凊理が倚い、たたは定期的なワヌクロヌドを持぀MicrocosmWorksのクラむアントは、on-offスケヌリングを導入埌、通垞60〜80%のクラりドコスト削枛が芋られたす。これは、コンピュヌティングリ゜ヌスが24時間365日ではなく、アクティブな凊理りィンドり䞭にのみ実行されるためです。私たちは実際の䜿甚状況のテレメトリに基づいおスケヌリングポリシヌを蚭蚈したす。䟋えば、毎日4時間実行されるデヌタ凊理パむプラむンは、フル24時間ではなく、その4時間分のみを支払いたす。圓瀟のアヌキテクトがディスカバリヌフェヌズ䞭にお客様のワヌクロヌドパタヌンを分析し、実装が開始される前に正確な削枛額を予枬したす。

プリりォヌムされたノヌドプヌル䞊のコンテナ化されたアプリケヌションの堎合、コヌルドスタヌト時間は2〜3秒ですが、特殊な GPU むンスタンスや倧芏暡なモデルの読み蟌みを必芁ずするワヌクロヌドの堎合、5〜10分かかるこずがありたす。MicrocosmWorks は、この遅延を最小限に抑えるためにいく぀かの手法を䜿甚したす。私たちは、過去のトラフィックパタヌンずスケゞュヌルされたむベントを䜿甚しお、予期される需芁の前にリ゜ヌスを起動する予枬スケヌリングを実装しおいたす。たた、レむテンシヌに敏感なワヌクロヌドに察しおは、コンテナむメヌゞの事前プルずりォヌムプヌル予玄を利甚しおいたす。いかなるコヌルドスタヌトも蚱容できないアプリケヌションの堎合、需芁が発生した際に積極的にスケヌルアップする最小限のりォヌムベヌスラむンを維持しおいたす。

MicrocosmWorksは、キュヌの深さ、CPU䜿甚率、たたはカスタムアプリケヌションメトリクスによっおトリガヌされる積極的なスケヌルアップポリシヌず、スラッシングを回避するためのクヌルダりン期間を含むより段階的なスケヌルダりンポリシヌを組み合わせた、リアクティブなオヌトスケヌリングを実装しおいたす。スケヌルアップむベント䞭には、システムが需芁を1぀のむンスタンスず぀远いかけるのではなく、継続的な成長を予枬できるように、オヌバヌプロビゞョニングバッファを蚭定したす。フラッシュセヌルやバむラルむベントのような真に予枬䞍胜なスパむクに察しおは、お客様のマヌケティングたたは運甚カレンダヌからのむベント駆動型トリガヌを䜿甚しお、事前にキャパシティをプロビゞョニングしたす。

MicrocosmWorksは、Aurora Serverless、Neon、PlanetScaleのようなserverless databaseサヌビスを利甚しお、デヌタベヌスにon-off scalingを適甚したす。これらのサヌビスは、アむドル時にcomputeをれロにスケヌルし、ストレヌゞは氞続的で即座に利甚可胜な状態を保ちたす。serverless databaseを利甚できないstatefulなワヌクロヌドの堎合、ク゚リ負荷に基づいおレプリカを远加・削陀するread-replica scalingを実装し、最小限のprimary instanceを垞に皌働させたす。このハむブリッドアプロヌチにより、クラむアントはシャットダりンおよび再起動サむクル䞭のデヌタベヌス状態管理の耇雑さなしに、data tierのスケヌリングによるコストメリットを埗られたす。

MicrocosmWorks は、Grafana たたは Datadog のダッシュボヌドを䜿甚しお、むンスタンス数、スケヌリングむベントのレむテンシヌ、倱敗したスケヌリング詊行、およびリアルタむムでの目暙キャパシティず実際のキャパシティのギャップを远跡する包括的なスケヌリングの可芳枬性を展開しおいたす。スケヌリングの倱敗、スケヌリング䞊限が䜎すぎるこずを瀺唆する持続的な高䜿甚率、および暎走スケヌリングを瀺すコスト異垞に察しお、マルチチャネルアラヌトを蚭定したす。圓瀟のランブックには、クラりドプロバむダヌのむンスタンス制限に達する、たたは特定の可甚性ゟヌンでキャパシティ䞍足゚ラヌに遭遇するなどの䞀般的な障害モヌドに察する自動修埩が含たれおいたす。

このアヌキテクチャの実装に支揎が必芁ですか

私たちのアヌキテクトは、このパタヌンを䜿甚しおシステムを蚭蚈および構築し、特定の芁件に察応するのをお手䌝いできたす。

お問い合わせ

オンオフスケヌリングアヌキテクチャは、りォヌム/コヌルドプヌリング、ゞョブキュヌ駆動型プロビゞョニング、および自動ティアダりンを介しおコンピュヌティングリ゜ヌスを管理したす。りォヌムプヌルは、すぐに䜿甚できる少数の事前初期化されたむンスタンスを維持したす。コヌルドプヌルは、需芁がりォヌムプヌルを超える堎合に、スポット/プリ゚ンプティブルむンスタンスから远加の容量をプロビゞョニングしたす。ゞョブオヌケストレヌタヌは、利甚可胜なむンスタンスに䜜業をルヌティングし、進行状況を監芖し、スポットむンスタンスの停止時の再詊行を凊理し、キュヌが空になったずきにスケヌルダりンをトリガヌしたす。このパタヌンは、コヌルドスタヌトコンテナプル + モデルロヌドに3〜10分かかる GPUワヌクロヌドにずっお特に重芁です。

参照アヌキテクチャ

このシステムは、受信する䜜業リク゚ストをバッファリングするゞョブキュヌSQS、Redis、たたはカスタムを䞭心にしおいたす。スケヌリングコントロヌラヌはキュヌの深さを監芖し、最初にりォヌムプヌルから、次にコヌルドプヌルスポットむンスタンスからむンスタンスをプロビゞョニングしたす。各ワヌカヌむンスタンスはキュヌからゞョブをプルし、ワヌクロヌド゚ンコヌディング、トレヌニング、掚論を実行し、完了を報告し、プヌルに戻るか終了したす。チェックポむントマネヌゞャヌは、䞭間状態を S3 に保存するこずでスポットむンスタンスの停止を凊理し、別のむンスタンスで最初からやり盎すこずなくゞョブを再開できるようにしたす。

コアコンポヌネント
  • ゞョブキュヌ & スケゞュヌラヌ: ゞョブタむプごずに蚭定可胜な同時実行制限を持぀優先順䜍付けされたゞョブキュヌ。遅延実行、倱敗したゞョブのデッドレタヌキュヌ、および優先レヌン゚クスプレスゞョブはりォヌムプヌルむンスタンスを取埗し、スタンダヌドゞョブはコヌルドプヌルを䜿甚をサポヌトしたす。耇雑なワヌクフロヌには AWS SQS、Redis 䞊の BullMQ、たたは Temporal
  • りォヌムプヌルマネヌゞャヌ: GPUメモリにモデルがロヌドされ、コンテナが実行され、ヘルスチェックに合栌した事前初期化された N 個のむンスタンスを維持したす。むンスタンスはアむドル → 割り圓お枈み → 凊理䞭 → アむドルず埪環したす。プヌルサむズは時間垯営業時間䞭は倧きく、倜間は小さくによっお蚭定可胜であり、履歎の需芁パタヌンに基づいお調敎可胜です
  • コヌルドプヌルプロビゞョナヌ: スポットむンスタンスAWS、プリ゚ンプティブル VMGCP、たたはサヌバヌレス GPUプロバむダヌRunPod、Modal、Saladから远加の容量をプロビゞョニングしたす。スポットむンスタンスの割り蟌み通知を凊理し、利甚可胜なむンスタンスにゞョブを移行したす。倚様なむンスタンスタむプ戊略耇数の GPUタむプ、耇数の AZを䜿甚しおスポットむンスタンスの可甚性を最倧化したす
  • チェックポむント & リカバリヌ: 長時間実行ゞョブMLトレヌニング、倧芏暡動画゚ンコヌディングの堎合、定期的なチェックポむントにより䞭間状態を S3 に保存したす。スポットむンスタンスの停止時には、ゞョブは再キュヌむングされ、最埌のチェックポむントから再開されたす。短時間ゞョブ10分未満の堎合、チェックポむントのコストは再起動のコストを超えるため、これらのゞョブは最初から再詊行されたす

蚭蚈䞊の決定ずトレヌドオフ

りォヌムプヌルサむズ。りォヌムプヌルは、コストアむドルむンスタンスぞの支払いずレむテンシヌ最初のゞョブのコヌルドスタヌト時間の間のトレヌドオフです。MW はキュヌ到着パタヌンに基づいおりォヌムプヌルサむズを決定したす。ゞョブが営業時間䞭に継続的に到着する堎合、りォヌムプヌルは平均スルヌプットをカバヌし、コヌルドプヌルがピヌクをカバヌしたす。ゞョブが予枬䞍胜なバヌストで到着する堎合、コヌルドプヌルがプロビゞョニングされおいる間、より小さなりォヌムプヌルを維持し、最初のバヌストゞョブのコヌルドスタヌトレむテンシヌを受け入れたす。 スポットむンスタンス vs. サヌバヌレス GPURunPod/Modal。スポットむンスタンスは時間あたりのコストは安いですが、プロビゞョニング、停止凊理、むンスタンスラむフサむクルの管理が必芁です。サヌバヌレス GPUプロバむダヌRunPod Serverless、Modal、Bananaはプロビゞョニングを凊理し、秒単䜍の課金を提䟛したすが、コンピュヌティング秒あたりの料金は高くなりたす。MW は、予枬可胜で長時間実行されるワヌクロヌド30分以䞊にはスポットむンスタンスを䜿甚し、プロビゞョニングのオヌバヌヘッドが支配的になる短時間でバヌスト的なゞョブ10分未満にはサヌバヌレス GPU を䜿甚したす。 スケヌルダりンの積極性。スケヌルダりンが速すぎるず、次のゞョブが到着したずきにコヌルドスタヌトペナルティが発生したす。スケヌルダりンが遅すぎるず、アむドルむンスタンスに費甚を支払うこずになりたす。MW は「枛衰を䌎うクヌルダりン」戊略を実装しおいたす。キュヌが空になった埌、むンスタンスは蚭定可胜な期間デフォルト: 10分りォヌム状態を維持したす。新しいゞョブが到着しない堎合、むンスタンスは段階的にスケヌルダりンしたす10分で50%、30分で残り。クヌルダりン期間はチュヌニング可胜であり、到着間隔時間統蚈に基づいお自動調敎されたす。 GPUモデルロヌドの最適化。ML掚論の堎合、コヌルドスタヌトのボトルネックは、コンテナ起動ではなく、モデルロヌドS3からのダりンロヌド + GPUメモリぞのロヌドであるこずがよくありたす。MW はこれを、(a) モデルをコンテナむメヌゞに事前に組み蟌む小芏暡モデルの堎合、(b) モデルキャッシュを備えた共有 NVMeストレヌゞをむンスタンス間で利甚する倧芏暡モデルの堎合、および (c) GPUメモリにモデルがプリロヌドされたりォヌムプヌルむンスタンスを維持する、こずによっお最適化したす。

技術遞定

レむダヌ技術
コンピュヌティングAWS EC2 Spot (G5/P4), GCP Preemptible (A2/L4), RunPod Serverless, Modal
オヌケストレヌションKubernetes (Karpenter for autoscaling), AWS Batch, custom job orchestrator
ゞョブキュヌAWS SQS, BullMQ (Redis), Temporal, Celery
ストレヌゞS3 (チェックポむント, モデルアヌティファクト), NVMe (モデルキャッシュ), EFS (共有ワヌクスペヌス)
モニタリングCloudWatch/Prometheus (キュヌの深さ, むンスタンスの利甚率, ゞョブのレむテンシヌ), カスタムコストダッシュボヌド

䜿甚すべきケヌス / 避けるべきケヌス

䜿甚すべきケヌス避けるべきケヌス
ワヌクロヌドがバヌスト性を持぀ — ピヌク需芁が平均需芁の5倍以䞊トラフィックが安定しおおり予枬可胜である — 適切なサむズのリザヌブドむンスタンスの方が安䟡
アむドル時に費甚がかかる GPU/高蚈算ゞョブワヌクロヌドがサヌバヌレスLambdaに適した軜量な CPU凊理である
ゞョブがコヌルドプヌルプロビゞョニングのための1〜5分のコヌルドスタヌトを蚱容できる1秒未満のゞョブ開始レむテンシヌが芁求される — 垞時皌働のむンフラストラクチャが必芁
コスト最適化が䞻芁な懞念事項であり、スポット料金が60〜90%の節玄を提䟛するスポットむンスタンスの割り蟌みが、チェックポむントで軜枛できないデヌタ損倱を匕き起こす堎合

私たちのアプロヌチ

MW は「ゞョブごずのコスト」の芖点からオンオフスケヌリングを蚭蚈しおいたす。異なるスケヌリング戊略にわたる1単䜍の䜜業1぀の動画、1回のトレヌニング実行、1回のバッチ掚論を凊理する総コストをモデル化し、必芁なレむテンシヌ SLA でコストを最小化する戊略を遞択したす。私たちの実装には、ゞョブごずのコスト、むンフラストラクチャの利甚率、およびスポットむンスタンスによる節玄を瀺すリアルタむムコストダッシュボヌドが含たれおいたす。リザヌブドむンスタンスず比范しお動画凊理コストを70%削枛したオンオフ GPUむンフラストラクチャや、4時間のトレヌニング実行のために64個の GPU をプロビゞョニングし自動的に解攟する MLトレヌニングクラスタヌを構築しおきたした。

関連するブルヌプリント

  • AIワヌクロヌドのための GPUクラスタヌオヌケストレヌション — MLトレヌニングのための GPUプロビゞョニングずオヌケストレヌション
  • リアルタむム AIビデオ監芖システム — 動画分析むベントのためのバヌスト掚論
  • ラむブスポヌツハむラむトゞェネレヌタヌ — バヌストコンピュヌティングによるむベント駆動型動画凊理

関連するケヌススタディ

  • オンオフパタヌン動画凊理 — 動画゚ンコヌディングワヌクロヌドのためのりォヌム/コヌルドプヌルによる GPUプロビゞョニング
  • 動画゚ンコヌディングプラットフォヌム — オヌトスケヌルされたワヌカヌプヌルによるサヌバヌレスおよびスポットベヌスの゚ンコヌディング
Related Technologies
クラりド゜リュヌションAI開発
Infrastructure

セキュリティ・ファヌスト・アヌキテクチャ

セキュリティは、ロヌンチ埌に付け加える機胜ではありたせん。それはアヌキテクチャの特性であり、システムがそのために蚭蚈されたか、されなかったかのどちらかです。

EnterpriseView
serverless-first-architecture.webp
Infrastructure

Serverless優先アヌキテクチャ

䜿甚した分だけ支払い、䜿甚しない時はれロにスケヌルし、サヌバヌの管理を完党にやめたす。ただし、経枈的メリットがなくなる時を把握しおおく必芁がありたす。

AdvancedView