KEDA スケーラーを使用した Dapr アプリケーションのスケーリング

  • [アーティクル]

Azure Container Apps は、HTTP トラフィックを自動的にゼロにスケーリングします。 ただし、非 HTTP トラフィック (Dapr pub/sub やバインドなど) をスケーリングするには、KEDA スケーラーを使用して、保留中の受信イベントと受信メッセージの数に基づいて、アプリケーションとその Dapr サイドカーを上下にスケーリングできます。

このガイドでは、KEDA メッセージング スケーラーを使用した Dapr pub/sub アプリケーションのスケール ルールの構成方法を説明します。 コンテキストについては、対応する次の pub/sub アプリケーションのサンプルを参照してください。

上記のサンプルでは、アプリケーションでは次の要素を使用しています。

  1. checkout パブリッシャーは、HTTP トラフィックをまったく受け取らないにも関わらず、無期限に実行され、ゼロにスケールダウンされることのないアプリケーションです。
  2. Dapr Azure Service Bus の pub/sub コンポーネント。
  3. order-processor サブスクライバー コンテナー アプリは、orders トピック経由で受信したメッセージを選択し、届いたときに処理します。
  4. Azure Service Bus のスケール ルールでは、order-processor サービスとその Dapr サイドカーは、orders トピックにメッセージが届き始めるとスケールアップします。

Diagram showing the scaling architecture of the order processing application.

Dapr アプリケーションでスケーリング ルールを適用する方法を見てみましょう。

パブリッシャー コンテナー アプリ

checkout パブリッシャーは、無期限に実行され、ゼロにスケールダウンすることはないヘッドレス サービスです。

既定では、Container Apps ランタイムは HTTP ベースのスケール ルールをアプリケーションに割り当て、HTTP 要求の受信数に基づいてスケーリングを促進します。 次の例では、minReplicas は 1 に設定されています。 この構成は、コンテナー アプリが HTTP トラフィックの着信がない状態でゼロまでスケーリングする既定の動作に従わないことを保証します。

resource checkout 'Microsoft.App/containerApps@2022-03-01' = {
  name: 'ca-checkout-${resourceToken}'
  location: location
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    //...
    template: {
      //...
      // Scale the minReplicas to 1
      scale: {
        minReplicas: 1
        maxReplicas: 1
      }
    }
  }
}

サブスクライバー コンテナー アプリ

次の order-processor サブスクライバー アプリには、azure-servicebus の種類のリソースを監視するカスタム スケール ルールが含まれます。 このルールを使用すると、アプリ (およびそのサイドカー) は、Bus の保留メッセージの数に基づいて、必要に応じてスケールアップまたはスケールダウンします。

resource orders 'Microsoft.App/containerApps@2022-03-01' = {
  name: 'ca-orders-${resourceToken}'
  location: location
  tags: union(tags, {
      'azd-service-name': 'orders'
    })
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    managedEnvironmentId: containerAppsEnvironment.id
    configuration: {
      //...
      // Enable Dapr on the container app
      dapr: {
        enabled: true
        appId: 'orders'
        appProtocol: 'http'
        appPort: 5001
      }
      //...
    }
    template: {
      //...
      // Set the scale property on the order-processor resource
      scale: {
        minReplicas: 0
        maxReplicas: 10
        rules: [
          {
            name: 'topic-based-scaling'
            custom: {
              type: 'azure-servicebus'
              metadata: {
                topicName: 'orders'
                subscriptionName: 'membership-orders'
                messageCount: '30'
              }
              auth: [
                {
                  secretRef: 'sb-root-connectionstring'
                  triggerParameter: 'connection'
                }
              ]
            }
          }
        ]
      }
    }
  }
}

スケーラーのしくみ

サブスクライバー アプリでのスケーラーの構成の次の messageCount プロパティに注意してください。

{
  //...
  properties: {
    //...
    template: {
      //...
      scale: {
        //...
        rules: [
          //...
          custom: {
            //...
            metadata: {
              //...
              messageCount: '30'
            }
          }
        ]
      }
    }
  }
}

このプロパティは、アプリケーションの各インスタンスで同時に処理できるメッセージ数をスケーラーに伝達します。 この例では、値は 30 に設定されており、トピックで待機している 30 個のメッセージのグループごとに、アプリケーションのインスタンスが 1 つずつ作成されることを示しています。

たとえば、150 個のメッセージが待機している場合、KEDA はアプリを 5 つのインスタンスにスケールアウトします。 maxReplicas プロパティは 10 に設定されています。つまり、トピックに大量のメッセージがある場合でも、スケーラーはこのアプリケーションのインスタンスを 10 個以上作成することはありません。 この設定により、スケールアップしすぎてコストがかかりすぎることを防止できます。

次のステップ

Dapr コンポーネントと Azure Container Apps の使用について詳しく説明します。