Чек-лист: готовим ИТ-инфраструктуру к микросервисам — что не забыть?

Микросервисное ПО не предъявляет специфических требований к аппаратному уровню ИТ-инфраструктуры. Вычислительная инфраструктура создается на стандартном оборудовании x86-й платформы. Основной момент здесь — правильно рассчитать планируемую нагрузку. В своей практике мы видели немало примеров, когда ошибочный изначальный сайзинг приводил к дефициту вычислительных ресурсов, тормозил развитие платформы и ее масштабирование.

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

Микросервисная архитектура может работать и на физическом оборудовании, так называемом bare metal, и на виртуальной инфраструктуре, и на гиперконвергентных платформах. Тот или иной выбор может задавать свои требования и ограничения реализации платформы. С одной стороны, контейнеры по своей сути являются механизмом виртуализации, более легковесной — уровня ОС. С другой — это не отрицает использование привычных технологий серверной виртуализации, как например, VMware. Каждый из подходов имеет плюсы и минусы и их нужно учитывать при дизайне проекта.

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

Определить стратегию непрерывности

На случай аварии в ЦОДе для критичных сервисов, простой которых дорого обходится бизнесу, должен быть план восстановления. Вариантом может стать дублирование продуктивной среды в резервном ЦОД или другие схемы DR. Конкретный вариант реализации DR определяется требованиями ПО. Но подходы к резервированию микросервисных окружений отличаются от используемых в монолитных средах. В отличие от привычных монолитных приложений, где большая часть решений по отказоустойчивости обеспечивалась на уровне ИТ-инфраструктуры (репликация средствами СХД, высокая доступность средствами кластеризации и системы виртуализации и т. д.), в микросервисных приложений привычные подходы зачастую не работают — здесь нужно обеспечивать устойчивость к отказам на уровне самого приложения и его компонентов. Их дублирование, распределенные схемы, встроенные механизмы репликации, балансировка нагрузки и т. д.

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

Интеграции со слоем ниже

Отдельный аспект связан с интеграцией микросервисной платформы с компонентами нижележащей инфраструктуры.

Одна из ключевых задач в этом — сопряжение сети микросервисной платформы с сетью предприятия в целом. Программно-определяемые сети, которые используются для микросервисных приложений внутри кластера оркестрации, необходимо подключить к существующим аппаратным сетевым устройствам, и обеспечить доступ к и извне калстера. Для этого есть много технических решений разного уровня зрелости. Выбор оптимального варианта зависит от того, какие возможности по поддержке технологии SDN есть у действующей сети предприятия. Критерии выбора также задают и требования микросервисов — куда им необходим доступ внутри кластера и за его пределами, к сервисам в ЦОДе компании и извне. Еще важно не забыть согласовать это с экспертами ИБ. Многим микросервисным решениям нужен доступ к интернету уже на этапе инсталляции, а находятся они в продуктивном сегменте, который прямого выхода в интернет не имеет, так как это противоречит требованиям ИБ. Свои требования также предъявляют аспекты шифрования трафика. Нужно выбирать правильный SDN, так как не все плагины поддерживают данную функциональность.

Другим важным стримом на подобных проектах становится подключение к хранилищу. Здесь спектр решений тоже широк. Например, при облачном развертывании микросервисов, логично выбирать облачное или программно-определяемое хранилище. Когда Kubernetes располагается на ресурсах фермы виртуализации VMware, есть основание использовать их дата-сторы. Для сервисов, которые требуют высокой скорости отклика и производительности, скорее всего подойдет блочное хранилище с внешней СХД. А управлять им лучше с уровня Kubernetes и подключаемых сторонних драйверов.

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

Предоставлено пресс-службой «Инфосистемы Джет».

Этапы подготовки ИТ-инфраструктуры под микросервисную архитектуру

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

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

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

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

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

Ошибки на пути создания ИТ-инфраструктуры

На пути создания ИТ-инфраструктуры под микросервисы встречается много подводных камней. И они заметно отличаются от тех вызовов, с которыми мы имеем дело в классических инфраструктурах.

Например, принципы построения надежных и отказоустойчивых конфигураций. Размещая кластер микросервисных приложений в виртуальной инфраструктуре, мало позаботиться об отказоустойчивости только на уровне виртуальных машин. Кластер микросервисов должен быть отказоустойчивым сам по себе с помощью масштабирования, резервирования, репликации и пр. Если отключился один из узлов кластера, что будет происходить дальше? Либо уровень виртуализации перезапустит виртуальную машину, либо кластер Kubernetes переподнимет упавшие контейнеры на другом узле. Создавая ИТ-инфраструктуру, важно учитывать подобные сценарии и выстраивать логику работы системы.

Ошибки и просчеты в подготовке ИТ-инфраструктуры неизбежно скажутся на устойчивости и производительности микросервисных приложений.

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

Как минимизировать затраты при переходе

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

В своих проектах мы стремимся максимально использовать имеющиеся ресурсы. Например, используем свободные вычислительные мощности, пусть даже разрозненные. Если компания применяет Open Source и у нее нет высоких требований к SLA и надежности, возможна экономия за счет «свободных» ОС и другого открытого ПО.

Серьезную экономию дает привлечение квалифицированной команды на проект. Мы не раз сталкивались с кейсами, когда компании с околонулевой экспертизой строили ИТ-инфраструктуры под микросервисные приложения. Они достигали своей цели. Но оказывалось, что стоимость этих внутренних проектов превысила рыночную в несколько раз. Потому что экспертиза в новой сфере доставалась болезненно, путем проб и ошибок. Гораздо более короткий и эффективный путь — привлечь опытную команду, которая поможет подготовить ИТ-инфраструктуру, интегрировать ее с действующей средой и настроить до состояния, когда она будет готова принять микросервисные нагрузки.

С вопросами можно обращаться по адресу info@jetinfosystems.kz.