Backpressure, изоляция сбоев и безопасность батчей в продакшене

Ваш Kafka consumer батчит по 500 сообщений за poll. У одного — битый header. Десериализатор бросает исключение. Без изоляции вы только что потеряли — или перепроиграли — 499 хороших сообщений вместе с ним. Батчинг умножает каждый сбой на размер батча, и тот же множитель берёт на вооружение атакующий. Это урок, который пропускают туториалы про throughput.

Уроки 01–05 покрыли плюс: амортизировать фиксированную стоимость, настроить окно, попасть в колено Парето. Это финальный урок, и он про минус — операционные edge case, которые превращают throughput-победу в пейджер в 3 утра. Каждое свойство, делающее батчинг эффективным (атомарное потребление, общая компрессия, одна очередь, одно окно), становится множителем сбоя, как только что-то ломается. Senior, который гонял батчевый пайплайн в продакшене, думает об этих четырёх вещах ещё до того, как смержен счастливый путь.

Изоляция сбоев: проблема отравленного сообщения

Батч потребляется атомарно: вы делаете poll() на 500 записей, обрабатываете их, потом коммитите один offset. Если обработка падает на элементе 47 — что с 1–46 и 48–500? Все наивные ответы — ловушки.

• Ретрай всего батча. Элемент 47 всё ещё отравлен, снова бросает исключение. Consumer никогда не сдвигает offset. Получаем бесконечный цикл, lag растёт без предела, партиция заморожена за одной плохой записью. Это классический столл на отравленном сообщении — тот самый, что будит пейджером, пока дашборды показывают «lag: 4.2M и растёт», а consumer выглядит здоровым.
• Skip батча при ошибке. Сдвигаемся за все 500, теряя 499 хороших, чтобы выбросить один плохой. Для платежей или заказов это потеря данных; для аудит-лога — потенциально инцидент комплаенса.
• Split-and-retry (бисекция). При сбое делим батч пополам и ретраим каждую половину. Падающая половина падает снова — бисектим только её. Рекурсируем, пока батч не станет одной записью, отправляем её в dead-letter и коммитим остальные. Платим O(log N) лишних запросов, чтобы изолировать один отравленный элемент из N. Для батча в 500 это ~9 ретраев, а не 500.

Облачный примитив для этого — BisectBatchOnFunctionError у AWS Lambda для источников Kinesis и DynamoDB Streams: при ошибке функции Lambda делит батч пополам и ретраит каждую половину независимо, сужаясь до проблемной записи. Сочетайте с ReportBatchItemFailures, где функция возвращает sequence number первого сбоя, и Lambda ретраит только с этой точки вместо повтора всего окна.

Всё это неполно без подстраховки: dead-letter queue (DLQ) плюс re-drive job. Записи, упавшие сверх maximumRetryAttempts, летят в DLQ (SQS-очередь или Kafka DLQ-топик) с оригинальным payload и контекстом ошибки. Оператор разбирает их вне основного потока, чинит схему или баг и re-drive-ит DLQ обратно в основной стрим. Пайплайн без DLQ не имеет изоляции сбоев — у него есть место, где сообщения тихо умирают.

Backpressure и ограниченные очереди

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

• Неограниченная in-memory очередь. Работает прекрасно, пока продюсер не обгонит consumer надолго и не заполнит heap, тогда JVM OOM-килит процесс, и вы теряете всё в полёте. Это классический антипаттерн — очередь, которая «никогда не заполняется», пока однажды не заполнится, в 2 ночи, унося весь узел.
• Ограниченная + block. При заполнении продюсер блокируется. Это сердце Reactive Streams: consumer сигнализирует спрос через request(n), и продюсер может эмитить только столько — backpressure как протокол первого класса (Akka Streams, Project Reactor, RxJava — все реализуют). Латентность деградирует мягко, throughput оседает на скорости самой медленной стадии. Это правильный дефолт, когда потеря данных дороже добавленной латентности.
• Ограниченная + drop. При заполнении выбрасываем новый (или самый старый) элемент. По дизайну с потерями, и корректно, когда свежесть важнее полноты — StatsD по UDP канонический пример: дропнутый сэмпл метрики невидим, а застрявший на полном буфере продюсер ломает ту самую видимость, ради которой он был нужен.
• Ограниченная + spill-to-disk. Страничим переполнение на локальный буфер на диске (write-ahead log), дренируемый за in-memory очередью. Durable при всплесках продюсера ценой disk IOPS и end-to-end латентности. Vector, Fluentd и Filebeat — все предлагают это для шиппинга логов.

Один нюанс, который важно понять верно: spill-to-disk — это рычаг ёмкости, а не сама политика переполнения. Даже дисковый буфер конечен, так что ему по-прежнему нужно правило when_full. Дисковый буфер Vector по дефолту when_full: block, прокидывая backpressure до самого источника, и переключается на drop_newest только когда вы явно выбираете сбрасывать нагрузку. Смысл в том, что «spill» даёт гораздо больший durable-буфер до того, как block-или-drop вообще сработает.

Выбор между ними — продуктовое решение, а не техническое. Вопрос: сколько стоит потеря одного элемента против одной секунды добавленной латентности? Для платежей потерянный элемент недопустим — block. Для метрик-firehose секундный столл ослепляет дашборды — drop. Ответьте один раз на пайплайн и зашейте ответ в конфиг очереди; не позволяйте этому быть случайностью того, какой дефолт привезла библиотека.

Безопасность: граница батча как примитив атакующего

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

Бомбы декомпрессии. Маленький сжатый payload, разворачивающийся в гигабайты на получателе. Конкретный инцидент Kafka — CVE-2023-34455 (с follow-up неполного фикса CVE-2023-43642): декомпрессор snappy-java читал 4-байтовое поле длины чанка и выделял байтовый массив этого размера без проверки верхней границы. Подделанный фрейм, объявляющий 0x7FFFFFFF, заставлял брокер пытаться выделить ~2 ГБ и бросать OutOfMemoryError — удалённый DoS, затрагивающий Kafka с 0.8.0 по 3.5.0, исправлено в snappy-java 1.1.10.1+. Общая защита: валидировать размер после декомпрессии, не только на проводе. Сжатый батч в 1 МБ может законно нести гораздо больше, так что лимит на уровне провода — вообще не защита.

Replay внутри батча. Если ваш idempotency key per-batch, а не per-item, атакующий отправляет один батч со 100 копиями одного payload. Проверка dedup на границе батча видит один уникальный ключ и спокойно обрабатывает все 100 копий. Идемпотентность должна быть per-item, с per-item nonce, проверяемым против dedup-стора по мере применения каждой записи.

Переупорядочивание при частичном сбое. Батчевые записи в KV store могут не сохранять порядок отправки, как только включается split-and-retry: переретраенная половина приземляется после успешной. Если порядок несёт смысл — event sourcing, CRDT merge, машина состояний — приложите sequence number per item, и пусть consumer режет out-of-order записи. Никогда не считайте, что порядок батча переживает ретрай.

Объединяющее правило: каждое свойство батча — общий размер, число элементов, idempotency key, порядок — должно валидироваться ПОСЛЕ декомпрессии и per-item, никогда не на границе провода и не per-batch. Сжатый батч — непрозрачный конверт; то, что внутри, и есть поверхность атаки.

Адаптивный батчинг: замыкание петли

Статичное окно — linger.ms=10, batch.size=16384 — неверно при любой нагрузке, кроме той, под которую тюнили. На низком трафике оно добавляет латентность, ожидая батч, который не наполнится; на высоком — упирает throughput ниже того, что система могла бы держать. Адаптивные системы трактуют окно как управляющую переменную, ведомую сигналом обратной связи.

• Сигнал. Наблюдаемая p99 латентность против потолка SLO. Когда p99 < SLO − margin, растим окно ради throughput. Когда p99 > SLO, уменьшаем, защищая латентность.
• AIMD (additive increase, multiplicative decrease). Тот самый контур, что использует TCP congestion control: толкаем окно вверх малым шагом каждый здоровый интервал, делим пополам при пробитии SLO. Он мягко прощупывает запас и резко отступает под стрессом — тот же инстинкт, что держит интернет стабильным, применяется к окну батча.
• Продакшен-примеры. У Kafka batch.size статичный, но linger.ms можно вести sidecar-ом, реагирующим на латентность. Фильтр adaptive concurrency у Envoy гоняет близко родственный контур — gradient controller (алгоритм Netflix), измеряющий minRTT под лёгкой нагрузкой и уменьшающий лимит in-flight конкуренции, как только sampled-латентность поднимается над ним. Та же идея, управляет конкуренцией вместо размера окна.
• Цена. Вы добавляете observability-поверхность (per-window гистограммы латентности) и контрольный контур, который сам может осциллировать при плохом тюнинге. Окупается после примерно 100k QPS, где разрыв между правильным окном на пике и в провале велик; ниже — хорошо выбранное статичное окно проще и достаточно.

Senior-чеклист перед шипом

Прежде чем батчевый пайплайн уйдёт в шип, senior может ответить на все шесть пунктов. Если хоть один ответ «мы не решили» — это и есть дыра, которая разбудит пейджером.

1. Путь восстановления от отравленного сообщения? Split-and-retry для изоляции, DLQ плохого элемента, re-drive job для повтора фиксов.
2. Поведение при переполнении? Block, drop или spill — выбранное явно из цены потерянного элемента vs добавленной латентности.
3. Максимальный размер payload после декомпрессии? Реальный лимит на распакованный размер, не только на проводе.
4. История per-item идемпотентности? Per-item nonce против dedup-стора, никогда не per-batch ключ.
5. Статичное окно или адаптивное? Статичное окей ниже ~100k QPS — просто знайте, что выбрали и почему.
6. Observability-поверхность? Гистограмма размера батча, gauge глубины очереди, rate DLQ, лаг consumer — четыре сигнала, ловящие всё вышеперечисленное до того, как оно разбудит пейджером.