110
0
0
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники
Назад

Как создать архитектуру для максимальной производительности highload-системы

Время чтения 1 минута
Нет времени читать?
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники
110
0
0
Нет времени читать?
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники

Привет! Меня зовут Станислав Тибекин, я CEO компании Nixys. Мы занимаемся поддержкой и обеспечением стабильной работы высоконагруженных систем для самых разных клиентов: от промышленных предприятий до ecommerce, от облачных вычислений до финансового сектора. 

В этой статье я поделюсь одним из наших рабочих кейсов.

Как создать архитектуру для максимальной производительности highload-системы

Цели проекта

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

К нам обратилась компания, занимающаяся разработкой собственного продукта — MES-системы (ПО, используемое для управления производственными процессами). Перед инженерами стояла задача развернуть Kubernetes-кластер для высоконагруженного приложения на текущих мощностях клиента и затем на мощностях конечного заказчика. 

Помимо основных требований к отказоустойчивости инфраструктуры, нужно было обеспечить доступность 24/7, внедрить системы мониторинга для отслеживания работы приложения в режиме реального времени и возможность горизонтального масштабирования. 

Наши методы работы

Вот основные практики, которые мы используем для обеспечения стабильной работы.

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

Контейнеризация и оркестрация. Мы упаковываем приложения и их зависимости в изолированные контейнеры для надежного развертывания.

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

Мониторинг в реальном времени. Для отслеживания работы систем и оперативного реагирования на проблемы мы используем системы мониторинга.

Резервирование и отказоустойчивость. Мы предусматриваем механизмы резервирования данных, репликации и резервирования сетевых путей, чтобы минимизировать потери данных в случае сбоев.

CI/CD. Автоматизация процессов сборки, тестирования и развертывания позволяет сократить время выхода в production.

Особенности проекта

Первая особенность этого проекта заключалась в том, что он был развернут полностью на bare-metal-серверах. Это давало программному обеспечению возможность прямого взаимодействия с аппаратной частью, обеспечивая максимальную производительность и контроль над ресурсами, что особенно важно для высоконагруженных приложений. 

В рамках проекта также применялся MetalLB — балансировщик нагрузки, предназначенный как раз для решений, где Kubernetes работает на bare-metal-серверах. Кроме того, в связи с требованиями к безопасности у клиента Kubernetes-кластер был настроен для работы в закрытом контуре, а доступ к нему осуществлялся через удаленный рабочий стол, что усложнило взаимодействие инженеров с продуктом.

Что было сделано

  1. Первым этапом мы развернули Kubernetes на текущих серверах клиента. Его настроили для работы в закрытом контуре, что обеспечило высокий уровень безопасности.
  2. Далее мы использовали PostgreSQL Cluster и подключили к стеку Patroni, обеспечив тем самым автоматическое переключение при отказе и хранение важных данных в распределенном хранилище конфигурации на базе систем ETCD. Здесь интересно то, что соединение приложения и базы данных происходит не напрямую, а осуществляется через прокси-сервер, в нашем случае HAProxy. Прокси определяет главный узел, который в каждый конкретный момент времени имеет возможность обрабатывать соединения. Использование прокси-сервера минимизирует шанс встретить split-brain (ситуация, когда узлы в распределенной системе теряют связь друг с другом, но продолжают работать независимо) в кластере баз данных. PGBouncer был использован для минимизации издержек, связанных с новыми подключениями к базе данных
  3. Заключительным этапом была настройка CI/CD и систем мониторинга для отслеживания состояния инфраструктуры в режиме реального времени. Мы использовали Prometheus для сбора метрик и Grafana для визуализации данных, а также системы алертинга для оповещения о неполадках.

Итоги

В результате мы выстроили инфраструктуру, полностью соответствующую требованиям заказчика. Развертывание Kubernetes-кластера на bare-metal-серверах обеспечило непрерывную доступность приложения 24/7.

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

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

Заключение

В нашем проекте высокая отказоустойчивость и горизонтальное масштабирование, обеспеченные посредством Kubernetes и связанных технологий, имели большое значение. PostgreSQL Cluster и Patroni были использованы для обеспечения автоматического переключения в случае отказа, что позволило минимизировать простой базы данных.

PGBouncer был внедрен для оптимизации подключения к базе данных, снижая нагрузку и ускоряя обработку запросов. HAProxy обеспечил эффективную балансировку нагрузки, распределяя трафик и поддерживая высокую производительность, а настроенные системы мониторинга гарантировали, что критические проблемы будут замечены и исправлены до того, как они повлияют на конечных пользователей.

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

Интересный факт: согласно исследованию Gartner, простой интернет-ресурса крупной компании обходится примерно в 5000 долларов за минуту. Это означает, что ваши системы должны быть подготовлены к огромной нагрузке и оптимизированы до мелочей.

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

В целом архитектура highload-систем требует глубокого понимания как технических, так и организационных аспектов, и наш опыт в Nixys подтверждает это. Внедрение DevOps-практик позволяет создавать масштабируемые, надежные и производительные системы, способные эффективно обслуживать миллионы пользователей.

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

Комментарии0
Тоже интересно
Комментировать
Поделиться
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники