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

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

Единый сервер

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

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

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

^{Источник изображения}

Отдельный сервер для БД

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

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

Тем не менее такая конфигурация также не может исключить проблем, поскольку их могут вызывать задержки, если физические серверы находятся на значительном расстоянии друг от друга. Кроме того, стоит обращать внимание и на пропускную способность канала связи. Ниже мы привели схему с отдельным сервером для БД, а о том, как организовать удаленное подключение к БД (на примере популярной СУБД MySQL), вы можете узнать в этой статье.

^{Источник изображения}

Обратный прокси

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

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

Однако такая настройка может приводить к сложностям, связанным с возникновением единой точки отказа. В этом случае при отказе обратного прокси всё приложение станет недоступным для пользователей. Кроме того, проблемы с производительностью могут возникать при не оптимальных настройках. Таким образом, на первый план выходит организация схемы с высокой доступностью, которая основана на использовании IP-адресов с резервированием. Более подробно о способах организации такой конфигурации читайте в нашей статье «Алгоритмы и методы распределения нагрузки на сервер», а сама схема реализации представлена на этом изображении:

^{Источник изображения}

Кеширующий прокси-сервер

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

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

Из программного обеспечения, поддерживающего такое кэширование, снова отметим Varnish, Squid и Nginx. А в общем виде подобная схема выглядит следующим образом:

^{Источник изображения}

Репликация БД

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

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

^{Источник изображения}

Совмещение конфигураций

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

^{Источник изображения}

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

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

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