Как интернет-магазину организовать ИТ-инфраструктуру

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

Вопрос в том, как разместить это программное обеспечение? Сколько серверов задействовать?

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

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

Рассмотрим возможные варианты архитектуры информационной системы на примере интернет-магазина. Практически в каждом из них есть веб-сервер и база данных.

Всё в одном

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

При этом имеет существенное значение, какой это будет сервер: аппаратный или виртуальный.

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

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

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

Витрина отдельно, данные отдельно

Следующим шагом в развитии интернет-магазина и любого другого интернет-сервиса может стать размещение его публичной части (витрины) и базы данных на разных серверах.

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

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

Из недостатков такого варианта архитектуры можно указать следующие: 1) придётся администрировать несколько серверов; 2) потребуется больше сетевых настроек; 3) сохранятся потенциальные ограничения в масштабировании, хоть и менее жёсткие, чем в случае одного сервера.

Группа серверов

Реальную нагрузку на интернет-магазин предсказать очень сложно. День недели, время суток, сезон, удачная рекламная кампания — всё это может изменить число активных пользователей в разы, если не на порядок.

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

В зависимости от особенностей организации таких групп, их называют пулами или кластерами.

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

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

Для обеспечения слаженной работы группы серверов потребуется балансировщик нагрузки.

Однако при размещении базы данных на нескольких серверах необходимы дополнительные механизмы поддержания её целостности, например, репликация, шардинг и т. п. Здесь углубляться в эти вопросы мы не станем.

Горячий резерв

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

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

Шаблон сервера

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

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

Репликация данных

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

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

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

Заключение

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

Если ваш проект стабилизировался и обрёл будущее, распределите свою информационную систему по разным серверам. Например, разделите базу данных и веб-сервер.

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

Если ваш сервис стал популярным (ура!), и потребность в производительности и надёжности увеличилась, примените пулы и кластеры серверов.

В этом контексте интересно посмотреть на статистику сервиса аренды инфраструктуры в облаке 1cloud.

Диаграмма хорошо иллюстрирует тот факт, что число небольших проектов всегда больше числа крупных. Это нормальный эволюционный процесс.

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

Например, один из клиентов 1cloud использует в своей информационной системе более 200 виртуальных машин.