managing-cluster-capacity

クラスター容量の管理

すべての CockroachDB デプロイ層にわたってクラスター容量を管理します。「容量」の意味は層によって異なります。Self-Hosted では個々のノードを管理し、Advanced／BYOC ではノード数とマシンサイズを管理し、Standard ではプロビジョニング済み vCPU を管理し、Basic ではコスト制御を行いながら自動スケーリングします。

このスキルを使用するタイミング

• クラスターからノードを恒久的に削除する場合（Self-Hosted）
• 容量を増やすためにノードを追加する場合（Self-Hosted）
• クラスターノード数またはマシンサイズをスケーリングする場合（Advanced、BYOC）
• プロビジョニング済みコンピューティングを調整する場合（Standard）
• サーバーレスクラスターのコストを管理する場合（Basic）
• ハードウェアを交換する場合、またはインフラストラクチャを移行する場合（Self-Hosted、BYOC）
• 障害が発生したノード、または停止したノードを交換する場合（Self-Hosted）
• ストレージ使用率とディスク圧迫を管理する場合（Self-Hosted）

一時的なメンテナンス（容量の変更ではない場合）には： performing-cluster-maintenance を使用してください。 操作前のヘルスチェックには： reviewing-cluster-health を使用してください。

---

ステップ 1：コンテキストの収集

必要なコンテキスト

質問	選択肢	重要な理由
デプロイ層は？	Self-Hosted、Advanced、BYOC、Standard、Basic	層ごとに容量モデルが異なります
どちらの方向に変更しますか？	スケールアップ（容量を追加）、スケールダウン（容量を削減）	手順を決定します

追加のコンテキスト（層別）

Self-Hosted の場合（スケールダウン）：

質問	選択肢	重要な理由
削除するノード数は？	1、複数	複数ノードのデコミッションは同時に実施する必要があります
対象ノード ID は？	cockroach node status のノード ID	CLI コマンドに必要です
ノードは稼働中ですか、それとも停止していますか？	稼働中、停止	停止したノードには異なる手順を使用します
デプロイプラットフォームは？	ベアメタル、VM、Kubernetes	CLI とクリーンアップの手順が変わります
現在のレプリケーション係数は？	3、5、カスタム	残すノード数が十分である必要があります
現在のノード数は？	数値	残存する容量を検証します
ストレージ使用率は？	低（60% 未満）、中（60～80%）、高（80% 超）	緊急度とストレージメンテナンスが必要かどうかを判断します

Advanced または BYOC の場合：

質問	選択肢	重要な理由
スケーリング方法は？	Cloud Console、API、Terraform	手順を決定します
現在の構成と目標の構成は？	例：5 ノード → 3 ノード、または 4 vCPU → 8 vCPU	制約を検証します
クラウドプロバイダーは？（BYOC のみ）	AWS、GCP、Azure	インフラストラクチャの検証に影響します

Standard の場合：

質問	選択肢	重要な理由
現在のプロビジョニング済み vCPU 数は？	数値	スケーリング判断の参考になります
目標の vCPU 数は？	数値	ワークロードが収まるかを検証します

Basic の場合： コスト管理の目標を収集します。Basic は手動で容量を制御せずに自動スケーリングします。

コンテキストに基づくルーティング

層	移動先
Self-Hosted	Self-Hosted の容量管理
Advanced	Advanced のスケーリング
BYOC	BYOC のスケーリング
Standard	Standard のコンピューティング管理
Basic	Basic のコスト管理

---

Self-Hosted の容量管理

適用条件： Tier = Self-Hosted

スケールダウン：ノードのデコミッション

デコミッション前の検証

# All nodes live, version-consistent, with replication and per-node range counts
cockroach node status --decommission --certs-dir=<certs-dir> --host=<any-live-node>

出力を確認し、次の点を検査します。

• すべてのノードで is_live = true であること
• すべての箇所で ranges_underreplicated が 0 であること（すべてのレンジが完全にレプリケートされていること）

-- Replication factor (and other zone-level settings)
SHOW ZONE CONFIGURATION FOR RANGE default;

ノードごとのストレージ容量を確認するには（デコミッションしたノードのデータを吸収した後も、残るノードの使用率が 60% を超えないことを検証できます）、DB Console の Overview → Storage ページを使用するか、Prometheus メトリクスエンドポイントからデータをスクレイピングします。

curl -ks https://<node>:8080/_status/vars | grep '^capacity'

デコミッション後のノード数は、ゾーンの num_replicas 以上である必要があります。

ノードが稼働中の場合：ドレインしてからデコミッション

# Step 1: Drain
cockroach node drain <node_id> --certs-dir=<certs-dir> --host=<any-live-node>

# Step 2: Decommission (single node)
cockroach node decommission <node_id> --certs-dir=<certs-dir> --host=<any-live-node>

# Step 2: Decommission (multiple nodes — more efficient, do simultaneously)
cockroach node decommission <id_1> <id_2> <id_3> --certs-dir=<certs-dir> --host=<any-live-node>

ノードが停止した場合：停止したノードを置き換える

ノードが server.time_until_store_dead（デフォルトは 5m）を超えて停止している場合、CockroachDB はそのデータを稼働中のノードに自動的に再レプリケーションします。以下の手順で停止したノードをクリーンアップし、必要に応じて置き換えノードを追加します。

ステップ 1：ノードが停止しており、データが安全であることを確認する

# Confirm the dead node and verify replication has caught up
cockroach node status --decommission --certs-dir=<certs-dir> --host=<any-live-node>

出力で、停止したノードの is_live = false と、稼働中のすべてのノードの ranges_underreplicated = 0 を確認します。稼働中のノードのストアごとの容量は、DB Console の Overview → Storage ページで確認します。

レプリケーション不足のレンジがある場合は、再レプリケーションが完了するまで待ってから次に進みます。

ステップ 2：停止したノードをデコミッションする（メタデータのクリーンアップ）

cockroach node decommission <dead_node_id> --certs-dir=<certs-dir> --host=<any-live-node>

ステップ 3：置き換えノードを追加する（推奨）

残りのノードの使用率が 60% を超えている場合は、スケールアップ：ノードの追加の手順に従って置き換えノードをプロビジョニングします。

複数のノードが停止している場合： 停止したノードをすべて同時にデコミッションします。

cockroach node decommission <id_1> <id_2> --certs-dir=<certs-dir> --host=<any-live-node>

詳細な障害シナリオと復旧手順については、停止したノードの置き換えに関するリファレンスを参照してください。

デコミッションの進行状況を監視する

cockroach node status --decommission --certs-dir=<certs-dir> --host=<any-live-node>

gossiped_replicas = 0 および membership = 'decommissioned' になるまで待ちます。その後、デコミッションしたノード上のプロセスを停止します。

デコミッションをキャンセルする

cockroach node recommission <node_id> --certs-dir=<certs-dir> --host=<any-live-node>

decommissioning 状態の間のみ有効です。

スケールアップ：ノードの追加

1. 既存ノードと同じ仕様の新しいハードウェア／VMをプロビジョニングします
2. 同じバージョンの CockroachDB をインストールします（cockroach version で確認します）
3. 既存のクラスター内ノードを指定する --join を付けてノードを起動します
4. ノードの参加を確認し、リバランスを監視します。

   cockroach node status --certs-dir=<certs-dir> --host=<any-live-node>
   

   新しいノードが出力に is_live = true として表示されます。新しいノードにデータがリバランスされるにつれて、ranges 列の値が増加します。

スケール後の検証

cockroach node status --decommission --certs-dir=<certs-dir> --host=<any-live-node>

すべてのノードで ranges_underreplicated = 0 となり、ノード間で ranges の数が均等になっていることを確認します。ストアごとの容量使用率は、DB Console の Overview → Storage ページで確認します。

---

高度なスケーリング

対象： Tier = Advanced

Advanced クラスターは Cockroach Labs によって管理されます。ノード数またはマシンサイズを変更して容量を調整します。

Cloud Console を使用する場合

1. Cluster → Capacity
2. ノード数またはマシンタイプ（ノードあたりの vCPU 数）を調整します
3. CRL がすべてのノード操作（ドレイン、デコミッション、プロビジョニング）を安全に処理します
4. Cloud Console で進行状況を監視します

Cloud API を使用する場合

# Scale node count
curl -X PATCH -H "Authorization: Bearer $COCKROACH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"config": {"num_nodes": <new_count>}}' \
  "https://cockroachlabs.cloud/api/v1/clusters/<cluster-id>"

Terraform を使用する場合

resource "cockroach_cluster" "example" {
  dedicated {
    num_virtual_cpus = 8     # vCPUs per node
    storage_gib      = 150
    num_nodes        = 5     # total nodes
  }
}

スケーリング前の確認

-- Ensure no disruptive jobs are running before scaling down
WITH j AS (SHOW JOBS)
SELECT job_type, status, COUNT(*) FROM j WHERE status = 'running' GROUP BY 1, 2;

制約

• 最小構成： 3 ノード x 4 vCPU（合計 12 vCPU）
• スケールダウン： データが残りのノードに収まる必要があります。ゾーン設定の要件も満たす必要があります
• スケールアップ： プランの上限内で追加のノードを利用できます

---

BYOC のスケーリング

対象： Tier = BYOC

高度なスケーリングの手順をすべて実行します。BYOC のスケーリングは、同じ Cloud Console／API／Terraform インターフェースを通じて管理されます。

クラウドプロバイダーでの確認（スケールダウン後）

AWS の場合：

aws ec2 describe-instances --filters "Name=tag:cockroach-cluster,Values=<cluster-name>" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name}'

GCP の場合：

gcloud compute instances list --filter="labels.cockroach-cluster=<cluster-name>"

Azure の場合：

az vm list --resource-group <rg> --query "[?tags.cockroachCluster=='<name>']"

BYOC に関する追加の考慮事項

• スケーリング後にセキュリティグループ／ファイアウォールルールを確認します
• リザーブドインスタンスまたはコミットメント利用割引の割り当てを更新します
• ネットワーク接続（PrivateLink／PSC／VPC ピアリング）に影響がないことを確認します
• クラウドの請求に新しいインスタンス数が反映されていることを確認します

---

Standard のコンピューティング管理

対象： Tier = Standard

Standard はマルチテナント型のマネージドサービスです。個別のノードはありません。プロビジョニング済みのコンピューティング（vCPU）を調整して容量を管理します。

プロビジョニング済み vCPU を調整する

1. Cloud Console → Cluster → Capacity
2. プロビジョニング済み vCPU を増減します
3. ダウンタイムなしで変更が有効になります

スケールダウンの前に

• Cloud Console で CPU 使用率を確認し、削減後のコンピューティング容量でワークロードを処理できることを確認します
• ストレージは使用量に応じて課金され、コンピューティングの変更による影響はありません

スケーリング後

Cloud Console で P99 レイテンシと QPS を 24～48 時間監視します。スケールダウン後にレイテンシが増加した場合は、コンピューティングを再びスケールアップします。

---

基本的なコスト管理

適用条件： Tier = Basic

Basic は自動スケーリングを行うサーバーレスサービスです。管理が必要なノードやプロビジョニング済みコンピューティングはありません。容量は需要に応じて自動的にスケーリングされます。コストは支出制御を通じて管理します。

支出の管理

• 支出上限を設定する： Cloud Console → Cluster → Settings → 月間支出上限を設定します
• 使用状況を確認する： Cloud Console で Request Unit（RU）の消費量を時系列で確認できます
• クエリを最適化する： クエリのチューニングとインデックス作成によって RU の消費量を削減します
• データをアーカイブする： 未使用のテーブルまたはデータベースを削除して、ストレージコストを削減します

アップグレードを検討するタイミング

コンピューティング容量（保証された vCPU）を明示的に制御する必要がある場合は、Standard へのアップグレードを検討してください。専用インフラストラクチャが必要な場合は、Advanced を検討してください。

---

安全に関する考慮事項

操作	Tier	元に戻せるか？
cockroach node decommission	SH	完了前に限り、再参加させることができます
デコミッション済みノードの停止	SH	いいえ（新しいノードとして再参加させる必要があります）
クラスターへのノード追加	SH	はい（削除するにはデコミッションします）
Console/API によるスケーリング	ADV/BYOC	元に戻すにはサポートにお問い合わせください
プロビジョニング済み vCPU の調整	STD	はい（スケールバックできます）
支出上限の設定	BAS	はい（いつでも調整できます）

重要（セルフホスト）：

• レプリケーション係数を下回るまでデコミッションしないでください
• （稼働中のノードでは）デコミッションの前に必ずドレインしてください
• 複数のノードを同時にデコミッションしてください（順番に行わないでください）
• 残りの容量でデータを受け入れられることを確認してください
• 停止したノードの場合：デコミッションする前に再レプリケーションが完了するまで待ってください
• ストレージ使用率を監視してください。80% を超えるノードではパフォーマンスが低下するリスクがあります

トラブルシューティング

問題	Tier	対処方法
デコミッションが停止する	SH	ゾーン設定の制約を確認し、停滞しているレンジを調査します
再参加に失敗する	SH	ノードはすでに完全にデコミッションされています。新しいノードとして再参加させる必要があります
新しいノードでリバランスが行われない	SH	自動リバランスを待ち、range_count を確認します
スケールダウンが拒否される	ADV/BYOC	最小値を下回っているか、データが収まりません
縮小後にレイテンシが急増する	STD	プロビジョニング済み vCPU を再びスケールアップします
クラウドインスタンスがクリーンアップされない	BYOC	サポートにお問い合わせください。クラウドコンソールで確認します
停止したノードで再レプリケーションが行われない	SH	server.time_until_store_dead を確認し、稼働中のノードに容量があることを確認します
スケールダウン後にストレージ使用率が高い	SH	代替ノードを追加するか、ディスクサイズを増やします

参考資料

スキルの参考資料：

• 障害が発生したノードの置き換え
• ストレージ管理

関連スキル：

• クラスターの健全性の確認 — 変更前後の健全性チェック
• クラスターのメンテナンスの実施 — ドレイン手順（SH）
• クラスターのバージョンアップグレード — アップグレードとライフサイクル

CockroachDB 公式ドキュメント：

• cockroach node decommission
• ノードのシャットダウン
• Advanced クラスターの管理
• Standard クラスターの管理
• Cloud API