Как разогнать TLS на Go до 100 Gbps — опыт Kinescope

https://habr.com/ru/companies/oleg-bunin/articles/913272/

Ребята из Kinescope показывают, как они добились скорости раздачи видео в 100 Gbps на обычных 1U-серверах, используя Go и kTLS.

Что интересного:

- Перенесли TLS-шифрование из user space в ядро Linux с помощью kTLS — получили zero-copy и минимальную нагрузку на CPU (1.4% при 40 Gbps)

- Обнаружили, что Let's Encrypt по умолчанию выдаёт RSA-сертификаты. Переход на ECDSA ускорил handshake в 40 раз (с 1.6 сек до 40 мс)

- Написали минимальный патч к стандартной библиотеке Go для поддержки kTLS — всё работает через обычные интерфейсы

- Решили проблему session resumption на множестве серверов простым способом — синхронизацией ключей между машинами

Интересный момент: когда из-за ошибки в конфиге весь трафик (40 Gbps) ушёл на одну машину — и она выдержала, хотя и "молотила" 600% CPU.

————

Хорошая статья с реальными продакшн-кейсами. Авторы не стесняются рассказывать про свои косяки (история с ChaCha и бабушкафонами) и показывают конкретные метрики.

Кстати, как заметил автор, в Go уже принято решение добавить поддержку kTLS в стандартную библиотеку — issue #44506 наконец-то сдвинулся с мёртвой точки.

#article #performance #tls

GOMAXPROCS для контейнеров

Параметр рантайма GOMAXPROCS определяет максимальное количество потоков операционной системы, которые планировщик Go может использовать для одновременного выполнения горутин.

Начиная с Go 1.5, по умолчанию он равен значению runtime.NumCPU, то есть количеству логических CPU на машине.

Например, на моем ноутбуке с 8 ядрами значение GOMAXPROCS по умолчанию тоже равно 8:

maxProcs := runtime.GOMAXPROCS(0)
fmt.Println("NumCPU:", runtime.NumCPU())
fmt.Println("GOMAXPROCS:", maxProcs)

NumCPU: 8
GOMAXPROCS: 8

Программы на Go часто запускаются в контейнерах под управлением Docker или Kubernetes. В этих системах можно ограничить использование процессора для контейнера с помощью функции Linux, которая называется cgroups.

До версии 1.25 рантайм Go не учитывал ограничение по CPU (CPU-квоту) при установке значения GOMAXPROCS. Как бы вы ни ограничивали ресурсы процессора, GOMAXPROCS всегда устанавливался равным количеству CPU на хосте.

А теперь начал учитывать:

docker run --cpus=4 golang:1.25rc1-alpine go run /app/nproc.go

NumCPU: 8
GOMAXPROCS: 4

Если лимит CPU изменяется, рантайм автоматически обновляет значение GOMAXPROCS. Сейчас это происходит не чаще одного раза в секунду.

подробности

🔀 Динамический GOMAXPROCS 🔀

До релиза Go 1.25 осталось около недели, а значит, самое время восполнить пробелы и написать всё то, о чем я (по-хорошему) должен был рассказать в течение последнего полугодия разработки новой версии языка. Начнем с небольшого, но значимого изменения: динамического GOMAXPROCS.

Для тех, кто не в курсе: Go позволяет определить число горутин, которые могут одновременно выполняться в пределах рантайма. Ключевое слово — одновременно. Это значит, что горутин у вас может быть сколько угодно, но выполняться из них (лопатить код, а не находится в ожидании сети, файлов или ответа из сишной либы), в момент времени, будет только число, указанное в GOMAXPROCS. По-хорошему, это число обычно равно числу физических ядер на вашем CPU. Но в серверных окружениях начинаются тонкости, главная из которых, cgroups, является столпом для Docker и K8S.

Смысл вот в чем: в контейнеризированном мире на приложение может быть выделено даже не ядро, а фракция или квота, при этом значения сии могут быть динамическими и изменяться в процессе работы кластера. Процесс может ошибочно исходить из того, что у него есть 64 ядра всего блейда (и как следствие — возможность 64-х активных потоков), но по факту доступных именно нашему процессу ядер намного меньше. И это не вдаваясь в подробности таких вещей, как "привязка к ядрам CPU конкретного процесса" которые актуальны в NUMA окружениях.

До версии Go 1.25 эту проблему частично решала библиотека automaxprocs от Uber, которая выставляла значения наиболее приближенные к ожидаемым оркестратором. Но делала она это только один раз и только на старте. Кроме того, много людей банально не знали об этой тонкости работы рантайма Go и, как следствие, неправильно использовали доступные ресурсы CPU.

Начиная с версии Go 1.25, GOMAXPROCS будет не только выставляться автоматически, но и периодически обновляться в течение жизни приложения, в зависимости от того, как меняется внешнее окружение.

На изменение GOMAXPROCS будут влиять в совокупности три вещи:

• Изменение числа логических ядер на машине.
• Изменение привязки приложения к ядрам CPU.
• И, специально для Linux, средний лимит пропускной способности, основанный на квотах CPU cgroup.

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

• Вы можете не выставлять в go.mod версию go 1.25.x — обновление придёт к вам только когда вы захотите перейти на поведение языка версии 1.25.
• Вы можете самостоятельно выставить GOMAXPROCS с помощью переменных окружения или с помощью функции GOMAXPROCS. В таком случае автообновление будет выключено, и рантайм доверится вашему суждению.
• Также можно оставить прошлое поведение с помощью GODEBUG переменных containermaxprocs=0 и updatemaxprocs=0.

P.S. Для полноценного мониторинга Go теперь держит в памяти дескриптор доступа к файлам cgroups на время жизни всего процесса.

🏎️ Об оптимизациях в Go 1.25 🏎️

В новом релизе, как и всегда, к нам приедут новые оптимизации для компилятора. Две из них меня заинтересовали больше всего:

• Цепочка из четырёх 1, 2, 3, 4 PR, суть которых можно описать с помощью одного примера:

var x []int

for i := 0; i < 4; i++ {
    x = append(x, i)
}

Если в Go 1.24 и ранее такой код приводил к аллокации в хипе, то начиная с Go 1.25 — нет. А всё просто: make и append теперь, в большинстве случаев, не аллоцируют память в хип до 32 байтов включительно. Вместо этого они используют память на стеке и лишь при превышении объёма начинают идти в хип. Такая вот консервативная оптимизация для слайсов всех типов.

• Нулевые значения и "константные" переменные больше не аллоцируют память в хипе при присвоении значения интерфейсу. Продемонстрировать проще всего вот так:

type doubleInt struct{ value1, value2 int }

localVariable := doubleInt{value1: 3, value2: 2}
globalAny = any(localVariable)

localVariable2 := doubleInt{}
globalAny2 = any(localVariable2)

Если ранее подобный код приводил к аллокации, то теперь компилятор достаточно умён, чтобы на этапе компиляции выделить специальное read-only место в памяти и использовать именно его во время исполнения. Особенно приятно, что reflect.Value.IsZero теперь использует сравнение по указателю для нулевых значений структур и массивов, что существенно удешевляет проверку.

🎉 Вышел Go 1.25! 🎉

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

— ♻️ Бинарей в комплекте теперь меньше. Разработчики компилятора активно использовать команду go tool у себя внутри, что убирает необходимость поставлять заготовки в комплекте. Но как минимум go build и go test бинари все еще на месте.

— Новая директива ignore в go.mod. Подробное описание тут. Если в вкратце: для этого вы раньше использовали каталог testdata и каталоги которые начинаются с точки.

— Когда go команда обновляет go 1.xx.y директиву в go.mod она больше не добавляет toolchain директиву.

— go vet теперь ругается на неправильное использование sync.WaitGroup.Add и fmt.Sprintf("%s:%d", host, port) ибо есть net.JoinHostPort.

— 🍵 Новый экспериментальный сборщик мусора. О нем статья будет позже.

— 🔀️️️️️️ Новый тип runtime/trace.FlightRecorder позволяет записывать только значимые события, а не всё подряд для tracing’га (под капотом используется циклический буфер, который помнит N последних секунд).

— 🛠 Компилятор теперь генерирует дебаг-инфу в формате DWARF5. Практический итог: бинари едят меньше места и быстрее комбинируются.

— 🏎️️️️️️ Новый экспериментальный пакет encoding/json/v2. По хорошему про него тоже надо писать отдельную статью, но если в кратце — он намного быстрее того что было внутри encoding/json. А другая хорошая новость заключается в том, что если вы включили GOEXPERIMENT=jsonv2 то больше ничего менять не надо, так как encoding/json сам подключит новую внутряку.

— Тип os.Root приобрел несколько новых методов.

— 🏎️️️️️️ Функция reflect.TypeAssert позволяет приводить типы из reflect.Value в конкретный тип, минуя потенциально аллоцирующий вызов reflect.Value.Interface.

— Директива GODEBUG=checkfinalizers=1 позволяет понять, как дела в вашей очереди cleanup’ов и finalizer’ов во время каждого GC.

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

— Новый метод sync.WaitGroup.Go - больше нет необходимости тащить errgroup если вам не нужен был возврат ошибок и отмена контекста.

— 🔥testing.T/B/F теперь имеют метод Output() io.Writer который позволяет правильно редиректить вывод внутри вызова теста.

Читать про релиз вот тут.

Ещё одна статья про Swiss Tables в Go

https://habr.com/ru/companies/oleg-bunin/articles/934906/

Если вам было мало статей на эту тему, то держите ещё один неплохой подробный разбор:

Попробуем найти ответы на вопросы о том, почему мапы изменились, что лежит в основе новой реализации и как к ней пришли.

#article #swiss_map

Как я пытался засунуть gRPC в браузер — часть первая

https://habr.com/ru/articles/941816/

Эдгар Сипки рассказывает о вечной боли — gRPC прекрасен для микросервисов, но не очень то дружит с браузерами.

Причина: браузеры не умеют работать с HTTP/2 стримами из JavaScript. За 10 лет было 4 серьёзных попытки это исправить, и самая первая до сих пор остаётся самой адекватной.

История про gRPC-Gateway (2015):

- Японская разработчица Yuki Yugui Sonoda придумала гениально простое решение: не надо тащить gRPC в браузер, давайте сделаем прокси

- Добавляешь в proto-файлы HTTP-аннотации, генерируешь код — получаешь REST API для фронта и gRPC для бэкенда

- Вся бизнес-логика пишется один раз, интерсепторы работают

- Стримы тоже работают... через WebSocket (ну хоть так)

- Бонусом идёт автоматическая генерация Swagger-документации

Результат: это не настоящий gRPC в браузере, а "REST с протобафами". Но работает, и это главное.

————

Забавно, что такой большой Google так и не смог придумать ничего лучше, чем решение одного разработчика из 2015 года. Хотя, автор статьи как раз предполагает, что у Гугла были свои внутренние наработки:

Кстати, взял небольшое интервью (ну как интервью, в линкеде спросил) и она еще рассказала, что когда проект возымел успех, с ней связались ребята из Google и предложили как раз воспользоваться описанием спеки из своей механики, что уже как бы говорит, что google имели схожий проект, но так и не зарелизили его в OpenSource

Бонус для меня: благодаря статье узнал, что автор gRPC-Gateway — японка, будет что почитать теперь для практики языка.

#article #grpc #web

🧪 Сравнение инструментов для генерации моков

https://habr.com/ru/companies/avito/articles/939388/

Семён Эйгин из Авито (мейнтейнер minimock) сравнивает три популярных инструмента для генерации моков:

- mockery
- gomock
- minimock

Очевидно, автор предвзят, но статья всё равно интересная. Просто учитывайте это во время чтения.

Какие проблемы обсуждаются:

1. Типизация параметров

- mockery и gomock используют interface{} в ожиданиях: GetUser(1) интерпретируется как int вместо int64
- minimock генерирует строго типизированные методы: Expect(id int64)
- На практике: можно пропустить ошибку в стиле (int64=1) != (int=1)

2. Контроль количества вызовов

- gomock по умолчанию разрешает только один вызов метода
- mockery и minimock позволяют неограниченные вызовы
- Двойственная ситуация: gomock помогает поймать лишние вызовы, но требует явного Times() или AnyTimes()

3. Тестирование асинхронного кода

- mockery: приходится встраивать каналы через RunAndReturn — плохо масштабируется
- gomock: нужен самописный хелпер с controller.Satisfied()
- minimock: встроенная поддержка через mc.Wait(timeout)

————

Выбор автора, предсказуемо — minimock как "самый простой и топорный, покрывающий 99% случаев".

И я в целом согласен: строгая типизация экономит время на дебаге, встроенная поддержка асинхронности избавляет от костылей.

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

#article #testing #mocks

Bubble Tea — TUI-фреймворк для Go

https://habr.com/ru/articles/939574/

Коротенький обзор фреймворка Bubble Tea. Сам обзор ни чем особо не примечателен, но фреймворк шикарный, очень рекомендую. Если вы любите красивые консольные утилиты. вам точно понравится.

#article #tui