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 |
| 課金モデル | 後払い（従量課金） |
| クラスターステータス | 実行中 |
| 設定 | Auto Scaling有効 |
注記： サブスクリプション（前払い）クラスターおよび中断または停止されたクラスターはAuto Scaling評価から除外されます。
Auto Scalingの動作原理
VeloDB Cloudは定期的にリソース使用量をチェックするバックグラウンド推奨エンジンを実行します。エンジンは目標クラスターサイズを算出し、最も近いサポートされたコンピュートティアにマッピングし、使用量が閾値を超えた時にクラスターをスケールします。
デュアルウィンドウ分析
高速応答と安定性のバランスを取るため、VeloDB Cloudは2つの時間ウィンドウでメトリクスを評価します：
- ショートウィンドウ（デフォルト3時間）： 突然のトラフィック変化を捕捉し、トラフィック低下後にクラスターを迅速にスケールダウンできるようにします。
- ロングウィンドウ（デフォルト30時間）： より大きな日次ピークを捕捉し、多くの小さなティアを段階的に経ることなく適切なティアにスケールアップできるようにします。
各ウィンドウは独自の推奨を生成します：スケールアップ、スケールダウン、または現在のサイズの維持。エンジンはこれらの推奨を一つのスケーリング決定に統合します。
ターゲット追跡とウォーターマーク
エンジンはリソース使用量を低位および高位ウォーターマークと比較します。高位ウォーターマークを上回る使用量はスケールアップをトリガーします。低位ウォーターマークを下回る使用量はスケールダウンをトリガーします。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)
計算されたターゲットは最も近い有効な階層に丸められます。推奨値が2つの階層のちょうど中間にある場合、VeloDB Cloudはより大きい階層を選択します。設定したMin CPU CoresとMax CPU Coresの値も、これらの階層に合わせて調整されます。
フラッピングとジッター保護
不安定なトラフィックによって頻繁に前後にスケーリングが発生する「フラッピング」を防ぐために、エンジンはいくつかの安全制御を使用します。
クールダウン期間
スケーリングイベントの成功後、エンジンは次のスケーリング変更を行う前に15分のクールダウン期間を待機します。新しくプロビジョニングまたは再起動されたクラスタも、Auto Scalingの対象となる前に15分のウォームアップウィンドウを持ちます。
ウィンドウ競合解決
短いウィンドウと長いウィンドウが異なるスケーリング方向を推奨する場合、エンジンは短いウィンドウのトレンドをチェックします：
- 短いウィンドウのトレンドが上昇している場合、トラフィックが増加しています。エンジンは長いウィンドウを優先し、スケールアップします。
- 短いウィンドウのトレンドが平坦または下降している場合、トラフィックが緩和されています。エンジンは短いウィンドウを優先し、スケールダウンします。
これにより、クラスタは入ってくるトラフィックスパイクに応答しながら、小さなトラフィック変化での不要なスケーリングを避けることができます。
スケーリング履歴の監視
すべてのAuto ScalingアクションはActivity Logsに記録されます。各エントリには、タイムスタンプ、スケーリング方向、および変更前後のクラスタサイズが含まれます。
- パス: Console Left Navigation -> Organization -> Activity Logs
Auto Scalingの制限を変更した後、これらのログを確認して、スケーリング頻度とクラスタサイズが期待に合致するかをチェックしてください。
FAQ
Q: Auto Scalingを有効にしましたが、クラスタサイズが変わりません。なぜですか？
これは通常、以下の要因のいずれかが原因です：
- クールダウンアクティブ: クラスタが15分未満前にスケールされ、作成され、または再起動されました。
- 十分なメトリクスがない: 短いウィンドウに十分なメトリクスがありません。これは新しいクラスタでよくあることです。
- 安定した使用率: 現在のメトリクスが最適なターゲット範囲内にあります（CPU: 37.5%-75%、Memory: 40%-80%）。
- すでにターゲット階層にある: 計算されたターゲットが現在のクラスタサイズと一致しています。
- 対象外: クラスタが基本要件を満たしていません。例えば、Running状態にありません。
Q: スケールアップ時間を短縮するために15分のクールダウンを無効にできますか？
いいえ。クールダウンは繰り返しスケーリングループとリソースの不安定性を防ぐシステムガードレールです。製品発表やフラッシュセールなど、大規模でスケジュールされたトラフィックスパイクを予期する場合は、事前にMin CPU Coresを増やし、イベント後に下げてください。
Q: スケールダウンイベントでクラスタがゼロに縮小され、ワークロードが終了しますか？
いいえ。クラスタは設定されたMin CPU Coresを下回ることはありません。VeloDB Cloudはクラスタを利用可能に保つために最低4コアも強制します。
Q: 暴走スケーリングによってコストオーバーランが発生するリスクはありますか？
いいえ。エンジンは常にMax CPU Cores制限を尊重します。VeloDB Cloudはクラスタあたり2048コアのプラットフォーム制限も強制します。
ベストプラクティス
- Min CPU Coresをベースライントラフィックに合わせる: この値が低すぎると、突然のスパイクでクラスタが適切なサイズに達するまでに複数のスケーリングイベントが必要になる場合があります。高すぎると、静かな期間中に節約を失う可能性があります。
- Max CPU Coresに十分な余裕を提供する: 最大値を予想されるピークトラフィックの約1.5-2倍に設定し、クラスタが突然のサージを処理できるようにします。
- 予測可能なサイクルにはScheduled Scalingを使用する: ワークロードに明確な日次ピーク期間がある場合、scheduled scalingは動的Auto Scalingよりも管理が簡単な場合があります。
- 重要なイベント前にクラスタを事前ウォームアップする: 重要な発表、キャンペーン、または移行の前に、事前にMin CPU Coresを増やし、イベント後に復元します。
- Activity Logsを定期的に確認する: スケーリング履歴を使用して、最小および最大CPU制限を微調整します。