Есть несколько способов развернуть интернет-магазин в облаке: например, его можно развернуть на инфраструктуре провайдера самостоятельно или с помощью готовых платформенных сервисов. Вне зависимости от выбранного способа для интернет-магазина нужны стабильная безопасная инфраструктура и надежное хранение данных.
В этой статье расскажем о разных подходах к построению интернет-магазина в облаке на примере нашей платформы, а также о том, какие инструменты помогут повысить его надежность и отказоустойчивость.
MCS – Mail.ru Cloud Solutions | Платформа облачных сервисов от Mail.ru Group
Разворачиваем инфраструктуру для интернет-магазина
В первую очередь для развертывания интернет-магазина потребуется инфраструктура, то есть серверы, на которых будет работать ваше решение. Кроме того, сам интернет-магазин может быть построен на основе готовой CMS для управления сайтом или собственного приложения:
- Если брать готовое решение, то на развертывание понадобится меньше ресурсов. Конечно, нужны будут доработки, но в любом случае это быстрее и проще, чем писать свой код: не надо нанимать дополнительных специалистов. Это хороший вариант, если нужно быстро начать продавать. В таком случае можно обойтись меньшим количеством времени и ресурсов разработчиков, при этом сохраняя большую часть плюсов самописного кода.
- Собственное приложение разработать сложнее, это требует времени, зато вы получаете полный контроль над кодом, можно внедрять любые новые функции.
В зависимости от того, какой вариант вам подходит — готовая CMS или собственная разработка, — вы можете выбрать разные способы развертывания облачной инфраструктуры.
Способ первый: разворачиваем интернет-магазин на облачных серверах
Вариант 1. Облачный сервер с предустановленной CMS. Этот вариант подходит, когда как можно скорее нужен обычный работающий сайт, не требуется доступ к виртуальным серверам, которые под ним лежат, вы не собираетесь администрировать инфраструктуру.
Тогда стоит выбрать готовое решение, которое можно запустить в облаке за полчаса. Например, на платформе Mail.ru Cloud Solutions есть маркетплейс — магазин облачных приложений. По сути, это образы операционных систем с набором скриптов для установки приложения в рамках развернутой виртуальной машины.
Там можно развернуть облачный сервер в нужной конфигурации с предустановленным WordPress, настроить эту CMS, установить нужные плагины для работы интернет-магазина и сразу получить работающий сайт. WordPress — одна из распространенных CMS, для нее существует огромное количество совместимых инструментов и дополнений.
В этом случае вы можете выбрать подходящую конфигурацию виртуальной машины, в частности тип процессора, количество его ядер, размер оперативной памяти, указать размер диска и его тип — от стандартных HDD до быстрых High-IOPS SSD-дисков. Выбор типа диска зависит от требуемой производительности: чем больше будет нагрузка на ваше приложение, тем более быстрой должна быть дисковая подсистема.
Это вариант с минимальным порогом входа. Вы получаете возможность использовать виртуальный сервер с нужной производительностью, пользоваться всеми возможностями WordPress и платить только за используемые ресурсы.
Недостаток в том, что это шаблонное решение, предназначенное для быстрого запуска простого сайта или тестовой среды. Здесь не стоит ждать оптимизации настроек под ваше приложение, отказоустойчивость и масштабируемость не заложены автоматически, но их можно реализовать, запустив несколько машин с WordPress и своими силами или с помощью экспертов провайдера донастроив все необходимые механизмы.
Кроме развертывания виртуальной машины с предустановленным WordPress, нужно будет сконфигурировать Firewall, настроить DNS-записи в соответствии с тем именем, с которым нам нужно, чтобы обращались к интернет-магазину, сгенерировать SSL-сертификат.
Также потребуется создать сеть, проставить ее параметры, дать ей название и указать внешний IP-адрес, чтобы виртуальная машина была доступна через интернет.
В правилах Firewall, которые можно найти в разделе «Виртуальные сети», уже будет автоматически созданный набор правил под наше приложение.
После настройки сети, DNS и установки SSL можно дополнить WordPress нужными плагинами и приступать к работе.
Вариант 2. Аренда облачного сервера (IaaS). Это традиционный подход, когда вы арендуете в облаке мощности и создаете ваш персональный виртуальный сервер. На этом сервере вы можете развернуть что угодно — от обычной CMS до самописного приложения. Такой вариант оптимален, когда вы хотите использовать приложения, написанные вашими разработчиками, получить полный контроль над виртуальными машинами и тем, что находится на них. Например, если уже есть написанное собственное приложение или существующие готовые решения не устраивают по каким-либо параметрам.
У вас полная свобода настроек и патчинга, можно быстро внедрять новую функциональность и закрывать уязвимости, создавать любые архитектурные решения. Кроме того, вы также платите только за использованные мощности. Из минусов — много ручной работы, требуется больше ресурсов администраторов для настройки инфраструктуры и ее эксплуатации, поэтому такой вариант может не подойти для владельцев небольших сайтов-визиток.
Здесь также можно подобрать оптимальную конфигурацию виртуальных машин, в частности типа процессора, включая TurboBoost для высокопроизводительных систем, а также размер и тип диска: HDD, SSD, High-IOPS SSD. По запросу также можно подключить диски Low Latency NVMe, если требуется моментальный отклик базы данных, например для каталогов. Кроме того, можно выбрать операционную систему, то есть вы получаете более гибкие настройки.
Для работы нашего интернет-магазина точно так же, как в первом случае, надо будет настроить IP-адреса, сеть, Firewall, DNS-имя. Стоит настроить внешний IP-адрес, чтобы доступ к ВМ был возможен через интернет.
Кроме того, стоит настроить резервное копирование, чтобы не потерять данные приложения. В настройках плана резервного копирования можно задавать полное резервное копирование, можно инкрементальное, когда сохраняются только измененные с момента последнего бэкапа данные. Также настраивается глубина хранения и расписание бэкапов. После того как ваш облачный сервер будет создан, автоматически для него сформируется резервная копия и план бэкапов в соответствии с настройками.
На следующем этапе начинается основная ручная работа. Вам нужно будет установить на виртуальную машину платформу для работы вашей CMS или приложения, например стек LAMP с MySQL. Потом устанавливаем WordPress, любую другую CMS или ваше самописное приложение. У нас есть инструкция о том, как установить WordPress и как установить Joomla!.
Недостатком использования стека LAMP будет то, что приложение и база данных используют одни и те же ресурсы сервера (CPU, память), что может снизить производительность и усложнить поиск неисправностей. Поэтому вы можете отдельно использовать базу данных для хранения данных вашего приложения: разместить ее на отдельной виртуальной машине или подключить готовую облачную СУБД как сервис.
Способ второй: разворачиваем интернет-магазин на платформенных сервисах
Интернет-магазин можно развернуть и на основе платформенных сервисов, в частности облачного Kubernetes. Это дает гибкость, надежность, а также автомасштабирование при росте нагрузки. Однако для работы с платформенными сервисами нужны специалисты с определенными навыками, чтобы правильно построить архитектуру приложения и настроить инфраструктурную часть.
Поэтому такой вариант больше подходит для крупных интернет-магазинов, которые посещают миллионы клиентов, где нужно подстраиваться под большую и меняющуюся нагрузку.
Примечание. Kubernetes — это платформа для управления контейнеризованными рабочими нагрузками, то есть приложением, упакованным в Docker-образ. Инструмент интересен тем, что решает за вас многие вопросы: там есть Service Discovery, то есть протоколы обнаружения сервисов, встроенные механизмы мониторинга приложений, а также самовосстановление, если какой-то узел кластера падает.
Запускать интернет-магазин в Kubernetes легче, если при построении архитектуры приложения вы сразу ориентируетесь на Cloud Native-подход и используете микросервисы. Но есть и другой подход, когда берут Legacy-приложение, упаковывают в контейнеры и также помещают в Kubernetes. Даже для таких приложений технология предоставляет возможности повышения отказоустойчивости и удобного управления, хотя могут возникать определенные сложности и надо учитывать ряд нюансов при размещении монолитов в Kubernetes, их там сложнее эксплуатировать.
Важно знать, что первоначально Kubernetes проектировали для запуска приложений, которые не хранят свои данные, но интернет-магазину их нужно сохранять. Поэтому к Kubernetes должны прилагаться хранилища данных. Если вы запускаете инструмент на собственной инфраструктуре, то ими придется заниматься самостоятельно.
У облачных провайдеров хранилища уже интегрированы с кластером. Например, на платформе Mail.ru Cloud Solutions хранилища для работы с Kubernetes работают на быстрых облачных дисках. Они позволяют сохранять состояние вашего приложения и монтируются непосредственно к контейнерам. Также интернет-магазин в облаке можно интегрировать с облачными базами данных или объектным S3-хранилищем, если приложение это поддерживает или есть контроль над кодом и можно его переделать. С последним интеграция будет проще.
В облачный Kubernetes уже встроена возможность по автоматическому развертыванию дополнительных сервисов, например мониторинга и балансировки нагрузки. Также можно быстро подключить другие инструменты; кроме того, провайдер берет на себя поддержание работоспособности сервиса, что сильно упрощает работу с этой сложной технологией.
В Kubernetes отказоустойчивость можно реализовать на нескольких уровнях — узлов или кластера. Узлы Kubernetes можно разнести по разным серверам и дата-центрам, что позволяет избежать падения приложения, если где-то в одном месте случится сбой. Если же критична максимальная отказоустойчивость интернет-магазина, то вы можете создать несколько кластеров, разместить их в разных дата-центрах и объединить в федерацию. В этом случае даже падение целого ЦОД никак не скажется на работе магазина. Подбирать эти настройки стоит с учетом нагрузки на ваши сервисы и критичности сбоев в их работе. Также с Kubernetes снижается риск при обновлении ПО: новый код можно выкатить только на часть контейнеров, проверить и только потом распространить обновление на всю систему без прерывания работы сервиса.
Еще один плюс использования Kubernetes для интернет-магазинов — простая настройка автомасштабирования. Эту функцию стоит подключить, если нагрузка на интернет-магазин неравномерная: есть всплески и спады спроса.
При этом не нужно докупать большое количество дополнительных серверов. В облаке дополнительные ресурсы автоматически предоставляются, когда нагрузка растет, и удаляются, когда она падает. В итоге не нужно платить за оборудование, простаивающее вне наплыва клиентов.
Kubernetes будет хорошим решением, если ваш интернет-магазин достаточно крупный, есть IT-специалисты, которые смогут работать с кластером. Даже для работы с сервисом в облаке нужны опытные администраторы и разработчики — однако в меньшем количестве, чем если вы запускаете технологию на своих серверах, так как многое берет на себя провайдер: обеспечение работы сервиса, интеграцию дополнительных инструментов вроде систем хранения, мониторинга, простую настройку автомасштабирования и многое другое.
Что еще надо учесть для стабильной работы интернет-магазина
Любое приложение, в том числе интернет-магазин, требует дальнейшего развития — недостаточно просто развернуть облачные серверы или контейнеры и запустить в них приложение. Вот что вам понадобится.
Настроить мониторинг. Мониторинг настраивать обязательно, причем как со стороны инфраструктурной части, так и на уровне самого приложения, чтобы собирать метрики его работы и реагировать на инциденты.
Примечание. Если вы разворачиваете интернет-магазин на облачном Kubernetes, то в нем уже есть встроенный мониторинг — отдельно его настраивать не требуется.
Если же вы разворачиваете магазин на облачных серверах, то для мониторинга можно использовать разные инструменты, например стек ELK. Прописав настройки вашего приложения так, чтобы оно отправляло данные в ELK, и настроив сбор данных, вы сможете понимать, какие сбои на каких серверах приводят к сбоям функциональности интернет-магазина.
Также можно подключить у провайдера готовый сервис мониторинга, с его помощью можно задать отслеживать состояние как инфраструктуры, так и самих приложений, используя стандартные или задавая любые пользовательские параметры.
Организовать хранение контента, в том числе медиа. Конечно, интернет-магазину нужно поднять базу данных, где будет храниться информация о клиентах. Но также стоит подумать о том, как оптимизировать хранение контента, который отображается на веб-сайте. Это каталоги, фотографии, видеоролики, обзоры товаров.
Для него оптимально использовать объектное S3-хранилище — и в случае развертывания интернет-магазина на IaaS, и в случае использования Kubernetes. Причина в том, что облачное объектное хранилище обладает значительной масштабируемостью: оно будет расти вместе с проектом, туда можно поместить неограниченный объем данных. В случае стандартного хранилища придется постоянно подключать новые диски, можно не успеть это сделать, если нагрузка вырастет неожиданно.
Также в S3 объекты доступны по HTTP-протоколу.То есть вы можете разместить обычную URL-ссылку на сайте, и посетители получат доступ к контенту, смогут просматривать его, но не изменять. А еще объектное хранилище надежное и экономичное с точки зрения оплаты: в отличие от обычных дисков его ресурсы полностью утилизируются, оно обходится примерно на 40% дешевле.
Облачные S3-хранилища доступны не только через обычный интерфейс, но и через API. Соответственно, приложение может напрямую общаться с хранилищем, все шаги по размещению контента и работе с ним легко автоматизировать.
Подумать о доставке контента пользователям. S3-хранилище отличается высокой производительностью, однако в зависимости от того, как организована работа с данными в приложении и количества обращений, в какой-то момент можно упереться в потолок производительности сервиса. В этом случае надо пересматривать структуру данных и переписывать приложение либо подключить к хранилищу сеть доставки контента (CDN), что будет дешевле и проще. Такая технология позволяет быстро доставлять контент из хранилища пользователям через распределенную сеть дополнительных серверов. Для этого контент дублируется на промежуточных узлах — серверах, которые расположены в разных городах и странах, они работают на быстрых дисках и находятся близко к магистральным каналам связи. То есть каталог или видеообзоры товаров максимально быстро откроются у любого клиента интернет-магазина независимо от того, как далеко он находится от ваших серверов.
Настроить безопасность. Кроме настроек Firewall и доступа через интернет, стоит отдельно подключить AntiDDoS-защиту. Ее может предоставлять провайдер, если нет, то нужно подключить отдельное решение. Также можно использовать сложные системы по фильтрации трафика приложения — Web Application Firewall, например такие решения, как Variti или Wallarm. В облаке их часто можно подключить в один клик, на своих инсталляциях надо установить и настроить.
WAF-решения анализируют трафик по техническим параметрам, а также оценивают, как ведут себя пользователи. Они умеют с первого запроса определять, кто обращается к ресурсу: бот или реальный человек. А также надежно защищают от DDoS-атак, в том числе работают с низкочастотными атаками, которые не выбиваются за легитимный пользовательский трафик.
Еще WAF защищает от парсинга каталогов, когда ваш контент воруют и размещают на чужом сайте, чтобы сэкономить время на подготовку фотографий, подбора логинов-паролей и фейковых заявок, когда генерируются ложные заказы, нагружающие менеджеров и службы доставки.
Дальнейший апгрейд интернет-магазина: добавляем аналитику данных
В любом интернет-магазине есть некая центральная OLTP-база данных, которая его обслуживает. Зачастую эту же базу данных используют для различных аналитических задач. То есть все дашборды, отчеты для различных подразделений и другая аналитика тоже собирается внутри OLTP-базы. Конечно, по мере роста интернет-магазина аналитическая нагрузка начинает влиять на основные сервисы.
Чтобы снизить загрузку основной СУБД и повысить стабильность работы интернет-магазина, аналитическую нагрузку рекомендуется выносить в OLAP-контур.
Его можно реализовать, подключив аналитическую базу данных. После того как вы запустили OLAP-контур, надо, чтобы данные из OLTP-базы сразу же туда дублировались, что достигается настройкой потока данных. Поверх аналитической базы данных уже строится платформа для аналитики, в том числе визуализации данных.
В облаке аналитические СУБД и все инструменты для работы с большими данными доступны фактически по клику, можно построить платформу для Data Science, BI-аналитики, машинного обучения, не развивая все это с нуля на своей инфраструктуре. Например, можно использовать Hadoop-кластер, Arenadata DB (Greenplum), ClickHouse, NiFi для построения процесса ETL, то есть извлечения и преобразования данных из источников, JupyterHub для проведения экспериментов дата-сайентистов. Все эти инструменты можно получить как сервис у провайдера.
Как снизить сложность управления инфраструктурой
Если вы разворачиваете интернет-магазин не через маркетплейс, а на IaaS или платформенных сервисах, то столкнетесь с необходимостью ручной настройки некоторого количества параметров, многие из которых друг с другом пересекаются. Вам нужно будет управлять виртуальными машинами или Kubernetes, базами данных и S3 и другими сервисами.
То есть чтобы следить за большим количеством инфраструктурных настроек, нужно много специалистов, надо правильно писать конфигурационные файлы, чтобы нигде не было никаких ошибок. Отдельно стоит вопрос быстрого создания тестовых сред. Эта сложность может пугать, но на самом деле есть инструменты, помогающие с ней справиться. И даже превратить минусы в плюсы.
Самый простой способ, который стандартно используют для автоматизации управления инфраструктурой, — скриптование с помощью того же bash. Но здесь есть нюанс: скрипты носят предикативный характер — вы в них шаг за шагом указываете, что необходимо сделать. Если на каком-то шаге ошибка, ваш скрипт не выполняется. Другой, более современный подход — декларативный. Его используют конфигурационные менеджеры, такие как Ansible, Puppet и другие. Также для декларативного описания инфраструктуры применяют подход Infrastructure-as-a-Code (IaC), инфраструктура как код, здесь самый распространенный инструмент — это Terraform.
При декларативных подходах вы описываете конечное состояние вашей инфраструктуры и специальный инструмент приводит ее в нужное состояние. То есть больше не надо думать о том, как реализовать с помощью скриптов тот или иной нюанс на каждом этапе настройки.
Для того чтобы управлять облачной инфраструктурой на базе OpenStack как кодом, есть специальный Terraform-провайдер. В Mail.ru Cloud Solutions используется свой дистрибутив OpenStack, а облачные сервисы Kubernetes, базы данных и S3 также улучшены и сильно отличаются от того, что есть в изначальной платформе. Поэтому для управления инфраструктурой стоит использовать не только классический Terraform-провайдер для OpenStack, но и собственный Terraform-провайдер MCS. С его помощью можно управлять Kubernetes-кластерами, а в дальнейшем и базами данных, и S3, который пока управляется через Terraform-провайдер AWS.
Стоит обязательно использовать инструменты IaC для развертывания и управления облачной инфраструктурой, так как они снижают риск ошибок и вероятность сбоев, не просто облегчают администрирование, но и повышают отказоустойчивость.
Стоит обязательно использовать инструменты IaC для развертывания и управления облачной инфраструктурой, так как они снижают риск ошибок и вероятность сбоев, не просто облегчают администрирование, но и повышают отказоустойчивость.
Что нужно для развертывания интернет-магазина: базовый минимум
- Организовать инфраструктуру на базе облачных серверов или платформенных сервисов — это зависит от масштабов интернет-магазина и его нагрузки.
- Подключить мониторинг, позаботиться о хранении данных и безопасности, в том числе фильтрации трафика.
- Реализовать отдельный контур для аналитики, если аналитическая нагрузка мешает работе основной базы данных.
- Использовать инструменты управления инфраструктурой, упрощающие ее развертывание и администрирование.