In this blog, we will delve into the scaling characteristics of Logic Apps standard and offer valuable insights on designing scalable Logic Apps for high throughput scenarios. This is the first of a blog series dedicated to exploring the scaling aspects of Logic Apps. 

We also plan to release subsequent blog posts featuring real-world designs and case studies of Logic Apps successfully handling high throughput workloads. Stay tuned for in-depth examples and practical applications!

Logic Apps offers a robust platform that seamlessly integrates with diverse services, including databases, messaging systems, and both PaaS and SaaS offerings. Additionally, it supports various connectivity protocols, enabling the creation of comprehensive integration solutions. By utilizing its intuitive workflow designer and a wide range of connectors, Logic Apps empowers developers to efficiently build intricate solutions. Moreover, its user-friendly management and monitoring capabilities ensure smooth app lifecycle management.

One commonly raised question is whether Logic Apps can effectively scale to handle high throughput requirements in demanding scenarios. To provide some context, here are a couple of examples of high throughput scenarios:

\n
• Every day, we receive a staggering volume of 1 million invoices at a specific time. Our objective is to process all these orders within a couple of hours. Is it possible to leverage a Logic App that can dynamically scale out during this period, enabling us to achieve the required high throughput? Subsequently, it should scale back in when there is no further processing needed, allowing us to optimize costs while maintaining the desired throughput.
\n
• Our system continuously receives a stream of events from an event hub, and these events exhibit peak loads either at specific times of the day or randomly, sometimes exceeding a rate of 10K events per minute.
\n

Indeed, the answer to the above question is a resounding yes. With a bit of capacity planning and a thorough comprehension of how scaling functions within Logic Apps, achieving higher throughput scenarios becomes as effortless as constructing a workflow to address an intricate business process.

In this blog, we will delve into the scaling characteristics of Logic Apps standard and offer valuable insights on designing scalable Logic Apps for high throughput scenarios. This is the first of a blog series dedicated to exploring the scaling aspects of Logic Apps. 

We also plan to release subsequent blog posts featuring real-world designs and case studies of Logic Apps successfully handling high throughput workloads. Stay tuned for in-depth examples and practical applications!

Scalability of Underlying Logic App Resources

There are two primary resources that Logic App uses when running your workflows - storage and compute.

Storage

Stateful workflows in Logic Apps leverage storage (table and blob) for persistent data storage during runtime and for maintaining run histories. Additionally, queues are utilized for scheduling purposes. A single storage account enables a substantial number of requests, with rates of up to 2K per partition and 20K requests per second( RPS) at the account level. Beyond these thresholds, request rates are subject to throttling. See here for more information about storage scalability limits.

As the workflow execution rate increases, it's important to note that while a single storage account can handle reasonably high throughput, there is a possibility of encountering partition level throttling or account level throttling. Therefore, it becomes crucial to understand the potential limitations and ways to address them in order to ensure smooth operations.

Scaling your Logic App for Storage Limits

\n
• Shard your load across multiple workflows
\n

The Logic Apps engine is specifically designed to minimize partition level throttling by distributing storage transactions across multiple partitions. However, to achieve even better distribution and mitigate partition level throttling, it is advisable to distribute the workload across two or more workflows instead of relying on a single workflow.

\n
• Shard your load across multiple Storage Accounts
\n

To significantly enhance throughput, a Logic App can be set up to distribute its load across multiple storage accounts, with a maximum limit of 32 storage accounts. If your application demands high throughput, it is recommended to utilize multiple storage accounts rather than relying on one. A general guideline to consider is aiming for approximately 100K action executions per minute per storage account to determine if additional storage accounts are necessary. Please note that while this limit is good number for most of the scenarios, if your workflow actions are compute heavy (such as Query action processing large array of data), the limit may be lower than this and it’s a always a good idea to perform load testing and tune your solution before you put your solution to production.

See the appendix below for instructions for configuring multiple storage accounts.

Compute

When it comes to running Logic Apps Standard, there are three primary compute options to consider: WS1, WS3, and WS3. These options offer varying amounts of memory and core counts. Moreover, if you decide to run your Logic App within ASEv3 (App Service Environment version 3), additional computing options become available.

The compute infrastructure of Logic Apps is designed to scale dynamically in order to effectively handle increasing loads. The decision to scale dynamically is determined by considering two primary factors.

\n
• Trigger - the scaler analyzes each trigger employed in the workflows of a specific app to determine scaling requirements. For instance, if a service bus trigger is present and the queue length continues to grow, the scaler will take action to add additional instances, enabling the processing of more messages. Similarly, when a request trigger is utilized in a workflow and the request latency experiences an upward trend, the will increase the number of instances to distribute the request load more efficiently.
\n

\n
• Workflow Job Execution Delay - at runtime, workflow actions are divided into individual jobs and placed in a queue for execution. Dispatchers regularly poll the job queue to retrieve and execute these jobs (for more details, refer to this blog post on how the runtime schedules and runs jobs). However, if there is insufficient compute capacity available to pick up these jobs, they will remain in the queue for a longer duration, resulting in increased execution delays. The scaler would monitor and make scaling decisions to keep the execution delays under control.
\n

In addition to the aforementioned factors, the scaler also considers the minimum and maximum instance counter configuration to determine whether scaling decisions should be made, such as adding, removing, or maintaining the current number of instances. Typically, the scaler makes these decisions at intervals of approximately 15-30 seconds. It is important to consider the ramp-up time and its impact on the scaling speed of your Logic App to effectively handle peak loads. For instance, if your workload necessitates scaling your Logic App from just 1 instance to 100 instances, the ramp-up alone could take approximately 25-50 minutes. Logic Apps scaling shares the same scaling infrastructure as Azure functions and you can read more about how Azure functions scales in this article.

Configuring your Logic App compute for faster scaling

\n
• Each Logic App can scale independently, and distributing your load across multiple apps can significantly accelerate the scaling speed. For instance, two apps can scale to twice the number of instances in the same timeframe compared to a single app. By splitting your load into multiple apps, you can effectively multiply the scalability and achieve faster scaling results.
\n
• Use prewarmed instances. If your scenario requires quicker ramp-up time, you would probably want to consider using prewarmed instances. If your peak load times are deterministic, then you can use an automation task (see here for more details) to adjust these prewarm instances on a schedule.
\n

Please note that if you are housing your Logic App inside an App Service Environment (ASEv3), the dynamic scaling functionality is not available. You are required to set scaling rules on the associated App Service Plans (ASP). A commonly used scaling rule is to use the CPU metric and scale your ASP to keep the VM CPU between 50-70%. See here for more details.  

Appendix – Configuring your Logic Apps with multiple storage accounts.

The following steps can be used to configure your Logic Apps with multiple storage accounts to achieve higher scalability.  Currently, there are two authentication models that you can select from to connect to your storage accounts based on what your logic app is using: connection string and managed identity.

Please note that you need to perform these configurations steps prior to creating new Logic Apps and changing these settings after workflows have been created could result in loss of data or not having desired level of scalability.

Connection String

Step 1: Update the host.json to specify the number of storage accounts to use. Here is an example of a host.json file using 3 storage accounts:

{ \"version\": \"2.0\", \"extensionBundle\": { \"id\": \"Microsoft.Azure.Functions.ExtensionBundle.Workflows\", \"version\": \"[1.*, 2.0.0)\" }, \"extensions\": { \"workflow\": { \"Settings\": { \"Runtime.ScaleUnitsCount\": \"3\" } } } }

Step 2: Create 3 storage accounts and save the associated connection strings.

Step 3: Add the connections strings in the application configuration, using the following pattern. Starting from 00 to {number of storage accounts – 1}:

\n
• Key{n}.ConnectionString (n is a two digit number depending on the number of storage accounts being used – e.g., 00, 01, 02, etc.)
\n
• Value: The connection string
\n

Example for 3 storage accounts:

Step 4: Update the AzureWebJobsStorage configuration key with the same connection string value as the CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU00.ConnectionString key.

Managed Identity

Step 1: Update the host.json to specify the number of storage accounts to use. Here is an example of a host.json file using 3 storage accounts:

{ \"version\": \"2.0\", \"extensionBundle\": { \"id\": \"Microsoft.Azure.Functions.ExtensionBundle.Workflows\", \"version\": \"[1.*, 2.0.0)\" }, \"extensions\": { \"workflow\": { \"Settings\": { \"Runtime.ScaleUnitsCount\": \"3\" } } } }

Step 2: Create 3 storage accounts and save the associated storage account names.

Step 3: Add the storage account names in the application configuration, using the following pattern. Starting from 00 to {number of storage accounts – 1}:

\n
• Key{n}.AccountName (n is a two digit number depending on the number of storage accounts being used – e.g., 00, 01, 02, etc.)
\n
• Value: The storage account name
\n

Example for 3 storage accounts:

Step 4: Update the service URI configuration keys to reference the same storage account as the one referenced in CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU00.AccountName

Logic Apps offers a robust platform that seamlessly integrates with diverse services, including databases, messaging systems, and both PaaS and SaaS offerings. Additionally, it supports various connectivity protocols, enabling the creation of comprehensive integration solutions. By utilizing its intuitive workflow designer and a wide range of connectors, Logic Apps empowers developers to efficiently build intricate solutions. Moreover, its user-friendly management and monitoring capabilities ensure smooth app lifecycle management.

One commonly raised question is whether Logic Apps can effectively scale to handle high throughput requirements in demanding scenarios. To provide some context, here are a couple of examples of high throughput scenarios:

\n
• Every day, we receive a staggering volume of 1 million invoices at a specific time. Our objective is to process all these orders within a couple of hours. Is it possible to leverage a Logic App that can dynamically scale out during this period, enabling us to achieve the required high throughput? Subsequently, it should scale back in when there is no further processing needed, allowing us to optimize costs while maintaining the desired throughput.
\n
• Our system continuously receives a stream of events from an event hub, and these events exhibit peak loads either at specific times of the day or randomly, sometimes exceeding a rate of 10K events per minute.
\n

Indeed, the answer to the above question is a resounding yes. With a bit of capacity planning and a thorough comprehension of how scaling functions within Logic Apps, achieving higher throughput scenarios becomes as effortless as constructing a workflow to address an intricate business process.

In this blog, we will delve into the scaling characteristics of Logic Apps standard and offer valuable insights on designing scalable Logic Apps for high throughput scenarios. This is the first of a blog series dedicated to exploring the scaling aspects of Logic Apps. 

We also plan to release subsequent blog posts featuring real-world designs and case studies of Logic Apps successfully handling high throughput workloads. Stay tuned for in-depth examples and practical applications!

Scalability of Underlying Logic App Resources

There are two primary resources that Logic App uses when running your workflows - storage and compute.

Storage

Stateful workflows in Logic Apps leverage storage (table and blob) for persistent data storage during runtime and for maintaining run histories. Additionally, queues are utilized for scheduling purposes. A single storage account enables a substantial number of requests, with rates of up to 2K per partition and 20K requests per second( RPS) at the account level. Beyond these thresholds, request rates are subject to throttling. See here for more information about storage scalability limits.

As the workflow execution rate increases, it's important to note that while a single storage account can handle reasonably high throughput, there is a possibility of encountering partition level throttling or account level throttling. Therefore, it becomes crucial to understand the potential limitations and ways to address them in order to ensure smooth operations.

Scaling your Logic App for Storage Limits

\n
• Shard your load across multiple workflows
\n

The Logic Apps engine is specifically designed to minimize partition level throttling by distributing storage transactions across multiple partitions. However, to achieve even better distribution and mitigate partition level throttling, it is advisable to distribute the workload across two or more workflows instead of relying on a single workflow.

\n
• Shard your load across multiple Storage Accounts
\n

To significantly enhance throughput, a Logic App can be set up to distribute its load across multiple storage accounts, with a maximum limit of 32 storage accounts. If your application demands high throughput, it is recommended to utilize multiple storage accounts rather than relying on one. A general guideline to consider is aiming for approximately 100K action executions per minute per storage account to determine if additional storage accounts are necessary. Please note that while this limit is good number for most of the scenarios, if your workflow actions are compute heavy (such as Query action processing large array of data), the limit may be lower than this and it’s a always a good idea to perform load testing and tune your solution before you put your solution to production.

See the appendix below for instructions for configuring multiple storage accounts.

Compute

When it comes to running Logic Apps Standard, there are three primary compute options to consider: WS1, WS3, and WS3. These options offer varying amounts of memory and core counts. Moreover, if you decide to run your Logic App within ASEv3 (App Service Environment version 3), additional computing options become available.

The compute infrastructure of Logic Apps is designed to scale dynamically in order to effectively handle increasing loads. The decision to scale dynamically is determined by considering two primary factors.

\n
• Trigger - the scaler analyzes each trigger employed in the workflows of a specific app to determine scaling requirements. For instance, if a service bus trigger is present and the queue length continues to grow, the scaler will take action to add additional instances, enabling the processing of more messages. Similarly, when a request trigger is utilized in a workflow and the request latency experiences an upward trend, the will increase the number of instances to distribute the request load more efficiently.
\n

\n
• Workflow Job Execution Delay - at runtime, workflow actions are divided into individual jobs and placed in a queue for execution. Dispatchers regularly poll the job queue to retrieve and execute these jobs (for more details, refer to this blog post on how the runtime schedules and runs jobs). However, if there is insufficient compute capacity available to pick up these jobs, they will remain in the queue for a longer duration, resulting in increased execution delays. The scaler would monitor and make scaling decisions to keep the execution delays under control.
\n

In addition to the aforementioned factors, the scaler also considers the minimum and maximum instance counter configuration to determine whether scaling decisions should be made, such as adding, removing, or maintaining the current number of instances. Typically, the scaler makes these decisions at intervals of approximately 15-30 seconds. It is important to consider the ramp-up time and its impact on the scaling speed of your Logic App to effectively handle peak loads. For instance, if your workload necessitates scaling your Logic App from just 1 instance to 100 instances, the ramp-up alone could take approximately 25-50 minutes. Logic Apps scaling shares the same scaling infrastructure as Azure functions and you can read more about how Azure functions scales in this article.

Configuring your Logic App compute for faster scaling

\n
• Each Logic App can scale independently, and distributing your load across multiple apps can significantly accelerate the scaling speed. For instance, two apps can scale to twice the number of instances in the same timeframe compared to a single app. By splitting your load into multiple apps, you can effectively multiply the scalability and achieve faster scaling results.
\n
• Use prewarmed instances. If your scenario requires quicker ramp-up time, you would probably want to consider using prewarmed instances. If your peak load times are deterministic, then you can use an automation task (see here for more details) to adjust these prewarm instances on a schedule.
\n

Please note that if you are housing your Logic App inside an App Service Environment (ASEv3), the dynamic scaling functionality is not available. You are required to set scaling rules on the associated App Service Plans (ASP). A commonly used scaling rule is to use the CPU metric and scale your ASP to keep the VM CPU between 50-70%. See here for more details.  

Appendix – Configuring your Logic Apps with multiple storage accounts.

The following steps can be used to configure your Logic Apps with multiple storage accounts to achieve higher scalability.  Currently, there are two authentication models that you can select from to connect to your storage accounts based on what your logic app is using: connection string and managed identity.

Please note that you need to perform these configurations steps prior to creating new Logic Apps and changing these settings after workflows have been created could result in loss of data or not having desired level of scalability.

Connection String

Step 1: Update the host.json to specify the number of storage accounts to use. Here is an example of a host.json file using 3 storage accounts:

Step 2: Create 3 storage accounts and save the associated connection strings.

Step 3: Add the connections strings in the application configuration, using the following pattern. Starting from 00 to {number of storage accounts – 1}:

\n
• Key{n}.ConnectionString (n is a two digit number depending on the number of storage accounts being used – e.g., 00, 01, 02, etc.)
\n
• Value: The connection string
\n

Example for 3 storage accounts:

Step 4: Update the AzureWebJobsStorage configuration key with the same connection string value as the CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU00.ConnectionString key.

Managed Identity

Step 1: Update the host.json to specify the number of storage accounts to use. Here is an example of a host.json file using 3 storage accounts:

Step 2: Create 3 storage accounts and save the associated storage account names.

Step 3: Add the storage account names in the application configuration, using the following pattern. Starting from 00 to {number of storage accounts – 1}:

\n
• Key{n}.AccountName (n is a two digit number depending on the number of storage accounts being used – e.g., 00, 01, 02, etc.)
\n
• Value: The storage account name
\n

Example for 3 storage accounts:

Step 4: Update the service URI configuration keys to reference the same storage account as the one referenced in CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU00.AccountName

In this blog, we will delve into the scaling characteristics of Logic Apps standard and offer valuable insights on designing scalable Logic Apps for high throughput scenarios. This is the first of a blog series dedicated to exploring the scaling aspects of Logic Apps. 

We also plan to release subsequent blog posts featuring real-world designs and case studies of Logic Apps successfully handling high throughput workloads. Stay tuned for in-depth examples and practical applications!

Has any testing been done with premium storage tiers? https://learn.microsoft.com/en-us/azure/storage/blobs/scalability-targets-premium-block-blobs