Проектирование архитектуры для облака с применением Microsoft Azure Web Sites

При проектировании облачного решения следует помнить одну важную вещь: всегда рассчитывайте на сбой. Однако архитектура многих приложений не отвечает этому требованию. Главная причина этого — отсутствие понимания того, как проектировать достаточно отказоустойчивую архитектуру с применением Microsoft Azure Web Sites. Итак, каким образом создается облачное решение, достаточно надежное для обработки сбоев? В этом статье мы обсудим методы, которые вы можете применять для проектирования такой системы.

Один экземпляр веб-сайта

Azure Web Sites предоставляют планы хостинга нескольких уровней: Free, Shared, Basic и Standard. Уровни Free и Shared обеспечивают сайты общей инфраструктурой, т. е. ваши сайты используют ресурсы совместно с другими сайтами. На уровнях Basic и Standard вашим сайтам предоставляются выделенная инфраструктура, а значит, только сайт или сайты, которые вы сопоставили со своим планом, будут использовать эти ресурсы.

На этих уровнях вы можете конфигурировать свой план веб-хостинга на использование одного или более экземпляров виртуальной машины (VM). Эти уровни могут поддерживать малые, средние и большие экземпляры. Провайдер будет управлять этими VM за вас, т. е. вам никогда не потребуется волноваться об обновлениях ОС или безопасности и конфигурации.

Для выполнения веб-сайта производственного уровня в Azure Web Sites рекомендуется выбирать уровень Basic или Standard в зависимости от размера вашего приложения и объема трафика, направленного на ваш веб-сайт. Хорошей отправной точкой является четкое понимание требований вашего приложения.

1. Какие компоненты нужны приложению — база данных, провайдер электронной почты, кеш и др.?
2. Какие компоненты подвержены риску сбоев и нуждаются в дублировании?
3. Какая функциональность вам нужна — SSL, промежуточные слоты (staging slots) и др.?
4. С каким объемом трафика должен справляться веб-сайт?

Ответив на эти вопросы, вы можете создать один веб-сайт и добавлять в приложение такие компоненты, как база данных и кеш, только по мере необходимости. На рис. 1 видно, как можно спроектировать архитектуру одного веб-сайта и его компонентов-зависимостей.

В сценарии с одним веб-сайтом самый крупный подвох заключается в том, что в случае сервисного обслуживания любого компонента (веб-сайта, базы данных или сервиса кеша) ваш веб-сайт будет недоступен в течение этого периода, что отразится на вашей клиентуре и вашем бизнесе.

Рис. 1. Стандартная архитектура для одного веб-сайта

В этом проекте не учтены риски, связанные с облачным решением, и не предусмотрено никаких мер для их исключения. В облачной среде ваша цель при проектировании должна заключаться в том, чтобы создать веб-сайт с высокой доступностью, сведя к минимуму простои и ускоряя восстановление при авариях.

Цель — высокая доступность

Стек типичного веб-приложения в Azure Web Sites будет состоять из веб-приложения, базы данных, Azure Storage и какой-то формы кеша. Все эти компоненты жестко связаны во избежание того, что какая-то одна сущность или компонент станет единой точкой сбоя (single point of failure, SPOF). Это главный критерий в проектировании архитектуры для любого облачного решения. Цель заключается в том, чтобы:

• избежать SPOF в архитектуре;
• ввести избыточность между каждым уровнем в архитектуре.

Azure Web Sites обеспечивает SLA (соглашение по уровню обслуживания) на уровне 99,9%. Это означает, что вы можете ожидать простой в течение примерно десяти минут в неделю из-за плановых развертываний или обновлений, выполняемых сервисом Azure Web Sites. Тем не менее, 10 мин простоя может серьезно отразиться на вашем бизнесе. Вашей целью должно быть такое проектирование решения, чтобы смягчить ущерб от таких простоев и быть в состоянии обслуживать своих клиентов, тем самым снижая риск негативного эффекта. Вы должны стремиться к созданию веб-архитектуры с высокой доступностью, как показано на рис. 2.

Увеличить
Рис. 2. Пример веб-архитектуры с высокой доступностью

Высокая доступность на уровне веб-приложения

Azure Web Sites создает облачное решение без поддержки состояний для вашего веб-приложения. Вам нужно продумать следующие моменты при проектировании в расчете на высокую доступность на уровне приложения.

1. Используйте режим Standard для веб-сайтов и укажите выполнение минимум двух экземпляров веб-сайтов.
2. В зависимости от шаблона вашего трафика сымитируйте нагрузки для тестирования с помощью различных средств, например Visual Studio и Apache JMeter (jmeter.apache.org), чтобы определить размер экземпляра и количество экземпляров, требуемых для вашего веб-сайта; эти параметры должны быть такими, чтобы веб-сайт справлялся с реальными уровнями трафика.
3. Обеспечьте централизованное хранение пользовательских и сеансовых данных в базе данных или в распределенном кеше. В Azure Web Sites все VM при выполнении в режиме Standard используют один файловый сервер.
4. Реплицируйте уровень веб-приложения минимум в два региона, поддерживаемые Azure Web Sites.
5. Пользовательский контент вроде медийной информации и документов, загружаемых на ваш веб-сайт, следует хранить под учетной записью Azure Storage. Убедитесь, что эта учетная запись относится к тому же географическому региону, что и веб-сайт, — это уменьшает задержки.
6. Всегда следуйте правилам безопасного кодирования, чтобы ваше приложение было устойчиво к атакам.

Высокая доступность на уровне баз данных

Данные — вот что генерирует реальную ценность в любом приложении, поэтому вы должны эффективно управлять ими. Чтобы ваше приложение корректно функционировало, крайне важно избегать создания единой точки сбоя на уровне баз данных. Azure Web Sites поддерживает Azure SQL Database и MySQL-сервис ClearDB. Оба предоставляют варианты, рассчитанные на самые разные решения — от минимальных до премиум-класса.

Azure SQL Database Premium предлагает более предсказуемую производительность и более высокую емкость для облачных приложений, использующих Azure Web Sites. В этом случае выделяется фиксированный объем резервной емкости под базу данных, включая встроенные средства репликации базы данных. Резервная емкость идеальна для следующего.

• Высокая пиковая нагрузка Приложение, которое требует больших процессорных ресурсов, памяти или интенсивного ввода-вывода для выполнения своих операций, является хорошим кандидатом на использование базы данных Premium.
• Множество параллельных запросов Некоторые приложения базы данных обслуживают множество одновременных запросов. Обычные редакции Web и Business для Azure SQL Database имеют лимит в 180 одновременных запросов. Приложения, требующие больше соединений, должны использовать базу данных Premium с соответствующим резервом для обработки максимального количества запросов.
• Предсказуемая задержка Некоторым приложения нужно гарантировать ответ от базы данных за минимальное время. Если данная хранимая процедура вызывается как часть более широкой клиентской операции, может предъявляться требование, чтобы возврат из вызова занимал не более 20 мс в 99% случаев. Приложение такого рода выигрывает от использования базы данных Premium, которая обеспечивает соответствующие ресурсы.

ClearDB предлагает SQL-маршрутизаторы с высокой доступностью (или CDBR), которые являются интеллектуальными диспетчерами трафика, отслеживающими эти кластеры баз данных. Когда один из узлов баз данных оказывается неработоспособным, CDBR автоматически перенаправляет запросы дополнительной базе данных master. Это помогает обеспечить бесперебойную работу вашей базы данных и в свою очередь самого веб-приложения. При проектировании такой архитектуры учитывайте рекомендуемые пары регионов, поддерживаемых ClearDB для подобных сценариев, например:

1. если вы выбираете одну базу данных в восточной части США, то парная база данных должна находиться в западной части США;
2. если вы выбираете одну базу данных в северной Европе, то парная база данных должна находиться в южной Европе.

Высокая доступность между регионами

В настоящее время Azure Web Sites поддерживает несколько регионов. Кроме того, мы работаем над расширением ее инфраструктуры. Архитектуры, использующие несколько регионов, можно классифицировать на веб-сайты «активный-активный» и «активный-пассивный».

Веб-сайты «активный-активный» В этом случае вы располагаете несколькими веб-сайтами между регионами, которые обслуживают одно и то же приложение. Трафик распределяется между всеми веб-сайтами, поэтому все они считаются активными.

Веб-сайты «активный-пассивный» В этом случае вы располагаете одним веб-сайтом, который действует как основной. Он будет обслуживать контент для всех клиентов. Если на этом сайте произойдет сбой, клиенты будут перенаправляться на другой сайт в другом информационном центре, сконфигурированный и синхронизированный с основным веб-сайтом; тем самым последствия сбоя значительно смягчаются.

Проектируя архитектуру для работы между несколькими регионами, вы должны продумать решение нескольких непростых проблем.

• Синхронизация данных Это возможность создания копии базы данных между регионами в реальном времени. В любой сложной системе есть, например, база данных, файловый сервер, внешнее хранилище и кеш. При проектировании архитектуры нужно обеспечить, чтобы данные, реплицируемые между несколькими регионами, были в синхронизированном состоянии, а иначе веб-приложение не сможет работать. Это может потребовать некоторых изменений в коде вашего приложения для поддержки этого сценария. Azure Web Sites поддерживает выполнение фонового процесса Web Jobs, который позволяет создавать пользовательские средства для управления синхронизацией данных.
• Сетевой поток Это возможность управлять сетевым трафиком между несколькими регионами. Azure Traffic Manager позволяет балансировать входящий трафик между несколькими размещенными веб-сайтами независимо от того, выполняются они в одном информационном центре или в разных. Эффективно управляя трафиком, вы обеспечите высокую производительность, доступность и отказоустойчивость своих приложений.

С помощью Traffic Manager можно обеспечить высокую доступность и «отзывчивость» ваших приложений. Traffic Manager предоставляет три метода балансировки нагрузки.

1. Failover (восстановление после сбоев) Используйте этот метод, если вы хотите задействовать основную конечную точку для всего своего трафика, но предоставить одну или более резервных конечных точек на случай, если основная или резервная конечная точка станет недоступной.
2. Round Robin (карусель) При этом методе вы равномерно распределяете трафик по набору конечных точек в одном информационном центре или между разными информационными центрами.
3. Performance (производительность) Этот метод позволяет запрашивать клиенты на использование ближайшей конечной точки, чтобы уменьшить задержки, предоставляя конечные точки в различных географических регионах.

Высокая доступность для уровня кеша

Для повышения производительности ваших веб-сайтов уровень кеширования крайне важен. При обработке данных в приложении вам нужно понимать, как кеширование может повлиять и на данные, и на приложение. Выбирая свой уровень кеша, примите во внимание потребность в поддержании целостности данных, хранящихся в разных экземплярах кеша. Чтобы избежать повреждения целостности данных, вы должны использовать механизм распределенного кеширования. Распределенный кеш способен задействовать несколько серверов, поэтому он является масштабируемым. Он хранит данные приложения, находящиеся в базе данных, что сокращает количество вызовов к базе данных.

Существует много облачных решений кеширования, которые можно интегрировать с Azure Web Sites, например Azure Cache и Memcached Cloud. Они доступны через Azure Store на портале Azure Management Portal.

Мониторинг производительности

Теперь, когда вы представляете стратегии достижения высокой доступности для своих веб-сайтов, вам нужно оценить варианты мониторинга. Azure Web Sites предоставляет два типа мониторинга на портале Azure Management Portal:

1. Мониторинг по показателям веб-сайта На информационной панели для каждого веб-сайта есть страница Monitor. На ней отображается статистика производительности по каждому сайту, например использование процессорных ресурсов, число запросов, данные, посылаемые веб-сайтом, и т. д.
2. Мониторинг конечной точки Позволяет сконфигурировать веб-тесты из географически распределенных участков, которые проверяют время ответа и время бесперебойной работы по указанным URL. В каждом сконфигурированном участке тест выполняется через каждые пять минут. Время бесперебойной работы отслеживается по кодам HTTP-ответов. Время ответа измеряется в миллисекундах. Время бесперебойной работы считается равным 100%, когда время ответа меньше 30 мс, а код HTTP-состояния ниже 400. И равно 0%, если время ответа больше 30 мс или код HTTP-состояния превышает 400. Сконфигурировав мониторинг конечной точки, вы можете подробнее проанализировать индивидуальные конечные точки, чтобы увидеть время ответа и состояние бесперебойной работы за период мониторинга по каждому тестовому участку.

Более детализированный и гибкий мониторинг можно вести с помощью портала Azure Preview. Здесь вы создаете полнофункциональную информационную панель DevOps. На рис. 3 показано, как выглядит информационная панель DevOps при выполнении в Azure Web Sites.

Рис. 3. Типичная информационная панель DevOps

При разработке для облака планирование приложения, разработка и тестирование обычно выполняются в других местах, например в Visual Studio Online. Мониторинг работоспособности этих приложений и анализ проблем может выполняться на другом портале, таком как Application Insights. Расходы отображаются на отдельной странице. Не заметили здесь никакого шаблона?

Новый портал DevOps сводит воедино все облачные ресурсы, членов групп и этапы жизненного цикла вашего приложения. Он обеспечивает вам централизованное место для планирования, разработки, тестирования, подготовки, развертывания, масштабирования и мониторинга таких приложений. Вы можете узнать больше об этом портале из публикации в блоге «Building Your Dream DevOps Dashboard with the New Azure Preview Portal» (bit.ly/1sYNRtK).

Варианты восстановления

Иногда с хорошими приложениями происходят плохие вещи. Azure Web Sites может помочь вам автоматически восстанавливать приложение после сбоев. Как правило, когда ваша система мониторинга обнаруживает проблему, она в той или ной форме оповещает сотрудника Ops. Этот сотрудник перезапускает веб-сайт, чтобы тот продолжил работу.

Вы можете настроить файл web.config своего приложения на обнаружение сбоя и действия в такой ситуации. Например, если выполнение X количества запросов занимает Y времени за Z период времени, то выполнить операцию ABC (которая могла бы перезапустить веб-сайт, запротоколировать событие или выполнить пользовательское действие). Другой пример: если мой процесс занимает X объема памяти, то выполнить операцию ABC. Узнать больше о процедурах восстановления можно из Microsoft Azure Blog по ссылке bit.ly/LOSEvS.

Хотя архитектуры с географической избыточностью обеспечивают защиту от инфраструктурных сбоев, такие средства, как автоматическое восстановление, помогают создавать отказоустойчивый прикладной уровень. В мире облачных вычислений заказчики всегда в первую очередь интересуются восстановлением и лишь во вторую — выполнение полноценной диагностики, пока веб-сайт не работает. С другой стороны, возникают другие ситуации, где диагностика очень важна.

Средства диагностики

Диагностика в чем-то сродни препарированию плохой луковицы. Вы никогда заранее не знаете, сколько слоев вам придется снять. Azure Web Sites — это полностью управляемое, мультитенантное предложение Platform as a Service (PaaS) и, как таковое, не поддерживает удаленную диагностику в VM. Это ставит новый набор трудных задач. Некоторые из доступных средств и сценариев диагностики, в которых они полезны, приведены ниже.

По умолчанию сервисы протоколирования обеспечивают разнообразные виды протоколирования, помогающие в анализе проблем. В их число входят, например, Web Server Logging, Detailed Error Logging, Application Logging, Failed Request Tracing и др. Подробнее о сервисах протоколирования см. по ссылке bit.ly/1i0MSou.

Консоль Kudu — еще одно средство диагностики. Это многоцелевое ПО для управления конечными точками заказчики часто используют для диагностических целей. При входе в конечную точку Kudu вы увидите на верхней ленте различные варианты диагностики (рис. 4).

Рис. 4. Консоль Kudu предоставляет средства диагностики

Вкладка Environment открывает представление только для чтения таких вещей, как информация о системе, параметры приложения, строки подключения, переменные окружения, системные пути, HTTP-заголовки и серверные переменные, специфичные для вашего веб-сайта и VM. Это всегда помогает в выборе дальнейшего направления анализа по разным точкам данных.

Вкладка Debug Console предоставляет консоль удаленного выполнения на основе CMD или Windows PowerShell, а также файловый браузер для доступа к вашим сайтам. Вы можете использовать эту консоль для выполнения большинства стандартных консольных операций и произвольных внешних команд, например команд Git, навигации по папке UI, скачивания файлов и папки, закачивания файлов и папки простым перетаскиванием в нужное место, просмотра и редактирования текстовых файлов и т. д. Подробности можно узнать, просмотрев видеоролик «The Azure Web Sites Diagnostic Console» (bit.ly/1h0ZZoR).

Вкладка Process Explorer сообщает вам список активных на данный момент процессов, которые видимы вашему приложению и с которыми оно может взаимодействовать в изолированной программной среде Azure Web Sites. Это представление дает информацию о памяти процессов и использовании процессорных ресурсов. Вы также можете просмотреть детальную информацию о данном процессе, генерировать и скачивать полные дампы памяти для автономной диагностики и т. п.

Вкладка Diagnostic Dump позволяет скачать дамп памяти в виде файла .zip. Затем вы можете воспользоваться анализатором дампов вроде DebugDiag для быстрого анализа дампа памяти.

Вкладка Log Stream позволяет направлять поток HTTP-сообщений или журналов приложений непосредственно в консоль. Это полезно для анализа проблем в активном приложении. Подробнее об этом см. статью Скотта Ханселмена (Scott Hanselman) в блоге «Streaming Diagnostics Trace Logging from the Azure Command Line (plus Glimpse!)» (bit.ly/1jXwy7q).

Список отладочных средств ни в коем случае этим не исчерпывается. Microsoft планирует создание более изощренных средств диагностики, где некоторые из наиболее распространенных сценариев потребуют всего одного щелчка кнопки мыши. Ну а до тех пор старайтесь создавать хорошие приложения, устойчивые к сбоям.