ApsaraMQ for RocketMQ でメッセージのバックログが蓄積すると、コンシューマー Pod の処理が追いつかなくなり、システム負荷の増大やサービス停止のリスクが生じます。Kubernetes Event-Driven Autoscaling (KEDA) を使用すると、リアルタイムのメッセージバックログメトリックに基づいてコンシューマー Pod を自動的にスケーリングできるため、手動での介入なしで需要に合わせてキャパシティを調整できます。
仕組み
KEDA は、2 つの異なるフェーズでコンシューマー Pod をスケーリングします:
アクティベーションフェーズ (0 から 1 レプリカへ): KEDA はメッセージのバックログメトリックを直接監視します。バックログがアクティベーションのしきい値を超えると、KEDA は Deployment を 0 から 1 レプリカにスケールアップします。
スケーリングフェーズ (1 から N レプリカへ): 少なくとも 1 つのレプリカが実行されると、Kubernetes の Horizontal Pod Autoscaler (HPA) が引き継ぎ、KEDA が公開するメトリックに基づいてレプリカ数を調整します。このため、ScaledObject を適用した後に
kubectl get hpaを実行すると、KEDA が管理する HPA リソースが表示されます。
ApsaraMQ for RocketMQ の場合、KEDA は Managed Service for Prometheus をメトリックソースとして使用します。ScaledObject の threshold は、レプリカごとのターゲットメッセージバックログを表します。例えば、各コンシューマー Pod が 30 メッセージを処理できる場合、threshold: '30' と設定します。90 メッセージが蓄積されると、KEDA は 3 つのレプリカにスケールアウトします。
オープンソースの Apache RocketMQ を使用している場合、Java Management Extensions (JMX) Prometheus エクスポーターによって収集されたメトリックに基づいて水平ポッド自動スケーリングを有効にできます。詳細については、「Apache RocketMQ」をご参照ください。
前提条件
開始する前に、以下を確認してください:
ack-keda コンポーネントがデプロイされていること。詳細については、「イベント駆動型自動スケーリング」をご参照ください。
ApsaraMQ for RocketMQ 5.x インスタンスが作成されていること。詳細については、「インスタンスの作成」をご参照ください。
サーバーレスの ApsaraMQ for RocketMQ 5.x インスタンスは、ビジネスワークロードに基づいた迅速なリソーススケーリングをサポートしており、コンピューティング料金は実際の使用量に応じて請求されます。詳細については、「サーバーレス ApsaraMQ for RocketMQ 5.x インスタンスの概要」をご参照ください。
Alibaba Cloud RocketMQ (5.0) サービスの統合が ARMS コンソールで実現されました。
Go 実行環境が設定されていること。
ステップ 1:アプリケーションのデプロイ
このステップでは、スケーリングターゲットとして sample-app という名前の NGINX Deployment を作成します。
Container Service for Kubernetes (ACK) コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理対象のクラスターの名前をクリックします。左側のペインで、[ワークロード] > [デプロイメント] を選択します。
[デプロイメント] ページで、[YAML から作成] をクリックします。[作成] ページで、[サンプルテンプレート] を [カスタム] に設定し、次の YAML を適用します:
apiVersion: apps/v1 kind: Deployment metadata: name: sample-app namespace: default labels: app: sample-app spec: replicas: 1 selector: matchLabels: app: sample-app template: metadata: labels: app: sample-app spec: containers: - name: sample-app # 実際の RocketMQ コンシューマーコンテナイメージに置き換えてください。 image: alibaba-cloud-linux-3-registry.cn-hangzhou.cr.aliyuncs.com/alinux3/nginx_optimized:20240221-1.20.1-2.3.0 resources: limits: cpu: "500m"
ステップ 2:ScaledObject によるスケーリングポリシーの設定
ScaledObject は、スケーリングターゲット、レプリカ数の上限と下限、およびスケーリングの決定を駆動する Prometheus クエリを定義します。ScaledObject を作成する前に、ApsaraMQ for RocketMQ コンソールと ARMS コンソールから Prometheus エンドポイントとインスタンスの詳細を収集します。
ApsaraMQ for RocketMQ コンソールからのインスタンス情報の収集
ApsaraMQ for RocketMQ コンソールにログインします。左側のナビゲーションウィンドウで、[インスタンス] をクリックします。
上部のナビゲーションバーで、[中国 (杭州)] などのリージョンを選択します。[インスタンス] ページで、管理対象のインスタンスの名前をクリックします。
左側のナビゲーションウィンドウで、[トピック] をクリックします。トピックの名前と右上に表示されるインスタンス ID (例:
kedaとmq-cn-uax33****) を記録します。
ApsaraMQ for RocketMQ インスタンスの Prometheus エンドポイントの取得
ARMS コンソールにログインします。
左側のナビゲーションウィンドウで、[Managed Service for Prometheus] > [インスタンス] を選択します。
Cloud Services-{{RegionId}} という名前のインスタンスを見つけて、その名前をクリックします。左側のペインで [設定] をクリックし、[HTTP API URL (Grafana 読み取り URL)] セクションからエンドポイントをコピーします。

ScaledObject の作成
次の内容で
ScaledObject.yamlという名前のファイルを作成します:パラメーター 説明 scaleTargetRef.nameスケーリングする Deployment。この例では、 sample-app(ステップ 1 で作成)。maxReplicaCountスケールアウト時に許可されるレプリカの最大数。 minReplicaCountスケールイン時に維持されるレプリカの最小数。 serverAddressApsaraMQ for RocketMQ のメトリックを格納する Prometheus エンドポイント。前の手順で [HTTP API URL (Grafana 読み取り URL)] からコピーしたエンドポイントを使用します。 metricNameスケーリングシグナルとして使用される PromQL メトリック名。 query指定されたインスタンスとトピックのメッセージバックログを、コンシューマーグループごとに集計する PromQL クエリ。 thresholdレプリカごとのターゲットメッセージバックログ (平均値)。KEDA は、各レプリカが平均してこの数以下のメッセージを処理するように Deployment をスケーリングします。この値を設定するには、単一のコンシューマー Pod が処理できるメッセージ数を見積もり、それをしきい値として使用します。 apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: name: sample-app # 必須。スケーリングする Deployment。 maxReplicaCount: 10 # 必須。スケールアウト時の最大レプリカ数。 minReplicaCount: 2 # 必須。スケールイン時の最小レプリカ数。 triggers: - type: prometheus metadata: # 必須フィールド: serverAddress: http://cn-beijing.arms.aliyuncs.com:9090/api/v1/prometheus/8cba801fff65546a3012e9a684****/****538168824185/cloud-product-rocketmq/cn-beijing # serverAddress を ARMS コンソールからコピーしたエンドポイントに置き換えます。 metricName: rocketmq_consumer_inflight_messages query: sum({__name__=~"rocketmq_consumer_ready_messages|rocketmq_consumer_inflight_messages",instance_id="rmq-cn-uax3xxxxxx",topic=~"keda"}) by (consumer_group) # instance_id と topic を実際のインスタンス ID とトピック名に置き換えます。 threshold: '30' # レプリカごとのターゲットメッセージバックログ (平均値)。 # 例:1 つの Pod が 30 メッセージを処理する場合、 # 90 メッセージが蓄積されると 3 レプリカにスケールアウトします。次の表に、主要なパラメーターを示します:
ScaledObject を適用し、作成されたリソースを検証します:
# スケーリング設定を適用します。 kubectl apply -f ScaledObject.yaml # ScaledObject が準備完了であることを確認します。 kubectl get ScaledObject期待される出力:
NAME SCALETARGETKIND SCALETARGETNAME MIN MAX TRIGGERS AUTHENTICATION READY ACTIVE FALLBACK AGE prometheus-scaledobject apps/v1.Deployment sample-app 2 10 prometheus True False False 105sKEDA は Deployment の HPA を自動的に作成します。それが存在することを確認します:
kubectl get hpa期待される出力:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE keda-hpa-prometheus-scaledobject Deployment/sample-app 0/30 (avg) 2 10 2 28m(オプション) Prometheus への読み取りアクセスを保護するには、トークンベースの認証を設定します。詳細な手順を表示するには展開してください
ページ上のプロンプトに従って Prometheus トークンを生成します。

customAuthHeaderおよびcustomAuthValueフィールドの値を Base64 でエンコードした Secret を作成します:apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: customAuthHeader: "QXV0Xxxxxxxlvbg==" customAuthValue: "kR2tpT2lJeFpXSmxaVFV6WlMTxxxxxxxxRMVFE0TUdRdE9USXpaQzFqWkRZd09EZ3dOVFV5WWpZaWZRLjlDaFBYU0Q2dEhWc1dQaFlyMGh3ZU5FQjZQZWVETXFjTlYydVNqOU82TTQ="Secret を参照する TriggerAuthentication リソースを作成します:
apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: customAuthHeader name: keda-prom-secret key: customAuthHeader - parameter: customAuthValue name: keda-prom-secret key: customAuthValueTriggerAuthentication を参照するように ScaledObject を更新します:
apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: name: sample-app maxReplicaCount: 10 minReplicaCount: 2 triggers: - type: prometheus metadata: serverAddress: http://cn-beijing.arms.aliyuncs.com:9090/api/v1/prometheus/8cba801fff65546a3012e9a684****/****538168824185/cloud-product-rocketmq/cn-beijing metricName: rocketmq_consumer_inflight_messages query: sum({__name__=~"rocketmq_consumer_ready_messages|rocketmq_consumer_inflight_messages",instance_id="rmq-cn-uax3xxxxxx",topic=~"keda"}) by (consumer_group) threshold: '30' authModes: "custom" authenticationRef: name: keda-prom-creds # 上記で作成した TriggerAuthentication を参照します。注:この例ではカスタム認証を使用しています。Prometheus スケーラーでサポートされている他の認証方式については、「KEDA コミュニティドキュメント」をご参照ください。
ステップ 3:データの生成と消費
rocketmq-keda-sample プロジェクトを使用して、メッセージを生成および消費します。プロジェクトのコードで、ステップ 2 で取得した ApsaraMQ for RocketMQ インスタンスのエンドポイント、ユーザー名、パスワードを指定します。
ステップ 4:自動スケーリング動作の検証
ApsaraMQ for RocketMQ コンソールにログインします。左側のナビゲーションウィンドウで、[インスタンス] をクリックします。
上部のナビゲーションバーで、[中国 (杭州)] などのリージョンを選択します。[インスタンス] ページで、管理対象のインスタンスの名前をクリックします。[エンドポイントとネットワーク情報] を記録します。
左側のナビゲーションウィンドウで [アクセス制御] をクリックし、[インテリジェント認証] タブをクリックします。ユーザー名とパスワードを記録します。
プロデューサープログラムを実行してメッセージを公開し、HPA のステータスを確認します:
kubectl get hpa期待される出力:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE keda-hpa-prometheus-scaledobject Deployment/sample-app 32700m/30 (avg) 2 10 10 47mREPLICASは、sample-appが ScaledObject で設定された最大レプリカ数にスケールアウトしたことを示しています。プロデューサーを停止し、コンシューマープログラムを実行します。バックログがクリアされるにつれて HPA がスケールインするのを監視します:
kubectl get hpa -w期待される出力:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE keda-hpa-prometheus-scaledobject Deployment/sample-app 222500m/30 (avg) 2 10 10 50m keda-hpa-prometheus-scaledobject Deployment/sample-app 232400m/30 (avg) 2 10 10 51m keda-hpa-prometheus-scaledobject Deployment/sample-app 0/30 (avg) 2 10 10 52m keda-hpa-prometheus-scaledobject Deployment/sample-app 0/30 (avg) 2 10 2 57mすべてのメッセージが消費されると、
REPLICASは最小レプリカ数 (minReplicaCount: 2) に戻ります。
次のステップ
ApsaraMQ for RabbitMQ のメトリックを使用して、キューの長さとメッセージングレートに基づいて Pod をスケーリングします。詳細については、「ApsaraMQ for RabbitMQ のメトリックに基づく水平ポッド自動スケーリング」をご参照ください。