Rambler's Top100
Статьи
Юрий БУШЕВ  09 июля 2018

Масштабирование облачной архитектуры: что важно предусмотреть

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

Трудный возраст

В основе облачных решений лежит технология виртуализации, т.е. создание виртуального представления физического оборудования. Проблема заключается в том, что если изначально вся нагрузка компании ложится на один виртуальный сервер (VPS/VDS), то в дальнейшем технически невозможно организовать миграцию части данных на второй дополнительный сервер. Другими словами, расширить парк оборудования под конкретный проект будет нельзя: приложения, которые работали на первом VPS, так и будут «крутиться» именно на этом сервере.

Какой выход есть в такой ситуации? Произвести вертикальное масштабирование системы: увеличить в физическом оборудовании количество оперативной памяти, объем и скорость обмена данных с жестким диском, тактовую частоту процессора. Это на какое-то время поможет. Но поскольку у «железа» всегда есть предел, вы не сможете бесконечно наращивать мощность одной вычислительной единицы и рано или поздно вам придется полностью обновить инфраструктуру.

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

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

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

Стартапы могут учесть горький опыт предшественников и не повторять ошибок, которые могут стать для бизнеса если не фатальными, то наверняка принести убытки.

Как это случается: пример из жизни

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

На этапе запуска мы планировали, что спустя три-четыре месяца будет продано около 5 тыс. GPS-трекеров, что обернется нагрузкой приблизительно в 100 обращений к серверу в секунду.

Для того чтобы обработать такое количество запросов, нам были нужны два сервера на базе Intel Xeon E5 2620 v4 с RAID-массивом из HDD-дисков на 1 Tбайт для хранения данных телеметрии, а также один сервер на базе Intel Xeon E5 2660 v4 для обработки запросов от трекеров и пользователей приложений.

Или же мы могли просто арендовать облачные ресурсы у сервис-провайдера. Мы, разумеется, выбрали второй вариант.

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

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

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

Юрий Бушев, специалист по Node.js-разработке
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!