нагрузка

Ну и телеграм работает с огромными задержками. Сообщения отправляются по несколько секунд.

Upd: пишут, что они просто не справляются с нагрузками.

Как не уронить свой сервис под нагрузкой, на примере Signal.

Люди массово переходят из вацапа в Signal. Серверы Signal не выдержали и совсем лежали почти 14 часов, а испытывали серьезные трудности больше суток. Не лучшее время, чтобы падать :( Официальный твиттер сигнала при этом хранил молчание, будто это не модный стартап, а какая-то древняя корпорация. Жаль. Надеюсь, позже они опубликуют подробный разбор, что случилось.

Пока поделюсь, как мы однажды сами положили свои серверы и как от этого защищаемся теперь. Почти все мобильные приложения отправляют запросы на сервер, например, для оформления заказа или отправки сообщения. Важно, как себя ведут мобильные приложения, если сервер ответил с ошибкой. Очевидное решение — просто повторить запрос ещё раз, как только получил ошибку, незаметно для пользователя.

В одном проекте именно так мы и сделали. Всё было хорошо, пока серверу не стало плохо на пару минут. Если обычно на сервер приходили 100 запросов в минуту (полтора запроса в секунду), то за три минуты скопились 300 запросов и теперь, стоило серверу очухаться, как ему насыпали все 300 запросов в одну секунду. То есть для сервера это выглядело как рост нагрузки в 200 раз и он опять ложился под нагрузкой. Очень неприятная ситуация. Мы сами себя задидосили, своими же собственными мобильными приложениями. 🙈

Есть две компоненты решения этой проблемы:

🛑 Первая: сервер должен уметь ответить «довольно!», и клиенты должны перестать повторять запрос, если получили такой ответ. Интересно, что именно этой функции в Android-клиенте Signal не было и они добавили её во время аварии.

⏱ Вторая, более сложная и интересная, но тоже классическая: exponential backoff (экспоненциальная задержка). Идея очень простая: если сервер не ответил в первый раз — ждем 1 секунду и повторяем запрос. Во второй раз — ждем 2 секунды, в третий — 4, в четвертый — 8. То есть с каждой неуспешной попыткой, даем серверу больше времени прийти в себя. У Signal эта функция реализована, но во время аварии они добавили jitter — небольшую случайную задержку, чтобы клиенты не набегали на серверу толпой, через одинаковые интервалы времени после его падения, а нагрузка была более плавной. Обычно, в этом же коде реализуют ещё паттерн circuit breaker, когда после определённого числа ошибок «выбивает пробки» и запросы прекращаются совсем.

Используйте оба приема и будьте здоровы!

💭 Есть твит и телеграм-пост в популярном канале, в которых утверждается, что причина падения сигнала — в само-дидосе (мол, анекдот). Это маловероятно. Во первых, exponential Backoff в сигнал внедрили больше 2 лет назад и он здорово распределяет нагрузку; во вторых, изменения коснулись только Android клиента. Не верьте советским газетам, читайте первоисточники.

Карагодина Степана Ивановича расстреляли 21 января 1938. Почти у всех нас в России есть истории, связанные с большим террором — у кого-то предков сослали или расстреляли, кто-то — потомок палачей, бывает и оба вместе. Денис Карагодин уже много лет делает удивительный проект — расследует, кто и как убил его прадеда.

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

Давно не писал, две недели решительно не хотел ничего делать. Хочется свалить всё на пневмонию (не коронавирусную), на самом деле просто устал. Продолбал несколько лидов-клиентов. Раньше бы стыдился, но это тема для отдельного поста.

Между тем, происходит куча всего интересного. В мире пандемия (вот классная визуализация и хорошее видео про неё), а у нас в iGooods рекорд за рекордом. Если раньше в пике было по 70 запросов в секунду, то теперь — больше 400. Каждое выступление Путина — +20% посещаемости.

Чтобы выдерживать такие нагрузки, нужно оптимизировать код и увеличивать объем железа. Серверы масштабируются горизонтально и вертикально. Горизонтально — это когда ставишь рядом со старым сервером ещё один, такой же новый, и они делят нагрузку. Это идеальная схема, так мы сейчас регулярно добавляем серверы приложений. К сожалению, базу данных мы горизонтально масштабировать не умеем — для того, чтобы поставить в параллель два сервера БД, нужна специальная магия, запрогать которую мы не успели.

После последнего выступления Путина мы поняли, что скоро уткнемся в гигабитную сетевую карту на сервере БД (раньше я такого не видел и да, нам нужно переписать эти долбаные запросы). Спасибо огромное селектелу — пошли навстречу и мгновенно собрали кастомный сервер с 10гигабитным интерфейсом. Вот теперь сижу жду, когда ребята потушат на пару минут сайт и переключат базу данных на новую машину. Это — вертикальное масштабирование.

Спокойной ночи! 🌛

Вовремя мы взяли iGooods в клиенты. У чуваков столько новых пользователей, что серверы не выдерживают и внешние сервисы бьют лимиты.

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

Кстати, про лямбды: для того, чтобы не попасть под блокировки РКН, пришлось завернуть все запросы через наш собственный nginx, расположенный в России. Не забывайте про это, если работаете в России.

Интереснее сейчас, наверное, только у эпидемиологов, в медиа и в школах, которые пытаются перейти на удаленку. 🚀

Насчет журналистской солидарности, в отсутствии которой меня уличают (https://t.me/mediasrachi/736) . Журналисты не при чем (неуиновны).

Налицо или халтура разработки: не протестировали ничего толком, не подготовились к нагрузке; или некомпетентность руководства, когда к разработке приходят с запросом «сколько тебе нужно времени, чтобы это было готово завтра?».

Извините, если выглядело как наезд, это не так. Это была серия постов «смотрите, как не нужно делать».

Запуск больших проектов — сложно и больно, но зато, в теории, есть время подготовиться. Супер-важно, чтобы руководство понимало, что «у меня всё работает» не равно «можно запустить на 100 тысяч пользователей». Ответственность разработки — объяснить важность тестирования. Вот вам бесплатный хороший кейс, на который можно ссылаться.