如何防止 azure 在其他实例准备好之前横向扩展它们? [英] how to prevent azure from scaling out additional instances until they are ready?

问题描述

我们遇到了 Azure 应用程序服务问题.我们的其中一个 Web 服务 (MVC) 在启动时缓存数据库中的数据 (Application_Start) - 这大约需要 3 分钟.在这准备好之前，我们无法处理请求.

We are having issues with an Azure Application Service. One of our webservices (MVC) caches data from the database at startup (Application_Start) - this takes approximately 3 minutes. Until this is ready we can't handle requests.

这是已知的，因此我们将其设置为始终开启"，并且旨在仅在必要时在非高峰时间重新启动它.

This is known so we set it 'always on' and will aim to only restart it during off-peak times if necessary.

但是，我们预计下个月服务器的负载会很重，在我们对自动缩放的测试中，我们发现当它添加额外的实例时，这些实例中的每一个都会经历相同的启动延迟 - 但流量是在当前运行的实例和正在预热的新实例之间拆分，例如在这 3 分钟内，一半的请求开始失败.

However, we expect heavy load to the server next month, and in our testing of the auto-scaling, we have found that when it adds additional instances, each of these instances goes through the same startup delay - but the traffic is split between the current running instance and the new one that's warming up so e.g. half of the requests start failing for that 3 minute period.

我们如何配置 Azure 以延迟使用新实例，直到它准备好?(或者我们应该使用例如 AWS 代替吗?).

How can we configure Azure to delay using the new instance until it is ready? (or should we be using e.g. AWS instead?).

一些文档指出使用自定义负载均衡器探针，但它主要讨论的是虚拟机，而我们使用的是 PAAS.

Some of the documentation points to using a custom Load Balancer Probe however it mainly talks about VM's whereas we are using PAAS.

推荐答案

尽量减少需要在 app_start 上加载的数据，并尝试在第一次请求时将数据延迟加载到缓存中.有时，即使在完成所有这些操作之后，我们最终还是会得到一开始就需要的大量数据.

Do try to reduce the data you need to load on app_start and try to lazy load data into Cache on first request. Some times even after doing all of this we do end up with large sets of data that is necessary on start.

我们有两种方法可以解决这个问题.

There are two ways we can approach this.

第一个，假设您正在使用内存缓存，并且应用程序的每个实例都需要在 App_Start 上填充其内存缓存.尝试使用外部缓存提供程序，例如 Azure Cache for Redis，您的新实例可以直接指向这个外部缓存，而无需重新加载数据.

One, assuming you are using in-memory caching and every instance of the app needs to hydrate its in-memory cache on App_Start. Try to use a external cache provider like Azure Cache for Redis, your new instance can just point to this external cache without having to reload the data.

二、可以依赖应用初始化模块IIS 7.5(安装在 Azure App Services 的 IIS 上).要使用此功能，您需要在 web.config 的 web.server 部分下添加 applicationInitialization 部分.这将帮助您在预热过程完成之前不使实例可用.这篇博文

Two, you can depend on Application Initialization Module which was introduced in IIS 7.5 (installed on Azure App Services' IIS). To use this feature, you need to add applicationInitialization section under web.server section of web.config. This will help you not make the instance available until the warm-up process is completed. More info on how to use ApplicationInitialization is available in this blog post

最好的情况是使用两者的组合，applicationInitialization 将指向您应用程序中的一个页面，该页面会检查外部缓存是否可用并已被水合，如果是，则完成，否则水合外部缓存.

The best case would be to use the combination of both, applicationInitialization will point at a page in your application which checks if the external cache is available and hydrated, if yes, complete, else hydrate the external cache.

这篇关于如何防止 azure 在其他实例准备好之前横向扩展它们?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！