Стабилизацию технической части ecommerce-продукта и проверку корректности всех процессов нужно начинать заранее и заканчивать за несколько недель до периода повышения активности покупателей (например, к Черной Пятнице).
Но массовая распродажа товаров часто влечет за собой нестабильность всей IT-системы маркетплейса, потому что не выполняются какие-либо действия по обновлению конфигурации или кода. Мы с командой попытались разобраться в том, что нужно предпринимать заранее, чтобы ecommerce выдержал наплыв покупателей.
Техническая команда всегда готова подстраховать
Даже с учетом того, что вы уверены в своей IT-системе, всегда есть вероятность, что что-то пойдет не так. У вас должна работать система мониторинга и нотификаций, которая позволяет оперативно быть проинформированными о нештатном поведении платформы, чтобы вы могли предпринять меры для безболезненного устранения любых проблем.
Для быстрого реагирования на проблемы ваша команда разработки должна находится в режиме быстрой доступности. Целью является возможность решения до момента, когда проблемы станут критичными.
Отказоустойчивость и надежность как часть архитектуры
Ваш маркетплейс или экосистема изначально должна проектироваться и разрабатываться с расчетом на то, чтобы иметь возможность обрабатывать быстро возрастающие нагрузки.
Рекомендуем создавать продукт, разделенный на отдельные сервисы, каждый из которых является отдельным компонентом, имеющим возможность автоматического горизонтального масштабирования (Kubernetes).
Взаимодействие между сервисами должно происходить путем обмена сообщениями через асинхронные очереди с логикой повторной отправки в случае ошибки. Это дает дополнительную надежность, если какой-то из сервисов перегружен, позволяя обработать сообщение чуть позже, когда спадет нагрузка или сервис масштабируется в сторону увеличения ресурсов.
К примеру, если вы создаете маркетплейс на базе продукта Scallium, то наша сервисная архитектура (SOA), в сочетании с кластером Kubernetes, позволяет производить горизонтальное масштабирование. Триггерами для начала процесса масштабирования сервисов являются возрастающая нагрузка ЦПУ, увеличение объема использованной оперативной памяти, возрастающее количество сообщений в шине. Эту функцию в Сервисной архитектуре обычно выполняет Message Bus, который у нас реализован на основе RabbitMQ.
Мы реализовали автоматическое масштабирование на уровне Kubernetes, которое развернули на гибкой Google Cloud Platform (GCP). Это дало возможность бесшовно масштабировать все ресурсы, а затем опять их свернуть в автоматическом режиме, при падении нагрузки. Платформа GCP позволяет из “коробки” заложить функционал по автоматическому масштабированию нод в кластере Kubernetes, что, при возрастающей нагрузке на приложение, увеличивает количество доступных ресурсов для автоскейлинга самого приложения.
Система мониторинга SaaS-платформы Health Monitoring System
Рекомендуем разработать инструмент мониторинга, который круглосуточно и автоматически анализирует работоспособность и быстродействие системы, фиксирует логи, формирует отчеты о событиях и возникновении нештатных ситуаций, сигнализирует дежурных.
Данные анализируются соответствующим сервисом, который прогнозирует точки отказа и дает возможность техническим экспертам реагировать заблаговременно до наступления нештатных ситуаций. Система мониторинга связана с корпоративным чатом для информирования соответствующих линий поддержи.
Система мониторинга должна работать на 2 уровнях:
Инфраструктурный уровень
Уровень приложения
Инфраструктурный уровень покрывает уровень доступности системных сервисов, сети, ресурсов кластера (Prometheus). На уровне приложения у нас работает Sentry DSN, он позволяет отслеживать работу приложения на уровне взаимодействия сервисов.
Данные уровни взаимодополняющие и позволяют в результате анализа предупреждать о возникновении нештатных ситуаций. Либо оперативно предпринимать меры по возникшим проблемам.
Система резервного копирования платформы маркетплейса
Одним из аспектов надежности любой платформы (к примеру, маркетплейса) есть стратегия создание резервных копий. Если архитектура спроектирована по парадигме сервисной архитектуры, то фактически позволяет выносить ключевые точки хранения данных за рамки Kubernetes кластера, и использовать сервисы как услугу от провайдера (GCP).
Это упрощает не только администрирование такого приложения, но и создание/обслуживание системы бекапов. И поскольку все ключевые точки (у нас это наборы сервисов разных типов - PostreSQL, MongoDB, RabbitMQ, S3 bucket и десятки сервисов) это “stand alone” сервисы провайдера, бекапирование реализовано нативными средствами GSP, а это простота в управлении, надежность, и безотказность.
