Разрабатывая IT-продукты для бизнеса, мы на старте работы над проектом закладываем предполагаемую нагрузку на продукт. После запуска продукта условия его использования могут меняться. Может меняться и сам бизнес. По этим причинам нагрузка на созданное решение тоже изменится: от падения на десятки до роста на сотни процентов относительно среднего уровня. Чтобы эти изменения не стали для бизнеса и его прибыльности критическими или фатальными, IT-инфраструктуру нужно масштабировать.
Наша практика показывает, что чаще всего находится какое-то место в системе, которое работает по принципу 80/20 – львиная доля несовершенств произрастает из одного узкого места, оптимизировав которое, можно получить значительный буст в производительности.
Оптимизация баз данных
Часто узким местом становится эффективность запросов в базы данных. Пример из практики: мы создавали систему документооборота для МФО. Через несколько лет компания расширилась путем покупки другой компании. В результате клиентов системы стало в разы больше, и существующая система уже не справлялась с нагрузкой. Пользователям приходилось ждать выполнения некоторых частых операций по несколько минут. Встал вопрос о масштабировании ИТ-инфраструктуры.
На проекте мы использовали ORM библиотеку, помогающую в объектно-ориентированном коде обращаться к базам данных (БД). Мы проанализировали запросы, которые генерировала библиотека и выделили неэффективные, где система берет из БД лишние данные или делает избыточные обращения к ней, не использует индексы.
Решение проблемы крылось в реструктуризации запросов в БД. Вообще, такого рода несовершенства часто встречаются при использовании ORM библиотек. Чтобы снизить нагрузку на инфраструктуру в таком случае можно перенастроить ORM, изменить структуру БД или настроить запросы напрямую в БД для меньшего потребления системой ресурсов. В результате проекта оптимизации удалось избежать увеличения ежемесячных расходов на инфраструктуру, а производительность системы вернулась в норму.
Строгое кэширование, serverless-вычисления и CDN
Другой пример – продукты, у которых сильно неравномерный профиль нагрузки. Примеры – сервисы для спортивных клубов и организаций, коих в нашей практике немало. Нагрузка на них сосредоточена в определенные дни – например, когда проводится очередной матч. Есть также элемент непредсказуемости: внезапно появившаяся скандальная новость может привести на ресурс толпы пользователей. Аналогичный профиль нагрузки можно встретить у медиа и e-commerce проектов.
Мы пользовались облачной инфраструктурой. Первоначально увеличивали ее в те дни, когда могли предсказать большую нагрузку. Прибегали к горизонтальным механизмам масштабирования проекта. Условно, в обычные дни работали 2 сервера, а в дни матчей было задействовано до 8 серверов. Однако это не особенно решало проблему внезапного наплыва. Для таких случаев мы использовали другой вид оптимизации: при росте нагрузки автоматически включали более строгое кэширование данных. Таким образом получалось снизить нагрузку на сервера за счет небольшого снижения скорости обновления информации для пользователей.
Второй обязательный элемент масштабирования любых публичных онлайн-проектов – это сеть доставки контента («content delivery network», CDN). Это сеть взаимосвязанных серверов, которая ускоряет процесс загрузки веб-страниц приложений с высокой нагрузкой за счет кэширования отдельных запросов на них.
Современные CDN позволяют использовать адаптивные правила кэширования, дополнительно защищают от DDoS атак и ботов, а некоторые позволяют даже выполнять небольшой код на edge-серверах. Российские CDN пока отстают от зарубежных, но постепенно догоняют. С точки зрения расходов на хостинг это вложение окупается всегда.
Справиться с непредсказуемыми высокими нагрузками на систему также помогают serverless-вычисления. Это модель предоставления серверных услуг без аренды или покупки оборудования. Проще говоря, мы платим только за то количество запросов к сервису , не тратя дополнительные средства на поддержание его работы (функционирования серверов) в моменты нулевых нагрузок. Мы применяли их для процессов интеграции данных из сторонних сервисов с неравномерным потоком.
Монолит и микросервисы
Первоначально при разработке нового продукта часто делают монолитное приложение, потому что это более простой путь: все в одном месте и разработка идет быстрее. После запуска по ходу эксплуатации могут начаться проблемы с производительностью, и тогда возникает дилемма. Получается, что нужно либо масштабировать инфраструктуру, что дорого и неудобно, либо делить монолит на микросервисы.
Проще провести масштабирования ИТ-проекта, когда система построена на микросервисах. Поэтому даже при создании монолитного приложения стоит закладывать возможности для переведения его на микросервисную архитектуру. В любом случае, не обязательно всю систему «распиливать» сразу. Удобнее и разумнее делать это постепенно, отделяя небольшие кусочки функциональности по очереди. По отдельности начинаем «вырезать» сегменты и переводить их на микросервисы, и переключать потоки данных из старого приложения в новое. Логично строить этот процесс, опираясь на нужды бизнеса, чтобы каждая итерация приносила пользу или экономила средства бизнеса. Так получится сократить расходы и привести архитектуру в порядок.
