Кейсы клиентов

Возможности платформы:
— формирование данных на основе фотографий, аудио записей и ответов на вопросы по продуктовой категории, которые делают потребители с помощью мобильного приложения;
— обработка данных системой распознавания изображений и модераторами, после которой результаты доступны в онлайн-аналитике;
— интеграция аналитики в мотивационную программу полевого персонала и менеджмента для улучшения торговых показателей.

Присутствовали проблемы:
— скрипты деплоя были написаны на Shell и расположены непосредственно в репозиториях приложений; учитывая, что приложения разрабатываются в некотором кол-ве веток (до 10-20) это делало весьма трудоёмким (и чреватым ошибками) внесение правок в систему деплоя;
— в Deployments не были указаны requests/limits, вследствие чего нагрузка распределялась по нодам весьма неравномерно. Readiness/liveness probes также не указывались, что вызывало необходимость ручного перезапуска контейнеров (подов) с приложениями по любому поводу - от подвисания приложения до рестарта БД;
— автоматического фейловера для postgresql не было, при сбоях master'ов приложения падали, пока администратор вручную не поднимет базу или сервер;
— не производилось резервное копирование PostgreSQL (бэкап предыдущим подрядчиком был настроен на свои мощности и ушёл вместе с ним - остался только быстро растущий архива WAL, съедающий место на дисках);
— автоматический vacuum (или repack) для postgresql не был настроен, из-за чего также постоянно возникали проблемы с заканчивающимся местом на дисках (в несколько баз идёт очень интенсивная запись с профилем, вызывающим bloating);
— redis, являющийся необходимым сервисом для работы приложений (большая часть без него просто не запускается, при отказе redis падает) был развёртнут в k8s как StatefulSet в виде кластера на sentinel и sidecar (представлявшем собой шелл-скрипт иногда отрабатывал непредсказуемо); этот sidecar вхолостую расходовал CPU на нодах и не обеспечивал отказоустойчивости (более того, являлся причиной периодических отказов сервиса redis);
— сетевое взаимодействие между физ. нодами и нодами k8s было настроено с наборами одинаковых IP на linux-bridge и правилами ebtables. Эта схема была создана, очевидно, для обеспечения отказоустойчивости при выходе одного из серверов из строя, но была несколько недоработана и крайне трудоёмка в понимании и поддержке.

Используемый стек технологий: CentOS GNU/Linux, Kubernetes, Gitlab, Ceph, PostgreSQL, Redis, Pacemaker, Ansible.

Решение: Для обеспечения поставленной цели были предприняты следующие действия:
— разработан отказоустойчивый сетап с автофейловером для PostgreSQL на базе Pacemaker с ресурс-агентом pgsql, развернуто несколько трёхнодовых кластеров и на них смигрированы все БД;
— настроена непрерывная архивация PostgreSQL, позволяющая восстановить состояние любой базы на любой момент времени за несколько дней назад;
настроен pg_repack по расписанию для таблиц с выраженным bloating (написан скрипт-обёртка для обхода проблемы незакрытых транзакций и вычисления необходимого дискового пространства);
— развёрнут новый кластер Kubernetes, в него смигрированы все приложения, старый кластер уничтожен;
— для обработки отказов вида "падение ноды с ingress" применена кластеризация Pacemaker с ресурс-агентом kumina-hetzner-ip для управления Hetzner Failover IP;
redis вынесен из k8s, для него разработан фейловер на Pacemaker + HA redis;
— деплой приложений в k8s был полностью переписан на ansible, применены resource requests и limits; также по просьбе разработчиков была применена схема blue-green deploy, позволяющая мгновенно и без простоя переключать трафик со "старого" кода на "новый".

Результат: Стабильность работы приложений значительно выросла, простои по вине инфраструктуры значительно сократились (пока не в 0, но мы продолжаем поиски решения комплексных проблем, связанных с растущей нагрузкой от приложений), трудоёмкость обслуживания уменьшилась в десятки раз (в основном, всё "просто работает").
Инфраструктура активно развивается, были развернуты новые экземпляры приложений и баз в других локациях (и планируется ещё).

Используемый стек технологий: Gitlab (CI, registry, gitlab-runner), Helm v3, Prometheus, Grafana, PostgreSQL, EFK, Kubernetes, Redis, Kafka, Clickhouse

Решение:
— развернут новый кластер k8s,
— создана репликация master-slave PostgreSQL,
— разработан унифицированный CI для всех микросервисов через Helm,
— добавлены окружения для тестирования,
— дополнительно на серверах вне кластеры были подняты apache Kafka и Clickhouse (необходимо для работы приложения).

Результат: Построен отказоустойчивый кластер с системой мониторинга и логирования. Доступность инфраструктуры вышла на уровень 99.95%, а небольшая доля простоев не связана с проблемами инфраструктуры. Из-за унифицированного CI клиенту стало возможным управлять им самостоятельно без привлечения инженеров, на базе этого CI позже были добавлены другие проекты. В дальнейших планах, при росте нагрузке, настроить масштабирование приложения.