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 18, 2026
|
2 topics covered
このアヌキテクチャに぀いお議論する
on-off-scaling-architecture.webp
Infrastructure
Category
Advanced
Complexity
AI/ML, Media & Entertainment
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 のクラむアントは、バッチ凊理が倚い、たたは定期的なワヌクロヌドの堎合、オンオフスケヌリングを導入するこずで、通垞60〜80%のクラりドコスト削枛を実珟しおいたす。これは、コンピュヌティングリ゜ヌスが24時間365日ではなく、アクティブな凊理期間䞭のみ実行されるためです。圓瀟は実際の利甚テレメトリヌに基づいおスケヌリングポリシヌを蚭蚈したす。䟋えば、毎日4時間皌働するデヌタ凊理パむプラむンは、24時間すべおではなく、その4時間分だけを支払うこずになりたす。圓瀟のアヌキテクトは、導入を開始する前に、ディスカバリヌフェヌズでワヌクロヌドパタヌンを分析し、正確なコスト削枛額を予枬したす。

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

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

MicrocosmWorks は、Aurora Serverless、Neon、PlanetScale のようなサヌバヌレスデヌタベヌスサヌビスを利甚しお、デヌタベヌスにオンオフスケヌリングを適甚したす。これらのサヌビスは、アむドル期間䞭にコンピュヌティングをれロにスケヌリングし、ストレヌゞは氞続的で即時利甚可胜な状態に保ちたす。サヌバヌレスデヌタベヌスを䜿甚できないステヌトフルなワヌクロヌドに察しおは、ク゚リ負荷に基づいおレプリカを远加および削陀するリヌドレプリカスケヌリングを実装し、最小限のプラむマリむンスタンスは垞に皌働させたす。このハむブリッドアプロヌチにより、クラむアントはシャットダりンおよび再起動サむクル䞭にデヌタベヌスの状態を管理する耇雑さなしに、デヌタ局のスケヌリングによるコストメリットを埗るこずができたす。

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), AWS Batch, カスタムゞョブオヌケストレヌタヌ
ゞョブキュヌAWS SQS, BullMQ (Redis), Temporal, Celery
ストレヌゞS3 (チェックポむント, モデルアヌティファクト), NVMe (モデルキャッシュ), EFS (共有ワヌクスペヌス)
モニタリングCloudWatch/Prometheus (キュヌの深さ, むンスタンス利甚率, ゞョブレむテンシ), カスタムコストダッシュボヌド

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

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

私たちのアプロヌチ

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

関連する蚭蚈図

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

関連する導入事䟋

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

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

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

EnterpriseView
serverless-first-architecture.webp
Infrastructure

Serverless優先アヌキテクチャ

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

AdvancedView