2
ОГЛАВЛЕНИЕ
ВВЕДЕНИЕ .................................................................................................... 5
ГЛАВА 1. Введение в современные web-технологии ............................... 9
1.1. Обзор отрасли и современных требований и приложениям ..... 9
1.1.1. Успех проекта зависит от производительности .................... 9
1.1.2. Контейнеры, виртуализация, оркестрация ............................. 11
1.1.3. Микрокэширование и CDN ...................................................... 15
1.2. Возможности NGINX .................................................................. 16
1.2.1. Архитектура NGINX............................................................... 16
1.2.2. Балансировка нагрузки ........................................................... 17
1.2.3. Кэширование контента ........................................................... 19
1.3. Основания для внедрения обратного прокси-сервера ............. 21
1.3.1. Использование связки php и Apache ..................................... 21
1.3.2. Одинаковое содержимое страниц ......................................... 22
1.3.3. Повышение отказоустойчивости........................................... 23
ГЛАВА 2. Внедрение обратного прокси-сервера на базе NGINX ......... 25
2.1. Цели существования оптимизируемого приложения и задачи,
решаемые им ...................................................................................................... 25
2.1.1 Приложение RMS....................................................................... 25
2.1.2. Особенности динамического содержимого ........................... 26
2.1.3. Статические файлы ................................................................... 28
2.2. Установка и настройка кэширующего прокси-сервера NGINX . 28
2.2.1. Установка контейнерного приложения .................................. 28
2.2.2. Подготовка приложения ........................................................... 30
2.2.3. Настройка NGINX ..................................................................... 34
2.3. Анализ результатов внедрения ....................................................... 38
3
2.3.1. Анализ журналов доступа ........................................................ 38
2.3.2. Анализ нагрузки на бек-энд ..................................................... 41
2.3.3. Ошибки, через которые пришлось пройти ............................. 41
ГЛАВА 3. Дальнейшая оптимизация работы приложения .................... 43
3.1. Оптимизация работы back-end сервера ..................................... 43
3.1.1. Создание стека с тестовым приложением .............................. 43
3.1.2. Анализ производительности после изменений ...................... 48
3.1.3. Анализ устойчивости при сбоях .............................................. 50
3.2. Отказ от слоя web-сервера apache .............................................. 52
3.2.1. Конфигурирование тестового приложения .......................... 52
3.2.2. Анализ производительности при использовании SSI ......... 56
3.2.3. Анализ доступности приложения ......................................... 58
3.3. Возможности, предоставляемые NGINX Plus........................... 60
3.3.1. Очистка кэша с помощью nginx-cache-purge ....................... 60
3.3.2. Анализ прироста производительности ................................. 64
3.3.3. Анализ устойчивости к сбоям ............................................... 65
ЗАКЛЮЧЕНИЕ ........................................................................................... 69
СПИСОК ЛИТЕРАТУРЫ .......................................................................... 72
ПРИЛОЖЕНИЯ ........................................................................................... 72
Приложение 1. Yml-файл приложения RMS ....................................... 76
Приложение 2. Конфигурационный файл nginx .................................. 77
Приложение 3. Структура каталогов со стеком приложения RMS. .. 82
Приложение 4. Программа для анализа журналов .............................. 88
Приложение 5. Файл docker-compose.yml финального тестового
стенда .................................................................................................................. 89
Приложение 6. Шаблон html тестового стенда .................................... 90
Приложение 7. Php-скрипт render.php .................................................. 91
4
Приложение 8. Конфигурационный файл nginx v1 ............................. 94
Приложение 9. Конфигурационный файл nginx v2 ............................. 96
Приложение 10. Конфигурационный файл nginx v3 ........................... 98
Приложение 11. Структура таблиц БД тестового стенда app .......... 100
Приложение 12. Конфигурационные файлы mysql ........................... 100
5
ВВЕДЕНИЕ
Тема данной работы - «Повышение производительности веб-
приложения за счет обратного проксирования с помощью NGINX».
Актуальность выбранной темы заключается в лавинообразном росте
количества высоконагруженных веб-приложений в связи с ростом
количества пользователей сети интернет. В течение последних нескольких
лет с каждым днем появляются новые сервисы, количество посещений
которых в сутки со временем начинает исчисляться в миллионах просмотров.
Для того чтобы удовлетворить современные требования к
производительности приложений, простого наращивания вычислительных
мощностей за счет установки более «быстрого» оборудования недостаточно.
Используются различные технологии, позволяющие распределять
вычисления.
Олицетворением одной из таких технологий является
высокопроизводительный веб-сервер Nginx. Он позволяет распределять
нагрузку на несколько бек-энд серверов, реализовывать различное
кэширование, в том числе многоуровневое и производить тонкую настройку
процесса обработки запросов пользователей[18].
Автором веб-сервера Nginx является Игорь Сысоев. В 2011 году он
основал компанию Nginx, Inc, призванную развивать и продвигать созданный
им продукт.
Объектом исследования в работе являлось веб-приложение RMS. Это
веб приложение для коллективной работы. Более подробно его назначение,
устройство, достоинства и недостатки рассмотрены в первом разделе главы
2.
Вся практическая часть работы была построена вокруг приложения
RMS (Requirements management system) и тестового приложения, на котором
была продемонстрирована работа технологий.
Целью исследования являлось повышение производительности работы
веб-приложения за счет установки перед ним кэширующего прокси-сервера.
6
В работе была рассмотрена установка и настройка фронт-энд сервера
Nginx после перемещения исследуемого веб-приложения в контейнерную
среду, в которой им проще управлять. После того, как была выполнена
настройка и проверена работа, были проанализированы журналы доступа. По
ним был определен прирост производительности от использования
кэширования, а также наглядно продемонстрирована работа механизма
балансировки нагрузки при распределении запросов пользователей.
Задачами исследования в работе являлись:
1. Выполнение обзора современных веб-технологий и отрасли в целом.
В работе активно используются технологии контейнеризации
приложений, главным образом, Docker. Эта технология стала
промышленным стандартом и будет подробно рассмотрена в первой
главе.
2. Выполнение обзора возможностей Nginx как кэширующего прокси-
сервера и как самостоятельного веб-сервера.
3. Проведен анализ, какие основания могут быть для внедрения
обратного прокси-сервера перед уже работающим веб-
приложением, какие возможности это дает.
4. Выполнен анализ существующего приложения, являющегося
объектом исследования в работе, выполнена оценка, что даст
кэширование контента и выявлены ограничения приложения РМС,
которые необходимо было учесть при внедрении прокси.
5. Выполнена практическая часть работы – подготовлено приложение,
установлен и настроен прокси-сервер.
6. Выполнен анализ результатов – собраны данные в журналы доступа
во время использования веб-приложения через прокси, затем с
помощью небольшой программы выведена статистика загрузки веб
страниц и определен выигрыш от использования кэширования.
7. Подготовка стека тестового приложения, отражающего основное
приложение RMS, на примере которого было продемонстрировано
7
использование более мощных технологий, чем простое
кэширование. Это было необходимо в связи с дороговизной и
сложностью модификации основного приложения, а также
позволило выявить возможные риски во время анализа
устойчивости к сбоям.
8. Внесение изменений в стек тестового приложения, позволивших
избавиться от промежуточного веб-сервера Apache. Переделано
тестовое приложение на использование технологии SSI. Это
позволило дать оценку эффективности работы Nginx в качестве
самостоятельного веб-сервера, на котором размещены статические
файлы, а также эффективности его работы с fastcgi сервером, на
который были перенесены php-сценарии. В ходе исследования также
была проанализирована не только производительность работы
приложения в таком стеке, но и устойчивость его к сбоям на бек-энд
серверах.
9. Установлен модуль nginx cache purge, позволяющий очищать
определенные страницы в кэше и внесены изменения в тестовое
приложение, позволяющие выполнять очистку кэша при отправке
запросов, изменяющих данные. Также был выполнен анализ
производительности и устойчивости к сбоям на бек-энд серверах.
Научная новизна данной работы заключается в применении технологий
кэширования там, где они ранее не применялись из-за ненадобности. Это
связано с постоянно возрастающей нагрузкой. Как будет отмечено в первой
главе, ее разделу посвященному обзору отрасли, производительность сейчас
крайне важна. Повышение нагрузки вызывает необходимость в модификации
имеющихся приложений. Для того чтобы правильно ее выполнить
необходимо правильно определить текущее состояние системы, желаемое
состояние и пути его достижения.
Теоретическая и практическая значимость работы заключается в
наглядной демонстрации слабых и сильных сторон различных технологий,
8
которыми на сегодняшний день могут оперировать администраторы. На
реальных примерах в работе рассматриваются различные состояния внешне
одинаковых систем и пути их перевода из одного состояния в другое.
9
ГЛАВА 1. Введение в современные web-технологии
1.1. Обзор отрасли и современных требований и приложениям
1.1.1. Успех проекта зависит от производительности
Веб-приложения создаются для доставки пользователям определенного
содержимого. Качество инфраструктуры доставки определяет ощущения,
которые будут испытывать пользователи от взаимодействия с приложениями
и способно, в конечном счете, повлиять на успех бизнеса, выпустившего
приложение.
Скорость отдачи веб-страниц в современном мире имеет огромное
значение. Годами аналитики различных компаний отслеживали поведение
пользователей. В результате исследований было сформулировано правило “N
секунд”. Его суть заключается в том, сколько секунд пользователь будет
ждать отдачи веб-страницы до того момента, как решит покинуть сайт.
Результаты исследования отражают прошлую и нынешнюю картину[8]:
- в 1997 году пользователь был готов ждать 10 секунд
- в 2001 ожидает около 8 секунд
- в 2006 около 4
- в 2010 количество секунд сократилось до 3
Ожидания пользователей от веб-сайтов и приложений с каждым годом
становятся все выше, ценой вопроса становится успех или провал проекта.
Компания Amazon делит загрузку веб-страниц на отрезки по 100
миллисекунд и обнаружила следующую взаимосвязь – с каждой
дополнительной 100 миллисекунд сайт теряет 1% посетителей[31]. В
соответствии с исследованиями Google, подтверждается, что процент отказов
экспоненциально растет, если общее время загрузки начинает выходить за
приемлемые рамки[16].
Данные принципы находят отражение в существовании любого
приложения, не зависимо от его назначения. Однако, если взаимосвязь между
производительностью коммерческого приложения, например торговой
площадки, видна сразу, то для приложений, призванных автоматизировать
10
работу сотрудников она может быть не очевидной. Тем не менее,
производительность работы корпоративных веб-приложений оказывает
влияние на работу сотрудников, от которой может зависеть получение
организацией дополнительной прибыли[8].
Исследуемое в работе приложение предназначено для совместной
работы сотрудников над задачами, созданными клиентами. Самый простой
случай - это задачи, которые требуют для решения участия только одного
специалиста. В этом случае производительность ни не что не влияет.
Но когда задача требует участия нескольких специалистов и
разрастается, производительность начинает оказывать влияние на ход
решения. Предположим, у сотрудника перед глазами находится список задач,
часть из которых выполняется им. По некоторым из задач требуется
получить дополнительную информацию от контрагента или другого
сотрудника. Если список будет обновляться дольше, например, 5 – 10 секунд,
то сотрудник будет стараться как можно реже обращаться к этой важной
странице и заниматься другими задачами. В результате то, что он должен
увидеть быстро, он увидит только тогда, когда в очередной раз обратится к
«нелюбимой» странице. Если таких страниц много, то приложение можно
считать не работоспособным, потому что на время загрузки каждой страницы
оно безраздельно будет завладевать вниманием пользователя и тратить его
время впустую. Если сотрудник в меру своих должностных обязанностей
должен отслеживать изменения списка, например, раз в 5 минут, который
обновляется в среднем за 7 секунд, то можно оценить сколько своего
времени он теряет за день: 60*8 / 5 * 7 = 672. Более 11 минут в день
сотрудник, постоянно работающий со списком, просто ждет его появления.
Может показаться, но на самом деле это очень много, это морально тяжело
так как список может и не измениться. Если и другие страницы ведут себя
подобным образом, то это катастрофа, так как в нем происходит основная
часть работы. Это будет приводить (исследуемое приложение реально
работает в реальной организации, так что уже приводит) к замедленной
11
реакции на важные сообщения, от которой зависит ход решения задачи
другими специалистами, в итоге из-за недостаточной производительности
при загрузке страниц страдает работа целой организации[9].
Одна из целей данной работы – наглядно продемонстрировать с
помощью журналов доступа, сколько времени тратят сотрудники впустую,
просто ожидая появления страниц.
1.1.2. Контейнеры, виртуализация, оркестрация
Необходимо сказать несколько слов о видах виртуализации, не
вдаваясь в подробности. Существует полная виртуализация, когда
физическое оборудование полностью эмулируется хостом виртуальных
машин (например, xen+qemu). Это наиболее требовательный к ресурсам вид
виртуализации. Далее следует отметить существование паравиртуализации,
когда хост-система предоставляет гостевой системе отдается полностью
виртуальное оборудование и она об этом знает (xen в режиме гипервизора),
при этом все же загружает и использует свое собственное ядро. То, о чем
речь пойдет далее относится к виртуализации на уровне ядра операционной
системы – экземпляры используют одно общее ядро хост-системы (так
работает openVZ). По такому же принципу работают контейнеры Docker –
система, на которой выполнялась практическая часть данной работы.
Контейнеризация приложений дает новые возможности и кардинально
меняет подход к администрированию и разработке веб-приложений. Раньше
для того, чтобы начать отдавать какое-либо содержимое пользователям,
нужно было проделать ряд операций по подготовке сервера и размещению на
нем приложения или контента. Такие системы достаточно плохо
горизонтально масштабировались, так как, во-первых, приложения часто
были не подготовлены для работы в кластере, а во-вторых сами требования к
кластеру не всегда можно было четко сформулировать. Как правило,
создавался один или несколько серверов (виртуальных или физических), на
которых устанавливались службы, необходимые для работы веб-приложения.