メインコンテンツへスキップ

​
はじめに

データベースリソースのオートスケーリングでは、慎重なバランスが求められます。スケールアップが遅すぎるとパフォーマンス低下のリスクがある一方、スケールダウンを積極的に行いすぎると、スケーリングが絶えず揺れ動く状態を引き起こしかねません。 ClickHouse Cloud は、2 つのウィンドウを用いた推奨フレームワークと、CPU のターゲット追跡型推奨システムを組み合わせることで、本番データベースに必要な安定性を維持しながら、より高速なスケールダウン、スケーリングの揺れの最小化、そして変動するワークロードにおけるインフラストラクチャコストの大幅な削減を実現します。

​
CPU ベースのスケーリング

CPU スケーリングはターゲットトラッキングに基づいており、使用率を目標レベルに維持するために必要な CPU 割り当てを正確に算出します。スケーリング アクションがトリガーされるのは、現在の CPU 使用率が定義された範囲を外れた場合のみです。 レコメンダーは過去の使用状況に基づいて CPU 使用率を評価し、次の式を使用して推奨 CPU サイズを決定します。
CPU 使用率が割り当て容量の 37.5%～75% の範囲内であれば、スケーリングは行われません。この範囲を外れた場合、レコメンダーが使用率を 53% に戻すのに必要な正確なサイズを算出し、それに応じてサービスがスケーリングされます。

​
例

4 vCPU が割り当てられたサービスで、使用量が 3.8 vCPU (使用率約 95%) まで急増し、75% の高水位を超えたとします。 レコメンダーは 3.8 / 0.53 ≈ 7.2 vCPU と計算し、次に大きい利用可能なサイズ (8 vCPU) に切り上げます。負荷が落ち着き、使用量が 37.5% (1.5 vCPU) を下回ると、レコメンダーはそれに応じて比例してスケールダウンします。

​
メモリ使用量に基づく推奨事項

ClickHouse Cloud は、サービスの実際の使用パターンに基づいて、適切なメモリサイズを自動的に推奨します。 レコメンダーはルックバックウィンドウ内の使用状況を分析し、急増に対応してメモリ不足 (OOM) エラーを防げるよう、ヘッドルームを加味します。 レコメンダーは次の 3 つの指標を確認します。
  • クエリメモリ: クエリ実行中に使用された最大メモリ量
  • 常駐メモリ: プロセス全体で保持された最大メモリ量
  • OOM イベント: クエリまたはレプリカで最近メモリ不足が発生したかどうか

​
ヘッドルームの計算方法

クエリメモリと常駐メモリでは、追加されるヘッドルームの量は使用状況の予測しやすさに応じて決まります。
  • 安定した使用状況 (変動が小さい) : 1.25 倍 — 使用状況が安定しており、予期しない急増が起こりにくいため、ヘッドルームを多めに確保します
  • スパイクしやすい使用状況 (変動が大きい) : 1.1 倍 — もともと変動幅の大きいワークロードに対して過剰なプロビジョニングを避けるため、ヘッドルームは少なめになります
OOM イベントが検出された場合、サービスが回復に必要なメモリを十分に確保できるよう、レコメンダーはより強めの 1.5 倍 の乗数を適用します。

​
最終的な推奨事項

システムは、すべてのシグナルのうち最も高い値を採用します。

​
Two-window recommender

ClickHouse Cloud では、単一のウィンドウではなく、時間範囲の異なる 2 つのルックバックウィンドウを使用します。
  • Small Window (3 hours): 直近の使用傾向を捉え、より迅速なスケールダウンを可能にします
  • Large Window (30 hours): 複数回に分けて段階的にスケールアップするのではなく、より長いルックバックウィンドウ内で観測された最大使用量まで 1 回でスケールアップできるようにします。これは、スケーリングには時間がかかり、ローカル cache も無効化されるため重要です。そのため、1 回でスケールアップするほうが安全です。
各ウィンドウは、メモリと CPU の両方を分析し、それぞれ独立して推奨値を生成します。 その後、以下の図に示すように、各ウィンドウが示すスケーリングの方向に基づいて、システムがこれらの推奨値を統合します。 レコメンダーの設計上の判断について詳しくは、“Smarter Auto-Scaling for ClickHouse: The Two-Window Approach ” を参照してください。
最終更新日 2026年6月12日