VIP-тариф на shared-хостинге не помог
У нас был веб-сервис, состоящий из нескольких веб-приложений, с одной базой данных. Количество пользователей в нем росло геометрически с тридцати до нескольких тысяч человек ежедневно в течение нескольких лет.
Вся инфраструктура располагалась на одном сервере. Сначала на shared-хостинге, где мы постепенно увеличивали тариф. Затем арендовали виртуальный сервер, потом выделенный сервер — и продолжили увеличивать тарифы там. Но очень скоро они снова закончились, и мы перешли уже на персональные VIP-тарифы, но и там быстро уперлись в потолок. Нам не хватало ресурсов процессора, памяти, места для хранения.
В какой-то момент мы ушли в оптимизацию, чтобы сервис работал быстрее и эффективнее на тех мощностях, которые есть. Но поняли, что бесконечно оптимизировать тоже не получится и что пора масштабировать инфраструктуру.
Опыта выполнения таких задач у нас еще не было
Мы рассматривали разные варианты, например решения от Amazon. Но по требованиям законодательства персональные данные должны были храниться на территории РФ, поэтому остановились именно на облаке от крупного российского провайдера. Как поднимать такого слона, мы не знали и обратились к компании, которая помогла нам пройти первый этап и, насколько это возможно, успешно запуститься в облаке.
Переезд мы начинали в канун Нового года, и это добавило нам дополнительных ощущений в праздничные дни. Если нет возможности переехать бесшовно, то надо выбирать время, когда пользователи отдыхают. Но если выполнять сложный переезд в долгие праздники — команда не отдохнет. Приходится выбирать.
С какими проблемами мы столкнулись
Несмотря на то что мы нарисовали последовательный план, архитектуру, пользовались поддержкой провайдера и сотрудничали с командой, которая умеет выполнять такие проекты, всё равно столкнулись с рядом проблем.
Проект начинался достаточно давно, и база данных располагалась на старой версии MySQL 5.7, в облаке же надо было поднимать кое-что поновее, например 8.1. И когда у нас начали падать функции, мы принялись переписывать сервис, чтобы стабильно работать на новой версии. На что потратили пару недель. Из этого мы сделали вывод, что, если проект долгосрочный, надо всегда закладывать время и ресурсы на актуализацию версий ПО и поддерживать текущее решение на более-менее последних версиях. Намного сложнее мигрировать сразу через несколько мажорных обновлений.
Разные веб-приложения работали на разных версиях PHP и были зависимы от них. Более того, некоторые библиотеки были зависимы от старых версий языка и отказывались работать на новых. Тут мы опять вернулись к своему выводу. Всё надо делать вовремя и заранее. Конечно, у нас получилось всё настроить, и мы запустились, но из-за этого мы не смогли нормально контейнировать развертывание. И тут напрашивается еще несколько выводов.
Выводы в процессе
Используйте Docker, K8S и прочие радости жизни, и чем раньше, тем лучше. Лучше с самого начала проекта, это позволит в дальнейшем избежать проблем с окружением и сэкономит кучу времени при миграции. Да и при развертывании сервиса у новых разработчиков на локальных машинах тоже.
Используйте в работе обновляемые решения, если это касается сторонних библиотек. Смотрите, поддерживают ли их, актуализируют ли. Иначе через какое-то время может оказаться, что уже готовые функции надо переписывать.
Следите за количеством запросов и оптимальной работой с БД. Для крупных сервисов это очень важно. Ранее и приложение, и база данных располагались физически на одной машине, теперь же мы решили использовать отдельный кластер базы данных. Сразу после запуска всё было хорошо. Но через два дня пошли жалобы на очень долгую работу сервиса, подвисания.
И действительно, некоторые страницы открывались по 20–30 секунд! Это было неприемлемым, поэтому мы начали разбираться и поняли причину. Пока кластер БД и веб-сервер находились в одном дата-центре, всё было более-менее хорошо. Как только мастером БД становился сервер из другого дата-центра, у нас начинались лаги. Увеличение отклика было всего на 15 миллисекунд, вроде бы не должно влиять, но! На некоторых страницах выполнялось по 600–1000 отдельных запросов. И вот уже время отклика 10 и более секунд.
Система мониторинга, тестирование и написание кода
Первое время мы проверяли всё ручками и поэтому часто узнавали о проблемах от конечных пользователей. Потом запустили телеграм-бота, который уведомлял нас о проблемах раньше, чем мы узнавали о них от пользователей. Поэтому очень советую: применяйте автотестирование на крупных проектах. Прогнать все кейсы при миграции вручную, если функций очень много, слишком затратно, что-нибудь пропустите обязательно.
Далее мы приступили к следующей задаче: у нас было достаточно много файлов, более терабайта, и надо было их вынести в отдельное хранилище с веб-сервера. Сначала мы пробовали монтировать S3 как сетевую папку, но скорость работы оставляла желать лучшего, пришлось дописывать код. Если файлов много, сразу планируйте и пишите код под работу, например с S3. Не храните пользовательские файлы там же, где и само приложение.
Кроме этого, разумеется, было и много других проблем, решений и побед.
Выводы на будущее
Пройдя один раз этот путь, мы определились с тем, как можно организовать работу в будущем. Нужно сразу использовать контейнеризацию, современные версии и обновляемые библиотеки. А на начальном этапе внимательно следить за качеством работы с базой данных и количеством запросов. Также не игнорировать и активно применять автоматическое тестирование. Это основные выводы, которые мы сделали, и большая часть из них позволит избежать проблем как на крупных сервисах, так и на небольших проектах. Для нас этот опыт был однозначно полезен, а местами непередаваем и ярок! Но каждый случай индивидуален, поэтому решать и выбирать инструменты и способы их использования только вам.
