Всем привет! Я Руслан Абдуллаев, DevOps-инженер компании Technocracy. Хочу рассказать вам о нашем проекте 2020 года.
В тексте будет немного моей боли, признание архитектурных ошибок, переход на анзибл и минио и финальная форма покемонов без единого простоя.
«Все упало — надо подобрать!»
На старте с архитектурной стороны все было просто: два сервера для разработчиков и тестовая среда, плюс продакшен, состоящий из двух серверов средней мощности: для приложения и базы данных.Но с простотой пришли проблемы.
Мы начали замечать слабые места этой конфигурации.
Основная проблема – акцент на ресурсах.
Это было только под нашим контролем вертикальное масштабирование .
То есть на все вызовы мы могли бы отвечать банальным увеличением ресурсов производственных серверов.
Но это спасало лишь на время.
Результат – частые падения и понимание, что у всего этого есть потолок.
Будильник в те времена был не нужен: в 6 утра менеджер все равно разбудит тебя с пеной у рта и криком: «Все упало — надо поднять!» Ситуация устраивала не всех, от пользователей, которые не могли пользоваться платформой, до меня, желавшего спать.
И здесь хотелось бы сказать, что в какой-то момент мы встали и со словами «перестаньте это терпеть» начали все кардинально менять, но нет. Изменения стали скорее естественным продолжением проекта.
Мы поняли, что горизонтальное масштабирование должно решить большинство проблем.
Мы начали.
Необходимо было распределить компоненты проекта по серверам и дублировать их для отказоустойчивости.
Мы приобрели сервера, в течение пары месяцев переработали всё, что можно было переработать, собрали новые продукты и после зимних праздников переключили весь трафик со старого на новый.
Теперь подробности
Пришлось углубиться в тему кластеров баз данных: поскольку мы строили отказоустойчивую инфраструктуру, обойтись одним сервером было невозможно, это стало бы точкой отказа.Поднимать этот кластер было больно из-за опасности испортить все данные и уложить платформу на долгое время.
Но и от этого можно уберечься.
Все, что вам нужно, это каждый день перед сном.
Имейте в виду, что репликация базы данных всегда требует некоторого времени.
Если мы хотим прочитать данные из реплики сразу после записи их на мастер, то, может быть, стоит задуматься о кэшировании? На данном этапе мы не настроили автопереключение мастера, но не факт, что это необходимо.
Основная цель заключалась в том, чтобы предотвратить вмешательство тяжелых запросов чтения в другие операции с данными.
Также помним о возможном расщеплении мозга при автопереключении.
Вот народный рецепт. С технической стороны кластер выглядит так: 3 сервера с 8 процессорами, 16 ОЗУ и 1 ТБ SSD. Репликация на основе трансляции журнала WAL. 
В результате мы имеем кластер из трёх серверов, способный принять на себя достаточно большую нагрузку.
Основной удар примут на себя четыре новых сервера, поэтому пришлось переделать файловое хранилище .
Вы больше не можете использовать для этого тот же сервер, на котором работал бэкенд — это приведет к десинхронизации: один файл будет записываться на первый сервер, а другой — на второй.
Мы с нашим бэкенд-разработчиком начали искать возможные решения и остановились на minio, поскольку это хранилище, совместимое с S3. При этом его можно развернуть на наших серверах и достаточно тонко настроить.
Например, обеспечить запись файлов только по внутренней сети, чтобы некоторые данные можно было загружать только бэкендом, а наружу можно было выбрасывать только раздачу файлов.
Кстати, недавно я столкнулся с мини-обновлением, которое сломало нашу среду разработки.
С обновлением админ-панель и API были разделены на разные порты.
На первый взгляд все нормально, я добавил еще один домен и привязал к нему админку, но по каким-то причинам часть нужного нам функционала оказалась сломана.
Например, делиться файлами по ссылке.
Пришлось откатиться на ту версию, которая была раньше.
Вперед, продолжать.
Я укрепил свои знания в развертывании с использованием ansible. Это очень удобно.
И почему я не сделал этого раньше? До Ansible мы использовали обычный скрипт, который выкатывал необходимые изменения на сервер из gitlab ci/cd. С приходом нескольких серверов, которые нужно было обновить, этот подход перестал работать.
Но ansible идеально подходил для этой задачи.
Вы можете сказать ему, что делать, и он будет делать это параллельно на всех серверах.
Работаем с нагрузкой
Следующий момент — балансировка нагрузки.Здесь по классике есть два сервера с nginx, которые выступают точкой входа в платформу и распределяют нагрузку по серверам.
Важно уточнить, что нагрузка, создаваемая во время нагрузочного тестирования, отличается от фактической пользовательской нагрузки.
Как бы хорошо ни были написаны тесты, они не смогут предсказать, как система отреагирует на реальных пользователей.
Пример: Прежде чем переключить трафик на новый продукт, мы несколько дней его активно нагружали.
Все просто летало.
И вот мы запустили реальных пользователей, но уже через несколько дней столкнулись с проблемой нехватки оперативной памяти на бекенд-серверах.
Все начало тормозить еще хуже, чем раньше.
Оказалось, что мы неправильно настроили количество рабочих-ганикорн .
У реальных пользователей они начали съедать много памяти.
Здесь стоит сказать вслух: « не доверяйте официальному документу о пушке! .
Количество рабочих следует устанавливать в зависимости от вашего приложения и проведенных испытаний, а не на основе формулы, приведенной в документе.
Но это еще не конец.
Когда мы осознали проблему, мы решили сократить количество работников.
Но наша сборка внезапно перестала работать и мы не смогли выкатить обновление.
В течение следующих нескольких дней мы возились со сборкой и каждую ночь перезагружали продукт, чтобы он не зависал из-за нехватки памяти.
В результате нам пришлось изменить базовый докер-образ приложения и переписать его сборку.
Это помогло выкатить и решить проблему.
После этого иногда все же приходилось перезагружаться, но очень редко.
Несколько слов о мониторинге
Мы настроили мониторинг всего оборудования, докер-контейнеров и работоспособности самой платформы на базе zabbix. Плюс никуда не пойдешь без оповещений в Telegram в случае возникновения проблем.В конечном итоге это помогло предвидеть проблемы и решить их заранее, а не как обычно, когда в 6 утра все ломается.
И вот уже более 6 месяцев без единого простоя.
Это мой первый текст, поэтому буду особенно рад задавать вопросы в комментариях.
Спасибо всем, кто дошёл до этого момента! Как и было обещано, в конце кое-что особенное: набор мемов Devops. 
Кстати, подписывайтесь на наш телеграм-канал «Голос Технократии» .
Каждое утро мы публикуем дайджест новостей из мира IT, а по вечерам делимся интересными и полезными шедеврами.
Теги: #Nginx #it-инфраструктура #Высокая производительность #postgresql #разработка #DevOps #Распределенные системы #ansible #highload #высокая производительность #масштабирование postgresql
-
Антонимия
19 Oct, 24 -
Реклама
19 Oct, 24 -
Организация Потока Дешевой Рабочей Силы
19 Oct, 24 -
Социальная Сеть По Симптомам Болезни
19 Oct, 24
