Программирование в облаке

  • 5 мин

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

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

Факторы производительности для приложений в облаке

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

Пропускная способность и задержка ресурса

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

Помимо задержки, приложения могут также иметь строгие требования к пропускной способности, особенно приложения, работающие с мультимедийным содержимым, таким как аудио и видео. Многие поставщики облачных служб позволяют разработчикам облачных систем задавать параметры производительности во время подготовки в виде требований к операциям ввода-вывода в секунду для вычислительных ресурсов и хранилища. Кроме того, многие поставщики облачных служб позволяют разработчикам настраивать виртуальные сети. Реализация и внедрение программно-определяемых сетей и хранилищ (описываемых в следующих модулях) дают дополнительное представление о новых методах, используемых центрами обработки данных для управления трафиком от нескольких клиентов, а также об управлении отдельными требованиями, указанными в SLO клиента.

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

Мультитенантность

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

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

Связанным аспектом мультитенантности является проблема вариации подготовки, когда идентичные запросы на виртуальные ресурсы в общедоступных облаках сопоставляются с физическими ресурсами неодинаково, что приводит к вариациям производительности1. Например, два одинаковых запроса на виртуальные машины (VM1 и VM2) могут быть направлены на два разных физических компьютера (A и B). Физический компьютер A может иметь четыре других клиента, конкурирующих за ресурсы на том же компьютере, в то время как на компьютере B их может быть только два. Клиент платит одинаковую плату за виртуальные машины VM1 и VM2, но потенциально может получить на них разную производительность.

Параметры безопасности

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

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

Ссылки

  1. Rehman, M. S and Sakr, M. F (2010). Initial Findings for Provisioning Variation in Cloud Computing from the 2010 IEEE Second International Conference on Cloud Computing Technology and Science (CloudCom)