Проблемы с подключением рабочих процессов NGINX приводят к простоям (как правильно настроить ngin...

#вебразработка #laravel #nginx #devops В этом видео мы рассмотрим недавний инцидент с простоем, с которым я столкнулся в своем веб-приложении. Мое веб-приложение — это многопользовательское приложение для электронной коммерции, предоставляющее интернет-магазины для ресторанов и закусочных, что-то вроде Shopify в меньшем масштабе. В основном оно работает на монолитном приложении Laravel. У нас довольно предсказуемый график трафика: один пик примерно в обеденное время и еще больший пик примерно в вечернее время. При каждом запросе у нас был один сервер приложений, который обрабатывал весь трафик, и у нас уже был балансировщик нагрузки для простого горизонтального масштабирования. Несмотря на мониторинг состояния нашей системы, который показывал низкую загрузку ЦП по всем направлениям, мы были застигнуты врасплох в пятницу вечером, когда наши сервисы внезапно отключились. Пятничные вечера около 18:00 — самое загруженное время недели на нашей платформе, потому что именно тогда все начинают заказывать ужин. В попытке решить эту проблему я масштабировал наш сервис горизонтально и добавил еще 2 сервера приложений. К счастью, у нас уже был настроен балансировщик нагрузки, DNS-записи были настроены правильно, а ресурсы уже размещались на S3 и обслуживались CloudFront. Поэтому добавление 2 серверов приложений прошло без проблем: Мы запускаем и выделяем новую машину Мы настраиваем наше приложение Мы добавляем его в пул балансировки нагрузки Когда поступает запрос пользователя, балансировщик нагрузки взаимодействует с пулом серверов приложений по принципу циклического распределения. Первый запрос попадает на приложение 1, второй — на приложение 2, а третий — на приложение 3. Важно отметить, что на сервере приложения 1 также работал сервер веб-сокетов для предоставления нашим продавцам некоторых функций в режиме реального времени, поэтому, когда клиент размещает заказ, его приложение мгновенно его обрабатывает. Этот сервер веб-сокетов находился за обратным прокси-сервером NGINX. В поисках первопричины я начал тщательное расследование — мне НУЖНО было докопаться до сути. Первым моим инстинктом было войти на сервер и проверить наличие ошибок 502 Gateway Timeout из-за неправильной конфигурации PHP-FPM. К моему удивлению, в логах нашего сервера приложений таких ошибок не было. Затем я зашёл в панель управления NGINX Amplify, и на нашем экземпляре LoadBalancer мы действительно наблюдали всплеск ошибок 502 Gateway Timeout. Однако наш сервер приложений не сообщал об ошибке 502 Gateway Timeout, что заставило меня заподозрить, что ошибка исходит от самого NGINX. А когда NGINX сам выдаёт ошибку, мы получаем не ошибку 502 Gateway Timeout, а **500 Internal Server Error**. После этого я снова открыл логи и поискал внутренние ошибки, и, о чудо, я нашёл виновника! Ошибка гласила: 512 worker_connections недостаточно при подключении к вышестоящему серверу. Я обратился к документации nginx, чтобы узнать больше об этом параметре, и по умолчанию он был установлен на 512. Из-за большого количества одновременных подключений через WebSocket мы фактически достигали лимита в 512, а nginx не был настроен на увеличение worker_processes, поэтому, когда наш сервер приложений достигал этого лимита, он переставал принимать новые входящие запросы. Я решил эту проблему, увеличив worker_connections до 768 и изменив конфигурацию worker_processes с 1 на auto, чтобы nginx добавлял дополнительные рабочие процессы при необходимости. И с тех пор мы больше не сталкивались с подобной проблемой! И мы даже смогли отменить работу наших двух серверов приложений, чтобы сократить ежемесячные расходы. Вот несколько уроков, извлеченных из этой ситуации: Номер 1 — Разделение ответственности Если бы мы разместили наш сервер WebSocket на другой машине, влияние было бы значительно меньше. Мы бы все равно столкнулись с ошибкой worker_connections, но вместо того, чтобы затрагивать весь сервер приложений, влияние ограничивалось бы машиной WebSocket. Номер 2 — Ошибки 502 и 500 Это может показаться очевидным, но поначалу может немного сбивать с толку. Когда ваш сервер приложений отвечает ошибкой 500, ваш балансировщик нагрузки ответит ошибкой 502. Номер 3 — Настройте балансировщик нагрузки до того, как почувствуете необходимость масштабирования Когда мы столкнулись с простоем, нас спасло наличие настроенного балансировщика нагрузки, который позволил нам легко добавлять дополнительные серверы приложений. И наконец, урок номер 4 — Настройка конфигурации по умолчанию NGINX поставляется с разумными настройками по умолчанию, но по мере роста вашей платформы вы легко можете перерасти эти настройки. Потратьте некоторое время на изучение конфигурации по умолчанию и настройте её под свои конкретные потребности. Надеюсь, вы узнали что-то новое, и до встречи в следующем уроке, пока! 00:00 — Введение 00:56 — Попытка решения проблемы 01:28 — Веб-сокеты 02:05 — Исследование причин простоя 02:51 — Ошибки 502 и 500 03:44 — Решение проблемы 04:31 — Уроки...