Приём №2: Типизация событий

События ДОЛЖНЫ направляться в разные топики, ЕСЛИ события явно ИЛИ неявно относятся к разным типам, И ЕСЛИ тип события можно определить перед отправкой.

❗️ Вроде всё понятно, но есть коварный случай – неявная типизация. Это тот случай, когда реально разные типы событий попадают в один топик и обрабатываются одним и тем же обработчиком. Казалось бы, бред! Но в реальности такое можно увидеть достаточно часто. В основном это вызвано недостаточным знанием предметной области.

Если мы недостаточно знаем предметную область, то можем сделать ложное обобщение. Например, для логически разных событий использовать универсальную структуру данных. Об этом же предостерегает и Роберт Мартин в книге "Чистая архитектура" (см. главу "Ложное дублирование").

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

Итак, как же выявить неявную типизацию? Можно выделить следующие отличительные признаки.

1️⃣ Контекст события уже на этапе публикации содержит какой-то ключ-классификатор (один или несколько атрибутов), по которому можно судить о типе события.

2️⃣ Алгоритм обработчика события имеет ветвление, которое производится по некоторым атрибутам контекста события. При этом логика обработки каждой ветки существенно разнится. В этом случае можно говорить, что типизация событий производится на стороне получателя.

3️⃣ Код обработчика не имеет ветвлений, но время обработки событий существенно варьируется. В этом случае можно говорить о вариативной вычислительной сложности обработки. Как правило, такое происходит, если обработчик делегирует основную работу внешнему компоненту. Если так, то см. код внешнего компонента и п. 2.

Данный пост поясняет тезисы моего доклада с конференции TeachLeadConf 2024.

#conf

Приём №3: Конвейеризация вычислений

Обработчик события ДОЛЖЕН быть поделен на стадии, где каждая стадия – отдельный топик, ЕСЛИ выполнение следующей стадии зависит от предыдущей, И ЕСЛИ время выполнения каждой стадии ощутимо большое.

❗️ Иначе говоря, мы рассматриваем ситуацию, когда алгоритм обработки состоит из нескольких стадий, где выходные данные одной являются входными для другой - следующей (или следующих в случае, если есть условия выбора следующей стадии). И при этом каждая стадия вносит существенный вклад в общее время обработки. В этом случае следует задуматься о конвейеризации и для каждой стадии конвейера предусмотреть отдельный тип события и топик.

Почему это должно ускорить поток данных? Тут следует начать с того, что конвейер позволяет осуществлять внеочередное исполнение. Как это происходит, лучше посмотреть на простом арифметическом примере. 🤓 Допустим, наш алгоритм состоит из двух стадий: A и B; а в очереди находится два события: E1 и E2.

Если у нас один обработчик, который последовательно выполняет все стадии, общее время обработки двух событий будет равно сумме задержек на всех этапах: Ts=A(E1)+B(E1)+A(E2)+B(E2).

E1: A(E1) -> B(E1) ->
E2: ----------------> A(E2) -> B(E2)

Если у нас конвейерная обработка, т.е. стадии A и B выполняют разные обработчики, то для разных событий они могут работать параллельно и независимо друг от друга. И в таком случае общее время обработки двух событий будет равно сумме: Tp=A(E1)+max(B(E1),A(E2))+B(E2). Не трудно увидеть, что Ts>Tp.

E1: A(E1) -> B(E1)
E2: -------> A(E2) -> B(E2)

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

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

🕚 Проверка возможности выполнения обработки и обработка. Например, проверяем счет клиента, а уже затем формируем для него коммерческое предложение.

🕚 Подготовка к обработке данных и обработка. Например, перед формированием отчета аккумулируем всех необходимые данные в одном месте.

Данный пост поясняет тезисы моего доклада с конференции TeachLeadConf 2024.

#conf

Решил сделать отдельный пост-справку для тех, кто не знаком с одним или другим видом брокеров. На нее я буду ссылаться в дальнейшем. 🤓

🟢 Log-based-брокеры

Имеют постоянно пополняемый лог сообщений, хранимый на диске. Именованный лог называется топиком (topic) и обычно хранит сообщения с одинаковой структурой данных (одного типа). Источник отправляет сообщения, записывая их в топик; приемник, называемый потребителем (consumer), получает сообщения, читая и обрабатывая их последовательно. При успешной обработке потребитель сдвигает указатель (offset) к следующему сообщению. Положение указателя также хранится на диске и ассоциировано с потребителем. У каждого топика может быть только один потребитель, относящийся к одной группе (consumer group). Чаще всего группа ассоциируется с каким-то одним приложением (например, микросервисом).

В целях масштабирования и увеличения пропускной способности топик можно разбить на части - партиции (partitions), каждая из которых может быть размещена на различных узлах кластера. В какую партицию будет направлено сообщение решает источник; какую партицию будет обрабатывать потребитель решает брокер. Брокер отслеживает жизненный цикл каждого потребителя и производит процедуру балансировки - перераспределения топиков между активными потребителями. При этом важно то, что одну партицию может обслуживать только один потребитель. Так гарантируется порядок обработки сообщений в рамках одной партиции.

❗️ Самые главные преимущества Log-based-брокеров - это лог, хранимый на диске; возможность перемещать указатель (offset) в любое положение; высокие гарантии соблюдения строгого порядка обработки. Таким образом, есть история возникновения событий и возможность ее многократной обработки.

Типичные представители: Apache Kafka, Redpanda.

🟢 Queue-based-брокеры

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

За маршрутизацию сообщений отвечает брокер. Одну и ту же очередь может обслуживать любое количество обработчиков. Как только обработчик заканчивает обработку очередного сообщения, брокер передает ему новое. В общем случае порядок обработки не гарантируется, т.к. основная задача - побыстрей обработать очередь.

❗️ Самые главные преимущества Queue-based-брокеров - это простота и гибкость обмена сообщениями; адаптивность к вариативной вычислительной сложности обработки; отсутствие простоев обработчиков.

Типичные представители: AMQP/JMS-based - RabbitMQ, Apache ActiveMQ; MQTT-based - Eclipse Mosquitto, HiveMQ.

Итого

Log-based- и Queue-based-брокеры спроектированы для разных типов задач, о характере которых можно судить, посмотрев на главные преимущества этих брокеров. В дальнейшем я раскрою тему выбора более подробно.

#tech

Приём №4: Распараллеливание вычислений

События в топике ДОЛЖНЫ обрабатываться параллельно, ЕСЛИ не важен порядок их обработки.

Вот с такого простого и очевидного утверждения начинается долгая история. 😃

Когда мы говорим о распараллеливании, нужно помнить про условия обеспечения эффективности параллелизма. И тут я выделяю два условия.

1️⃣ Основное время уходит на полезную работу. Тут мы сводим к минимуму программные блокировки и ожидания результатов при вызове внешних компонентов. Избавляемся от необходимости в синхронизации потоков, минимизируем количество IPC, оптимизируем запросы к БД и т.п. Пожалуй, именно с выполнения этого условия и нужно начинать процесс повышения эффективности параллелизма.

2️⃣ Вычислительная сложность обработки одинакова для всех событий. В самом деле, выполнение этого условия дает шансы на то, что время обработки каждого события будет плюс-минус одинаковое. Это значит, что простои обработчиков будут сведены к минимуму, поскольку они будут начинать и закачивать работу примерно в одно и тоже время.

       ┌─> AAA ─┐
fork >─┼─> BBB ─┼─> join
       └─> CCC ─┘

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

       ┌─> AAAAAAAAA ─┐
fork >─┼─> BBBBB.... ─┼─> join
       └─> CCC...... ─┘

Хорошо, и что мне теперь делать с этой теорией?! Запомнить и переходить к практике. 😃 Ниже я рассмотрю как эта теория соотносится с Log-based- и Queue-based-брокерами, что может повлиять на выбор брокера или на пересмотр сценариев по работе с ними.

Данный пост поясняет тезисы моего доклада с конференции TeachLeadConf 2024.

#conf

Распараллеливание вычислений в Log-based-брокерах

Начало см. выше.

В контексте распараллеливания вычислений я выделяю две важных особенности Log-based-брокеров:

1️⃣ Уровень параллелизма зависит от количества партиций. Мы не можем создать обработчиков больше, чем количество партиций.

2️⃣ Неравномерная загрузка обработчиков, если время обработки сильно варьируется. В разные партиции могут попасть сообщения с разной вычислительной сложностью.

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

🕚 Увеличение числа партиций (сразу много или добавляем по мере возрастания нагрузки). Существует ряд недостатков данного решения, в том числе дополнительные накладные расходы на обслуживание партиций; увеличение времени балансировки; значительные сложности при сокращении числа партиций.

🕚 Параллельная обработка пачки сообщений в разных потоках одного процесса ОС. Иначе говоря, потребитель считывает N-сообщений и каждое обрабатывает в отдельном потоке. Когда заканчивается обработка всех N-сообщений, происходит смещение к следующей пачке. Недостатки - необходимость ожидания окончания обработки всей пачки сообщений. Подход подробно описан тут (VPN), имеет готовую реализацию. Более глобально эту проблему пытаются решить на уровне Apache Kafka в рамках KIP-932.

Вторая проблема куда более значительная для Log-based-брокеров, поскольку по замыслу они не предназначены для нагрузки подобного рода. Если от сообщения к сообщению время обработки варьируется существенно, то это может привести к ребалансировке. Один из потребителей может уйти в долгую обработку, перестав подавать признаки жизни, в результате чего брокер может счесть потребителя нерабочим и начать процесс перераспределения партиций. Это сложный и долгий процесс, который частично или полностью останавливает обработку событий топика.

В случае с Apache Kafka решить проблему можно "на глазок": установить более точные настройки для max.poll.records (сделать поменьше) и/или max.poll.interval.ms (сделать побольше). Или усложнить логику взаимодействия с брокером так, чтобы потребитель подавал брокеру признаки жизни, даже в случае долгой/зависшей обработки (см. методы pause/resume).

Иногда эту проблему удается решить частично с помощью приёма "Типизация событий". Например, предположим, что событием является запрос на формирование сложного финансового отчета. Если пользователь укажет слишком большой календарный период, придется анализировать слишком много данных, это увеличит время формирования отчета. Если пользователь задаст более точный фильтр, это ожидаемо сократит время обработки. Таким образом, на стороне отправителя можно сделать небольшую эвристику - типизацию отчётов, например, на "простые" ("быстрые") и "сложные" ("медленные"). Для каждого типа завести свой тип и топик. Обработчик каждого типа будет обслуживать очередь в своем темпе, со своими настройками.

#conf

Распараллеливание вычислений в Queue-based-брокерах

Начало см. выше.

Пожалуй, я начну с совета:

Для увеличения параллелизма МОЖНО отказаться от Log-based-брокера в пользу Queue-based, ЕСЛИ не важен порядок обработки событий, И ЕСЛИ не нужен лог событий.

Этот совет особенно ценен в случае, когда время обработки событий сильно варьируется, поскольку это та нагрузка, к которой Queue-based-брокеры особенно хорошо приспособлены. Как только обработчик заканчивает обработку очередного сообщения, брокер передает ему новое. Обработчики работают non-stop, исключая простои, увеличивая пропускную способность и по-максимуму утилизируя выделенные ресурсы.

Можно сделать мини-вывод, что Queue-based-брокеры отлично подходят:
🕚 для задач с малопредсказуемой продолжительностью выполнения;
🕚 когда гораздо важней как можно быстрей выполнить весь объем задач.

Примеры идеальных задач для Queue-based-брокеров:
🕚 задача формирование отчета по запросу-фильтру пользователя;
🕚 поиск и анализ ссылок в документе;
🕚 сборка мусора - удаление ненужных данных и т.п.

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

На этом эпопею с брокерами считаю законченной. 😃

#conf

Приём №5: Локальность данных

Пожалуй, это один из основных принципов обработки данных в распределенных системах. Самое простое определение звучит так: держите данные ближе к месту их обработки. Этот приём направлен на оптимизацию вычислений, чтобы основное время уходило на полезную работу. Такой подход особенно оправдан при частом и одновременном обращении к некоторой части данных.

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

Данные ДОЛЖНЫ находиться в месте их использования, ЕСЛИ они изменяются редко.

Существует множество способов реализации этого приёма, выбор зависит от решаемой задачи, доступного времени и средств. Примеры реализации:

🕚 Локальный (файловый) кэш/индекс редко меняющихся данных. Сюда же можно отнести алгоритм "Hash Join". В большинстве случаев значительно ускоряет обработку, но требует усилий по поддержанию кэша/индекса в актуальном состоянии.

🕚 Использование общей области памяти (shared memory) или общего диска. Также значительно ускоряет обработку, но в какой-то степени увеличивает связность между взаимодействующими компонентами, добавляет зависимость от технологии взаимодействия. "Читатель" знает, куда, что и как пишет "писатель", и наоборот. Помимо этого, взаимодействующие компоненты могут не ужиться на одной машине (разные требования к окружению, ресурсам, масштабированию и т.п.); общий диск может оказаться сетевым, что еще хуже скажется на производительности.

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

🕚 Модель хранения данных - это тоже способ локализации данных. Например, key-value, column-family, индексы, да даже файловая система. Мы выбираем ту модель, которая наиболее удобна для большинства сценариев приложения. И я думаю, что многие сталкивались с ситуацией, когда модель хранения не отвечает существующим требованиям. Это способствует появлению неуклюжей и запутанной логики в коде.

🕚 Использование денормализации данных или даже документно-ориентированных хранилищ (например, MongoDB). Если необходимые данные распределены по множеству таблиц, потребуются достаточные усилия, чтобы собрать их вместе. Это создаст нагрузку на дисковую и сетевую инфраструктуру, увеличит время обработки. С другой стороны, мы получим избыточность данных и, если мы будем использовать только малую часть большого документа, это может негативно отразиться на сценариях чтения и записи.

🕚 Использование локальной файловой системы для генерации отчета вместо того, чтобы генерировать его в оперативной памяти или сразу производить запись в BLOB-хранилище. Преимущества очевидны - минимальное потребление памяти, сокращение количества сетевых обращений. Недостатки - места на локальном диске может не хватить; приложение должно позаботиться об удалении временных файлов.

🕚 Алгоритм "Partitioned Hash Join" - партиционирование разных потоков данных по одному ключу, чтобы иметь возможность эффективно объединять потоки на стороне обработчика. Этот подход применим только в случае, когда партиции могут быть помещены в оперативную память.

Итого

❗️ Локализация данных позволяет добиться значительных или даже прорывных успехов в сокращении времени обработки. Это очень сильный приём, но в этом же кроется и его слабость, т.к. за мощную оптимизацию приходится платить. И если на сегодняшний день эта цена может показаться не такой большой, то завтра, когда поменяются требования к системе, это может стать серьезным препятствием, чтобы двигаться дальше.

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

Данный пост поясняет тезисы моего доклада с конференции TeachLeadConf 2024.

#conf

Прошло полтора года, как я участвую в проекте "Виртуальная лаборатория: информатика и программирование". Это учебный модуль информационного портала "Московской Электронной Школы" (МЭШ), где ученики могут проходить курсы по информатике и программированию, выполнять различные тематические задания, в том числе решать задачи по программированию. Нам присылают код, который мы должны выполнить многократно, используя набор тестов предопределенный автором задачи. И каким бы подозрительным не был код, выполнить мы его обязаны в любом случае. Таково функциональное требование заказчика.

На проект я зашел в тот момент, когда нам объявили, что через три месяца на базе нашего модуля необходимо начать проводить олимпиады по программированию, а нагрузка в связи с этим возрастет в несколько десятков раз. То, с чем пришлось столкнуться, я рассказывал на UWDC 2024, а уже после этого я подготовил более проработанный доклад на TeachLeadConf 2024.

Я намеренно обходил моменты, связанные с особенностью прикладной области этого проекта. Не каждому интересно то, как мы компилируем и исполняем код, который нам прислали школьники. 👨🏻‍🎓 Однако, несмотря на кажущуюся простоту, эта задача, действительно, оказалась нелегкой. Что нам только не присылают, как только не пытаются нас "сломать" и "положить". И некоторым это удавалось сделать, за что пытливым умам можно выразить отдельный респект. 🔥 Однако за последний год это удалось сделать только один раз, после чего мы исправили уязвимость. 😃

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

А у вас была необходимость в запуске подозрительного кода? Подозреваю, что для QA любой код выглядит подозрительно. 😃

#untrusted_code #summary

Фэйл с RabbitMQ и Kubernetes API (продолжение)

Во время обработки происходит обращение к Kubernetes API (такова специфика нашей прикладной задачи). И вот на этом шаге всё и зависало, поскольку не был установлен таймаут ожидания результатов вызова. 🙉 Дело в том, что для вызова Kubernetes API мы используем fabric8io/kubernetes-client, у которого, как выяснилось, по умолчанию был установлен некоторый Rate Limit. 🙊 Превышение этого лимита приводило к зависанию при обращении к Kubernetes API. В результате проблема была решена добавлением таймаута ожидания результатов, подбором и установкой подходящих значений для Rate Limit, выносом этих настроек в конфигурационный файл приложения.

По итогу я был рад не столько тому, что нашёл и исправил проблему, сколько тому, что моё архитектурное решение было правильным, а возникшая ситуация подтвердила это ещё раз. В Kafka всё работало, и проблема не проявлялась только потому, что она не приспособлена к ситуациям, когда время обработки может варьироваться. В итоге пропускная способность системы на базе Kafka была ниже, мы никогда не упирались в Rate Limit для Kubernetes API и даже не знали о существовании этой проблемы. С переходом на RabbitMQ пропускная способность увеличилась, проблема материализовалась, опустившись на тот уровень, где она всегда и была, а мы стали упираться в Rate Limit.

❗️ Из этой истории можно извлечь, как минимум, два урока.

1️⃣ Если в коде приложения есть синхронные обращения к сторонним службам, то всегда нужно контролировать время ожидания (timeout). Также не забывать и про другие шаблоны устойчивости, а именно: не злоупотреблять шаблоном "Повтор" (Retry), в нужные моменты использовать "Предохранитель" (Circuit Breaker), и понимать, что "Ограничитель скорости" (Rate Limiter) может быть установлен с двух сторон (на клиенте и сервере). Однажды я не уделил этому должного внимания, спровоцировав неприятности в дальнейшем.

2️⃣ Не нужно сомневаться в том, как на концептуальном уровне работают инструменты, в частности брокеры. Если что-то идет не так, проблема может быть в развертывании, но, скорей всего, в коде приложения. Нужно убедиться, что настройки клиентского драйвера выполнены в соответствии с рекомендациями; не осталось ни одной настройки по умолчанию, в которых у вас есть сомнения. Я начал поиски проблемы не с того и поплатился временем.

Делитесь своими фэйлами, будем учиться на ошибках друг друга. 😃

Надёжность, прочность, устойчивость

При обсуждении свойств программной системы мы часто оперируем такими терминами, как надежность, прочность и устойчивость, не проводя четких различий между ними. Однако, при формулировании требований эти понятия следует рассматривать отдельно. Если вы думаете, что это не столь важно, то инженеры NASA, которые занимаются проектированием систем жизнеобеспечения, так не считают. 🚀 Как мне кажется, данный опыт вполне применим и при проектировании программных систем.

1️⃣ Надёжность (Reliability) - вероятность того, что система не выйдет из строя в течении определенного периода времени и при определенных условиях эксплуатации. Иначе говоря, в заданных условиях эксплуатации система стабильна и отвечает проектным требованиям.

2️⃣ Прочность (Robustness) - способность системы работать удовлетворительно или даже в соответствии с заявленными требованиями, несмотря на воздействия, выходящие за рамки предопределенных условий эксплуатации, но при этом являющимися возможными. Прочность рассматривается в контексте предвидимых проблем.

3️⃣ Устойчивость (Resilience) - способность системы быстро восстанавливаться или адаптироваться к непредвиденным происшествиям или изменениям, которые нарушают базовые проектные предположения. Устойчивость рассматривается в контексте непредвиденных или маловероятных проблем.

Таким образом, надежность, прочность и устойчивость определяют поведение системы на трех уровнях сложности условий эксплуатации. Сначала в заданной среде; затем в среде с вероятными проблемами; наконец, во враждебной, деструктивной среде.

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

Всегда ли необходимо заботиться об устойчивости? Зависит от рисков, которые несет бизнес при возникновении таких ситуаций. Последствия могут включать временны́е, репутационные, финансовые риски или даже создавать угрозу жизни людей. С одной стороны, совсем игнорировать уровень непредвиденных ошибок, упрощая модель системы, конечно, было бы глупо. С другой, попытка учесть всевозможные ситуации для большинства программных систем, является неоправданным усложнением.

К посту прикрепляю оригинал статьи "Going Beyond Reliability to Robustness and Resilience in Space Life Support Systems", Harry W. Jones, 2021. ⬇️

По итогу хочу всем пожелать в Новом 2025 году надежности, прочности и устойчивости! А если будут возникать непредвиденные ситуации, то пусть они будут только приятными. 🎉🎄☃️

#arch

Наконец, могу поделиться ссылкой на видеозапись 📱 моего доклада "Кратно ускоряем потоки данных. Практичные архитектурные приёмы", тезисы которого я анонсировал ранее.

P.s. К сожалению, пока только YouTube. Позже обещали выложить в RuTube и VK.

#conf

Борьба с зомби-процессами

Ранее я обещал, что постараюсь раскрыть тему безопасного исполнения ненадежного кода. Сегодня будет первая статья из цикла "Как безопасно исполнять ненадежный код" #untrusted_code Надеюсь, что будет интересно. 😃

В Linux каждый процесс знает о своих потомках и должен самостоятельно о них заботиться. Например, если код приложения создает дочерний процесс вызовом системной функции fork(), то он должен дождаться его завершения через вызов функции waitpid(). Вполне логично, ведь "родитель" должен заботиться о своих детях. :)

int pid = fork();

if (pid > 0) {
    // Parent logic
    waitpid(pid);
} else {
    // Children logic
}

Когда процесс завершается, он переходит в статус "зомби" 🧟 (zombie, defunct), а ОС формирует сигнал SIGCHLD для всех процессов, которые ожидали его завершения с помощью функции waitpid(). Вместе с этим waitpid() заканчивает работу и возвращает управление, а зомби уничтожается - удаляется из системных таблиц ядра ОС. Если никто не ждет дочерний процесс, он продолжает бесконечно висеть в статусе "зомби", находясь на учете у ОС.

В общем случае зомби-процессы сигнализируют об ошибках ПО, для этого их и придумали. В справках пишут, что зомби-процессы не потребляют ресурсы (RAM/CPU), но, находясь на учете у ОС, расходуют PIDs. Таким образом, рано или поздно может произойти нехватка PIDs. Это значит, что вы не сможете запустить новый процесс или поток! ☠️

Самый простой способ создать зомби - убить родительский процесс раньше дочернего. В этом случае ОС назначает сироте нового родителя - опекуна. По дизайну Linux им становится процесс с PID=1, который называют init-процессом. В обязанности init-процесса в том числе входит грязная работа - делать то, что не сделали безответственные родители - дожидаться завершения "зомби" и таким образом удалять их из системных таблиц ядра ОС.

Как правило, в большинстве Docker-образов init-процессом является sh. Так повелось, что sh специально "игнорирует" наличие зомби и не освобождает PIDs. Это сделано для того, чтобы системные администраторы могли увидеть проблему, например, выполнив команду ps, в выводе которой зомби-процессы отображаются как <defunct>. Таким образом, зомби будут висеть в системе бесконечно, до рестарта системы. Игнорирование этой проблемы ведет к утечке PIDs, которая при наличии в ОС лимита на их количество приводит к невозможности запуска новых процессов и потоков. Следовательно, к серьезным проблемам функционирования сервера.

Кстати, на базе этой особенности построена очень простая, но крайне агрессивная атака, называемая Fork bomb (по имени системной функции). Вот вариант ее реализации на C++ - процесс клонирует сам себя в бесконечном цикле:

#include <unistd.h>
int main() {
    while (1) fork();
}

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

Но что, если мы знаем, что запускаем ненадежный код? Например, реализация какого-нибудь GitLab делает это постоянно, выполняя CI на базе наших скриптов. Для GitLab пользовательские скрипты являются ненадежным кодом, и такие процессы могут быть завершены некорректно или принудительно. В таком приложении наличие зомби-процессов в системе - это норма. Тогда как бороться с зомби и утечкой PIDs?

❗️ Решение заключается в подмене init-процесс на такой, который будет удалять зомби сразу, как только они появляются. Делать ничего не нужно, т.к. всё уже сделано за нас. ⚡️ Проект называется tini. Использовать легко: в Dockerfile нужно указать tini в качестве ENTRYPOINT.

В дополнение могу порекомендовать книгу "Linux System Programming" (Robert Love). В ней очень кратко и понятно описывается внутреннее устройство Linux и то, как правильно работать с функциями ОС.

#tech #dev #devops #untrusted_code

Принцип прочности

В продолжении разговора о надежности, прочности и устойчивости. Недавно наткнулся на принцип, о существовании которого не знал, но много раз применял его на практике. Точней сказать, я не знал, что это целый принцип. 😃

Представляю вашему вниманию "Принцип прочности" (Robustness principle), он же "Закон Постела" (Postel's law). Джон Постел - один из основных соавторов современных сетевых протоколов. В ранней спецификации TCP он сформулировал этот принцип так:

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

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

1️⃣ Интеграция со сторонними системами. С одной стороны, вызывая внешний сервис, лучше четко следовать его спецификации. В случае отклонения от спецификации в лучшем случае можно получить ошибку, в худшем - неоднозначный результат. Например, если не передали значение какого-то атрибута, то внешний сервис может установить для этого атрибута значение по умолчанию или каким-то неочевидным образом изменить логику обработки запроса. С другой стороны, нет никакой надежды, что внешние сервисы будут пользоваться нашим, четко следуя нашей спецификации. В связи с этим можно смягчить требования к формату входящих запросов. Например, используя значения по умолчанию для отсутствующих атрибутов или игнорируя неизвестные атрибуты. Аналогично, вызывая внешний сервис и получая в ответе больше атрибутов, чем ожидалось, можно игнорировать всё ненужное.

2️⃣ Расширение функциональности. Например, случай расширения модели данных. Очевидно, что клиенты, рассчитывающие на старую версию сервиса, не будут передавать новых значений. Также очевидно, что при переходе на новую версию системы без ее остановки в один момент времени будут существовать и старые, и новые клиенты. Если недостающие данные можно заполнить какими-то значениями по умолчанию, и это не приведет к негативным последствиям, такое решение может быть хорошим компромиссом, как минимум на время обновления системы.

❗️ Пожалуй, главный недостаток рассматриваемого подхода в том, что он может долго скрывать неблагонадежных участников взаимодействия. Если кто-то отклоняется от спецификации, а кто-то этому потворствует, умалчивая подобные факты, с течением времени может сформироваться целый пласт проблем. Критики также отмечают, что это также может приводить к проблемам безопасности в системе.

А как вы использовали этот подход в своей практике? Насколько этот опыт был позитивным или негативным? 😉

#arch

Что не так с PostgreSQL

Если вы никогда не задумывались о том, что не так с PostgreSQL, скорей всего, у вас всё так и можно спокойно жить дальше. Но это не точно. 😃

PostgreSQL - это высокопроизводительная монолитная реляционная база данных, предоставляющая гарантии ACID при выполнении транзакций. PostgreSQL - отличный инструмент для подавляющего большинства задач, имеет обширный функционал, инструментарий и множество расширений. Это настолько проверенное и универсальное решение, что многие выбирают PostgreSQL почти не глядя. Однако крайне не рекомендую делать выбор вслепую, поэтому предлагаю рассмотреть основные и подтвержденные проблемы PostgreSQL, а также возможные способы их решения.

🔴 Отсутствие автоматического горизонтального масштабирования. Из коробки такой функциональности нет; шардирование реализовано как частный случай партиционирования; вся ответственность за распределение данных ложится на плечи разработчиков. Расширение Citus (GitHub) частично решает проблему с масштабированием, однако нужно понимать, что оно не делает из PostgreSQL полноценную распределенную реляционную базу с гарантиями ACID при выполнении транзакций. Иначе говоря, Citus обеспечивает только согласованность в конечном счёте, следовательно, в общем случае не подходит для OLTP-задач; либо подходит, но в рамках одного шарда; и хорошо подходит для "складов данных" (data warehouses).

🔴 Низкие гарантии отказоустойчивости. При выходе из строя мастера гарантирован простой в работе системы и риск потери согласованности данных. Очень часто для построения высокодоступного (HA, High Availability) кластера PostgreSQL используют Patroni (GitHub). Экземпляры Patroni работают как sidecars для узлов PostgreSQL, которые координируют свои действия через указанное распределенное хранилище конфигураций (etcd, ZooKeeper и т.п.). Patroni отслеживает доступность узлов кластера, управляет их работой и конфигурацией, определяет узел мастера, производит выбор нового мастера из существующих реплик в случае недоступности старого.

🔴 Простои при обновлении на новую версию. Частично решить проблему может логическая репликация, но она имеет ряд ограничений, в том числе не умеет переносить изменения схемы данных (DDL) и сразу же останавливается, если такое вдруг произойдет. Также нужно иметь в виду, что тот же Patroni использует только физическую репликацию.

🔴 Раздувание базы данных (bloat). Со временем файлы данных "раздуваются", занимая больше места на диске, чем могли бы. Эта проблема присуща не только PostgreSQL и связана с версионированием изменений данных. Для новых изменений резервируется дополнительное пространство на диске, а место, занимаемое старыми и неактуальными версиями, не освобождается. Для минимизации последствий рекомендуется контролировать уровень bloat и настроить автоматическую очистку. В крайних случаях можно использовать команды VACUUM, CLUSTER или REINDEX, но они создают блокировки, что может сказаться на работоспособности приложения. Если блокировки недопустимы, можно посмотреть в сторону расширений типа pg_repack.

Подводя небольшой итог, можно выделить случаи, когда PostgreSQL не подойдет:

✖️ Предвидится большой размер базы данных

✖️ Необходимо горизонтальное масштабирование

✖️ Необходимы высокие гарантии отказоустойчивости

✖️ Недопустимы простои в работе базы данных

Если всё вышеперечисленное к вам не относится или не является серьезной проблемой, тогда вы вне зоны риска и можно продолжать использовать PostgreSQL или рассматривать его в качестве кандидата для выбора.

❗️ Что важно сказать в конце. Никакие теоретические выкладки, обзоры, анализы или бенчмарки не учитывают ваши потребности и возможности. Поэтому при выборе хранилища нужно принимать во внимание не только ту информацию, которая находится в общем доступе, но и проводить свои собственные эксперименты, тесты и расчеты, оценивать возможные риски и заранее искать и отрабатывать варианты их устранения.

#db #devops

ACID, AID или AD (1/3)

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

Самое главное преимущество транзакций - это упрощение программной модели приложения, осуществляющего доступ к данным. Транзакции позволяют представить последовательность операций чтения и записи как одну изолированную логическую операцию. Концептуально это значит, что все операции должны быть выполнены как одна по принципу "всё или ничего". Либо все действия выполняются успешно, либо производится отмена произведённых изменений. В первом случае речь про фиксацию изменений (commit), во втором - про откат (rollback, abort).

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

В чём же заключаются гарантии сохранности? Я думаю, что многие знают акроним ACID, тем не менее предлагаю пройтись по этой теме еще раз и посмотреть на неё под другим углом. 🔭

#arch #db

ACID, AID или AD (2/3)

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

🕚 Atomicity (атомарность). Все операции транзакции представляют собой одну логическую операцию, которая должна быть выполнена только успешно, а в случае любой ошибки все произведенные действия должны быть отменены (abort). Мартин Клеппманн в своей знаменитой книге Designing Data-Intensive Application сетует на перегруженность термина "атомарность" и говорит, что термин "отменяемость" (abortability) был бы более точным.

🕚 Consistency (согласованность). Если данные находились в согласованном состоянии до выполнения транзакции, они должны остаться согласованными и после неё. Однако что считать согласованностью? Да, база данных может предоставлять некоторые механизмы обеспечения согласованности в виде ограничений (constraints), например, контроль внешних ключей, уникальности, полноты данных, их формата, размера и т.п. Однако, только приложение может определить, какие данные корректны, а какие нет, а база данных отвечает лишь за их сохранение. Кто вас остановит от записи некорректных данных в базу?! Таким образом, здесь можно говорить лишь о согласованности файлов базы данных, поскольку применяются изменения только успешных транзакций. При таком подходе я бы предложил назвать это свойство целостностью. Клеппманн также указывает, что исторически буква C была добавлена лишь для создания акронима, и это не то свойство, которое может гарантировать база.

🕚 Isolation (изолированность). Параллельно выполняемые транзакции изолированы друг от друга таким образом, что результат их выполнения должен быть идентичен тому, который получился бы при их последовательном (serial) выполнении. Однако на практике такой уровень изоляции (serializable) используется крайне редко, поскольку может оказывать негативное влияние на производительность приложения. Более того, разные базы данных по-разному реализуют это свойство, ослабляя в некоторых случаях уровень изоляции в угоду производительности.

🕚 Durability (долговечность). Если транзакция завершилась успешно, все произведенные изменения не должны быть забыты. В монолитных базах данных долговечность реализуется записью данных на постоянный носитель информации (HDD/SSD); в распределенных - репликацией, то есть копированием данных на несколько узлов - реплик. Прежде, чем транзакция завершится успешно, база данных должна дождаться успешной записи всех изменений на диск или окончания репликации. Даже несмотря на это, нетрудно догадаться, что некоторые вещи не зависят от базы данных и идеальной долговечности не существует. Отключение питания, нарушение температурного режима, аппаратные сбои, деградация секторов накопителя, ошибки на уровне файловой системы - всё это не редкость. Наряду с этим, использование асинхронной репликации может стать причиной потери изменений. Таким образом, никаких гарантий нет, есть только техники снижения рисков: репликация и резервное копирование.

В итоге в лучшем случае транзакции могут обеспечить лишь три свойства: AID, т.к. согласованность может быть обеспечена только на прикладном уровне. А с учетом того, что чаще всего используются ослабленные уровни изоляции, остаются лишь два свойства: AD, причем со множеством уже сделанных оговорок. 🤷🏻‍♂️😃

Многие так привыкли к абсолюту ACID, что подобные выводы могут показаться неожиданными. 🦄 Причем они справедливы для любой реализации транзакций. Разница лишь в том, что для транзакционных (реляционных) баз данных это не совсем очевидно, а для распределенных систем - это норма. Например, процесс согласования данных на основе распределенных транзакций (2PC) или повествований (Saga) изначально подразумевает отсутствие изоляции и предполагает применение контрмер, которые нивелируют этот недостаток.

#arch #db

ACID, AID или AD (3/3)

Поддержка ACID на уровне базы данных, безусловно, упрощает программную модель приложения, сдвигая акцент в сторону прикладной логики. За многие годы использования транзакционных (монолитных) баз они доказали свою надежность. Используя принцип KISS, мы должны следовать этим путём, если он для нас открыт, и только в противном случае искать более сложные решения. Однако мы должны помнить, что согласованность и изоляция - это то, о чём разработчик должен заботиться не меньше, чем база данных! К сожалению, иногда вижу, что про это забывают, прикрывая неудачные архитектурные решения транзакциями и ссылаясь на незыблемость реляционных баз. Из-за этого ошибки по причине нарушения согласованности и изоляции в монолитных системах встречаются не реже, чем в распределенных.

Подводя итоги, можно сказать, что ACID-транзакции - это лишь один из инструментов, используемый в архитектурном решении. Где-то он проще, поскольку поддерживается используемой базой данных, а где-то сложней, как например, в распределенных системах или при гетерогенном хранении данных. В последнем случае для упрощения прикладного кода мы используем специализированные фреймворки (для управления распределенными транзакциями или повествованиями).

Переходя от инструментов к архитектурным методам, в контексте согласованности и изоляции очень выгодную позицию занимает объектный подход и DDD, в котором предлагается концепция ограниченных контекстов, агрегата и необходимость соблюдения инвариантов. Похожих целей пытаются добиться при использовании шаблона Event Sourcing. Иначе говоря, основная цель - сделать так, чтобы программная модель обеспечивала жесткие рамки, направляющие разработчика писать корректный код. Пожалуй, последнее - это то, к чему мы все должны стремиться. 😜

***

Надеюсь, что было интересно и не скучно. 😃 А у вас есть интересные истории, когда даже транзакции не спасали от страшного? Или успешные истории, как и где можно жить без ACID? 🪐👾

#arch #db

Хочешь рисуй, не хочешь - вызывай REST

Решил завести нерегулярную рубрику "Утилиты" #tools, в которой буду делиться своими находками удобных и полезных инструментов. Если сталкивались с чем-то похожим, делитесь своими подборками в комментариях. 😉👇

⚔️ Excalidraw

Давно хотел найти простой и удобный векторный редактор, в котором можно делать неформальные диаграммы со стилизацией рисования от руки. Когда я набрел на Excalidraw, я был в восторге. Прекрасный инструмент с открытым исходным кодом, который превзошел все мои ожидания. Есть публичная библиотека готовых объектов; есть горячие клавиши; есть возможность сохранения в файл, экспорта в PNG/SVG. Наконец, есть возможность делиться ссылкой и рисовать что-то совместно - отличное средство во время переговоров, учитывая что по итогу у вас будет красивая и понятная картинка, которую не стыдно сохранить для истории.

🦬 httpYac

Иногда, когда я запускаю Postman и жду, жду, жду... Думаю, что вы меня поняли. 😄 В эти моменты у меня возникает дикое желание найти ему простую замену, особенно когда не требуется вся его функциональность. В IntelliJ IDEA есть то, что мне бы идеально подошло для большинства случаев - HTTP Client, но он доступен только в Ultimate-редакции. В итоге я нашел прекрасную альтернативу в виде плагина для VSCode. Этот инструмент тоже с открытым исходным кодом, делает то, что мне нужно, предоставляет возможность шаблонизации URL и тела запроса. Пока я только обкатываю этого яка, но, судя по документации он может гораздо больше.

#tools