Kubernetes で実行されるほとんどのサービスは、コマンドラインまたは構成のオーバーライドでスケーリングできます。Apigee ハイブリッド ランタイム サービス用のスケーリング パラメータは、overrides.yaml ファイルで設定できます。
| サービス | 実装方法 | スケーリング |
|---|---|---|
| Cassandra | ApigeeDatastore（CRD） | Cassandra のスケーリングをご覧ください。 |
| Ingress / LoadBalancer | Deployment | Cloud Service Mesh は、水平 Pod 自動スケーリング（HPA）を使用します。 |
| Logger | DaemonSet | DaemonSet は、すべてのノードで Pod のレプリカを管理し、Pod 自身のスケーリングに合わせてスケーリングします。 |
| MART Apigee Connect Watcher |
ApigeeOrganization（CRD） | 構成でスケーリングするには、 mart: replicaCountMax: 2 replicaCountMin: 1 watcher: replicaCountMax: 2 replicaCountMin: 1 connectAgent: replicaCountMax: 2 replicaCountMin: 1 これらの Deployment では、自動スケーリングに HorizontalPodAutoscaler が使用されます。Deployment オブジェクトの 構成プロパティの設定の詳細については、ランタイム プレーン コンポーネントの管理をご覧ください。 |
| Runtime Synchronizer UDCA |
ApigeeEnvironment（CRD） | 構成でスケーリングするには、オーバーライド ファイルで、udca、synchronizer、runtime スタンザに対する replicaCountMin プロパティの値を増やします。次に例を示します。synchronizer: replicaCountMax: 10 replicaCountMin: 1 runtime: replicaCountMax: 10 replicaCountMin: 1 udca: replicaCountMax: 10 replicaCountMin: 1 注: これらの変更は、オーバーライド ファイル内のすべての環境に適用されます。環境ごとにスケーリングをカスタマイズする場合は、後述の高度な構成をご覧ください。 これらの Deployment では、自動スケーリングに HorizontalPodAutoscaler が使用されます。Deployment オブジェクトの 構成プロパティの設定の詳細については、ランタイム プレーン コンポーネントの管理をご覧ください。 |
高度な構成
状況によっては、高度なスケーリング オプションを使用する必要があります。次のようなシナリオの場合です。
- 環境ごとに、異なるスケーリング オプションを設定するとき。たとえば、env1 の
minReplicaが 5 で、env2 のminReplicaが 2 の場合です。 - 環境内のコンポーネントごとに、異なるスケーリング オプションを設定するとき。たとえば、
udcaコンポーネントのmaxReplicaが 5 で、synchronizerコンポーネントのmaxReplicaが 2 の場合です。
次の例では、kubernetes patch コマンドを使用して、runtime コンポーネントの maxReplicas プロパティを変更する方法を示します。
- 次のコマンドで、使用する環境変数を作成します。
export ENV=my-environment-name export NAMESPACE=apigee #the namespace where apigee is deployed export COMPONENT=runtime #can be udca or synchronizer export MAX_REPLICAS=2 export MIN_REPLICAS=1
- patch を実行します。この例では、
kubectlがPATHに入っていることを前提としています。kubectl patch apigeeenvironment -n $NAMESPACE \ $(kubectl get apigeeenvironments -n $NAMESPACE -o jsonpath='{.items[?(@.spec.name == "'$ENV'" )]..metadata.name}') \ --patch "$(echo -e "spec:\n components:\n $COMPONENT:\n autoScaler:\n maxReplicas: $MAX_REPLICAS\n minReplicas: $MIN_REPLICAS")" \ --type merge
- 次のコマンドで変更を確認します。
kubectl get hpa -n $NAMESPACE
環境に基づくスケーリング
デフォルトでは、スケーリングは組織レベルで記述されます。次の例に示すように、overrides.yaml ファイルで環境固有のスケーリングを指定することで、デフォルト設定をオーバーライドできます。
envs:
# Apigee environment name
- name: test
components:
# Environment-specific scaling override
# Otherwise, uses scaling defined at the respective root component
runtime:
replicaCountMin: 2
replicaCountMax: 20
指標に基づくスケーリング
指標に基づくスケーリングでは、ランタイムは CPU とアプリケーション指標を使用して apigee-runtime Pod をスケーリングできます。Kubernetes HorizontalPodAutoscaler（HPA）API は、hpaBehavior フィールドを使用して、ターゲット サービスのスケールアップとスケールダウンの動作を構成します。指標に基づくスケーリングは、ハイブリッド デプロイの他のコンポーネントでは使用できません。
スケーリングは次の指標に基づいて調整できます。
| 指標 | メジャー | 考慮事項 |
|---|---|---|
| serverNioTaskWaitTime | http レイヤでのプロキシ リクエストのランタイム インスタンスにおける、処理キューの平均待機時間（ミリ秒）。 | この指標は、プロキシのリクエストとレスポンスの数とペイロード サイズの影響を測定します。 |
| serverMainTaskWaitTime | ランタイム インスタンスでプロキシ リクエストがポリシーを処理する、処理キューの平均待機時間（ミリ秒）。 | この指標は、プロキシのリクエスト フローに接続されたポリシーの複雑さの影響を測定します。 |
overrides.yaml の runtime スタンザでの次の例は、ハイブリッド実装で apigee-runtime Pod をスケーリングするための標準パラメータ（と許可された範囲）を示しています。
hpaMetrics: serverMainTaskWaitTime: 400M (300M to 450M) serverNioTaskWaitTime: 400M (300M to 450M) targetCPUUtilizationPercentage: 75 hpaBehavior: scaleDown: percent: periodSeconds: 60 (30 - 180) value: 20 (5 - 50) pods: periodSeconds: 60 (30 - 180) value: 2 (1 - 15) selectPolicy: Min stabilizationWindowSeconds: 120 (60 - 300) scaleUp: percent: periodSeconds: 60 (30 - 120) value: 20 (5 - 100) pods: periodSeconds: 60 (30 - 120) value: 4 (2 - 15) selectPolicy: Max stabilizationWindowSeconds: 30 (30 - 120)
より積極的なスケーリングを構成する
スケールアップ ポリシーの percent と pods の値を大きくすると、より積極的なスケールアップ ポリシーになります。同様に、scaleDown で percent と pods の値を大きくすると、アグレッシブなスケールダウン ポリシーになります。次に例を示します。
hpaMetrics: serverMainTaskWaitTime: 400M serverNioTaskWaitTime: 400M targetCPUUtilizationPercentage: 75 hpaBehavior: scaleDown: percent: periodSeconds: 60 value: 20 pods: periodSeconds: 60 value: 4 selectPolicy: Min stabilizationWindowSeconds: 120 scaleUp: percent: periodSeconds: 60 value: 30 pods: periodSeconds: 60 value: 5 selectPolicy: Max stabilizationWindowSeconds: 30
上記の例では、scaleDown.pods.value が 5に、scaleUp.percent.value が 30に、scaleUp.pods.value が 5 に増えています。
より積極的ではないスケーリングを構成する
hpaBehavior 構成値を減らすことで、より積極的ではないスケールアップとスケールダウンのポリシーを実装することもできます。例:
hpaMetrics: serverMainTaskWaitTime: 400M serverNioTaskWaitTime: 400M targetCPUUtilizationPercentage: 75 hpaBehavior: scaleDown: percent: periodSeconds: 60 value: 10 pods: periodSeconds: 60 value: 1 selectPolicy: Min stabilizationWindowSeconds: 180 scaleUp: percent: periodSeconds: 60 value: 20 pods: periodSeconds: 60 value: 4 selectPolicy: Max stabilizationWindowSeconds: 30
上記の例では、scaleDown.percent.value は 10 に、scaleDown.pods.value は 1 に、scaleUp.stablizationWindowSeconds は 180 に減少します。
hpaBehavior フィールドを使用した指標に基づくスケーリングの詳細については、スケーリング ポリシーをご覧ください。
指標に基づくスケーリングを無効にする
指標に基づくスケーリングはデフォルトで有効になっており、完全に無効にすることはできませんが、指標に基づくスケーリングがトリガーされないレベルの指標しきい値を構成できます。その結果、スケーリング動作は CPU に基づくスケーリングと同じになります。たとえば、次の構成を使用すると、指標に基づくスケーリングがトリガーされなくなります。
hpaMetrics: serverMainTaskWaitTime: 4000M serverNioTaskWaitTime: 4000M targetCPUUtilizationPercentage: 75 hpaBehavior: scaleDown: percent: periodSeconds: 60 value: 10 pods: periodSeconds: 60 value: 1 selectPolicy: Min stabilizationWindowSeconds: 180 scaleUp: percent: periodSeconds: 60 value: 20 pods: periodSeconds: 60 value: 4 selectPolicy: Max stabilizationWindowSeconds: 30
トラブルシューティング
このセクションでは、スケーリングと自動スケーリングの構成の際に発生する可能性がある一般的なエラーのトラブルシューティング方法について説明します。
HPA で指標の値に unknown が表示される
指標に基づくスケーリングが機能せず、HPA に unknown が指標値として表示される場合は、次のコマンドを使用して HPA 出力を確認します。
kubectl describe hpa HPA_NAME
コマンドを実行する際に、HPA_NAME を、表示する HPA の名前に置き換えます。
出力にサービスの CPU ターゲットと使用率が表示されます。指標に基づくスケーリングがない場合、CPU スケーリングが機能することが示されます。複数のパラメータを使用した HPA の動作については、複数メトリクスでのスケーリングをご覧ください。