Хамзет Шогенов, архитектор облачной платформы Mail.ru Cloud Solutions

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

Порядка 90% интернет-магазинов в западных странах работают исключительно в облаке. В России на облачных платформах развернуто около 20% торговых онлайн-площадок, еще около 50% ритейлеров используют гибридную модель (облака + собственную инфраструктуру). Российский рынок технологий традиционно идет по западному пути с отставанием в 3-5 лет. Поэтому можно предположить, что в течение 5 лет большинство интернет-магазинов в России будут базироваться в облаках.

Быстрому переходу способствуют несколько факторов: связанный с пандемией массовый уход покупателей в онлайн, повышение функциональности и защищенности публичных облаков, а также возможность сэкономить серьезные средства, отказавшись от традиционной инфраструктуры. Еще одна важная причина востребованности облачных технологий — сокращение времени вывода нового сервиса на рынок (time-to-market) благодаря использованию набора готовых инструментов, предоставляемых облачным провайдером по модели PaaS (платформа как услуга).

Облака выбирают как для создания интернет-магазинов с нуля, так и переноса в облако работающего сервиса по мере роста бизнеса и увеличения нагрузки. Что нужно учесть, вставая на "облачный" путь развития?

Нюанс первый: варианты развертывания в облаке

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

Второй вариант заключается в аренде виртуальных машин с предустановленной ОС. На их базе можно построить любую нужную инфраструктуру: выбрать необходимые конфигурации сетей и виртуальных машин, различные типы дисков под разные задачи, высокопроизводительные процессоры. Плюсом такого подхода является сохранение полного контроля над кодом и его инфраструктурой, а также всеми механизмами обеспечения отказоустойчивости сервиса. Минусом же можно назвать необходимость в "ручных" настройках и администрировании.

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

Такой сервис, как Managed Kubernetes, может стать основой для производительного, устойчивого к отказам интернет-магазина с возможностью практически безграничного горизонтального масштабирования. Минусом этого пути можно считать необходимость держать в штате сильную команду ИТ-специалистов, хорошо знакомых с концепцией Cloud native. В случае с облачным Kubernetes его администрированием занимается провайдер, эксплуатируют разработчики и, например, один администратор.

Нюанс второй: обеспечение отказоустойчивости

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

При использовании облачной инфраструктуры и услуг обеспечение их работоспособности в магазине лежит на стороне поставщика и регулируется требованиями SLA (соглашение об уровне предоставления услуг). Зрелый провайдер предоставляет все инструменты для организации отказоустойчивой инфраструктуры. В свою очередь, на стороне заказчика специалисты по эксплуатации должны уметь ими грамотно пользоваться. В зависимости от потребностей клиент может настроить тройную репликацию систем хранения данных (наличие копий на трех серверах) или услугу аварийного восстановления (Disaster Recovery as a service). Чем выше уровень отказоустойчивости и, соответственно, больше объем вовлекаемых ресурсов, тем выше надежность инфраструктуры, но и стоимость услуг тоже начинает быстро расти.

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

Нюанс третий: масштабирование и нагрузочное тестирование

Серьезной ошибкой на этапе внедрения может стать недостаточное внимание к изменениям нагрузки. В традиционной локальной инфраструктуре ошибки масштабирования могут оказаться фатальными, однако облака более устойчивы к скачкам нагрузки. Публичные облака «эластичны» по определению и способны легко справиться с кратным повышением количества обращений, объема хранимых данных и т.д. Эластичность выделения облачных ресурсов позволяет реализовать автоскейлинг (эта услуга не включена по умолчанию). Ее подключение действительно позволяет почти не задумываться о нагрузках — мощности автоматически "подтягиваются" в случае необходимости.

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

Нюанс четвертый: оптимизация доставки контента

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

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

Несмотря на доступность хранилища S3 из любой точки мира, на большие расстояния данные передаются с задержкой. Поэтому глобальные продавцы часто сочетают хранилище с сетью доставки контента CDN (Content Delivery Network). Сервис ускоряет загрузку сайтов и приложений вне зависимости от региона нахождения пользователей: данные дублируют на серверах, размещенных в разных географических зонах. Если облачный провайдер имеет распределенную сеть дата-центров и предоставляет такую услугу, то комбинация S3+CDN решит проблемы медленной загрузки страницы.

Нюанс пятый: защита приложений

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

Зрелый облачный провайдер сможет предложить клиенту собственный сервис по защите от DDoS, воспользоваться которым лучше до того, как начнется первая атака. Что касается атак, накручивающих регистрации ботов, то для защиты от них требуется достаточно сложная фильтрация всех обращений при помощи решений класса Web application firewall. На основе анализа поведенческих моделей они фильтруют нежелательные обращения к сайту. Такое ПО тоже может быть предоставлено облачным провайдером.

Отдельно стоит упомянуть о том, что провайдер не должен навязывать клиенту свои инструменты. Свобода выбора защитного ПО должна оставаться за заказчиком услуг.

Нюанс шестой: аналитика

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

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

Нюанс седьмой: выбор облачного провайдера

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

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

● Облачный провайдер должен предоставлять четкие, понятные и легко проверяемые SLA, соответствующие требованиям конкретного заказчика услуг. Договор об уровне предоставления нужно изучить внимательно. Кроме основного SLA доступности всей инфраструктуры, стоит включить отдельные пункты по скорости сети и дисков, уровню доступности объектного хранилища, времени реакции техподдержки.

● Площадка должна предоставлять доступ к исчерпывающему и современному инструментарию разработки. Например, давать возможность использовать сервисы Infrastructure as a Code (инфраструктура как код). Его идея в том, чтобы управлять инфраструктурой как программным обеспечением, с помощью написание кода. Например, таким инструментом является Terraform. Преимуществом является наличие платформенного сервиса Kubernetes.

● Возможности провайдера должны отвечать не только текущим, но и будущим запросам проекта, которые появятся по мере его роста. Для организации действительно отказоустойчивой архитектуры стоит обратить внимание на инфраструктурные сервисы провайдера (IaaS). Необходимо, чтобы в облаке была возможность организовать сеть, как между виртуальными машинами, так для доставки контента (CDN). Как правило, в IaaS-сервисы провайдера по умолчанию включены инструменты управления виртуальными машинами: балансировщик нагрузок, частный DNS (система доменных имен), VPN (виртуальные частные сети), маршрутизатор.

● Большим преимуществом является возможность провайдера предоставлять различные готовые инструменты. Это позволит повысить надежность магазина, создать недорогую аналитическую платформу, быстро подключить средства мониторинга и создать удобные средства визуализации и управления (дашборды).

● Для более предсказуемого развития бизнеса следует избегать зависимости от вендоров. Облачные платформы могут строить свои сервисы как на проприетарном ПО, так и на решениях с открытым исходным кодом. В первом случае есть риски приостановки поддержки продукта, ухода вендора с локального рынка или прекращение деятельности. В случае с Open Source решениями проект независим от ситуации в сторонних компаниях.

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

Источник: Retail Loyalty