Как IT-архитектор поможет сократить затраты: история одного проекта

Начинаете разработку IT-проекта или уже обнаружили в архитектуре системы проблемы с производительностью и масштабируемостью? Тогда вам может быть полезно прочитать один из кейсов SimbirSoft. В нем рассказываем, как наш специалист, подключившийся для усиления команды заказчика, помог оптимизировать затраты при масштабировании сервиса. Материал будет полезен СТО, CIO, руководителям проектов и владельцам IT-продуктов.

Привет! Меня зовут Михаил, я веб-разработчик компании SimbirSoft. Расскажу вам о случае из своей практики. Когда я подключился к проекту заказчика, то сразу обнаружил, что скорость обработки запросов к серверу сильно отличается от оптимальных значений: 15 секунд вместо 1,5.

При этом такая скорость была при количестве посещений в 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-архитектор хоть и повысит стоимость разработки на старте, но в процессе работы эти вложения окупятся многократно. Если не получилось подключить такого специалиста, рекомендуем при необходимости провести технический аудит вашего проекта.

Другие кейсы можете посмотреть в нашем портфолио.