Очень черная пятница

Все началось с того, что случился коронавирус, и более 500 точек продаж Орматек по всей стране — закрыли на клюшку. Зато онлайн как ПОПЁР, все ломанулись в него! И два средненьких сервачка (один 6-ядерный — под сайт, второй — под базу) работали так, что из тех 500 можно было уволить половину, и все равно на хлеб бы хватило. Товар ходовой. Однако кому нужен хлеб без икры?

И вот. В пятницу вечером, без объявления войны, маркетинговый отдел включил свою адскую маркетинговую машину «Черная пятница» (это весной то). Пиф-паф-пуф, уворачивайтесь, кто может.

Наш админ пошел на кухню за очередной кружкой вкусного, ароматного чаю, обдумывая, не взять ли чего еще, более пятничного, из холодильника, когда взгляд его упал на Большой Черный Телевизор в на стене опенспейса. На телевизоре краснел Zabbix (это такая админская программа для мониторинга серверов), мол, одному из серверов скоро будет плохо. А вскоре начали приходить телеграммки: «алярм-алярм, бросай пить чай, пора спасать мир».

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

Мы перезапустили web-сервер, чтобы все текущие подключения, которые выполняются одновременно, прекратились и серверу стало легче. Легче стало, но время обработки запроса не сократилось. Стали разбираться — увидели +40% прирост посетителей к тому, что было вчера (а с момента начала короны трафик вырос в несколько раз). Было подозрение, что это боты, проверили — настоящие люди!

Для 6-ядерного 12-поточного web-сервера нагрузка стала неподъемной. Странный наплыв покупателей положил сервер полностью — вместо красивущих кроватей по скидке сайт выдавал 504 ошибку «Time-out шлюза». Быстрых решений — два. Тормознуть рекламу (нельзя, процесс запущен и его не остановить) и добавлять сервера. Ну, то есть решение — одно.

Кто помнит из статьи о технической грамотности, какие бывают типы серверов? У разных хостеров с серверами все по-разному. У кого-то в наличии есть готовые серверы, которые можно просто взять и купить сразу же без необходимости долгой настройки. Кто-то готовит серверы чуть ли не в течение суток (это слишком долго). У кого-то просто через пару команд можно запустить в облаках копию инстанса (к сожалению, это не наш случай). Поэтому, если подобная ситуация на вашем проекте возможна, у вас должен быть хостер, который позволит быстро нарастить мощности (пост не рекламный, все рекомендации — в личку).

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

На стороне клиента руководитель проекта Ольга — супер-пробивная, талантливая, умница-красавица. В общем, минут за 20 бухгалтерия и другая внутренняя бюрократия была побеждена, деньги найдены. Докупили дополнительный сервер из тех, что по-мощнее, но не надо ждать установки: 96 Гб памяти и 2 процессора (в каждом 10 ядер/20 потоков). Чик-чик, вот вам доступы.

Итак, у нас есть мощный, но пустой сервер, и два не сильно мощные, но под завязку трафиком. Что дальше с ним делать?

Если проблемы с сервером базы данных, то… — не наш случай (сервер базы был не особо нагружен), но расскажем вам на всякий :)

Один из вариантов — использовать репликации Master-Slave или даже Master-Master: когда данные с одного сервера базы данных незаметно копируются на другие — сервера-реплики. Таким образом можно разгрузить основной сервер.

Одну из реплик назначаем «мастером» (англ. master — хозяин, т. е. главный сервер), а другие — «слейвом» (англ. slave — раб, т. е. подчиняющийся).

«Мастер-слейв» — классическая схема: «слейв» копирует изменения с «мастера». «мастер» может писать и читать в базу, а «слейв» только читать. «Слейвов» может быть несколько и случайным образом один из них обрабатывает запрос. Позволяет быстрее отработать очередь из клиентов, которые хотят чего-то прочитать из базы.

«Мастер-мастер» — схема встречается, но реже, т.к. делать несколько мастер-серверов — чревато (мы про MySQL). Как минимум, нужно придумать, чтобы первичные ключи записей не пересекались (например, один сервер делает четные ключи, второй — нечетные). Схема рабочая, но неуютная.

Впрочем, у нас с базой все ОК, запас прочности есть. Нужно раздуплять web-сервер. А там — пользователи, которые постоянно что-то заказывают…

Как бы решал задачу классический админ-разгильдяй:

1. Закрыл бы старый сервер на клюшку (чтобы не дай бог чего не поменялось во время бэкапа и переноса данных).
2. Сделал полный бекап.
3. Перетащил на новый сервер.
4. Развернул на новом (и, возможно, даже протестировал).
   
5. Перенастроил DNS, чтобы он смотрел на новый сервер, и открыл к нему доступ для DNS.
   
   

Или перетащил бы все через докер-контейнеры.

У нас больше 100 Гб данных, закрывать сервер на несколько часов — не правильно. Будем работать на горячем железе. Алгоритм вырисовывается сам собой:

1. На новом сервере монтируем по сети папку с ядром сайта.
   
2. На новом сервере поднимаем веб-сервер. Нам нужен apache.
   
3. Сессии переносим в базу данных (оказалось, что уже так и было) — это нужно, чтобы любой из серверов мог вспомнить, что за клиент к нему пришел.
   
4. На старом сервере на nginx настраиваем балансировщик и часть динамических запросов отдаем на новый сервер. Пока соотношение 90% запросов — на старом сервере, 10% на новом. Статику все еще раздает старый.
   
   

Ух. Заняло ровно 4 минуты.

Старому серверу стало немного полегче. Но это не то, что нам надо. И не на долго. Сетевой диск работает мееедленно и жрет много процессорного времени на шифрование. Больше 10% запросов на новый сервер пока перекидывать нельзя. Нужно сначала решить проблему с сетевым доступам к файлам сайта:

1. rsync-ом переносим с сетевого диска — ядро сайта на ssd нового сервера;
   
2. перебаллансируем nginx (там очень гибкие настройки балансировщика). Интуиция подсказывает, что нужно балансировать чисто по количеству ядер / потоков: 6 клиентов на старый, 24 на новый. Интуиция не наврала.
   
   

Занимает еще минут 20. В основном, медитация, пока данные копируются.

Итого, от момента «мы все умрем» до момента «мы будем жить вечно» прошло менее часа. Причем все на живую, на горячую да еще и с учетом оплат. В пятницу-вечером. В черную пятницу, вечером. Чих-пых, и в продакшн.

Еще минут 20−30 занимает шлифовка конфигов, мелкий тест, настройка почтового релея (сервера), переброс кеша с файловой системы в memcache и прочий тюнинг. Но это админ уже что-то достал из холодильника, и, доволен собой, просто понтуется.

Смеркалось.

Утром в понедельник — придумать скрипты автодеплоя (CI/CD) и завернуть уже все по-нормальному в докеры (а надо ли? вопрос…). Не спеша, несколько чашек чая.

За операцию-трансплантацию денег с клиента не берем (это ж по дружески было).

В итоге получилась вот такая, классическая схема. На картинку не вошли блокировщих DDoS-атак Varity и CDN для статики, но они у нас есть!