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