Даже крупные компании с огромными ИТ-бюджетами и высококвалифицированными командами часто испытывают трудности с обеспечением работоспособности критически важных бизнес-приложений. Поэтому проекты по масштабированию происходят «вспышками» — когда нагрузка на приложения достигает пиковых значений и при этом есть необходимый бюджет. Как грамотно подойти к такому проекту и в каких случаях масштабирование реально решает проблемы бизнеса, рассказывает Александр Козлов, ведущий архитектор направления Cloud&Infra ИТ-компании iiii Tech («Форайз», ex-Tietoevry Russia).
На первый взгляд масштабирование инфраструктуры, особенно гибридной, может показаться простой задачей — достаточно расширить количество пользователей или добавить еще один сервер в стойку. Однако важно обеспечить баланс между стратегиями развития SaaS, IaaS и мощностями центра обработки данных (ЦОД). Для этого бизнесу необходимо понимать нюансы масштабирования — дьявол кроется в деталях.
Вертикальное или горизонтальное масштабирование
В течение долгого времени единственным способом повысить производительность ИТ-систем и приложений было добавление новых аппаратных ресурсов: емкости памяти, более быстрых процессоров или большего количества массивов хранения. Этот сценарий масштабирования называется вертикальным.
Инфраструктуру можно масштабировать «количественно». Например, если системе нужно больше вычислительной мощности или хранилища для данных, в ЦОД добавляется больше серверов с аналогичными конфигурациями. Аналогично поступают, если один или несколько компьютеров перестают работать. Это называется горизонтальным масштабированием.
Как правило, масштабирование включает в себя добавление дополнительных ресурсов памяти, центрального процессора (ЦП), дискового или сетевого ввода-вывода к существующим экземплярам. Если же бизнес пользуется услугами облачных провайдеров, масштабирование происходит за счет увеличения размеров инстансов (экземпляров объекта). Вертикальное масштабирование выполняется быстро и просто. Это делает его привлекательным для малого и среднего бизнеса и растущих стартапов, но при этом ограничивает степень масштабируемости.
К другим преимуществам вертикального масштабирования можно отнести:
-
экономию энергии: один сервер потребляет ее меньше, чем несколько;
-
более простое управление в рамках одного сервера;
-
отсутствие сложностей с ПО, которое чаще всего «заточено» под вертикальное масштабирование.
Среди недостатков:
-
большие затраты на модернизацию оборудования;
-
сбой оборудования потенциально может привести к общему сбою;
-
привязка к одному поставщику накладывает на инфраструктуру ограничения, связанные с конкретными технологиями.
Горизонтальное масштабирование ограничивает количество запросов и таким образом разделяет или «дозирует» нагрузку. Это дает двойное преимущество. Во-первых, поддержка производительности не зависит от размера устройств. Во-вторых, сохраняется высокая доступность — инстансы можно динамически добавлять без простоев, что часто невозможно при вертикальном масштабировании. Поэтому горизонтальный метод расширения инфраструктуры является более предпочтительным, особенно для крупных технологических компаний.
У горизонтального масштабирования есть еще несколько преимуществ:
-
капитальные затраты на добавление нового оборудования меньше, что при значительном расширении инфраструктуры будет более экономным вариантом;
-
высокая отказоустойчивость из-за большего количества возможностей для балансировки нагрузки, дублирования и репликации;
-
отсутствие предела для масштабирования.
К минусам горизонтального масштабирования можно отнести:
-
обилие параллельно работающих устройств, а значит, большие затраты на коммунальные услуги, электроэнергию и пространство;
-
большое количество и разнообразие ПО, которым часто сложно управлять из-за дополнительной нагрузки на обработку распределения данных и параллельной обработки процедур;
-
обилие узлов в общей архитектуре, которые необходимо обеспечить защитой.
Всем ли нужно масштабирование ИТ-инфраструктуры
Ключевой момент подготовки к модернизации инфраструктуры — выявление узких мест. Это непросто: проблемы не всегда заметны и могут медленно нарастать с течением времени. Среди таких «узких мест» может быть медленная загрузка страниц, долгое время ожидания сетевых подключений и т.д. Для приложений проблемы, связанные с разработкой, приобретают чудовищные масштабы. Например, когда среды разработки, тестирования и производства не совпадают, код трудно тестировать, искать и устранять ошибки становится проблематично, а добавление новых функций занимает гораздо больше времени.
Еще важнее для бизнеса быть уверенным в том, что масштабирование — это и есть решение его проблем. Сами по себе дополнительные ресурсы могут привести к новым сложностям. На уровне приложений цель модернизации в том, чтобы технологический стек обрабатывал запросы эффективнее, а не в том, чтобы сделать инфраструктуру «избыточной». Приведем несколько примеров, когда это уместно и когда нет.
Перегрузка веб-сервера. Достаточно просто увеличить масштаб до более мощного сервера. Особенно это касается рабочих нагрузок больших данных или высокопроизводительных вычислений — для них нужны более мощные узлы, чем обычно. Используйте гибкий размер облачного сервера.
Единая точка отказа. Правильным решением будет горизонтальное масштабирование и настройка нескольких серверов, на которых размещено одно и то же приложение. Реплицируйте базы данных с помощью архитектуры «ведущий-ведомый»: запросы на чтение отправляйте на ведомые устройства, а запросы на запись — на ведущие.
Распределение трафика. Используйте несколько подсистем балансировки нагрузки. Экономичные аппаратные и программные решения в облаке, как правило, легкодоступны.
Сеансы факторинга. Некоторые веб-приложения сталкиваются с проблемами при использовании нескольких серверов или подсистем балансировки нагрузки. Разделите сеансы с помощью распределенного хранилища, например Redis, и добавьте для него «избыточность», чтобы решить проблему.
Перегрузка запросов к базе данных. Огромное приложение, которое обслуживает тысячи пользователей с миллионами запросов, очень быстро переполняет свой кэш. Масштабирование здесь не нужно — использование очередей и периодическая очистка кэша неактивных пользователей или сеансов помогает избежать этой проблемы.
Гибкость платформы. Облачные провайдеры часто ограничивают доступ к ОС и приложениям, работающим на их платформах, что влияет на стратегические технологические решения компании. Дополнительные мощности не решат проблемы — лучше выбрать открытые платформы, которые поддерживают несколько программных надстроек и имеют предустановленные приложения.
После того как бизнес выявил проблемы и понял, что масштабирование — это наиболее эффективное решение, можно переходить к следующему шагу — аудиту инфраструктуры. По его результатам у ИТ-архитектора должно сложиться полное представление о каждой рабочей нагрузке в системе и о том, как каждая из них будет расти в течение следующих нескольких кварталов. Любые исторические данные об обновлениях оборудования или ПО могут оказаться решающими для выявления потенциальных рисков для масштабирования. Более того, это может влиять на принятие решения об инструментах для обеспечения непрерывности бизнеса на протяжении всего процесса.
Имея четкое представление о существующих ресурсах, операционных процессах, схемах трафика и о том, как пробелы и рост в каждой области будут соответствовать бизнес-целям, руководитель проекта может принимать решения о географическом расположении новых ресурсов, хостинге, облачных поставщиках и т.д.
Факторы, влияющие на успех масштабирования
Как и во всем, что связано с ИТ-инфраструктурой и архитектурой, гибридный подход к масштабированию, вероятно, является лучшим. Он включает в себя несколько ключевых факторов: люди, автоматизация, данные и гиперконвергенция. О каждом из них детальнее.
Люди
На каждом этапе масштабирования важны идеи и мнения нескольких команд, старших ИТ-специалистов из разных областей (системных администраторов, архитекторов данных, инженеров DevOps и других). Каждый из них должен быть осведомлен об ограниченности ресурсов, провести четкую и прозрачную оценку текущей инфраструктуры, разработать дорожную карту для миграции и модернизации, а также иметь возможность решать различные проблемы архитектуры и реализации, как только они возникают.
Автоматизация
Ключевым решением является то, будет ли масштабирование выполняться вручную или автоматизированно. За исключением некоторых продвинутых и сложных сценариев вертикального масштабирования, в которых для изменения конфигурации нужна экспертиза, ручное масштабирование подвержено ошибкам из-за человеческого фактора.
С другой стороны, автоматическое масштабирование позволяет динамически добавлять или удалять ресурсы ЦП, памяти и хранилища всякий раз, когда коэффициенты использования превышают или опускаются ниже пороговых значений. Ключевые преимущества здесь — доступность и эффективное использование ресурсов.
Новые технологии — это ключевой фактор эффективного масштабирования. Обеспечить бесперебойную подготовку ресурсов и миграцию систем в облако может помочь подход «инфраструктура как код» (IaC). Он позволяет создавать, управлять и автоматизировать инфраструктуру, используя код, но при этом требуется достаточный уровень знаний в области программирования и DevOps, а также инвестиции в инфраструктуру и инструменты.
Данные
Аналитика больших данных требует высокопроизводительной инфраструктуры. Узкие места в вычислительных ресурсах и хранилищах могут быстро вывести из строя рабочие нагрузки, связанные с доступом к наборам данных и их передачей. Поэтому компаниям, которые работают с большими данными, нужен универсальный вариант облачного или локального масштабирования, который плавно удовлетворяет эти потребности в производительности хранилища.
Гиперконвергенция
До распространения гиперконвергенции вертикальное масштабирование было нормой — компании добавляли сервера всякий раз, когда требовалось масштабировать приложение. Эта модель была крайне неэффективной: любое из последних устройств было в значительной степени неактивным из-за частичного использования. Проблема усугублялась тем, что ИТ-командам часто трудно управлять разрозненным аппаратным и программным обеспечением из-за отсутствия унификации и централизации.
Технология виртуализации серверов облегчила эту проблему — достаточно дополнительных виртуальных машин без необходимости покупать физическое оборудование. Затем наступила эпоха гиперконвергенции. Она вывела виртуализацию на новый уровень — теперь все вычислительные ресурсы и ресурсы хранения можно объединить в единый пул. Это влияет на скорость решения проблемы: когда в кластере не хватает емкости, администратор может создавать новые узлы из дополнительных физических устройств и масштабировать инфраструктуру в течение нескольких минут. Более того, за всем стеком, состоящим из локальных и гибридных облачных сред, можно управлять через интерфейс «единой панели».
Лицензии на программное обеспечение
На сегодняшний день многие поставщики предоставляют гибкие условия для покупки программных продуктов и «железа». Например, можно купить систему хранения, в которой все отсеки под диски будут заняты, но при этом лицензия на ПО будет только на 30% от всего объема. По мере увеличения данных компания может докупить лицензии под дополнительное место.
Также некоторые ИТ-поставщики лицензируют не физические ядра гипервизора, а виртуальные. Словом, правильное планирование и выбор ПО для инфраструктуры и приложений сильно влияет на затраты в будущем.
Планирование модернизации и обновления ИТ-инфраструктуры должно основываться на стремлении оптимизировать затраты и повысить эффективность работы. На каждом этапе ИТ-директора должны сосредоточиться на виртуализации, гиперконвергенции, частном, общедоступном и гибридном облаке. Критически важно справляться с рабочими нагрузками с помощью архитектуры с меньшим количеством узлов, которые полностью используют доступную им вычислительную мощность, память и хранилище. В этом случае масштабирование пройдет гладко и гарантированно принесет пользу бизнесу.