В этой статье показано, как применить шаблон Reliable Web App. Шаблон Reliable Web App — это набор принципов и методов реализации, определяющих способ изменения веб-приложений (переплатформ) при миграции в облако. Он фокусируется на минимальных обновлениях кода, необходимых для успешного выполнения в облаке.
Чтобы упростить применение этого руководства, существует эталонная реализация шаблона Reliable Web App, который можно развернуть.
Архитектура эталонной реализации. Скачайте файл Visio этой архитектуры.
В следующем руководстве в качестве примера используется эталонная реализация. Чтобы спланировать реализацию шаблона Reliable Web App, выполните следующие действия.
Определение бизнес-целей
Первоначальный шаг перехода на облачные вычисления — сформулировать бизнес-цели. Шаблон Reliable Web App подчеркивает важность настройки как непосредственных, так и будущих целей для веб-приложения. Эти цели влияют на выбор облачных служб и архитектуру веб-приложения в облаке.
Пример: вымышленная компания Relecloud продает билеты через локальное веб-приложение. Relecloud имеет положительный прогноз продаж и ожидает повышенного спроса на их веб-приложение для билетов. Для удовлетворения этого требования они определили цели веб-приложения:
- Применение изменений кода с низкими затратами и высокой стоимостью
- Достичь цели уровня обслуживания (SLO) 99,9%
- Внедрение методик DevOps
- Создание оптимизированных для затрат сред
- Повышение надежности и безопасности
Локальная инфраструктура Relecloud не была экономически эффективным решением для достижения этих целей. Поэтому они решили, что перенос веб-приложения в Azure является самым экономичным способом достижения своих непосредственных и будущих целей.
Выбор правильных управляемых служб
При перемещении веб-приложения в облако следует выбрать службы Azure, которые соответствуют вашим бизнес-требованиям и соответствуют текущим функциям локального веб-приложения. Выравнивание помогает свести к минимуму усилия по переформировки. Например, используйте службы, которые позволяют поддерживать один и тот же ядро СУБД и поддерживать существующие по промежуточного слоя и платформы. В следующих разделах приведены рекомендации по выбору нужных служб Azure для веб-приложения.
Пример. До перехода в облако веб-приложение Relecloud для билетов было локальным монолитным приложением ASP.NET. Она выполнялась на двух виртуальных машинах и имела базу данных Microsoft SQL Server. Веб-приложение страдало от распространенных проблем в развертывании масштабируемости и функций. Эта отправная точка, их бизнес-цели и SLO привели к выбору их услуг.
Платформа приложений
Выберите лучшую платформу размещения приложений для веб-приложения. Azure имеет множество различных вариантов вычислений для удовлетворения ряда требований к веб-приложениям. Сведения о сужающих параметрах см. в дереве принятия решений вычислений Azure.
Пример: Relecloud выбрал службу приложение Azure в качестве платформы приложений по следующим причинам:
Соглашение об уровне обслуживания (SLA): оно имеет высокий уровень обслуживания, соответствующий производственной среде SLO 99,9%.
Сокращение затрат на управление. Это полностью управляемое решение, которое обрабатывает масштабирование, проверка работоспособности и балансировку нагрузки.
Поддержка .NET: она поддерживает версию .NET, написанную приложением.
Возможность контейнеризации. Веб-приложение может конвергентироваться в облаке без контейнеризации, но платформа приложений также поддерживает контейнеризацию без изменения служб Azure.
Автомасштабирование. Веб-приложение может автоматически масштабироваться вверх, вниз, в и выходить на основе пользовательского трафика и параметров.
Управление удостоверениями
Выберите оптимальное решение для управления удостоверениями для веб-приложения. Дополнительные сведения см. в статье "Сравнение решений по управлению удостоверениями" и методов проверки подлинности.
Пример: Relecloud выбрал идентификатор Microsoft Entra по следующим причинам:
Проверка подлинности и авторизация. Приложение должно пройти проверку подлинности и авторизовать сотрудников центра обработки вызовов.
Масштабируемость: масштабируется для поддержки более крупных сценариев.
Управление удостоверениями пользователей: сотрудники центра обработки вызовов могут использовать имеющиеся корпоративные удостоверения.
Поддержка протокола авторизации: она поддерживает OAuth 2.0 для управляемых удостоверений.
База данных
Выберите лучшую базу данных для веб-приложения. Сведения об сужении параметров см. в дереве принятия решений хранилища данных Azure.
Пример. Веб-приложение использовало локальное приложение SQL Server и Relecloud, чтобы использовать существующую схему базы данных, хранимые процедуры и функции. Несколько продуктов SQL доступны в Azure, но Relecloud выбрал База данных SQL Azure по следующим причинам:
Надежность. Уровень общего назначения обеспечивает высокий уровень обслуживания и избыточность в нескольких регионах. Он может поддерживать высокую нагрузку пользователя.
Сокращение затрат на управление: предоставляется управляемый экземпляр базы данных SQL.
Поддержка миграции. Она поддерживает миграцию базы данных из локальной среды SQL Server.
Согласованность с локальными конфигурациями: она поддерживает существующие хранимые процедуры, функции и представления.
Устойчивость. Она поддерживает резервное копирование и восстановление на определенный момент времени.
Опыт и минимальная переработка: База данных SQL использует преимущества внутреннего опыта и требует минимальной работы для принятия.
Мониторинг производительности приложения
Выберите мониторинг производительности приложения для веб-приложения. Приложение Аналитика — это решение для управления производительностью приложений Azure (APM). Это функция решения для мониторинга Azure, Azure Monitor.
Пример: Relecloud решил использовать приложение Аналитика по следующим причинам:
Интеграция с Azure Monitor. Она обеспечивает лучшую интеграцию с Azure Monitor.
Обнаружение аномалий: оно автоматически обнаруживает аномалии производительности.
Устранение неполадок. Это помогает диагностировать проблемы в работающем приложении.
Мониторинг. Он собирает сведения о том, как пользователи используют приложение, и позволяет легко отслеживать пользовательские события.
Разрыв видимости. Локальное решение не было решения для мониторинга производительности приложений. Приложение Аналитика обеспечивает простую интеграцию с платформой приложений и кодом.
Cache
Выберите, следует ли добавлять кэш в архитектуру веб-приложения. Кэш Azure для Redis — это основное решение кэша Azure. Это управляемое хранилище данных в памяти на основе программного обеспечения Redis.
Пример: загрузка веб-приложения Relecloud сильно сложена на просмотр концертов и сведений о месте проведения. Он добавил Кэш Azure для Redis по следующим причинам:
Сокращение затрат на управление: это полностью управляемая служба.
Скорость и объем. Он имеет высокую пропускную способность и низкую задержку чтения для часто доступного, медленно меняющегося данных.
Разнообразная поддержка: это единое расположение кэша для всех экземпляров веб-приложения для использования.
Внешнее хранилище данных: локальные серверы приложений выполнили кэширование локальной виртуальной машины. Эта настройка не выгружает часто задаваемые данные, и не удалось сделать недопустимые данные.
Нестистиковые сеансы: состояние сеанса внешних данных поддерживает нестистиковые сеансы.
Подсистема балансировки нагрузки
Выберите лучший балансировщик нагрузки для веб-приложения. Azure имеет несколько подсистем балансировки нагрузки. Дополнительные сведения о сужающих параметрах см . в разделе "Выбор оптимальной подсистемы балансировки нагрузки" для вашего приложения.
Пример: Relecloud требует подсистемы балансировки нагрузки уровня 7, которая может направлять трафик в нескольких регионах. Relecloud требуется мультирегионное веб-приложение для удовлетворения SLO 99,9%. Relecloud выбрал Azure Front Door по следующим причинам:
Глобальная балансировка нагрузки: это подсистема балансировки нагрузки уровня 7, которая может направлять трафик в нескольких регионах.
Брандмауэр веб-приложения: он интегрируется изначально с Azure Брандмауэр веб-приложений.
Гибкость маршрутизации. Это позволяет группе приложений настраивать входящий трафик, который должен поддерживать будущие изменения в приложении.
Ускорение трафика. Он использует любую рассылку для достижения ближайшей точки присутствия Azure и поиска самого быстрого маршрута к веб-приложению.
Личные домены: он поддерживает пользовательские доменные имена с гибкой проверкой домена.
Пробы работоспособности: приложению требуется интеллектуальный мониторинг проб работоспособности. Azure Front Door использует ответы из пробы, чтобы определить лучший источник для маршрутизации клиентских запросов.
Поддержка мониторинга. Она поддерживает встроенные отчеты со всеми панелями мониторинга как для Front Door, так и для шаблонов безопасности. Вы можете настроить оповещения, которые интегрируются с Azure Monitor. Он позволяет журналу приложений каждый запрос и неудачные пробы работоспособности.
Защита от атак DDoS: она имеет встроенную защиту от атак DDoS уровня 3-4.
Сеть доставки содержимого: он позиционирует Relecloud для использования сети доставки содержимого. Сеть доставки содержимого обеспечивает ускорение сайта.
Брандмауэр веб-приложения
Выберите брандмауэр веб-приложения для защиты веб-приложения от веб-атак. Azure Брандмауэр веб-приложений (WAF) — это брандмауэр веб-приложения Azure и обеспечивает централизованную защиту от распространенных веб-эксплойтов и уязвимостей.
Пример: Relecloud, необходимый для защиты веб-приложения от веб-атак. Они использовали Azure Брандмауэр веб-приложений по следующим причинам:
Глобальная защита: она обеспечивает улучшенную глобальную защиту веб-приложений без ущерба для производительности.
Защита botnet: команда может отслеживать и настраивать решения проблем безопасности из ботнетов.
Паритетность с локальной средой: локальное решение выполнялось за брандмауэром веб-приложения, управляемым ИТ-службой.
Простота использования: Брандмауэр веб-приложений интегрируется с Azure Front Door.
Хранилище конфигурации
Выберите, следует ли добавлять хранилище конфигурации приложений в веб-приложение. Конфигурация приложений Azure — это служба для централизованного управления параметрами приложения и флагами компонентов. Ознакомьтесь с рекомендациями Конфигурация приложений, чтобы решить, подходит ли эта служба для вашего приложения.
Пример: Relecloud хотел заменить конфигурацию на основе файлов центральным хранилищем конфигурации, которое интегрируется с платформой приложений и кодом. Они добавили Конфигурация приложений в архитектуру по следующим причинам:
Гибкость. Она поддерживает флаги функций. Флаги функций позволяют пользователям отказаться от ранних предварительных версий функций в рабочей среде без повторного развертывания приложения.
Поддерживает конвейер Git: источник истины для данных конфигурации, необходимых для репозитория Git. Конвейер, необходимый для обновления данных в центральном хранилище конфигурации.
Поддерживает управляемые удостоверения: она поддерживает управляемые удостоверения для упрощения и защиты подключения к хранилищу конфигураций.
Диспетчер секретов
Используйте Azure Key Vault , если у вас есть секреты для управления в Azure. Вы можете включить Key Vault в приложения .NET с помощью объекта ConfigurationBuilder.
Пример: локальное веб-приложение Relecloud хранит секреты в файлах конфигурации кода, но это более эффективная практика для внешнего использования секретов. Хотя управляемые удостоверения являются предпочтительным решением для подключения к ресурсам Azure, Relecloud имел секреты приложений, которым они необходимы для управления. Relecloud использовал Key Vault по следующим причинам:
Шифрование: оно поддерживает шифрование при хранении и передаче.
Управляемые удостоверения: службы приложений могут использовать управляемые удостоверения для доступа к хранилищу секретов.
Мониторинг и ведение журнала. Это упрощает доступ к аудиту и создает оповещения при изменении хранимых секретов.
Интеграция. Она обеспечивает встроенную интеграцию с хранилищем конфигурации Azure (Конфигурация приложений) и платформой веб-размещения (Служба приложений).
решение служба хранилища
Выберите лучшее решение для хранилища для веб-приложения. Дополнительные сведения см. в разделе "Просмотр параметров хранилища".
Пример. Локальное веб-приложение подключено к каждому веб-серверу, но команда хотела использовать внешнее решение для хранения данных. Relecloud выбрал Хранилище BLOB-объектов Azure по следующим причинам:
Безопасный доступ: веб-приложение может устранить конечные точки для доступа к хранилищу, доступ к общедоступному Интернету с анонимным доступом.
Шифрование. Он шифрует неактивных и передаваемых данных.
Устойчивость. Она поддерживает избыточное между зонами хранилище (ZRS). Хранилище, избыточное между зонами, реплика выполняет синхронную синхронизацию между тремя зонами доступности Azure в основном регионе. Каждая зона доступности находится в отдельном физическом расположении с независимым питанием, охлаждением и сетью. Эта конфигурация должна сделать образы билетов устойчивыми к потере.
безопасность конечных точек.
Выберите, чтобы включить частный доступ только к службам Azure. Приватный канал Azure предоставляет доступ к решениям платформы как услуга через частную конечную точку в виртуальной сети. Трафик между виртуальной сетью и службой перемещается по магистральной сети Майкрософт.
Пример: Relecloud использовал Приватный канал по следующим причинам:
Расширенное взаимодействие с безопасностью. Это позволяет приложению приватно обращаться к службам на платформе Azure и сокращает сетевой объем хранилищ данных для защиты от утечки данных.
Минимальные усилия: частные конечные точки поддерживают платформу веб-приложения и платформу базы данных, использует веб-приложение. Обе платформы зеркало существующие локальные конфигурации для минимального изменения.
Безопасность сети
Выберите, следует ли добавлять службы безопасности сети в виртуальные сети. Брандмауэр Azure — это сетевой брандмауэр с отслеживанием состояния, который проверяет сетевой трафик. Бастион Azure позволяет безопасно подключаться к виртуальным машинам без предоставления портов RDP/SSH.
Пример: Relecloud принял концентратор и периферийную топологию сети и хотел поместить общие службы безопасности сети в концентратор. Брандмауэр Azure повышает безопасность, проверяя весь исходящий трафик с периферийных узлов, чтобы повысить безопасность сети. Relecloud требуется Бастион Azure для безопасных развертываний из узла перехода в подсети DevOps.
Выбор правильной архитектуры
После определения доступных средств для веб-приложения и выбора лучших облачных служб необходимо определить лучшую архитектуру для веб-приложения. Архитектура должна поддерживать бизнес-требования, технические требования и SLO.
Выбор избыточности архитектуры
Бизнес-цели определяют уровень инфраструктуры и избыточности данных, необходимых веб-приложению. SLO веб-приложения предоставляет хорошие базовые показатели для понимания требований к избыточности. Вычислите составное соглашение об уровне обслуживания для всех зависимостей по критическому пути доступности. Зависимости должны включать службы Azure и решения, отличные от Майкрософт.
Назначьте оценку доступности для каждой зависимости. Соглашения об уровне обслуживания (соглашения об уровне обслуживания) обеспечивают хорошую отправную точку, но соглашения об уровне обслуживания не учитывают код, стратегии развертывания и решения об архитектуре подключения.
Пример: Relecloud определил службы по критическому пути доступности. Они использовали соглашения об уровне обслуживания Azure для оценки доступности. На основе составного вычисления соглашения об уровне обслуживания Relecloud требуется архитектура с несколькими регионами для удовлетворения SLO 99,9%.
Выбор топологии сети
Выберите правильную топологию сети для ваших веб-приложений и сетевых требований. Топология сети концентратора и периферийной сети является стандартной конфигурацией в Azure. Она обеспечивает преимущества затрат, управления и безопасности. Он также поддерживает варианты гибридного подключения к локальным сетям.
Пример: Relecloud выбрал концентратор и периферийную топологию сети, чтобы повысить безопасность развертывания в нескольких регионах при снижении затрат и затрат на управление.
Выбор избыточности данных
Обеспечение надежности данных путем распространения данных в регионах и зонах доступности Azure; чем больше географическое разделение, тем выше надежность.
Задайте целевую точку восстановления (RPO). RPO определяет максимальную допустимую потерю данных во время сбоя, определяя частоту реплика данных. Например, RPO за один час означает принятие до часа потери данных.
Реализуйте реплика данных. Выравнивание реплика данных с архитектурой и RPO. Azure обычно поддерживает синхронную реплика tion в зонах доступности. Использование нескольких зон для упрощения повышения надежности. Для веб-приложений с несколькими регионами в активно-пассивной установке реплика te data to the passive region as per the web app's RPO, гарантируя, что частота реплика tion превышает RPO. Для конфигураций "активный— активный" требуется синхронизация данных в режиме реального времени в разных регионах, что может потребовать корректировки кода.
Создайте план отработки отказа. Разработка плана отработки отказа (аварийного восстановления) для определения стратегий реагирования на сбои, определяемых временем простоя или потерей функциональных возможностей. Укажите цели времени восстановления (RTO) для максимально допустимого времени простоя. Убедитесь, что процесс отработки отказа быстрее RTO. Определите механизмы автоматической или ручной отработки отказа для согласованности и управления, а также подробно о возвращении к обычному процессу операций. Проверьте план отработки отказа, чтобы обеспечить эффективность.
Следующий шаг
В этой статье показано, как спланировать реализацию шаблона Reliable Web App. Следующим шагом является применение методов реализации шаблона Reliable Web App.