Настройка вашего приложения: как выбрать лучшую конфигурацию сервера?

Введение

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

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

Как выбрать правильную конфигурацию сервера

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

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

1. Все на одном сервере

Как следует из названия, вы загружаете всю среду на один единственный сервер. Среда будет включать в себя ваш веб-сервер, сервер приложений, а также сервер базы данных. Например, это работает на конфигурации стека Linux, Apache, MySQL, и PHP (LAMP). Вы можете следовать нашим руководствам по установке стека LAMP на сервер Ubuntu и установке стека LAMP на CentOS.

Когда использовать:

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

Преимущества:

• Просто и легко понять и внедрить.
• Полная настройка занимает мало времени.

Недостатки:

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

2. Отдельный сервер базы данных

Основная проблема использования одного сервера — это конкуренция за ограниченные ресурсы. Данная конфигурация призвана решить эту проблему. Здесь система управления базами данных, или СУБД, отделена от сервера приложений. Сервер базы данных находится в частной сети и имеет собственные ресурсы. Это приводит к повышению производительности и безопасности.

Когда использовать:

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

Преимущества:

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

Недостатки:

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

3. Обратный прокси-сервер или балансировщик нагрузки

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

Когда использовать:

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

Преимущества:

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

Недостатки:

• В случае недостаточных системных ресурсов балансировщик нагрузки может ограничить производительность вашего приложения.
• Для обеспечения надлежащей производительности необходима правильная настройка.
• Значительно сложнее, чем конфигурации с одним сервером или отдельными серверами.
• Вам необходимо учитывать такие факторы, как терминация SSL и приложения, которым требуются закрепленные сессии (sticky sessions).
• Основная проблема при использовании балансировщиков нагрузки заключается в том, что они являются единой точкой отказа. Это означает, что если балансировщик нагрузки выйдет из строя, вся ваша служба перестанет работать.

4. HTTP-акселератор или кэширующий обратный прокси-сервер

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

Когда использовать:

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

Преимущества:

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

Недостатки:

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

5. Репликация базы данных «основной-реплика» (Primary-Replica)

Конфигурация репликации базы данных «основной-реплика» (primary-replica) обычно очень полезна для систем, которые выполняют больше операций чтения, чем записи. Например, системы управления контентом (CMS) могут эффективно использовать такую архитектуру. Для репликации вам нужен один основной узел (primary) и один или несколько узлов репликации. Она распределяет операции чтения по всем узлам. Обновления поступают только на основной узел.

Когда использовать:

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

Преимущества:

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

Недостатки:

• Любое приложение, пытающееся получить доступ к базе данных, должно уметь определять, на какой узел отправлять обновления, а на какой — запросы на чтение.
• В случае сбоя основной реплики обновления прекращаются. Вам придется решить проблему, чтобы обновления могли продолжиться.
• Отсутствует механизм автоматического переключения при отказе (failover) на случай возможного сбоя основного узла.

Совместное использование серверных конфигураций

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

Пример:

Мы попытаемся разобраться в такой среде на примере:

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

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

• Балансировщик нагрузки сначала определит, является ли контент попаданием в кэш (cache-hit) или промахом кэша (cache-miss). Контент с попаданием в кэш присутствует в кэше, в то время как контент с промахом кэша там отсутствует. Он делает это путем проверки на бэкенде кэширования.
• В случае попадания в кэш балансировщик нагрузки отправляет контент пользователю.
• В случае промаха кэша сервер кэширования перенаправляет запрос на бэкенд приложения.
• Бэкенд приложения найдет и отправит контент из базы данных.
• Бэкенд кэширования получает контент от балансировщика нагрузки. Он также кэширует этот контент перед возвратом его балансировщику нагрузки.
• Последний затем пересылает ответ пользователю.

С другой стороны, вот что произойдет, если пользователь запросит динамический контент:

• Запрос поступит от пользователя к балансировщику нагрузки.
• Этот запрос поступает на бэкенд приложения.
• Бэкенд приложения находит запрошенный контент и возвращает его балансировщику нагрузки.
• Пользователь получает контент.

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

Заключение

Вы можете использовать каждую конфигурацию сервера по отдельности в своей среде. С другой стороны, вы также можете объединить несколько из них вместе, чтобы создать индивидуальное решение. Здесь нет «правильного» ответа. Все зависит от функциональности, которую вы хотите получить от архитектуры.

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

Удачных вычислений!