Принцип адвоката Брофловски, или облачная балансировка нагрузки своими руками

[robert_ayrapetyan]

А сколько всего ядер в сумме трудится над 5гбит/с?

[igors]

Сервер на расчётные 15К/сек — это 2 x E5-2630v4, то есть 20 ядер, принимает он 100 и отдаёт 80 Мбит/с. То есть 1000 ядер должно хватить. Ну, у нас где-то 800.

Наша специфика — bid requests, это очень мелкие сетевые пакеты. Нормального трафика можно обработать в несколько раз больше.

Как в любом живом проекте, это война со множеством переменных:
— нам нужно стараться не превышать 25 ТБ на сервер — дальше трафик не сильно, но платный, и выгоднее добирать серверы
— поэтому, когда мы приближаемся к красной отметке, находим фиксированные куски и утаскиваем на CDN — трафик снижается
— а в это время разработка делает новые фичи и усложняет логику — QPS и трафик на сервер ещё снижается
— чтобы это поправить, логику в Java оптимизируем и утаскиваем в user-defined functions в Aerospike — трафик растёт
— но впадают в задумчивость аэроспайки — теперь настало время усиливать их ферму.
Ну и так далее.

[robert_ayrapetyan]

Хм, спасибо. У нас просто аналогичные 5Гб\с и ДСП\ССП, но все на С++ и в разы меньше ядер поэтому…
Не думали о переезде на колокейшн?

[igors]

У нас сейчас 4 локации. На восточном побережье США, например, мы сменили за 2 года 3 хостинговые компании и 5 серверных платформ. Вот вырастем раз в 100, стабилизируем софт, и тогда обязательно окопаемся. :-)

[robert_ayrapetyan]

Очень знакомы все эти метания… Аналогично сменили 3 хостинга, но за 5 лет )

[erthad]

Архитектура однослойная или многослойная? Иными словами, эти сервера с какими-то своими бакендами разговаривают (например, через очереди), или только с базой?

[chemistmail]

Сколько ядер терминируют трафик из htts в http, на 15000 запросов в секунду?
У меня на 15k запросов входящего трафика получается 200 — 250 Мбит/с.
Трафик тоже бид реквесты.

[igors]

Возможно, дело в сжатии? Некоторые SSP и, например, обменник BidSwitch умеют присылать сжатый POST. Мы используем сжатие там, где оно поддерживается. http/2 тоже экономит трафик несколькими способами.

По ядрам — раньше мы никак не распределяли их между nginx и Java, а потом обнаружили, что если выдать nginx четверть всех ядер и включить worker_cpu_affinity, результат будет лучше. Но в целом наше узкое место не https, а логика.

[chemistmail]

Логика это понятно, у меня на тоже самое количество запросов java потребляет порядка 12 аналогичных ядер, еще 6 уходит на терминацию. Так что по большому счету цифры выходят аналогичные.

[kt97679]

У вас в конфиге написано:

down_thresh => 4,; Не ответил 4 раза на тест? Этот сервер лежит.
ok_thresh => 1,; Хоть раз ответил нормально? Жив!
interval => 20,; Проверяем каждые 20 секунд
timeout => 5,; Тупку более 5 секунд считаем отсутствием ответа

Правильно ли я понимаю, что если балансировочный nginx падает gdnsd от 20 до 40 секунд будет продолжать направлять на него запросы?

[igors]

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

[miolini]

Если ложится один из серверов, то клиенты какое-то время не смогут получать сервис, обращаясь к его публичному IP из кэша DNS. Это время легко может достигать 24ч, особенно если упавший сервер заменен новым с иным IP.

[igors]

Как я уже написал выше, механизм client retry решает проблему во всех современных браузерах. Вот чувак оттестировал всё, до чего дотянулся: https://blog.engelke.com/tag/client-retry/

А почему именно 24 часа?

[dcheklov]

Отличная статья, хорошо, когда коллеги по цеху делятся опытом. Есть пару вопросов:

1. Вы пишите про использование Aerospike на NVMe дисках. У вас при этом гибридная схема хранения? Просто если все в RAM, то не понятно, какой прирост дает NVM?
2. Как синхронизируете Aerospike в разных локациях: родную синхронизацию или еще как?

[igors]

1. Да, смысл Аэроспайка в том, чтобы использовать дешёвый SSD вместо дорогой оперативки, которая при больших объёмах начинает стоить совершенно неразумных денег. RTB это данные о пользователях, и это десятки терабайт.

Переход с простых SSD на NVMe SSD снизил нам load average впятеро. А с Редиса на Аэроспайк мы переезжали, когда альтернативой было взять сервер с 256 GB RAM.

2. Не синхронизируем — считаем, что в США и России у нас разные пользовательские базы, и гоняться за пользователем не надо. Вряд ли он в Штатах захочет пойти в Юлмарт за новым айфоном. :-)

[dcheklov]

А есть информация по тому, какой rps и на каком датасете дает оптимальные результаты при работе с NVMe на одном сервере. Объясню, в нашем случае, когда работаем с RAM, мы вообще не паримся с количеством инстансов, ограничение по сути — это слоты оперативной памяти, и мы ни разу не упирались в rps, запас по нагрузке в десятки раз больше, чем есть.

[igors]

NVMe у нас есть только в Германии, где Hetzner даёт его на базе «бытовых» материнок (PX61-NVMe). В США, где нормальные серверы, на NVMe интересных цен не получается. Текущие цифры такие: кластер из 4 серверов работает с 2 ТБ данных, над которыми делает 2К чтений, 15К записей, выполняет 30К UDFs и 25K batch reads. У нас довольно развесистые UDF, скрывающие несколько операций, поэтому прикидка довольно условная.