Loading...

📈

適応的な計算スケーリング(ACS)

ワークロードの需要とパフォーマンス要件に応じて、計算リソースを動的に調整する。

複雑さ: highリソースを考慮した最適化

In 30 seconds

What: ワークロードの指標をリアルタイムで監視し、計算資源を自動的に追加または削減して、コストを抑えながら性能目標を維持します。
When to use: 予測できないトラフィックの急増や変動する計算需要にさらされるサービス、あるいは性能保証とインフラ費用の釣り合いを取る必要があるサービス。
Watch out: スケーリングの判断は需要の変化に遅れて追随するため、閾値や予測モデルの調整が不十分だと連鎖的な障害や資源の浪費を招きます。

Loading technique guide…

Patterns

Loading...

Loading Agentic Design…

Agentic Design本番環境のAIエージェント向けパターンとツール

専門家に相談料金

設計パターンと手法

Loading...

📈

適応的な計算スケーリング(ACS)

ワークロードの需要とパフォーマンス要件に応じて、計算リソースを動的に調整する。

複雑さ: highリソースを考慮した最適化

In 30 seconds

What: ワークロードの指標をリアルタイムで監視し、計算資源を自動的に追加または削減して、コストを抑えながら性能目標を維持します。
When to use: 予測できないトラフィックの急増や変動する計算需要にさらされるサービス、あるいは性能保証とインフラ費用の釣り合いを取る必要があるサービス。
Watch out: スケーリングの判断は需要の変化に遅れて追随するため、閾値や予測モデルの調整が不十分だと連鎖的な障害や資源の浪費を招きます。

中核メカニズム

アダプティブ・コンピュート・スケーリングは、リアルタイムの需要とSLOに応じて計算容量(ポッド/レプリカ、ノード/VM、GPUワーカー)を自動調整する。メトリクス駆動のポリシー(p95レイテンシ、キュー長、使用率など)に、安定化ウィンドウ、クールダウン、予測型/スケジュール型スケーリングを組み合わせ、性能を保ちながらコストを最小化する。一般的な構成では、サービスのオートスケーリング(HPA/KEDA/Ray Serve)とクラスタ/VMのオートスケーリング(Cluster Autoscaler、AWS ASG、Azure VMSS、GCP MIG)を重ね、ワークロードに応じたバッチ処理を併用する。

ワークフロー / 手順

シグナルを取り込む: p95レイテンシ、キューの深さと待ち時間、CPU/メモリ/GPU使用率、エラー率、RPS/TPS。
目標を定義する: SLO(レイテンシ、可用性)、予算(コスト/電力)、レプリカ数の下限と上限。
ポリシーを選ぶ: ターゲット追従かステップスケーリングか、スケールアップとスケールダウンの挙動を分ける。
スケーリングを実行する: レプリカ数を調整し(HPA/KEDA/Ray Serve)、続いて容量をプロビジョニングする(ASG/VMSS/MIG、Cluster Autoscaler)。
安定化する: stabilizationWindow やクールダウン、レート制限を適用してスラッシングを防ぐ。
事前ウォームアップ: ウォームプールを維持するか、日内変動やバーストに備えてスケジュール型/予測型スケーリングを行う。
観測して調整する: KPIとステージ別の寄与を監視し、シグナルやしきい値を定期的に見直す。

ベストプラクティス

ワークロードに適したシグナルを使う: GPUでのLLMサービングでは、CPU%よりp95レイテンシとキューの深さを優先する。

スケールアップ(速く積極的)とスケールダウン(遅く保守的)で別々のポリシーを設定し、安定化ウィンドウを設ける。

コールドスタートの重いモデルではワーカーを事前ウォームアップし、ウォームプールやスケジュール型・予測型スケーリングを使う。

オートスケーラーを重ねる: サービス層(HPA/KEDA/Ray Serve)+ クラスタ/VM層(Cluster Autoscaler/ASG/VMSS/MIG)。

レプリカ数の下限と上限、最大サージ/ドレインで制約し、Pod Disruption Budget と穏やかなドレインを用いる。

賢くバッチ化し(vLLM/TGI/Triton の動的バッチング)、リクエストあたりのトークン数を制限してテールレイテンシを安定させる。

ノードのサイズを適正化し、GPUをビンパッキングし、必要に応じてMIG/MPSを使い、リソースの断片化を避ける。

SLO駆動の目標を用い(例: p95 < 目標値を維持)、マルチテナントクラスタではテナントごとの公平性を監視する。

意思決定ログとランブックを整備し、本番前にバーストや障害モードをシミュレーションする。

使用を避けるべき場合

コールドスタートや再バランスが一切許容されない、超低レイテンシのハードリアルタイム経路。
シャーディングやスティッキールーティングの戦略がない、状態を持ちセッション親和性の高いワークロード。
ライセンスやクォータに制限され、レプリカを増やしてもスループットが上がらないサービス。
エラスティックな基盤リソースを持たない、エアギャップ環境や固定容量の環境。

よくある落とし穴

GPUバウンドの推論にCPU%を使うこと。代わりにキューのレイテンシ/深さとGPU使用率を選ぶ。
安定化ウィンドウやクールダウンの欠如と、上下対称なスケーリングポリシーによるスラッシング。
ウォームアップ時間、イメージのプル、大きなモデルのロード時間を無視すること → SLO違反の長期化。
最小容量やヘッドルームがなく、Cluster Autoscaler の遅延がポッドのオートスケーラーを飢餓状態にする。
リクエストのバッファリングやウォーマーなしにゼロまでスケールすること → 深刻なコールドスタートの代償。
平均値に頼りすぎること。p95/p99を目標にし、バースト的な到着に備える。

主な特徴

メトリクス駆動のオートスケーリング(レイテンシ、キューの深さ、使用率、エラー率)。

外部システムを介したイベントベースのスケーリング(KEDA: Kafka、SQS、Redis、Prometheus)。

日内変動や既知のイベントに対応する予測型・スケジュール型スケーリング。

多層スケーリング: サービス、ノード/VM、クラスタ容量の協調。

SLOを考慮したポリシーで、スケールアップとダウンの挙動を分け、安定化を行う。

コストとエネルギーを考慮した制約と予算、テナントごとのクォータ。

KPI / 成功指標

SLOに対するp50/p95/p99レイテンシ、キューの待ち時間、バースト時のエラー/タイムアウト。
スループット(RPS/TPS、トークン/秒)とスケーリングのレイテンシ(容量到達までの時間)。
成功リクエストあたりのコスト、インスタンス/GPU時間、過剰/不足プロビジョニング時間の割合。
オートスケーリングのイベント発生率と安定性(フラッピングがないこと)、飽和までの余裕。
マルチテナントクラスタにおけるテナントごとの公平性とクォータ遵守。

トークン / リソース使用量

LLM推論では、トークン/秒、同時リクエスト数、KVキャッシュのメモリを追跡する。バッチ処理とコンテキスト/トークンの上限でテールレイテンシを抑え、キューの深さとp95レイテンシを主要シグナルとする。GPUノードではVRAM/SM使用率とモデルのロード時間を監視し、オートスケーラーに容量の余裕を確保する。

シグナル: キューの深さ、p95レイテンシ、GPU使用率、リクエストの同時実行数、トークン予算。
制御: 動的バッチング、最大新規トークン数、プロンプト長の制限、ウォームプール。
効率化: KV/プレフィックスをキャッシュし、大規模モデルをシャーディングし、GPUをビンパッキングし、使用率の低い小さなポッドを避ける。

最適なユースケース

バースト的、日内変動的、またはキャンペーン起因のトラフィック(EC、ローンチ、ライブイベント)。
動的バッチングと厳格なレイテンシ/コストSLOを備えたGPU上のLLMサービング。
バックログの長さが明確なシグナルとなるイベント駆動処理(キュー/ストリーム)。
コスト管理、公平性、予測可能なSLOを必要とするマルチテナントプラットフォーム。

参考文献と関連資料

学術論文

実装ガイド

ツールとライブラリ

Kubernetes HPA/KEDA/Cluster Autoscaler、AWS ASG、Azure VMSS、GCP MIG。
vLLM、Text Generation Inference (TGI)、NVIDIA Triton Inference Server。
Prometheus + Grafana、CloudWatch、Azure Monitor、GCP Cloud Monitoring。

コミュニティと議論

Loading technique guide…

Patterns

設計パターンと手法

Loading...

中核メカニズム

ワークフロー / 手順

シグナルを取り込む: p95レイテンシ、キューの深さと待ち時間、CPU/メモリ/GPU使用率、エラー率、RPS/TPS。
目標を定義する: SLO(レイテンシ、可用性)、予算(コスト/電力)、レプリカ数の下限と上限。
ポリシーを選ぶ: ターゲット追従かステップスケーリングか、スケールアップとスケールダウンの挙動を分ける。
スケーリングを実行する: レプリカ数を調整し(HPA/KEDA/Ray Serve)、続いて容量をプロビジョニングする(ASG/VMSS/MIG、Cluster Autoscaler)。
安定化する: stabilizationWindow やクールダウン、レート制限を適用してスラッシングを防ぐ。
事前ウォームアップ: ウォームプールを維持するか、日内変動やバーストに備えてスケジュール型/予測型スケーリングを行う。
観測して調整する: KPIとステージ別の寄与を監視し、シグナルやしきい値を定期的に見直す。

ベストプラクティス

ワークロードに適したシグナルを使う: GPUでのLLMサービングでは、CPU%よりp95レイテンシとキューの深さを優先する。

スケールアップ(速く積極的)とスケールダウン(遅く保守的)で別々のポリシーを設定し、安定化ウィンドウを設ける。

コールドスタートの重いモデルではワーカーを事前ウォームアップし、ウォームプールやスケジュール型・予測型スケーリングを使う。

オートスケーラーを重ねる: サービス層(HPA/KEDA/Ray Serve)+ クラスタ/VM層(Cluster Autoscaler/ASG/VMSS/MIG)。

レプリカ数の下限と上限、最大サージ/ドレインで制約し、Pod Disruption Budget と穏やかなドレインを用いる。

賢くバッチ化し(vLLM/TGI/Triton の動的バッチング)、リクエストあたりのトークン数を制限してテールレイテンシを安定させる。

ノードのサイズを適正化し、GPUをビンパッキングし、必要に応じてMIG/MPSを使い、リソースの断片化を避ける。

SLO駆動の目標を用い(例: p95 < 目標値を維持)、マルチテナントクラスタではテナントごとの公平性を監視する。

意思決定ログとランブックを整備し、本番前にバーストや障害モードをシミュレーションする。

使用を避けるべき場合

コールドスタートや再バランスが一切許容されない、超低レイテンシのハードリアルタイム経路。
シャーディングやスティッキールーティングの戦略がない、状態を持ちセッション親和性の高いワークロード。
ライセンスやクォータに制限され、レプリカを増やしてもスループットが上がらないサービス。
エラスティックな基盤リソースを持たない、エアギャップ環境や固定容量の環境。

よくある落とし穴

GPUバウンドの推論にCPU%を使うこと。代わりにキューのレイテンシ/深さとGPU使用率を選ぶ。
安定化ウィンドウやクールダウンの欠如と、上下対称なスケーリングポリシーによるスラッシング。
ウォームアップ時間、イメージのプル、大きなモデルのロード時間を無視すること → SLO違反の長期化。
最小容量やヘッドルームがなく、Cluster Autoscaler の遅延がポッドのオートスケーラーを飢餓状態にする。
リクエストのバッファリングやウォーマーなしにゼロまでスケールすること → 深刻なコールドスタートの代償。
平均値に頼りすぎること。p95/p99を目標にし、バースト的な到着に備える。

主な特徴

メトリクス駆動のオートスケーリング(レイテンシ、キューの深さ、使用率、エラー率)。

外部システムを介したイベントベースのスケーリング(KEDA: Kafka、SQS、Redis、Prometheus)。

日内変動や既知のイベントに対応する予測型・スケジュール型スケーリング。

多層スケーリング: サービス、ノード/VM、クラスタ容量の協調。

SLOを考慮したポリシーで、スケールアップとダウンの挙動を分け、安定化を行う。

コストとエネルギーを考慮した制約と予算、テナントごとのクォータ。

KPI / 成功指標

SLOに対するp50/p95/p99レイテンシ、キューの待ち時間、バースト時のエラー/タイムアウト。
スループット(RPS/TPS、トークン/秒)とスケーリングのレイテンシ(容量到達までの時間)。
成功リクエストあたりのコスト、インスタンス/GPU時間、過剰/不足プロビジョニング時間の割合。
オートスケーリングのイベント発生率と安定性(フラッピングがないこと)、飽和までの余裕。
マルチテナントクラスタにおけるテナントごとの公平性とクォータ遵守。

トークン / リソース使用量

シグナル: キューの深さ、p95レイテンシ、GPU使用率、リクエストの同時実行数、トークン予算。
制御: 動的バッチング、最大新規トークン数、プロンプト長の制限、ウォームプール。
効率化: KV/プレフィックスをキャッシュし、大規模モデルをシャーディングし、GPUをビンパッキングし、使用率の低い小さなポッドを避ける。

最適なユースケース

バースト的、日内変動的、またはキャンペーン起因のトラフィック(EC、ローンチ、ライブイベント)。
動的バッチングと厳格なレイテンシ/コストSLOを備えたGPU上のLLMサービング。
バックログの長さが明確なシグナルとなるイベント駆動処理(キュー/ストリーム)。
コスト管理、公平性、予測可能なSLOを必要とするマルチテナントプラットフォーム。