すべてのプロダクト
Search
ドキュメントセンター

Container Service for Kubernetes:RocketMQ メトリックに基づくイベント駆動型自動スケーリング (KEDA)

最終更新日:Mar 26, 2026

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」をご参照ください。

前提条件

開始する前に、以下を確認してください:

ステップ 1:アプリケーションのデプロイ

このステップでは、スケーリングターゲットとして sample-app という名前の NGINX Deployment を作成します。

  1. Container Service for Kubernetes (ACK) コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。

  2. [クラスター] ページで、管理対象のクラスターの名前をクリックします。左側のペインで、[ワークロード] > [デプロイメント] を選択します。

  3. [デプロイメント] ページで、[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 コンソールからのインスタンス情報の収集

  1. ApsaraMQ for RocketMQ コンソールにログインします。左側のナビゲーションウィンドウで、[インスタンス] をクリックします。

  2. 上部のナビゲーションバーで、[中国 (杭州)] などのリージョンを選択します。[インスタンス] ページで、管理対象のインスタンスの名前をクリックします。

  3. 左側のナビゲーションウィンドウで、[トピック] をクリックします。トピックの名前と右上に表示されるインスタンス ID (例:kedamq-cn-uax33****) を記録します。

ApsaraMQ for RocketMQ インスタンスの Prometheus エンドポイントの取得

  1. ARMS コンソールにログインします。

  2. 左側のナビゲーションウィンドウで、[Managed Service for Prometheus] > [インスタンス] を選択します。

  3. Cloud Services-{{RegionId}} という名前のインスタンスを見つけて、その名前をクリックします。左側のペインで [設定] をクリックし、[HTTP API URL (Grafana 読み取り URL)] セクションからエンドポイントをコピーします。

    image

ScaledObject の作成

  1. 次の内容で 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 レプリカにスケールアウトします。

    次の表に、主要なパラメーターを示します:

  2. 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      105s

    KEDA は 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
  3. (オプション) Prometheus への読み取りアクセスを保護するには、トークンベースの認証を設定します。詳細な手順を表示するには展開してください

    1. ページ上のプロンプトに従って Prometheus トークンを生成します。image

    2. customAuthHeader および customAuthValue フィールドの値を Base64 でエンコードした Secret を作成します:

      apiVersion: v1
      kind: Secret
      metadata:
        name: keda-prom-secret
        namespace: default
      data:
        customAuthHeader: "QXV0Xxxxxxxlvbg=="
        customAuthValue: "kR2tpT2lJeFpXSmxaVFV6WlMTxxxxxxxxRMVFE0TUdRdE9USXpaQzFqWkRZd09EZ3dOVFV5WWpZaWZRLjlDaFBYU0Q2dEhWc1dQaFlyMGh3ZU5FQjZQZWVETXFjTlYydVNqOU82TTQ="
    3. 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: customAuthValue
    4. TriggerAuthentication を参照するように 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:自動スケーリング動作の検証

  1. ApsaraMQ for RocketMQ コンソールにログインします。左側のナビゲーションウィンドウで、[インスタンス] をクリックします。

  2. 上部のナビゲーションバーで、[中国 (杭州)] などのリージョンを選択します。[インスタンス] ページで、管理対象のインスタンスの名前をクリックします。[エンドポイントとネットワーク情報] を記録します。

  3. 左側のナビゲーションウィンドウで [アクセス制御] をクリックし、[インテリジェント認証] タブをクリックします。ユーザー名とパスワードを記録します。

  4. プロデューサープログラムを実行してメッセージを公開し、HPA のステータスを確認します:

    kubectl get hpa

    期待される出力:

    NAME                               REFERENCE               TARGETS           MINPODS   MAXPODS   REPLICAS   AGE
    keda-hpa-prometheus-scaledobject   Deployment/sample-app   32700m/30 (avg)   2         10        10         47m

    REPLICAS は、sample-app が ScaledObject で設定された最大レプリカ数にスケールアウトしたことを示しています。

  5. プロデューサーを停止し、コンシューマープログラムを実行します。バックログがクリアされるにつれて 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 のメトリックに基づく水平ポッド自動スケーリング」をご参照ください。