次の方法で共有

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 トピックにメッセージが届き始めるとスケールアップします。

注文処理アプリケーションのスケーリング アーキテクチャを示す図。

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'
              identity: 'system'
              metadata: {
                topicName: 'orders'
                subscriptionName: 'membership-orders'
                messageCount: '30'
              }
            }
          }
        ]
      }
    }
  }
}

スケーラーのしくみ

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

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

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

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

次のステップ

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