Разработка требований для устойчивых приложений AzureDeveloping requirements for resilient Azure applications

Построение устойчивости (восстановление после сбоев) и доступности (запущенного в работоспособном состоянии без значительного увеличения времени простоя) в приложения начинается с сбора требований.Building resiliency (recovering from failures) and availability (running in a healthy state without significant downtime) into your apps begins with gathering requirements. Например какое время простоя приемлемо?For example, how much downtime is acceptable? Сколько стоит потенциального простоя вашего бизнеса?How much does potential downtime cost your business? Каковы требования к доступности ваших клиентов?What are your customer's availability requirements? Сколько вы инвестировать в создание приложения высокой доступности?How much do you invest in making your application highly available? Что такое риск и затраты?What is the risk versus the cost?

Определение различных рабочих нагрузокIdentify distinct workloads

Облачные решения обычно состоят из нескольких приложений рабочих нагрузок.Cloud solutions typically consist of multiple application workloads. Рабочая нагрузка представляет уникальных возможностей или задачу, которая логически отделена от других задач с точки зрения бизнес-логику и данные хранилища требований.A workload is a distinct capability or task that is logically separated from other tasks in terms of business logic and data storage requirements. Например приложение электронной коммерции может иметь следующие рабочие нагрузки:For example, an e-commerce app might have the following workloads:

  • просмотр и поиск в каталоге продукции;Browse and search a product catalog.
  • создание и отслеживание заказов;Create and track orders.
  • просмотр рекомендаций.View recommendations.

Каждая рабочая нагрузка имеет свои требования к доступности, масштабируемости, согласованности данных и аварийному восстановлению.Each workload has different requirements for availability, scalability, data consistency, and disaster recovery. Сделать бизнес-решений, балансировки затраты и риски для каждой рабочей нагрузки.Make your business decisions by balancing cost versus risk for each workload.

Кроме того, разделяйте рабочие нагрузки, цель уровня обслуживания.Also decompose workloads by service-level objective. Если служба состоит из важных и менее важных рабочих нагрузок, управления ими по-разному и укажите функции службы и число экземпляров, необходимый для соблюдения требований к доступности.If a service is composed of critical and less-critical workloads, manage them differently and specify the service features and number of instances needed to meet their availability requirements.

План для шаблонов использованияPlan for usage patterns

Определите различия в требованиях в критические и некритические периоды.Identify differences in requirements during critical and non-critical periods. Существуют ли определенные критические периоды, когда система должна быть доступной?Are there certain critical periods when the system must be available? Например приложение заполнения налоговых деклараций не может завершиться ошибкой во время крайним сроком их подачи и служба потоковой передачи видео не следует запаздывания во время события прямой трансляции.For example, a tax-filing application can't fail during a filing deadline and a video streaming service shouldn't lag during a live event. В таких ситуациях взвесить издержки с риском.In these situations, weigh the cost against the risk.

  • Для обеспечения бесперебойной работы и удовлетворения соглашение об уровне обслуживания (SLA) в критические периоды, планировать избыточность в нескольких регионах в случае сбоя одного, даже если он стоит дороже.To ensure uptime and meet service-level agreements (SLAs) in critical periods, plan redundancy across several regions in case one fails, even if it costs more.
  • И наоборот некритические периоды, запустите приложение в одном регионе, чтобы свести к минимуму затраты.Conversely, during non-critical periods, run your application in a single region to minimize costs.
  • В некоторых случаях можно избежать дополнительных расходов, с помощью современных бессерверных методов, имеющих выставления счетов на основе потребления.In some cases, you can mitigate additional expenses by using modern serverless techniques that have consumption-based billing.

Установить показатели доступности и восстановленияEstablish availability and recovery metrics

Создание исходных значений для двух наборов метрик как часть процесса требования.Create baseline numbers for two sets of metrics as part of the requirements process. Первый набор поможет вам определить место добавления избыточность для облачных служб и какие соглашения об уровне обслуживания для обеспечения для клиентов.The first set helps you determine where to add redundancy to cloud services and which SLAs to provide to customers. Второй набор поможет при планировании аварийного восстановления.The second set helps you plan your disaster recovery.

Метрики доступностиAvailability metrics

Эти меры можно используйте для планирования для обеспечения избыточности и определить соглашения об уровне обслуживания клиентов.Use these measures to plan for redundancy and determine customer SLAs.

  • Среднее время восстановления (MTTR) среднее время, необходимое для восстановления после сбоя компонента.Mean time to recover (MTTR) is the average time it takes to restore a component after a failure.
  • Среднее время между сбоев (MTBF) , как долго компонент может рассчитывать на длительный период между простоев.Mean time between failures (MTBF) is the how long a component can reasonably expect to last between outages.

Метрики восстановленияRecovery metrics

Получение этих значений с Проведение оценки риска и убедитесь, что вы понимаете, стоимость и риск простоя и потерю данных.Derive these values by conducting a risk assessment, and make sure you understand the cost and risk of downtime and data loss. Это нефункциональные требования системы и зависит от бизнес-требований.These are nonfunctional requirements of a system and should be dictated by business requirements.

  • Время восстановления (RTO) — это максимальное время допустимо, приложение недоступно после инцидента.Recovery time objective (RTO) is the maximum acceptable time an application is unavailable after an incident.
  • Точки восстановления (RPO) — это максимальная продолжительность потери данных, которая является приемлемой во время аварии.Recovery point objective (RPO) is the maximum duration of data loss that's acceptable during a disaster.

Если значение MTTR любой наиболее важным компонентом в настройки с высокой доступностью превышает RTO система, сбой в системе может привести к неприемлемой бизнес-процессов.If the MTTR value of any critical component in a highly available setup exceeds the system RTO, a failure in the system might cause an unacceptable business disruption. А это значит, что вы не сможете восстановить систему в рамках определенного значения RTO.That is, you can't restore the system within the defined RTO.

Определение целевых показателей доступности рабочей нагрузкиDetermine workload availability targets

Определите свои собственные целевые соглашения об уровне обслуживания для каждой рабочей нагрузки в решении, чтобы можно было определить, соответствует ли архитектура бизнес-требования.Define your own target SLAs for each workload in your solution so you can determine whether the architecture meets the business requirements.

Учитывать стоимость и сложностьConsider cost and complexity

Равных, более высокая доступность лучше.Everything else being equal, higher availability is better. Однако как вы стремитесь к дополнительные девятки, стоимость и сложность увеличиваться.But as you strive for more nines, the cost and complexity grow. Время непрерывной работы 99,99% преобразуется около пяти минут общее время простоя в месяц.An uptime of 99.99% translates to about five minutes of total downtime per month. Стоит ли дополнительную сложность и стоимость для достижения 99,999%?Is it worth the additional complexity and cost to reach five nines? Ответ зависит от бизнес-требований.The answer depends on the business requirements.

Ниже приведены некоторые рекомендации по выбору SLA:Here are some other considerations when defining an SLA:

  • Чтобы добиться четыре девятки (99,99%), нельзя полагаться на ручное вмешательство для восстановления после сбоев.To achieve four nines (99.99%), you can't rely on manual intervention to recover from failures. Приложение должно иметь возможности самостоятельной диагностики и самовосстановления.The application must be self-diagnosing and self-healing.
  • За четыре девятки сложно обнаружении сбоев достаточно быстро, в соответствии с соглашением об уровне ОБСЛУЖИВАНИЯ.Beyond four nines, it's challenging to detect outages quickly enough to meet the SLA.
  • Подумайте о временном окне, для которого измеряется SLA.Think about the time window that your SLA is measured against. Чем меньше окно, тем строже допуски.The smaller the window, the tighter the tolerances. Нет смысла определять SLA с точки зрения ежечасного или ежедневного времени работы.It doesn't make sense to define your SLA in terms of hourly or daily uptime.
  • Проанализируйте результаты измерений MTBF и MTTR.Consider the MTBF and MTTR measurements. Чем выше уровень ОБСЛУЖИВАНИЯ, тем реже службы можно перейти и более быстрые необходимо восстановить службу.The higher your SLA, the less frequently the service can go down and the quicker the service must recover.
  • Получить соглашение о заказчиках для целевых показателей доступности каждой части приложения и ее следует задокументировать.Get agreement from your customers for the availability targets of each piece of your application, and document it. В противном случае ваш проект может не соответствовать ожиданиям клиентов.Otherwise, your design may not meet the customers' expectations.

Определить зависимостиIdentify dependencies

Выполните упражнения сопоставление зависимостей для определения внутренних и внешних зависимостях.Perform dependency-mapping exercises to identify internal and external dependencies. Примеры включают зависимости, относящиеся к безопасности или удостоверение, например Active Directory или сторонних служб, таких как поставщика платежных услуг или электронной почты службы обмена сообщениями.Examples include dependencies relating to security or identity, such as Active Directory, or third-party services such as a payment provider or e-mail messaging service.

Обратите особое внимание на внешние зависимости, которые могут представлять собой единую точку отказа или узких мест.Pay particular attention to external dependencies that might be a single point of failure or cause bottlenecks. Если рабочей нагрузки требуется 99,99%, но зависит от службы с 99,9% времени, эта служба не может быть единой точкой отказа в системе.If a workload requires 99.99% uptime but depends on a service with a 99.9% SLA, that service can't be a single point of failure in the system. Одним из средств защиты является наличие резервного пути в случае сбоя службы.One remedy is to have a fallback path in case the service fails. Кроме того можно принять другие меры для восстановления после сбоя в этой службе.Alternatively, take other measures to recover from a failure in that service.

В следующей таблице показано потенциальное суммарное время простоя для различных уровней SLA.The following table shows the potential cumulative downtime for various SLA levels.

Соглашение об уровне обслуживанияSLA Время простоя в неделюDowntime per week Время простоя в месяцDowntime per month Время простоя в годDowntime per year
99 %99% 1,68 часа1.68 hours 7,2 часа7.2 hours 3,65 дня3.65 days
99,9%99.9% 10,1 минуты10.1 minutes 43,2 мин43.2 minutes 8,76 часа8.76 hours
99,95 %99.95% 5 минут5 minutes 21,6 мин21.6 minutes 4,38 часа4.38 hours
99,99 %99.99% 1,01 минуты1.01 minutes 4,32 минуты4.32 minutes 52,56 минуты52.56 minutes
99,999 %99.999% 6 секунд6 seconds 25,9 секунды25.9 seconds 5,26 минуты5.26 minutes

Понять, соглашение об уровне обслуживанияUnderstand service-level agreements

В Azure соглашение об уровне обслуживания описываются обязательства корпорации Майкрософт в отношении доступности и подключения.In Azure, the Service Level Agreement describes Microsoft's commitments for uptime and connectivity. Если соглашение об уровне ОБСЛУЖИВАНИЯ для конкретной службы составляет 99,9%, следует ожидать, служба будет доступна 99,9% времени.If the SLA for a particular service is 99.9%, you should expect the service to be available 99.9% of the time. Разные службы используют разные соглашения об уровне обслуживания.Different services have different SLAs.

Соглашение об уровне ОБСЛУЖИВАНИЯ Azure также включены положения о получении кредита на службу, если соглашение об уровне ОБСЛУЖИВАНИЯ не выполняются, а также конкретные определения доступности для каждой службы.The Azure SLA also includes provisions for obtaining a service credit if the SLA is not met, along with specific definitions of availability for each service. Этот аспект SLA действует как политика принудительного применения.That aspect of the SLA acts as an enforcement policy.

Составные соглашения об уровне обслуживанияComposite SLAs

Составные соглашения об уровне обслуживания задействовать несколько служб, которые поддерживает приложение, каждый с разным уровнем доступности.Composite SLAs involve multiple services supporting an application, each with differing levels of availability. Например рассмотрим веб-приложение службы приложений, который записывает в базу данных SQL Azure.For example, consider an App Service web app that writes to Azure SQL Database. На момент написания статьи эти службы Azure имеют следующие соглашения об уровне обслуживания:At the time of this writing, these Azure services have the following SLAs:

  • Веб-приложениях службы приложений — 99,95%App Service web apps = 99.95%
  • База данных SQL — 99,99 %.SQL Database = 99.99%

Каково максимальное время простоя, ожидаемое для этого приложения?What is the maximum downtime you would expect for this application? Если какая-либо из служб завершается ошибкой, приложение также прекращает работу.If either service fails, the whole application fails. Вероятность сбоя каждой службы независима, поэтому составное SLA для этого приложения составляет 99,95% × 99,99% = 99,94%.The probability of each service failing is independent, so the composite SLA for this application is 99.95% × 99.99% = 99.94%. Это ниже, чем отдельные SLA, что не удивительно, так как приложение, которое зависит от нескольких служб имеет больше потенциальных точек отказа.That's lower than the individual SLAs, which isn't surprising because an application that relies on multiple services has more potential failure points.

Составное SLA можно усовершенствовать, создав независимые резервные пути.You can improve the composite SLA by creating independent fallback paths. Например, если база данных SQL недоступна, поместите транзакции в очереди для последующей обработки.For example, if SQL Database is unavailable, put transactions into a queue to be processed later.

Составное соглашение об уровне обслуживания

При такой структуре приложение по-прежнему доступно, даже если оно не может подключиться к базе данных.With this design, the application is still available even if it can't connect to the database. Тем не менее, оно завершится сбоем, если одновременно произойдет сбой базы данных и очереди.However, it fails if the database and the queue both fail at the same time. Ожидаемый процент времени для одновременного сбоя является 0,0001 × 0,001, поэтому составное SLA для этого комбинированного пути:The expected percentage of time for a simultaneous failure is 0.0001 × 0.001, so the composite SLA for this combined path is:

  • База данных или очередь = 1,0 − (0,0001 × 0,001) = 99,99999%Database or queue = 1.0 − (0.0001 × 0.001) = 99.99999%

Общий уровень SLA:The total composite SLA is:

  • Веб-приложения и (база данных или очереди) = 99,95% x 99,99999% = ~99,95%Web app and (database or queue) = 99.95% × 99.99999% = ~99.95%

Не лишен недостатков этого подхода.There are tradeoffs to this approach. Логика приложения сложнее, вы платите за очереди и необходимо учитывать проблемы согласованности данных.The application logic is more complex, you are paying for the queue, and you need to consider data consistency issues.

Соглашения об уровне обслуживания для развертываний в нескольких регионахSLAs for multiregion deployments

Соглашения об уровне обслуживания для развертываний в нескольких регионах включают в себя методика высокого уровня доступности развернуть приложение в нескольких регионах и использовать диспетчер трафика Azure для отработки отказа при сбое приложения в одном регионе.SLAs for multiregion deployments involve a high-availability technique to deploy the application in more than one region and use Azure Traffic Manager to fail over if the application fails in one region.

Для развертывания нескольких регионах составное SLA рассчитывается следующим образом:The composite SLA for a multiregion deployment is calculated as follows:

  • N является составное SLA для приложения, развернутого в одном регионе.N is the composite SLA for the application deployed in one region.
  • R является количество регионов, где развернуто приложение.R is the number of regions where the application is deployed.

Ожидаемая вероятность того, происходит сбой приложения во всех регионах, в то же время является ((1 − N) ^ R).The expected chance that the application fails in all regions at the same time is ((1 − N) ^ R). Например, если в одном регионе соглашение об уровне ОБСЛУЖИВАНИЯ — 99,95%:For example, if the single-region SLA is 99.95%:

  • Объединенный соглашение об уровне ОБСЛУЖИВАНИЯ для двух регионов = (− 1 (1 − 0.9995) ^ 2) = 99.999975%The combined SLA for two regions = (1 − (1 − 0.9995) ^ 2) = 99.999975%
  • Объединенный соглашение об уровне ОБСЛУЖИВАНИЯ для четырех регионах = (− 1 (1 − 0.9995) ^ 4) = 99.999999%The combined SLA for four regions = (1 − (1 − 0.9995) ^ 4) = 99.999999%

Соглашение об уровне ОБСЛУЖИВАНИЯ для диспетчера трафика также является фактором.The SLA for Traffic Manager is also a factor. Отработка отказа не происходит мгновенно в активно пассивной конфигурации, которые могут привести к простою во время отработки отказа.Failing over is not instantaneous in active-passive configurations, which can result in downtime during a failover. См. в разделе мониторинг конечных точек диспетчера трафика.See Traffic Manager endpoint monitoring and failover.

Дальнейшие действияNext steps