Cassandra のスケーリング

このトピックでは、Cassandra の水平方向のスケールアップと垂直方向のスケールアップを行う方法、Cassandra をスケールダウンする方法について説明します。

Cassandra の水平方向のスケーリング

Cassandra を水平方向にスケールアップするには

  1. Cassandra をスケーリングする前に、必要に応じて追加の容量を apigee-data ノードプールに設定してください。専用ノードプールの構成もご覧ください。
  2. オーバーライド ファイルで cassandra.replicaCount 構成プロパティの値を設定します。replicaCount の値は 3 の倍数にする必要があります。必要な replicaCount 値を決定するには、次の点を考慮してください。
    • プロキシのトラフィック需要を見積もる。
    • 負荷テストを行い、CPU 使用率を合理的な範囲で予測する。
    • リージョンごとに異なる replicaCount 値を指定できる。
    • replicaCount は後からオーバーライド ファイルで拡張できる。

    このプロパティの詳細については、構成プロパティのリファレンスをご覧ください。ランタイム プレーン コンポーネントの管理もご覧ください。

  3. 変更を適用します。次に例を示します。
    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 とメモリを増やす手順は次のとおりです。

  1. Kubernetes のプラットフォームの指示に沿って、クラスタに新しいノードプールを追加します。対応プラットフォームについては、インストール手順に一覧を載せています。
  2. 新しいノードプールの準備ができていることを確認します。
    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
  3. 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
  4. オーバーライド ファイルをクラスタに適用します。
    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 リングをスケールダウンする一般的な方法は次のとおりです。

  1. Cassandra クラスタが正常で、スケールダウンをサポートするのに十分なストレージがあることを確認します。
  2. overrides.yamlcassandra.replicaCount プロパティを更新します。
  3. 構成の更新を適用します。
  4. クラスタ構成に応じて、永続ボリュームのクレームまたはボリュームを削除します。

注意事項

  • 停止するノード以外のノードが正常な状態でない場合は、処理を続行しないでください。Kubernetes でクラスタから Pod をスケールダウンすることはできません。
  • スケールダウンまたはスケールアップは 3 ノード単位で行ってください。

Cassandra をスケールダウンする

  1. 次の例のように、クラスタが正常で、すべてのノードが稼働していることを確認します。
    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
    kubectl -n APIGEE_NAMESPACE exec -it apigee-cassandra-default-0 nodetool status
    
    Datacenter: dc-us-east1
    注意: クラスタの状態が良好でないか、少なくとも 1 つのノードが稼働していない場合は、このプロセスを続行しないでください。
  2. スケールダウンをサポートするために Cassandra クラスタに十分なストレージがあるかどうかを確認します。スケールダウン後、Cassandra ノードがストレージ全体の 75% 以上を占めないよう確認します。

    たとえば、クラスタに 6 つの Cassandra ノードがあり、すべて約 50% の場合、3 ノードにダウンスケーリングすると 3 つのノードがすべて 100% になり、稼働を継続する余力は残りません。

    Cassandra ノードが 9 個あり、すべて約 50% の場合、6 ノードにダウンスケーリングすることで、残りの各ノードは約 75% 近くになるのでダウンスケーリングが可能です。

  3. overrides.yaml ファイルの cassandra.replicaCount プロパティを更新または追加します。たとえば、現在のノード数が 9 の場合は、6 に変更します。
    cassandra:
      replicaCount: 6 # 
  4. 構成の変更をクラスタに適用します。
    helm upgrade datastore apigee-datastore/ \
      --namespace APIGEE_NAMESPACE \
      --atomic \
      -f OVERRIDES_FILE.yaml
    
  5. 残りのすべての 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
    
    
  6. cassandra.replicaCount 値が nodetool status コマンドから返されたノード数と一致していることを確認します。

    たとえば、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
    
    
  7. 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