Ветменеджер: история архитектуры нашего сервиса

Когда-то в глубокой древности, когда деревья были совсем маленькими я (Владимир Романичев) пришел на проект Ветменеджер. До меня его кто-то уже делал, что-то уже работало.

Ветменеджер работал на одном компьютере, на нем стоял веб-сервер, php и база данных. Этот компьютер, который еще можно назвать сервером, мы арендовали в дата-центре, его обслуживал системный администратор Аркадий. Еще 2 года мы работали над программой без пользователей. Пользователями были программисты и Владимир Хубирьянц.

Сначала программу начали использовать в Краснодарской клинике На Бабушкина, затем мы открыли бесплатную бета-версию. У нас появились первые пользователи. Хоть это и не касается темы, я вынес с тех времен огромный урок: запускайся как можно раньше. Все, что мы считали важным до запуска, улетучилось, как только появились реальные пользователи. Все, что виделось как серьезная проблема, ушло на двадцатый план и уже 10 лет никому не нужно.

Время шло и мы наблюдали за тем, как серверу тяжелее справляться с нагрузками. Мы начали подключать новые сервера. Для этого программа тоже менялась. Мы подключили несколько серверов, и каждая клиника жила на своем. Конечно, не одна клиника на один сервер. Мы поделили клиники на группы и знали, где какая обитает. Перед сервером стоял специальный узел, который по адресу клиники понимал, на какой именно сервер идет конкретная клиника.

Так мы жили какое-то время и выросли до 5 серверов. Последний сервер мы так и не начали эксплуатировать, но он был. У нас появился кеш, появились очереди, хорошая система резервного копирования, репликации серверов БД. Но эксплуатация подобной системы требовала от нас много ручной работы. К примеру, публикация обновления в конце начала занимать несколько дней и это все было в полу ручном режиме. Мы регулярно перетасовывали клиники с одного сервера на другой, чтобы обеспечить равномерную загрузку, ибо клиники все активнее использовали программу и это было неравномерно. Плюсом этой системы была простота, количество точек отказа (их было мало) и все работало достаточно стабильно. Количество простоев можно было пересчитать по пальцам. Минус — слишком тяжело менять сервер и его настройки, обновление ПО на серверах было страшной проблемой чреватой длительным простоем.

В один очень грустный момент произошла авария и мы простояли несколько часов. Самое печальное, что в этот момент никто из программистов и даже системный администратор не знали, что делать и как это поднять. Сервер поднимался несколько часов. Мы начали искать другое решение.

Сотрудничество с компанией ФЛАНТ

Это были долгие поиски, консультации с несколькими компаниями предоставляющими подобные услуги. В итоге мы выбрали для сотрудничества компанию ФЛАНТ. В тот момент они практически единственные пропагандировали подход Devops для инфраструктуры, тогда это все еще был рискованный шаг, он еще не был стандартом в индустрии. Это было 3 года назад.

Компания Флант нам предложила Kubernetes кластер. Это такая штука, где все сервера виртуальные, их легко масштабировать в любую сторону просто делая правки в конфиге. На картинке показана слегка упрощенная схема нашей архитектуры.

Связь m-m между базами данных означает, что оба сервера являются ведущими и в них можно записывать информацию. Связь m-s говорит о том, что один сервер является ведомым, и из него можно только читать, но не писать информацию, программа его использует для построения отчетов.

Обратите внимание, что в качестве php и других сервисов я нарисовал облачко. Это не обычный сервер с php, нет. Это именно облако, в котором может быть сколько угодно php серверов. Сейчас там уже 22 виртуальных php сервера (только для самого проекта Vetmanager), а начинали мы с 6. Еще несколько десятков серверов наберется и для виджетов записи на прием, бэкэнда мобильной версии и других проектов, о которых вы еще не знаете.

Мы получили сервис абсолютно нового уровня, у нас появилась круглосуточная техническая поддержка, которая реагирует на инциденты в течение 5 минут 24 на 7. Разработчики получили возможность работать с передовыми технологиями, а главное — их легко обновлять. Приложение получило правильные архитектурные изменения, мы перешли на новую версию php, мы получили возможность использовать новые инструменты, которые в прошлом не могли себе позволить. Чтобы программа начала работать не на 5 серверах, а на многих десятках серверов, было потрачено более чем полгода усилий (и зарплат) целой команды программистов.

Есть и минусы, виртуальные сервера отличаются от реальных только тем, что физически их может быть много на одном компьютере. Система получилась очень громоздкой. Много узлов и точек отказа. Наш сервис часто шатало из-за этого. Каждый раз мы вместе с сотрудниками ФЛАНТ находили новые и новые проблемы, которые приводили к сбоям. Каждый раз мы искали и устраняли причину, сервис становился надежнее.

С момента переезда на новую архитектуру мы выросли с 300 клиник до 800 и продолжаем расти. Мы снова стали сталкиваться с проблемами производительности, сервера работали на высоких нагрузках и стали часто уходить в пик и недоступность. Мы рассматривали много разных способов решения, какое-то время у нас появился дубль серверов баз данных. К БД1-БД2-БД3 мы добавили такой же кластер серверов и часть клиник переехали туда.

Следующий шаг — дублирование инфраструктуры в другом дата-центре

Мы решили идти еще дальше. Мы будем дублировать инфраструктуру в другом дата-центре. Полностью!

Да, это дорогое удовольствие и для аренды, и для обслуживания. С января мы прорабатывали этот вариант. Закупили сервера. Много серверов. Это же полный дубль по инфраструктуре. Админы несколько недель настраивали ПО на них, строили систему мониторинга, резервного копирования, доставки обновлений на сервера. Параллельно программисты меняли архитектуру программы. Программа теперь должна уметь работать в разных дата-центрах, безошибочно понимать, где она находится. Много десятков серверов мы теперь умножаем еще и на количество дата-центров. Сотни серверов (пусть и виртуальных).

Мы выбрали именно этот путь, поскольку это возможность дать еще больше пользы нашим клиентам. Сейчас в новый дата-центр мы уже мигрируем клиентов, для которых он ближе территориально, а значит повышается и скорость работы для них. Еще несколько недель мы будем осуществлять переезд клиник. Приносим извинения тем, кого это затронет. Мы видим и тренд на деглобализацию интернета и уже готовы размещать мощную инфраструктуру в любом месте как можно ближе к нашим клиентам.

Мы благодарны всем нашим клиентам, которые остались с нами несмотря на наши болезни роста. Мы делаем все, что в наших силах, для надежности и стабильности сервиса.