5 общих настроек сервера для вашего веб-приложения

Введение

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

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

Настройка всего на одном сервере

Настройка одного сервера — это когда вся среда находится на одном сервере. Для типичного веб-приложения это включает веб-сервер, сервер приложений и сервер базы данных. Распространенным вариантом этой установки является стек LAMP, который означает Linux, Apache, MySQL и PHP, на одном сервере. Пример использования этого — когда вы хотите быстро настроить приложение. Подобную базовую настройку можно использовать для проверки идеи или запуска простой веб-страницы.

К сожалению, это мало что дает в плане масштабируемости и изоляции компонентов. Кроме того, приложение и база данных конкурируют за одни и те же ресурсы сервера, такие как ЦП, память, ввод-вывод и т. д. В результате это может привести к снижению производительности и затруднить определение основной причины. Использование одного сервера также не является легко масштабируемым по горизонтали. Вы можете узнать больше о горизонтальном масштабировании в нашем руководстве «Как установить LAMP в Ubuntu 22.04». Ниже приведено визуальное представление использования одного сервера:

Настройка отдельного сервера базы данных

DMZ или публичный интернет.

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

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

Настройка балансировщика нагрузки (обратный прокси)

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

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

Настройка балансировщика нагрузки может стать узким местом в производительности, если у балансировщика нагрузки недостаточно ресурсов или если он плохо настроен. Это также может представлять сложности, которые требуют дополнительного рассмотрения, например, где выполнять завершение SSL и как обрабатывать приложения, требующие закрепленных сеансов. Кроме того, балансировщик нагрузки является единственной точкой отказа, а это означает, что если он выйдет из строя, весь ваш сервис может выйти из строя. Настройка высокой доступности (HA) — это инфраструктура без единой точки отказа. Чтобы узнать, как реализовать настройку высокой доступности, вы также можете прочитать нашу документацию «Введение в HAProxy и концепции балансировки нагрузки». Ниже приведено визуальное представление настройки балансировщика нагрузки:

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

Ускоритель HTTP или кэширующий обратный прокси-сервер HTTP можно использовать для сокращения времени, необходимого для предоставления контента пользователю с помощью различных методов. Основным методом, используемым с ускорителем HTTP, является кэширование ответов от веб-сервера или сервера приложений в памяти, чтобы будущие запросы на тот же контент могли обслуживаться быстро, с меньшим количеством ненужного взаимодействия с веб-сервером или сервером приложений. Несколько примеров программного обеспечения, способного к ускорению HTTP, — Varnish, Squid, Nginx. В качестве примера можно привести среду с динамическими веб-приложениями с большим объемом контента или множеством часто используемых файлов.

Ускорение HTTP может повысить производительность сайта за счет снижения нагрузки на ЦП веб-сервера за счет кэширования и сжатия, тем самым увеличивая пропускную способность пользователей. Его также можно использовать в качестве балансировки нагрузки обратного прокси-сервера, а некоторые программы для кэширования могут даже защитить от DDOS-атак. К сожалению, это может снизить производительность, если частота попаданий в кэш низкая, и требует настройки для получения наилучшей производительности. Ниже приведено визуальное представление настройки HTTP-акселератора:

Настройка репликации базы данных первичной реплики

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

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

Объединение концепций

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

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

Вот разбивка процесса, когда пользователь отправляет запрос на динамическое содержимое:

Пользователь запрашивает динамическое содержимое с http://example.com/ (балансировщик нагрузки)
Балансировщик нагрузки отправляет запрос серверной части приложения
Бэкенд приложения считывает данные из базы данных и возвращает запрошенный контент балансировщику нагрузки.
Балансировщик нагрузки возвращает запрошенные данные пользователю

Когда пользователь запрашивает статический контент, применяется следующий процесс:

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

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

Заключение

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