6 кейсов клиентов Southbridge

Крупнейшая страховая компания в России

Ситуация заказчика

Решение

Результат

Аудит

Используемый стек технологий

Заказчик обратился из-за нестабильной работы проектов в кластере Kubernetes, необходимо было проработать варианты решения проблемы. Также заказчика интересовало компетентное мнение о текущих настройках и программном обеспечении.

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

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

У клиента микросервисы, написанные на ruby, sidekiq в качестве брокера сообщений. CI/CD осуществлялся с помощью ansible, в CI/CD использовалось огромное количество самописных скриптов, таким образом процесс завязывался на одном инженере. Был кластер кубернетиса, но из-за неверно выбранной архитектуры поды оказались прибиты к определенным нодам (у haproxy в качестве бэкенда указывались конкретные Ip и порты).

Онлайн видео-конструктор с расширенными возможностями

Ситуация заказчика

Решение

Результат

Аудит

Используемый стек технологий

Проект с плавающей нагрузкой в пиках сильно проседал по производительности. Необходимо было обеспечить отказоустойчивость и масштабируемость. Также клиенту требовался универсальный чарт для управления изменениями большого количества однотипных сервисов.

Автоматическое масштабирование приложений обработчиков видео реализовано в зависимости от нагрузки CPU. Предприняты следующие действия:
— кластер развернут с помощью eksctl;
— приложения из ECS, перенесли в EKS (k8s в Amazon);
— веб-приложения на Heroku
— перенесли в k8s (экономия финансов);
— gitlab раньше использовался только для хранения кода. Сейчас CI запускается автоматически, образ сохраняется в registry, автоматически развертывается новая версия приложения в кластере;
— разработан унифицированный CI для всех микросервисов через Helm;
— сборка и деплой реализован в режиме DinD. Это имеет ряд преимуществ: дополнительную изоляцию, удобное масштабирование, возможность запускать на spot-нодах;
— убраны окружения, настроенные вручную. Подняты 3 окружения dev, prod, stage управляются автоматически;
— используется 2 зоны доступности, минимально необходимое количество для отказоустойчивости.

Быстрый и автоматический деплой приложений в кластер без простоя сервиса. Использование нескольких окружений для тестирования и подготовки приложений. Удобный мониторинг потребления ресурсов и доступности сервисов. Планируется сделать автоматическое масштабирование приложений в зависимости от количества заданий в очереди на обработку.

У клиента множество микросервисов, написанных на node.js. Нужен был унифицированный подход к CI/CD для всех приложений. Особенностью проекта является сильно плавающая нагрузка от приложений-обработчиков видео. Для деплоя применялся Docker. Gitlab использовался только для хранения кода. Сборка и деплой проводились вручную. Развертывание происходило на ноды ECS в Amazon. Веб-приложения были расположены на Heroku.

Онлайн-платформа для организации независимого торгового аудита и оценки сервиса

Ситуация заказчика

Решение

Результат

Аудит

Используемый стек технологий

Клиент обратился с проблемой нестабильной работы приложений в кластере и периодическими проблемами с недоступностью баз данных PostgreSQL и Redis. Несмотря на то, что Redis был реализован в HA-сетапе, при недоступности одной из нод кластер долго переключался, что было критично для приложения клиента.

Для обеспечения поставленной цели были предприняты следующие действия:
— разработан отказоустойчивый сетап с автофейловером для 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, но мы продолжаем поиски решения комплексных проблем, связанных с растущей нагрузкой от приложений), трудоёмкость обслуживания уменьшилась в десятки раз (в основном, всё «просто работает»).
Инфраструктура активно развивается, были развернуты новые экземпляры приложений и баз в других локациях (и планируется ещё).

Инфраструктура представляла собой нагруженный кластер Kubernetes на 3-х физических нодах (с использованием Ceph в качестве общего хранилища) и некоторое количество экземпляров PostgreSQL (до полутерабайта объёмом), также на 3-х серверах. В кластере Kubernetes посредством GitLab CI было развёрнуто два десятка приложений.

Платформа объединяет в себе сервис для заказа, доставки еды и онлайн-академию рестораторов

Ситуация заказчика

Решение

Результат

Аудит

Используемый стек технологий

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

Проведен аудит серверов и выполнен пул следующих работ:
— когда серверы и кластер k8s был запущен, оказалось что в кластере elasticsearch на одном из трех узлов отсутствовали данные. В настройках узла elasticsearch не был убран параметр: «cluster.initial_master_nodes: elastic-0». В результате узел не мог добавиться в существующий кластер, и создавал новый из одного узла. Опцию убрали, и узел успешно присоединился к кластеру.
— появилась задача ручного управления кластерами Hazelcast. Развернут managment-center, интегрирован в кластер. Он предоставляет веб-интерфейс для ручного управления кластером. Работы успешно проведены.
— не запускалась Kafka. Причина была в исчерпании места на PV в кластере. Место добавили.
— некоторые приложения в окружениях dev и prod использовали единый кластер Kafka. Внесены изменения в helm-чарты для разделения окружений.
— по просьбе клиента был заполнен индекс в elasticsearch на основании данных из cassandra. Типы данных и структура индекса приведены к необходимым для приложения.

В рамках разовых работ сервера и кластер приведены в работоспособное состояние. Данные в кластере Hazelcast успешно восстановлены. В рамках поддержки произведены следующие дополнительные работы: — по просьбе клиента часто приходилось вручную редактировать данные в кластере cassandra, вносить изменения в схему. Поэтому было принято решение реализовать ежедневный бэкап кластеров cassandra на удаленный сервер. Восстановление данных из бэкапа cassandra уже использовалось при откате на предыдущую версию в dev-окружении.- клиентом было разработано приложение на Flask, которое позволяет удобно проводить обслуживание внутренних данных основного приложения через веб-интерфейс. Для приложения написан helm-chart, настроен CI без использования werf. Персистентные данные приложения хранятся в ceph rbd.

Кластер заказчика пришел к нам в неработоспособном состоянии. Не стартовали поды, отсутствовали данные в кластере ElasticSearch.

Инструмент для интеграции, анализа и улучшения покупок внутри iOS приложений

Ситуация заказчика

Решение

Результат

Аудит

Используемый стек технологий

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

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

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

У клиента микросервисы, написанные на ruby, sidekiq в качестве брокера сообщений. CI/CD осуществлялся с помощью ansible, в CI/CD использовалось огромное количество самописных скриптов, таким образом процесс завязывался на одном инженере. Был кластер кубернетиса, но из-за неверно выбранной архитектуры поды оказались прибиты к определенным нодам (у haproxy в качестве бэкенда указывались конкретные Ip и порты).

Рекламная сеть

Ситуация заказчика

Решение

Результат

Аудит

Используемый стек технологий

Обновления кластера Kubernetes сопровождались простоем и большим количеством проблем в последствии. Процесс CI/CD часто завершался с ошибками что сильно увеличивало time-to-market.

— развернуть новую версию Kubernetes-кластера,
— создать новые процессы CI/CD,
— оптимизировать обработку метрик.

— повысили отказоустойчивость кластера Kafka,
— оптимизировали хранение и обработку метрик, пересмотрели подход к алёртингу,

— доработали CI/CD, внедрили канареечный деплой,
— обеспечили надёжность хранения персистентных служебных данных.

Рекламная сеть обрабатывает большой объём трафика, что создаёт высокую нагрузку на инфраструктуру. При этом состояние Kubernetes-кластера не отвечало требованиям отказоустойчивости, не было уверенности в текущей инсталляции, процедура обновления была непрозрачной, при деплое возникали ошибки.

Будем рады проконсультировать вас и обсудить проект.