このトピックでは、Apigee ハイブリッドの本番環境用に Cassandra データベース コンポーネントを構成するために必要な手順と推奨される手順について説明します。
必要な構成
次の構成が必要です。
高可用性を確保する
本番環境での可用性を維持するため、Cassandra クラスタには 3 つのアベイラビリティ ゾーンが必要です。1 つのゾーンが停止した場合は、そのゾーンがオンラインに復帰するまでの間、残りのゾーンがリクエストへの応答を継続します。複数のゾーンが停止した場合は、少なくとも 2 つのゾーンがオンラインに戻るまで、Cassandra はリクエストに応答できません。データ更新の欠落リスクを最小限に抑えるため、ゾーンは 3 時間以内にオンラインに戻すことをおすすめします。
Cassandra ストレージ設定を構成する
Apigee ハイブリッドの本番環境のインストールでは、次のストレージとヒープの設定をオーバーライド ファイルに追加してクラスタに適用することをおすすめします。
cassandra:
...
replicaCount: 3
storage:
storageclass: your-preferred-ssd-storage #If not using default storage for your cluster
capacity: 500Gi
resources:
requests:
cpu: 7
memory: 15Gi
maxHeapSize: 8192M
heapNewSize: 1200Mcassandra に変更を適用するには、次のコマンドを使用します。
helm upgrade datastore apigee-datastore/ \ --namespace apigee \ --atomic \ -f OVERRIDES_FILE.yaml
replicaCount
replicaCount の値は 3 の倍数にする必要があります。指定する replicaCount 値を決定する際は、次の点を考慮してください。
- プロキシのトラフィック需要を見積もる。
- 負荷テストを行い、CPU 使用率を合理的な範囲で予測する。
- リージョンごとに異なる
replicaCount値を指定できる。 replicaCountは後からオーバーライド ファイルで拡張できる。
storageclass
本番環境では、Cassandra ストレージは SSD の StorageClass である必要があります。クラスタでデフォルトの Kubernetes StorageClass を使用していない場合は、storageclass の値を設定します。デフォルトの StorageClass は、次のコマンドで確認できます。
kubectl get storageclass
出力は次のようになります。
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE premium-rwo pd.csi.storage.gke.io Delete WaitForFirstConsumer true 6d23h standard kubernetes.io/gce-pd Delete Immediate true 6d23h standard-rwo (default) pd.csi.storage.gke.io Delete WaitForFirstConsumer true 6d23h
デフォルトの Kubernetes StorageClass を変更する場合は、StorageClass の構成の手順に沿ってください。
現在の storageclass 設定を確認するには、クラスタで次のコマンドを実行します。
kubectl get pvc -n NAMESPACE cassandra-data-apigee-cassandra-default-0 -o=jsonpath="{['.spec.storageClassName', '.metadata.annotations.volume\.beta\.kubernetes\.io/storage-class']}"
storageSize
本番環境のインストールでは、500 GiB（ギビバイト）以上のストレージ サイズをおすすめします。ストレージ サイズは、クラスタのストレージ要件に応じて変更できます。ストレージ容量を変更するには、Cassandra の永続ボリュームを拡張するの手順をご覧ください。
現在のサイズ設定を確認するには、クラスタで次のコマンドを実行します。
kubectl get pvc -n NAMESPACE cassandra-data-apigee-cassandra-default-0 -o=jsonpath='{.spec.resources.requests.storage}'
cpu と memory
本番環境のインストールでは、Pod あたり 7 個以上の CPU と最小 15 Gi（ギビバイト）をおすすめします。cassandra.resources.requests.cpu と cassandra.resources.requests.memory を指定する場合は、トラフィック ボリュームとプロキシの CPU およびメモリ需要を考慮してください。
現在の CPU 設定を確認するには、クラスタで次のコマンドを実行します。
kubectl get pods -n NAMESPACE apigee-cassandra-default-0 -o=jsonpath='{.spec.containers[].resources.requests.cpu}'
現在のメモリ設定を確認するには、クラスタで次のコマンドを実行します。
kubectl get pods -n NAMESPACE apigee-cassandra-default-0 -o=jsonpath='{.spec.containers[].resources.requests.memory}'
maxHeapSize と heapNewSize
これらのプロパティは、Cassandra プロセスに割り当てられる最大メモリヒープとメモリの増加量をそれぞれメガバイト単位で指定します（ヒープサイズはメビバイトではなくメガバイト単位で指定されます）。本番環境では、次の値を使用することをおすすめします。
maxHeapSize: 8192MheapNewSize: 1200M
最適なヒープサイズ値については、Kubernetes プラットフォーム プロバイダのドキュメントをご覧ください。
現在の maxHeapSize 設定を確認するには、クラスタで次のコマンドを実行します。
kubectl get sts -n NAMESPACE apigee-cassandra-default -o=jsonpath='{.spec.template.spec.containers[].env[?(@.name=="MAX_HEAP_SIZE")]}'
現在の heapNewSize 設定を確認するには、クラスタで次のコマンドを実行します。
kubectl get sts -n NAMESPACE apigee-cassandra-default -o=jsonpath='{.spec.template.spec.containers[].env[?(@.name=="HEAP_NEWSIZE")]}'
これらのプロパティ設定の詳細については、構成プロパティ リファレンスをご覧ください。
本番環境のデプロイに SSD ストレージを使用する
ハイブリッド ランタイムで Cassandra データベースにデータを保存する場合は、動的に作成された永続ボリュームのみがサポートされます。ローカル SSD（ソリッド ステート ディスク）ドライブはサポートされていません。
現時点で Cassandra 用に SSD が構成されていない場合は、SSD（ソリッド ステート ドライブ）を基盤とする StorageClass の定義を構成し、それをデフォルト クラスにする必要があります。詳細な手順については、StorageClass の構成をご覧ください。
デフォルトの Kubernetes StorageClass を変更する場合は、StorageClass の構成の手順に沿って実行します。
推奨構成
このセクションでは、Cassandra の推奨構成について説明します。
日次バックアップ スケジュールを構成する
構成ミスによりマルチリージョン Cassandra の問題が発生した場合、Google はランタイム データを復元できず、データが完全に失われます。
データの損失を防ぐため、毎日のバックアップ スケジュールを構成します。バックアップのサイズと頻度をモニタリングし、バックアップ パイプラインが失敗したときに通知されるようにします。
Cassandra の最小クラスタ要件を遵守する
Cassandra の最小クラスタ構成に沿って操作します。
すべてのユーザー向け環境を本番環境として扱う
ハイブリッド インストールが「非本番環境」と見なされる場合でも、本番環境対応の設定が必要になることがあります。たとえば、ユーザー受け入れテスト（UAT）のインストールでサービスが停止した場合は、優先度の高いインシデントをトリガーする必要があります。
お客様向けの「非本番環境」のハイブリッド インストールでも、本番環境対応の設定を使用します。この記事で説明されているように、お客様向けのすべての環境で、本番環境サーバーと同じ原則に従うことをおすすめします。特に、replicaCount とリージョンを使用して障害復旧の原則に従ってください。詳細については、Cassandra ストレージ設定を構成するをご覧ください。