Начинаете разработку IT-проекта или уже обнаружили в архитектуре системы проблемы с производительностью и масштабируемостью? Тогда вам может быть полезно прочитать один из кейсов SimbirSoft. В нем рассказываем, как наш специалист, подключившийся для усиления команды заказчика, помог оптимизировать затраты при масштабировании сервиса. Материал будет полезен СТО, CIO, руководителям проектов и владельцам IT-продуктов.
Привет! Меня зовут Михаил, я веб-разработчик компании SimbirSoft. Расскажу вам о случае из своей практики. Когда я подключился к проекту заказчика, то сразу обнаружил, что скорость обработки запросов к серверу сильно отличается от оптимальных значений: 15 секунд вместо 1,5.
Если на сервер, который обрабатывает запрос за 1,5 секунды, уходит в месяц 300 тысяч рублей, то на такой же сервер, который делает ту же самую работу за 15 секунд, тратится уже в разы больше.
При этом такая скорость была при количестве посещений в 100 тысяч человек в день, а заказчик планировал увеличить эту цифру до 300 тысяч. В таком случае, показатель снизился бы ещё в 3 раза (до 30–45 секунд на запрос). Это потребовало бы увеличения мощности и повлекло за собой постоянно растущие затраты на инфраструктуру.
Итого на входе мы имеем следующие данные:
1. Количество активных пользователей ежедневно — 100 000.
2. Время получения ответа от сервера —15 сек.
3. Стабильная нагрузка на сервера приложения и базы данных — 90–100%.
Если при таких показателях заказчик продолжит добавлять в систему новый функционал, то эти значения вырастут еще больше, а презентация результатов перед инвесторами в конце года пройдет не самым благоприятным образом.
Почему произошла такая ситуация?
Из-за ошибок при проектировании архитектуры проекта, а именно:
1. Логические блоки приложения были слишком сильно связаны друг с другом.
Для выполнения простейшей операции в одном сервисе, необходимо было получить информацию из двух-трёх других, что сильно увеличивало время на обработку.
2. Высокая связанность логических блоков также негативно влияла на структуру базы данных. Запросы получались громоздкие и тяжелые — с использованием большого количества таблиц, условий и команд.
3. При подборе технологий на проект не учитывались особенности их совместной работы — минусы одной технологии дополнялись минусами другой. Возникал эффект снежного кома.
4. Отсутствовала возможность кэширования запросов из-за низкого процента идемпотентности.
Что делать?
Подсветив заказчику все нюансы, я подготовил рекомендации, что и как можно улучшить:
1. Разработать новую архитектуру проекта, которая будет закрывать не только текущие потребности бизнеса, но и будет актуальной, гибкой, масштабируемой в дальнейшем.
2. Под новую архитектуру выбрать новые, современные, актуальные технологии, которые будут лучше сочетаться друг с другом, без конфликтов.
3. Переработать тяжелые запросы к базе данных. Разбить их на несколько более мелких, поработать над условиями фильтрации и отказаться от устаревших, а также пересмотреть индексы.
4. Установить менеджер соединений к базе данных.
5. Вынести некоторые запросы к серверу в асинхронные задачи, выдавая ответ пользователю сразу.
Каких результатов достигли?
После внедрения рекомендаций получили следующие результаты:
1. Количество активных пользователей ежедневно — 300 000.
2. Время получения ответа от сервера — 1,5 секунд.
3. Нагрузка на ресурсы сервера приложения и базы данных упала до 20–35%.
При этом количество ресурсов сервера не только не понадобилось увеличивать, но и удалось снизить. Все эти действия были направлены на то, чтобы дать заказчику время на исправление архитектуры приложения и переписывание некоторых модулей.
Чтобы не столкнуться с такими проблемами, нужно на старте проекта подключить IT-архитектора. Он проанализирует потребности бизнеса, технические требования и проработает архитектуру IT-системы так, чтобы в дальнейшем она легко развивалась и приносила прибыль.
Таким образом, IT-архитектор хоть и повысит стоимость разработки на старте, но в процессе работы эти вложения окупятся многократно. Если не получилось подключить такого специалиста, рекомендуем при необходимости провести технический аудит вашего проекта.
Другие кейсы можете посмотреть в нашем портфолио.