Разработка с учетом горизонтального увеличения масштаба
Разработка приложения с учетом горизонтального масштабирования
Основным преимуществом облака является эластичное масштабирование — возможность использовать столько емкости, сколько вам нужно, масштабирование по мере увеличения нагрузки и масштабирование, если дополнительная емкость не требуется. Создайте приложение таким образом, чтобы оно могли горизонтально масштабироваться, добавлять или удалять экземпляры, сопоставляя предложение с спросом.
Масштабируемость измеряется по коэффициенту увеличения пропускной способности к увеличению ресурсов. В идеале в хорошо разработанной системе оба числа пропорциональны: двукратное выделение ресурсов удвоит пропускную способность. Масштабируемость обычно ограничивается введением узких мест или точек синхронизации в системе.
Рекомендации
Избегайте закрепления экземпляров. Закрепление экземпляров, или сходство сеансов, означает ситуацию, в которой запросы от конкретного клиента всегда направляются к одному и тому же серверу. Прилипание ограничивает возможность горизонтального масштабирования приложения. Например, трафик от пользователя с большим объемом не будет распространяться между экземплярами. Закрепление возникает по разным причинам, например при сохранении в памяти сведений о состоянии сеанса или при шифровании с использованием ключей конкретного компьютера. Следите за тем, чтобы любой экземпляр приложения всегда мог обработать любой запрос.
Определите узкие места. Горизонтальное масштабирование не станет панацеей от любых проблем с производительностью. Например, если узким местом является серверная база данных, дополнительные веб-серверы никак не улучшат ситуацию. Сначала найдите и устраните все узкие места в системе, и лишь затем пытайтесь решить проблему, добавляя новые экземпляры. Возникновение узких мест наиболее вероятно в компонентах, которые работают с отслеживанием состояния.
Разделите рабочие нагрузки на части в соответствии с требованиями к масштабируемости. В приложениях часто выполняется несколько рабочих нагрузок с разными требованиями к масштабированию. Например, в приложении может использоваться общедоступный веб-сайт и отдельный веб-интерфейс администрирования. На общедоступном сайте часто возникают непредвиденные всплески трафика, а нагрузка на сайт администрирования намного ниже и более предсказуема.
Разработка автономных и разделенных компонентов, взаимодействующих через асинхронные протоколы связи. В идеале компоненты должны иметь собственное, независимое состояние и использовать события для обмена данными об изменениях или действиях с внешними компонентами. Это помогает независимо масштабировать только перегруженный компонент. Реализуйте механизмы управления потоками для управления трафиком и снижения производительности. Потребители должны контролировать свой собственный уровень потребления. Производители должны контролировать свою собственную скорость передачи, включая остановку. Очереди сообщений являются хорошими способами поглощать дополнительную рабочую нагрузку и разрешать потребителям сбрасывать работу на своем досуге.
Избегайте бесполезного взаимодействия, координации и ожидания.
Выгрузите естественно асинхронные задачи. Задачи, такие как отправка сообщений электронной почты, действия, в которых пользователь не нуждается в немедленном ответе, и интеграция с другими системами являются хорошими местами для использования шаблонов асинхронного обмена сообщениями.
Разгружайте ресурсоемкие задачи. Задачи, которые требуют значительных ресурсов процессора или ввода-вывода, при возможности следует перемещать в фоновые задания, чтобы снизить нагрузку на внешний интерфейс, в котором обрабатываются запросы пользователей.
Автомасштабирование на основе метрик динамического использования и использование встроенных функций автомасштабирования. В многие вычислительные службы Azure встроена поддержка автомасштабирования. Если рабочая нагрузка приложения хорошо прогнозируется и регулярно изменяется, используйте горизонтальное увеличение масштаба по расписанию. Например, горизонтально увеличивайте масштаб приложения в рабочее время. Если же рабочая нагрузка плохо прогнозируется, используйте для автомасштабирования триггеры по метрикам производительности, таким как загрузка процессора и длина очереди. Наблюдайте за приложениями и их коммуникациями, чтобы определить узкие места и получить более точные решения. Также изучите наши рекомендации по автомасштабированию.
Используйте агрессивное автомасштабирование для критически важных рабочих нагрузок. Для критически важных рабочих нагрузок следует предвосхищать повышение интенсивности. При значительной нагрузке можно быстро добавить сразу несколько экземпляров для ускоренной обработки трафика, а затем постепенно уменьшать их количество.
Учитывайте возможность горизонтального уменьшения масштаба при разработке приложения. Не забывайте, что при гибком масштабировании нужно предусмотреть и периоды свертывания, когда выполняется горизонтальное уменьшение масштаба и удаляются некоторые экземпляры приложения. Приложение должно корректно обрабатывать удаление экземпляров. Вот несколько возможных способов для обработки свертывания:
- Прослушивайте сообщения о событиях завершения работы (если они доступны) и завершайте работу надлежащим образом.
- Клиенты (потребители) службы должны поддерживать обработку временных сбоев и выполнять повторные попытки.
- Длительно выполняемые задачи можно разделять на части, использовать для них контрольные точки или реализовать шаблон каналов и фильтров.
- Передавайте рабочие элементы в очередь, из которой они смогут перейти в другой экземпляр, если текущий будет удален в процессе обработки.
Рассмотрите возможность масштабирования для избыточности. Масштабирование может повысить надежность приложения. Например, рекомендуется масштабировать между несколькими зонами доступности, например с помощью служб, избыточных между зонами. Такой подход может повысить пропускную способность приложения, а также обеспечить устойчивость, если в одной зоне возникает сбой.
Модель и оптимизация масштабируемости системы. Вы можете использовать модель системы с помощью такого подхода, как закон Amdahl. Квалифицируйте масштабируемость на основе таких параметров, как состязание и когерентность. Спор относится к задержке из-за ожидания или очереди для общих ресурсов. Согласованность относится к задержке для обеспечения согласованности данных. Например, наличие высокого уровня конфликтов указывает на последовательную обработку, которая может быть параллелизирована, при наличии высокой согласованности предполагается чрезмерное количество зависимостей между процессами, что позволяет свести к минимуму взаимодействие. Во время проектирования рабочей нагрузки можно вычислить максимальную эффективную емкость системы, чтобы избежать предоставления большего объема предложения, чем спрос, что приводит к отходам.