Какая ИТ-инфраструктура нужна для приложений будущего?

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

Свободное ПО

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

«В тени» мира лицензионных приложений всегда развивался свободный код, он же – свободное ПО, он же – открытое ПО, он же – open source. Его развивали и группы энтузиастов, и корпорации. Но долгое время открытые технологии вызывали скепсис у бизнеса, которому требовались поддерживаемые, протестированные решения. Считалось, что открытое ПО – незрелое, сложнее найти ИТ-специалистов, готовых с ним работать, и его сложнее поддерживать. До недавнего времени так оно и было, но сегодня это уже не так – свободное ПО вышло на новый уровень зрелости, достаточный даже для масштабных, высоконагруженных систем, а решения на его основе стали предлагать даже глобальные вендоры.

Свободный код, как известно, оттого и называется свободным, что открыт для самостоятельной доработки, развития, создания новых продуктов. Это дает возможность создавать любые приложения под свои требования, любые сервисы, самостоятельно поддерживать и развивать их. И без какой-либо привязки к одному вендору (vendor lock), поскольку доступ к коду открыт, любой программист или команда могут пользоваться им, создавая на его основе новые продукты. В результате вокруг приложений с открытым кодом вырастают целые экосистемы в той или иной мере совместимых решений. Отсутствие привязки к вендору означает, что разработанный на базе открытого ПО продукт проще интегрируется с другими решениями экосистемы, а его будущее не находится в зависимости от закрытых проприетарных платформ, так как они не использовались при его создании. Таким образом, открытое ПО имеет свои преимущества с точки зрения устойчивости и независимости бизнеса разработчика и будущего его продукта.

Одной из первых больших российских ИТ-компаний, сделавших ставку на широкое использование свободного кода при создании высоконагруженных сервисов, стала Mail.ru Group. Строго следуя этому подходу, облачную платформу Mail.ru Cloud Solutions (MCS) сделали на базе открытой облачной платформы OpenStack.

Микросервисная архитектура

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

Появление облаков позволило разбивать каждое приложение на множество микросервисов — маленьких приложений, каждое из которых делает небольшой кусочек работы и передает его дальше, на другие микросервисы. В облаке можно разместить и «монолит», но если в его цепи операций возникает узкое место, приходится делать более мощным весь облачный сервер для приложения, усиливая даже те его части, которые не «тормозят». Обновление приложения тоже происходит целиком, а при его падении нужно «воскрешать» на другой виртуальной машине полностью всю систему. В микросервисной архитектуре можно избирательно, ситуативно и автоматически усиливать отдельные функции приложений, обновлять их по одному. А при падении отдельных микросервисов новые копии поднимаются быстро – просто в силу их небольшого размера. Поэтому микросервисный подход делает приложения гораздо более надежными, он более эффективно утилизирует вычислительные ресурсы.

В техническом отношении для микросервисной архитектуры на первый план выходят технологии контейнеризации и управления контейнерами – оркестрации.

Микросервис по своей сути – это небольшая программа, в которой реализована та или иная часть функциональности приложения. Но это не просто программа – она упакована в «контейнер». И не в единственном числе упакованная, сама по себе, а вместе с необходимым для ее работы окружением – операционной системой, библиотеками. Можно сказать, что это маленький, атомарный компьютер для запуска и работы одной программы. Контейнер можно разработать и протестировать в «контуре разработки», а потом легко переместить и развернуть в рабочей среде – виртуализированной или на оборудовании. Причем его можно запускать во многих экземплярах, которые усиливают общую производительность выполнения соответствующей задачи. В сочетании с автоматическим масштабированием каждый конкретный микросервис регулирует свою производительность и утилизирует облачные ресурсы на 100%. Docker – один из самых популярных «упаковщиков» или, на языке профи – «исполняемых сред контейнеров», но есть и другие – CoreOS, Intel Clear Containers, hyper.sh и пр.

Создавать сами контейнеры с микросервисами достаточно просто, как отмечают специалисты, – многие уже научились делать это самостоятельно. А вот дальше возникает задача оркестрации контейнеров, то есть управления ими в рамках единого кластера микросервисов приложения, и здесь самая популярная технология – Kubernetes. Но создать кластер микросервисов на базе Kubernetes, чтобы он был отказоустойчивым и легко управляемым, достаточно сложно, поскольку здесь требуется специальный опыт и знания. К счастью, готовый и настроенный кластер Kubernetes можно получить в виде облачного платформенного сервиса Kubernetes (Kubernetes as a Service). Сервис автоматизирует запуск кластеров микросервисов и управление ими. Посредством облачного Kubernetes заказчик может удобно запускать обновления, откатывать их обратно, если они оказались неудачными, управлять выделением ресурсов. А если понадобится помощь – эксперты MCS всегда поделятся своими знаниями. Площадками для этого становятся специально проводимые для клиентов мастерские (т.н. воркшопы, workshop), оперативные консультации в Telegram. Специалисты MCS помогают заказчику по всем направлениям: при аудите приложений, оценке возможности их переработки на микросервисную архитектуру и в процессе самой «переделки», при налаживании конвейера непрерывной разработки, тестирования и выкатывания обновлений – т.н. CI/CD.

Kubernetes + виртуальная машина – это оптимально

Однако не все приложения можно поместить в контейнер – например, для баз данных это делать нерационально. И в этом случае компании предпочитают гибридную конфигурацию, в рамках которой используется и Kubernetes – для приложений, которые можно контейнеризовать, и виртуальные машины – на них работают другие системы. Например, на виртуальной машине можно запустить СУБД и предоставлять ее как сервис (DBaaS). В облаке MCS по этой модели предоставляются сервисы на основе СУБД PostgreSQL, Postgres Pro, Redis, ClickHouse, MongoDB, Arenadata DB.

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

CDN-сервис – возможность быть рядом с пользователем

Задержка даже на долю секунды в оказании интернет-сервиса пользователю может быть критичной. Особенно значим этот параметр – время получения сервиса – для игр в реальном времени, стриминга различного медиа-контента. И даже на бизнес интернет-магазинов и сайтов заказа еды задержки тоже влияют: за проседание скорости поисковики «штрафуют» сайты в позиции поиска. Снизить временные задержки в предоставлении сервисов, свести их к минимуму помогают т.н. сети доставки контента или Content Delivery System, CDN. И это тоже важная опция, на которую нужно обращать внимание при выборе облачного провайдера, если бизнес чувствителен к падению скорости раздачи контента.

MCS предлагает доставку контента как сервис на базе сети CDN-серверов. Он создан в партнерстве с «Мегафоном» и в сотрудничестве с 700 провайдерами контента и операторами связи. Сеть представлена во всех регионах мира – в 34 городах, включает порядка 400 ЦОД. Техническая поддержка оказывается в режиме 24/7. В рамках CDN-сервиса система сама в автоматическом режиме выбирает оптимальный маршрут доставки контента, гарантирует доступность содержимого при любой нагрузке, ускоряет загрузку сайта, снижает количество отказов, повышает конверсию, то есть долю посетителей сайта, ставших клиентами.

Мультиоблако

Мультиоблако – это когда облако заказчика включает в себя более одной облачной платформы разных провайдеров, которые отличаются друг от друга на технологическом уровне. Таким образом, критичный признак мультиоблака, в отличие от гибридной модели, – технологическая гетерогенность облачных платформ.

Приложение, чтобы оно могло работать в мультиоблаке, обязательно должно иметь микросервисную архитектуру и быть автомасштабируемым. Именно для этого предназначены технологии Docker и Kubernetes – последний реализует большую часть того, что нужно для мультиоблака, позволяет установить и отмасштабировать приложение из единой панели управления сразу в двух или более облаках – например, и на Amazon, и на MCS.

Какие задачи можно решать посредством мультиоблака? Первое назначение – снижение рисков привязанности к одному вендору (vendor lock), упрощение смены провайдера в случае необходимости. Например – перестал устраивать уровень обслуживания (SLA), технические возможности платформы. Или провайдер вдруг резко поднял оплату вычислительных мощностей. Или, что бывает чаще, изменился профиль использования трафика, при котором его стоимость становится критичным моментом. Вторая важная задача мультиоблака, отчасти связанная с первой, – обеспечение практически 100% гарантии доступа к сервису, защита от выхода из строя одной из облачных платформ. И третье назначение – возможность сэкономить, выбрав для разных сервисов наиболее подходящих по цене провайдеров. Это усложняет администрирование, но тоже возможно.

Есть у мультиоблака и отдельные недостатки, в их числе – невозможность использовать те или иные проприетарные сервисы облачных провайдеров. Например, СУБД DinamoDB от AWS – реплику этой базы данных у другого провайдера создать не получится. Выход из ситуации – отказ от использования такого рода сервисов в пользу базовых IaaS и PaaS-сервисов.

В рамках мультиоблачной стратегии MCS предоставляет клиентам инструментарий для единого управления развертыванием, управлением, мониторингом, масштабированием приложений, работающих в федеративных кластерах Kubernetes. Оказывают специалисты MCS и услуги консалтинга на этапе построения мультиоблачной стратегии бизнеса, а также в ходе эксплуатации. MCS реализовано решение для автоматического развертывания федеративных кластеров Kubernetes одновременно на мощностях AWS и MCS. Работает проект с Acronis, позволяющий создавать бэкапы в другом облачном плече. Кроме того, MCS предоставляет сервисы, позволяющие осуществлять мультиоблачное восстановление данных после сбоя (Disaster Recovery).

Более простой вариант мультиоблака (в нестрогом смысле) создают для выполнения требований закона 152-ФЗ и других правил использования персональных данных на том или ином локальном рынке. Здесь объединение облаков разных вендоров реализуется проще: часть данных хранится и обрабатывается в одном облаке, часть — в другом. Например, международная компания работает одновременно и в Западной Европе, и в России. В этом случае встречается вариант, когда мультиоблако базируется на платформах AWS и MCS: на Amazon обслуживаются европейские пользователи сервисов, на облаке MCS – российские. Примером таких компаний может быть «Битрикс24».

Уже сегодня, как свидетельствуют эксперты, наблюдается возросший спрос на мультиоблако со стороны банковской и других отраслей экономики – количество конкурсов на создание гетерогенных облачных платформ растет с прошлого года. Один из существенных факторов, способствующих этому, – слияния и поглощения, когда возникает гетерогенная ИТ-инфраструктура, которую требуется поддерживать. Мультиоблачную стратегию будут использовать и российские поставщики SaaS-сервисов, которым необходимо гарантировать доступность почти на 100%-м уровне, что невозможно реализовать на базе монооблака.

Будущее ИТ-инфраструктуры

Каждая из технологий для современных приложений «прокачивает» их в разных аспектах. Микросервисная архитектура, которая технически реализуется на контейнерах под управлением Kubernetes, берет на себя надежность, простоту обновлений приложений и даже оптимизацию расходов на облачную инфраструктуру – за счет 100% утилизации ресурсов. CDN улучшает опыт пользователей и помогает обойти конкурентов в поиске. Использование свободного ПО и мультиоблака направлены на устойчивость и безопасность бизнеса, обеспечение его независимости от отдельных вендоров приложений и провайдеров облаков.