このトピックでは、Cassandra の水平方向のスケールアップと垂直方向のスケールアップを行う方法、Cassandra をスケールダウンする方法について説明します。
Cassandra の水平方向のスケーリング
Cassandra を水平方向にスケールアップするには
- Cassandra をスケーリングする前に、必要に応じて追加の容量を
apigee-data
ノードプールに設定してください。専用ノードプールの構成もご覧ください。 - オーバーライド ファイルで
cassandra.replicaCount
構成プロパティの値を設定します。replicaCount
の値は3
の倍数にする必要があります。必要なreplicaCount
値を決定するには、次の点を考慮してください。- プロキシのトラフィック需要を見積もる。
- 負荷テストを行い、CPU 使用率を合理的な範囲で予測する。
- リージョンごとに異なる
replicaCount
値を指定できる。 replicaCount
は後からオーバーライド ファイルで拡張できる。
このプロパティの詳細については、構成プロパティのリファレンスをご覧ください。ランタイム プレーン コンポーネントの管理もご覧ください。
- 変更を適用します。次に例を示します。
helm upgrade datastore apigee-datastore/ \ --namespace APIGEE_NAMESPACE \ --atomic \ -f OVERRIDES_FILE.yaml
Cassandra の垂直方向のスケーリング
このセクションでは、より高い CPU とメモリ要件に対応するように Cassandra Pod を垂直方向にスケーリングする方法について説明します。
概要
Apigee ハイブリッドの本番環境デプロイでは、個別のノードプールを少なくとも 2 つ作成することをおすすめします。1 つはステートフル サービス(Cassandra)用で、もう 1 つは、ステートレス サービス(ランタイム)用です。詳しくは、GKE 本番環境クラスタの要件をご覧ください。
ステートフルな Cassandra ノードプールの場合、最初は 8 つの CPU コアと 30 GB のメモリを使用することをおすすめします。ノードプールがプロビジョニングされると、これらの設定を変更することはできません。本番環境用に Cassandra を構成するもご覧ください。
Cassandra Pod をスケールアップして、より高い CPU とメモリの要件を満たす必要がある場合は、このトピックで説明されている手順を行ってください。
Cassandra Pod のスケールアップ
Cassandra に使用するステートフル ノードプールの CPU とメモリを増やす手順は次のとおりです。
- Kubernetes のプラットフォームの指示に沿って、クラスタに新しいノードプールを追加します。対応プラットフォームについては、インストール手順をご覧ください。
- 新しいノードプールの準備ができていることを確認します。
kubectl get nodes -l NODE_POOL_LABEL_NAME=NODE_POOL_LABEL_VALUE
コマンドの例:
kubectl get nodes -l cloud.google.com/gke-nodepool=apigee-data-new
出力例:
NAME STATUS ROLES AGE VERSION gke-apigee-data-new-441387c2-2h5n Ready <none> 4m28s v1.14.10-gke.17 gke-apigee-data-new-441387c2-6941 Ready <none> 4m28s v1.14.10-gke.17 gke-apigee-data-new-441387c2-nhgc Ready <none> 4m29s v1.14.10-gke.17
- Cassandra 用の新しいノードプールを使用するためにオーバーライド ファイルを更新し、希望する量に増やした CPU 数とメモリサイズに Pod リソースを更新します。たとえば、GKE クラスタの場合は、次のような構成を使用します。別の Kubernetes プラットフォームを使用している場合は、適宜
apigeeData.key
値を調整する必要があります。nodeSelector: requiredForScheduling: true apigeeData: key: "NODE_POOL_LABEL_NAME" value: "NODE_POOL_LABEL_VALUE" cassandra: resources: requests: cpu: NODE_POOL_CPU_NUMBER memory: NODE_POOL_MEMORY_SIZE
次に例を示します。
nodeSelector: requiredForScheduling: true apigeeData: key: "cloud.google.com/gke-nodepool" value: "apigee-data-new" cassandra: resources: requests: cpu: 14 memory: 16Gi
- オーバーライド ファイルをクラスタに適用します。
helm upgrade datastore apigee-datastore/ \ --namespace APIGEE_NAMESPACE \ --atomic \ -f OVERRIDES_FILE.yaml
この手順を完了すると、Cassandra Pod が新しいノードプールに徐々に切り替わります。
Cassandra のスケールダウン
Apigee ハイブリッドは、Cassandra ノードのリングを StatefulSet として使用します。Cassandra は、ランタイム プレーンの特定の Apigee エンティティに永続ストレージを提供します。Cassandra の詳細については、ランタイム プレーンについてをご覧ください。
Cassandra はリソースを大量に消費するサービスで、他のハイブリッド サービスのある Pod では使用できません。負荷に応じて、クラスタのリング内にある Cassandra ノードの数をスケーリングする必要があります。
Cassandra リングをスケールダウンする一般的な方法は次のとおりです。
- Cassandra クラスタが正常で、スケールダウンをサポートするのに十分なストレージがあることを確認します。
overrides.yaml
のcassandra.replicaCount
プロパティを更新します。- 構成の更新を適用します。
- クラスタ構成に応じて、永続ボリュームのクレームまたはボリュームを削除します。
注意事項
- 停止するノード以外のノードが正常な状態でない場合は、処理を続行しないでください。Kubernetes でクラスタから Pod をスケールダウンすることはできません。
- スケールダウンまたはスケールアップは 3 ノード単位で行ってください。
Cassandra をスケールダウンする
- 次の例のように、クラスタが正常で、すべてのノードが稼働していることを確認します。
kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra
NAME READY STATUS RESTARTS AGE apigee-cassandra-default-0 1/1 Running 0 2h apigee-cassandra-default-1 1/1 Running 0 2h apigee-cassandra-default-2 1/1 Running 0 2h apigee-cassandra-default-3 1/1 Running 0 16m apigee-cassandra-default-4 1/1 Running 0 14m apigee-cassandra-default-5 1/1 Running 0 13m apigee-cassandra-default-6 1/1 Running 0 9m apigee-cassandra-default-7 1/1 Running 0 9m apigee-cassandra-default-8 1/1 Running 0 8m
==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.16.2.6 690.17 KiB 256 48.8% b02089d1-0521-42e1-bbed-900656a58b68 ra-1 UN 10.16.4.6 705.55 KiB 256 51.6% dc6b7faf-6866-4044-9ac9-1269ebd85dab ra-1 to UN 10.16.11.11 674.36 KiB 256 48.3% c7906366-6c98-4ff6-a4fd-17c596c33cf7 ra-1 UN 10.16.1.11 697.03 KiB 256 49.8% ddf221aa-80aa-497d-b73f-67e576ff1a23 ra-1 UN 10.16.5.13 703.64 KiB 256 50.9% 2f01ac42-4b6a-4f9e-a4eb-4734c24def95 ra-1 UN 10.16.8.15 700.42 KiB 256 50.6% a27f93af-f8a0-4c88-839f-2d653596efc2 ra-1 UN 10.16.11.3 697.03 KiB 256 49.8% dad221ff-dad1-de33-2cd3-f1.672367e6f ra-1 UN 10.16.14.16 704.04 KiB 256 50.9% 1feed042-a4b6-24ab-49a1-24d4cef95473 ra-1 UN 10.16.16.1 699.82 KiB 256 50.6% beef93af-fee0-8e9d-8bbf-efc22d653596 ra-1kubectl -n APIGEE_NAMESPACE exec -it apigee-cassandra-default-0 nodetool status
Datacenter: dc-us-east1
- スケールダウンに対応できる十分なストレージが Cassandra クラスタにがあるかどうかを確認します。スケールダウン後、Cassandra ノードがストレージ全体の 75% 以上を占めないよう確認します。
たとえば、クラスタに 6 つの Cassandra ノードがあり、すべて約 50% の場合、3 ノードにダウンスケーリングすると 3 つのノードがすべて 100% になり、稼働を継続する余力は残りません。
Cassandra ノードが 9 個あり、すべて約 50% の場合、6 ノードにダウンスケーリングすることで、残りの各ノードは約 75% 近くになるのでダウンスケーリングが可能です。
overrides.yaml
ファイルのcassandra.replicaCount
プロパティを更新または追加します。たとえば、現在のノード数が 9 の場合は、6 に変更します。cassandra: replicaCount: 6 #
- 構成の変更をクラスタに適用します。
helm upgrade datastore apigee-datastore/ \ --namespace APIGEE_NAMESPACE \ --atomic \ -f OVERRIDES_FILE.yaml
- 残りの Cassandra ノードがすべて稼働していることを確認します。
kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra
NAME READY STATUS RESTARTS AGE apigee-cassandra-default-0 1/1 Running 0 3h apigee-cassandra-default-1 1/1 Running 0 3h apigee-cassandra-default-2 1/1 Running 0 2h apigee-cassandra-default-3 1/1 Running 0 25m apigee-cassandra-default-4 1/1 Running 0 24m apigee-cassandra-default-5 1/1 Running 0 23m
nodetool status
コマンドから返されたノード数とcassandra.replicaCount
値が一致していることを確認します。たとえば、Cassandra を 6 ノードにスケールダウンする場合、次のようになります。
kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE -- nodetool -u JMX_USER -pw JMX_PASSWORD status
Datacenter: us-east1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.16.2.6 1009.17 KiB 256 73.8% b02089d1-0521-42e1-bbed-900656a58b68 ra-1 UN 10.16.4.6 1.65.55 KiB 256 75.6% dc6b7faf-6866-4044-9ac9-1269ebd85dab ra-1 to UN 10.16.11.11 999.36 KiB 256 72.8% c7906366-6c98-4ff6-a4fd-17c596c33cf7 ra-1 UN 10.16.1.11 1017.03 KiB 256 74.2% ddf221aa-80aa-497d-b73f-67e576ff1a23 ra-1 UN 10.16.5.13 1061.64 KiB 256 75.9% 2f01ac42-4b6a-4f9e-a4eb-4734c24def95 ra-1 UN 10.16.8.15 1049.42 KiB 256 74.9% a27f93af-f8a0-4c88-839f-2d653596efc2 ra-1
- Cassandra クラスタをダウンスケーリングした後、pvcs(PersistentVolumeClaim)が残りの Cassandra ノードに対応していることを確認します。
pvc の名前を取得します。
kubectl get pvc -n APIGEE_NAMESPACE
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE cassandra-data-apigee-cassandra-default-0 Bound pvc-f9c2a5b9-818c-11e9-8862-42010a8e014a 100Gi RWO apigee-gcepd 7h cassandra-data-apigee-cassandra-default-1 Bound pvc-2956cb78-818d-11e9-8862-42010a8e014a 100Gi RWO apigee-gcepd 7h cassandra-data-apigee-cassandra-default-2 Bound pvc-79de5407-8190-11e9-8862-42010a8e014a 100Gi RWO apigee-gcepd 7h cassandra-data-apigee-cassandra-default-3 Bound pvc-d29ba265-81a2-11e9-8862-42010a8e014a 100Gi RWO apigee-gcepd 5h cassandra-data-apigee-cassandra-default-4 Bound pvc-0675a0ff-81a3-11e9-8862-42010a8e014a 100Gi RWO apigee-gcepd 5h cassandra-data-apigee-cassandra-default-5 Bound pvc-354afa95-81a3-11e9-8862-42010a8e014a 100Gi RWO apigee-gcepd 5h
この例では、ダウンスケーリングされた 3 つのノードに対応する pvcs は表示されません。
cassandra-data-apigee-cassandra-8
cassandra-data-apigee-cassandra-7
cassandra-data-apigee-cassandra-6