В выходные прочитал интересную статью:

⇨ Как настроить веб-приложение под высокие нагрузки

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

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

Изначально это был небольшой проект на PHP и его фреймворке Symfony, который писали 3-5 проектировщиков. СУБД была PostgreSQL, под кэш Redis, написана API и очередь для неё на RabbitMQ. Такое типовое классическое веб приложение. Проект располагался на 16 физических серверах, фронтенды и бэкенды — по 24 ядра и 128 ОЗУ каждый, ноды СУБД имели 56 ядер и 512 ГБ ОЗУ.

Огромную помощью в решении возникающих проблем оказывал мониторинг. Он был реализован на базе Zabbix, Symfony Profiler, Cockpit, DBeaver, Nginx Amplify.

🔹Одним из узких мест оказались логи Nginx. Была включена буферизация логов. В момент скидывания буферов на диск, они тормозили. Временно перенесли логи в RAM-диски (tmpfs). Потом перенастроили систему хранения логов.

🔹Другим узким местом была главная страница. Её целиком закешировали и поместили в Redis. Далее весь код перетряхнули и по возможности настроили использование кэша в Redis. После этого Redis вынесли в отдельный кластер. Это привело к тому, что даже в границах одной серверной и максимально быстрой сети, кэш стал работать медленнее, а на саму локалку сильно выросла сетевая нагрузка. Пришлось разбить кэш на 2 уровня. Первый хранить в локальных инстансах Redis, а второй в отдельном кластере с доступом по сети.

🔹Для разгрузки СУБД установили PgBouncer для управления пулом соединений, постановки их в очередь, если всё занято. Один огромный сервер под СУБД распили на кластер из 5-ти серверов. Запросы к кластеру стали распределять с помощью PGPool. INSERT, UPDATE, DELETE отправляли на Master, всё остальное распределяли между остальными серверами.

🔹В какой-то момент все серверные мощности были нагружены на 70-80%. Это стало приводить к проблемам, когда что-то из железа выходило из строя. Пришлось добавить серверов, чтобы нагрузка стала 40-50%.

🔹Далее упёрлись в ёмкость входного канала. Пришлось переходить на использование геораспределённой CDN.

#perfomance