Auto Scaling
Auto Scalingは、ワークロードの需要に基づいて、コンピュートクラスタのCPUコア数を自動的に調整します。特にピーク時間や容量のニーズが予測困難な場合において、トラフィックパターンが変化するワークロードに有効です。
Auto Scalingが有効になっている場合、VeloDB CloudはCPUとメモリの使用率を監視し、推奨クラスタサイズを計算して、設定した最小・最大CPU制限の範囲内でクラスタをスケールします。これにより、トラフィックスパイク時には十分な容量を保ち、静穏時には未使用リソースを削減できます。
主要なユースケース:
- 予測不可能または急速に変化するトラフィックを持つワークロード
- CPUやメモリの圧迫に対して自動的な対応が必要なシステム
- 固定のスケーリングスケジュールではなく、柔軟なコスト制限を求めるチーム
Auto Scalingの有効化
コンピュートクラスタの作成またはプロビジョニング時に、Auto Scalingを有効にしてCPU制限を設定できます。
| パラメータ | 定義 | ベストプラクティス |
|---|---|---|
| Min CPU Cores | クラスタがスケールダウンできる最小CPU コア数 | ベースライントラフィックに必要な容量に設定します。通常4～16コアです。 |
| Max CPU Cores | クラスタがスケールアップできる最大CPUコア数 | ピークトラフィック時に許可する最大容量とコスト制限に設定します。 |
推奨値がこれらの制限の範囲外になった場合、VeloDB Cloudは最も近い設定制限に調整します。クラスタはMin CPU Coresを下回ったり、Max CPU Coresを上回ったりすることは決してありません。
適用条件
Auto Scalingは、以下の条件がすべて満たされた場合にのみ適用されます:
| 項目 | 要件 |
|---|---|
| クラスタタイプ | Compute Cluster |
| 課金モデル | Post-paid (Pay-as-you-go) |
| クラスタステータス | Running |
| 設定 | Auto Scaling有効 |
注意: Subscription（前払い）クラスタと、サスペンドまたは停止状態のクラスタは、Auto Scalingの評価対象から除外されます。
Auto Scalingの仕組み
VeloDB Cloudは、定期的にリソース使用状況をチェックするバックグラウンド推奨エンジンを実行します。このエンジンは目標クラスタサイズを計算し、それを最も近いサポートされているコンピュートティアにマッピングして、使用率が閾値を超えた際にクラスタをスケールします。
デュアルウィンドウ解析
高速な応答性と安定性のバランスを取るため、VeloDB Cloudは2つの時間ウィンドウでメトリクスを評価します:
- 短時間ウィンドウ（デフォルト3時間）: 突然のトラフィック変化を捉え、トラフィック減少後にクラスタを迅速にスケールダウンできます。
- 長時間ウィンドウ（デフォルト30時間）: より大きな日次ピークを捉えて、多くの小さなティアを段階的に経由することなく、適切なティアにクラスタをスケールアップできます。
各ウィンドウはそれぞれ独自の推奨を生成します：スケールアップ、スケールダウン、または現在のサイズを維持。エンジンはこれらの推奨を1つのスケーリング決定に統合します。
ターゲット追跡とウォーターマーク
エンジンはリソース使用率を低・高ウォーターマークと比較します。高ウォーターマークを超える使用率はスケールアップをトリガーします。低ウォーターマークを下回る使用率はスケールダウンをトリガーします。2つのウォーターマーク間の使用率では、クラスタは現在のサイズを維持します。
| リソース項目 | 低ウォーターマーク | 高ウォーターマーク | 目標使用率 |
|---|---|---|---|
| CPU | 37.5% | 75% | ~53% |
| Memory | 40% | 80% | ~57% |
目標使用率は低・高ウォーターマークの幾何平均です。これにより、同じワークロードを同じクラスタティアにマッピングし直すことができ、繰り返される上向きドリフトを防ぎ、プロビジョニング不足を回避できます。
独立したリソース評価
CPUとメモリは独立して評価されます。VeloDB Cloudは2つのメトリクスから計算されたより大きな目標サイズを選択します。結果として、メモリ集約的なワークロードはCPU使用率が低いだけではスケールダウンされず、CPU集約的なワークロードはメモリ使用率が安定していてもスケールアップできます。
スケーリングトリガー：例
例1（スケールアップ）: 16コアクラスタが短時間ウィンドウ中にCPU負荷ピーク14コアに達した場合。
- 使用率 = 14 / 16 ≈ 87.5%、75%の高ウォーターマークを上回る → スケールアップ
- 推奨サイズ ≈ ⌈14 / 0.53⌉ ≈ 27コア → 最も近い有効なティアに切り上げ: 32コア
例2（スケールダウン）: 同じ16コアクラスタが短時間ウィンドウ中に持続ピーク5コアのみの場合。
- 使用率 = 5 / 16 ≈ 31%、37.5%の低ウォーターマークを下回る → スケールダウン
- 推奨サイズ ≈ ⌈5 / 0.53⌉ ≈ 10コア → 最も近い有効なティアに切り下げ: 8コア
サポートされているコンピュートティア
クラスタは任意のコア数ではなく、事前定義されたCPUティア間でスケールします。有効なティアは以下の通りです:
4, 8, 16, 32, 48, 64, 80, 96, 128, 160, 192, ... (Tiers above 80 cores scale in increments of 32)
計算されたターゲットは最も近い有効なtierに丸められます。推奨値が2つのtierの間にちょうど位置する場合、VeloDB Cloudはより大きなtierを選択します。設定したMin CPU CoresとMax CPU Coresの値も、これらのtierに整列されます。
Flapping & Jitter Protection
不安定なトラフィックによって引き起こされる頻繁な前後のスケーリングを意味する「flapping」を防ぐため、エンジンはいくつかの安全制御を使用します。
Cooldown Periods
成功したスケーリングイベントの後、エンジンは次のスケーリング変更を行う前に15分のcooldown periodを待機します。新しくプロビジョニングされた、または再起動されたクラスターも、Auto Scalingの対象になる前に15分のwarm-upウィンドウがあります。
Window Conflict Resolution
短いウィンドウと長いウィンドウが異なるスケーリング方向を推奨する場合、エンジンは短いウィンドウのトレンドをチェックします：
- 短いウィンドウのトレンドが上向きの場合、トラフィックが増加しています。エンジンは長いウィンドウを優先し、スケールアップします。
- 短いウィンドウのトレンドがフラットまたは下向きの場合、トラフィックが緩和されています。エンジンは短いウィンドウを優先し、スケールダウンします。
これにより、クラスターは受信トラフィックスパイクに応答しながら、小さなトラフィック変動時の不要なスケーリングを回避できます。
Monitoring Scaling History
すべてのAuto ScalingアクションはActivity Logsに記録されます。各エントリには、タイムスタンプ、スケーリング方向、および変更前後のクラスターサイズが含まれます。
- パス: Console Left Navigation -> Organization -> Activity Logs
Auto Scalingの制限を変更した後、これらのログを確認して、スケーリング頻度とクラスターサイズが期待に合致するかチェックしてください。
FAQ
Q: Auto Scalingを有効にしましたが、クラスターサイズが変わらないのはなぜですか？
これは通常、以下のいずれかの要因によって引き起こされます：
- Cooldown Active: クラスターがスケーリング、作成、または再起動されてから15分未満です。
- Not Enough Metrics: 短いウィンドウに十分なメトリクスがありません。これは新しいクラスターでよくあることです。
- Stable Utilization: 現在のメトリクスが最適なターゲット範囲内にあります（CPU: 37.5%-75%、Memory: 40%-80%）。
- Already at the Target Tier: 計算されたターゲットが現在のクラスターサイズと一致しています。
- Not Eligible: クラスターが基本要件を満たしていません。例えば、Running状態ではありません。
Q: scale-up時間を短縮するために15分のcooldownを無効にできますか？
いいえ。cooldownは繰り返されるスケーリングループとリソースの不安定性を防ぐシステムガードレールです。製品ローンチやフラッシュセールなど、大きなスケジュールされたトラフィックスパイクを予想する場合は、事前にMin CPU Coresを増やし、イベント後に下げてください。
Q: scale-downイベントによってクラスターがゼロまで縮小され、ワークロードが終了されることはありますか？
いいえ。クラスターは設定されたMin CPU Coresを下回ることはありません。VeloDB Cloudはクラスターを利用可能に保つために、最小4コアも強制します。
Q: 暴走スケーリングによってコストが超過するリスクはありますか？
いいえ。エンジンは常にMax CPU Coresの制限を尊重します。VeloDB Cloudはクラスターあたり2048コアのプラットフォーム制限も強制します。
Best Practices
- Min CPU Coresをベースライントラフィックに合わせる: この値が低すぎると、突然のスパイクでクラスターが適切なサイズに達するまでに複数のスケーリングイベントが必要になる可能性があります。高すぎると、静かな期間中の節約を失う可能性があります。
- Max CPU Coresに十分な余裕を提供する: クラスターが突然のサージを処理できるよう、最大値を予想されるピークトラフィックの約1.5-2倍に設定してください。
- 予測可能なサイクルにはScheduled Scalingを使用する: ワークロードに明確な日次ピーク期間がある場合、scheduled scalingは動的なAuto Scalingよりも管理が容易になる可能性があります。
- 重要なイベント前にクラスターをpre-warmする: 重要なローンチ、キャンペーン、またはマイグレーションの前に、Min CPU Coresを事前に増やし、イベント後に復元してください。
- Activity Logsを定期的に確認する: スケーリング履歴を使用して、最小および最大CPU制限を微調整してください。