Новое

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

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

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

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

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

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

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

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

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

Очередная статья вида «делайте простые, скучные, рабочие штуки», а не «сложные, интересные и умные».

Интересный пример с моторами рыбацких лодок SABB: они работают на любом топливе и в них нечему ломаться (YouTube), потому что раньше для рыбаков надежность лодочного мотора была вопросом жизни и смерти.

У маркетологов тоже бывают классные истории!

Вот, например, бывший глава маркетингового отдела Uber Кевин Фриш рассказывает, как случайно обнаружил, что из 150 миллионов долларов рекламного бюджета (performance marketing) 100 миллионов уводили мошенники. Источник в твиттере и подкаст.

Началось всё с того, что социальные активисты задолбали основателя убера Трависа Каланика твитами «вот вы говорите, что против Breitbart, а всё размещаете у них рекламу». Каланик: wtf, чувак, ты ведь говорил что всё под контролем! Фриш начинает разбираться и находит посредников, которые не отключили рекламу по просьбе и ставит их на паузу. Речь о 15 миллионах долларов рекламы, 10% всего рекламного бюджета. Готовится к обвалу показателей установок, но не происходит вообще ничего.

Начинает копать: запрашивает логи и видит в них супер странные вещи, вроде того, что человек кликает по рекламе и через 2 секунды (!) логинится в убер — так не бывает. Оказывается, это мошенники, которые обманывают рекламные сети с помощью зараженных вирусами Android телефонов и других техник. На такие «установки» приходилось 2/3 бюджета «performance marketing» – 100 миллионов долларов.

Продолжает копать и из оставшихся 50 срезает ещё 20 не особо эффективных, в результате получается, что можно было достичь того же результата за пятую часть цены. Такая вот история. А мы программы оптимизируем.

Часто в результатах гугл-поиска первую строчку занимает пинтерест. Это такой сервис, где удобно собирать идеи нарядов (не только, но это, кажется, лучшее применение).

SEOшники пинтереста — черные маги и у них есть блог на медиуме, где они делятся своими секретами. Вот программная статья о том, как они ставят научные SEO-эксперименты, а вот все их статьи про SEO.

Фото с прекрасной IT-конференции Ulcamp, на которой мы познакомились с Андреем в 2017 году.

Горячо рекомендую формат, закончится коронавирус и обязательно ещё поеду.

Новый эпизод подкаста: про разработку в Убере. Андрей Неверов был техдиром стартапа грузоперевозок Trucker Path, а теперь работает инженерным менеджером в Убере в Дании.

Андрей руководит командами, ответственными за CI/CD: системы автоматизации установки серверного софта. Его инструментами пользуются больше двух тысяч программистов, а количество конечных пользователей идёт на сотни миллионов. Пока вы читаете этот текст и слушаете эпизод, в мире будут в пути 400 тысяч водителей такси и курьеров, управляемые убером. Вот такой масштаб ответственности.

Поговорили об устройстве команд и межкомандном взаимодействии, как тушат пожары (incident management) и как продвигаются по карьерной лестнице.

Слушайте и подписывайтесь: Apple, Google, ютуб, Castbox, Spotify, Яндекс, Overcast и веб-версия.

Очередная страшно красивая нейросеть от OpenAI.

Вы пишете текст, она генерирует картинку. Вот, например, «стулья в форме авокадо».

По ссылке куча других примеров.

Страшно.

https://openai.com/blog/dall-e/

Хороший канал про аналитику, ту, которая с числами и базами данных, от чувака в теме. И название подходящее — @leftjoin. Особенно хорошо, что много репостов — можно полистать вверх и обнаружить все важные каналы про аналитику.

Похвастаюсь классным клиентом.

Сервис upmarket размещает товары производителей на интернет-рынках вроде озона и вайлдберрис. Ребята делают полный цикл, от написания карточек товаров и работы с отзывами до логистики.

Звучит довольно просто, но оборот у парней больше полумиллиарда рублей в год.

Нас позвали по двум причинам: 1) придумать, как автоматизировать те вещи, которые сложно поручить машине из-за слабого API торговых площадок и как сделать из «самодельных скриптов» надежную и масштабируемую систему; 2) вторая причина даже интереснее — мы соберем команду разработки, которая будет развивать IT в бизнесе после нашего ухода.

Одна из первых задач — обновить сервер статистики, который собирает данные из личных кабинетов крупных интернет-площадок в наше собственное хранилище. Данные нужны для принятия выгодных решений о ценах и объемах товаров, а ещё для сложных отчетов. Наша цель — автоматизировать подключение новых личных кабинетов, чтобы можно было добавить новых клиентов без лишних операционных затрат.

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

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

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

Обращайтесь @samatg, мы берем ещё клиентов.

Cloudflare готовится перевернуть рынок хостинга веб-приложений. Длинный пост, но технологии на самом деле поразительные.

Исторически, Cloudflare — крупный и агрессивный игрок на рынке CDN, то есть они умеют с минимальной задержкой и максимальной скоростью отдавать статический контент: картинки или страницы, которые одинаковые для всех пользователей. Они забирают их с ваших серверов, копируют (кешируют) на сотни своих серверов и отдают пользователю. Прикол в том, что у Cloudflare есть свои серверы в 200 главных точках обмена трафиком, 99% пользователей интернета живут ближе, чем в сотне километров от сервера Cloudflare. Это называется edge-network, пограничная сеть, в смысле та, которая граничит с пользователями. Небольшое расстояние и оптимизированные серверы означают, что статический контент будет грузиться мгновенно.

Проблема в том, что большинство страниц — динамические. Например, гугл-документ или мою ленту фейсбука кешировать на edge смысла нет — никому кроме меня она не нужна, да и мне интересна только самая последняя версия документа, и я его только что отредактировал. Исторически это означает, что нам нужно вести все эти вычисления новых страниц где-то на центральном сервере. У крупных компаний вроде гугла или фейсбука обычно есть несколько крупных серверных ферм на каждом континенте, поближе к пользователям, так что пользователи из России кучкуются на европейских серверах, а американцы — на штатовских. Это всё требует довольно сложную инфраструктуру, маленьким компаниям недоступную. Облака Амазона и другие конкуренты пытаются решить эту проблему, но без поллитра во всех их рычажках не разберешься.

Кажется, у Cloudflare получилось придумать элегантное, красивое решение для динамических страниц, которое работает прямо на edge-серверах! Встречайте Cloudflare Workers и Durable Objects.

Cloudflare Workers — облачные функции, в Амазоне они называются лямбды (lambda@edge). То есть вы пишете программу, которая обрабатывает запросы пользователей, загружаете её в облако и она запускается по необходимости на серверах облака, прозрачно, незаметно для вас и для пользователя. Придет один пользователь — запустится одна копия, придет тысяча — запустится тысяча копий. Обычно есть время на так называемый cold start, то есть после некоторого ожидания облачная функция тушится и нужно время, чтобы она проснулась и начала отвечать на запросы. Тут этой задержки нет. Обычно вам нужно выбрать регион работы функции (помните про близость к пользователю?), тут выбирать не нужно, код запустится из самого ближнего к пользователю edge (!) сервера. Обычно эта штука стоит недешево, здесь она примерно в 3-10 раз дешевле, чем у конкурентов. Весь этот банкет за счет того, что наш код работает не контейнерах, а v8-изолятах, то есть частично — на движке гугл-хрома! (тут рассказано, как их выбрали). Но это всё закуска, кайф — дальше.

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

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

Отдельно подчеркну достойную документацию и хороший инструментарий разработчика.

Перечисленное выше — базовые технологии, на которых можно строить впечатляющие бизнес-решения.