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

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

Calvin Protocol для распределенных транзакций

Многие знают про протокол двухфазной фиксации (2PC), но мало кто слышал про протокол Calvin. Честно говоря, до недавних пор я тоже относился к этому меньшинству, поэтому решил поделиться своей находкой с вами. Однако для начала предлагаю освежить память. 🥸😃

ℹ️ Распределенная транзакция - это транзакция, затрагивающая несколько ресурсов распределенной системы. Как и обычные транзакции в монолитных базах данных, распределенные действуют по принципу "всё или ничего". Тематика достаточно стара, хорошо проработана, отражена в стандарте X/Open XA (1991), который реализован на многих платформах. Таким образом, концепция распределенных транзакций появилась задолго до появления шумихи вокруг микросервисов, но сейчас особенно актуальна и рассматривается как возможный инструмент обеспечения согласованности данных.

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

В 2012 была опубликована статья "Calvin: Fast Distributed Transactions for Partitioned Database Systems" с описанием нового подхода к реализации распределенных транзакций. В его основу положена идея формирования журнала транзакций и подачи его на вход исполнителю, вместо того чтобы позволить ему самому формировать журнал. (Под исполнителем понимается какой-то ресурс, например, реплика базы данных.) Такой подход позволяет уменьшить число сетевых взаимодействий, обеспечив высокую скорость выполнения распределенных транзакций.

😀 Подход был назван не в честь производителя трусов, как можно было бы подумать изначально, а в честь французского богослова Жана Кальвина (Jean Calvin), считавшего, что все события человеческой жизни предопределены Богом. Ведь если журнал сформирован заранее, то и результат исполнения транзакций из этого журнала предопределён.

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

Таким образом, можно обозначить следующие особенности подхода:

1️⃣ Один и тот же журнал можно подавать на вход любому количеству исполнителей.

2️⃣ Если исполнитель записал транзакцию в свой журнал, значит, эта транзакция выполнена.

3️⃣ Если одна транзакция останавливается в ожидании доступа к диску, все остальные транзакции тоже ждут!

🔥 Несомненным достоинством Calvin является практически неограниченная возможность горизонтального масштабирования с сохранением ACID-гарантий. Причём гарантии обеспечиваются даже в случаях, когда транзакция охватывает несколько распределенных партиций.

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

Резонный вопрос: есть ли практические реализации и опыт использования этого подхода? Да, есть. Например, разработчики Apache Cassandra разрабатывают совместимый продукт под названием Accord. Он должен позволить выполнять запросы к Cassandra, объединяя их в ACID-транзакции. Однако гораздо бо́льших успехов добились разработчики YDB, о чём можно почитать в их официальном блоге.

P.s. Жду от вас историй про опыт работы с распределёнными транзакциями или YDB. 😉👇

#db

Удаление конфиденциальных данных

Бывает так, что встречаешь описание интересного подхода или алгоритма, а потом про него забываешь, так как теория не была подкреплена практикой или прошло очень много времени. И вот когда наступает момент, где можно блеснуть своими знаниями, приходится тратить время, чтобы вспомнить детали. 😃 В очередной раз, когда я поймал себя на подобной мысли, я решил, что было бы неплохо делиться подобными находками. 🤔 #tip

Сегодня расскажу о способе моментального удаления конфиденциальных данных.

Контекст

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

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

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

🕚 Архитектурные ограничения. Чаще всего являются прямым следствием бизнес-требований. Например, разработчики решили, что для реализации большей части требований к системе идеально подходит шаблон Event Sourcing.

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

🕚 Сложность физического удаления. Для многих баз данных операции UPDATE и DELETE проблематичны. Например, для MariaDB удаление - это настолько нетривиальная задача, что ее разработчики подготовили целую инструкцию - "Big DELETEs". Аналогичные проблемы имеются и у MySQL. В PostgreSQL частые удаления могут быть одной из причин раздувания базы. У Cassandra удаление может приводить к большой загрузке узлов во время компоновки. В общем, большинство баз спроектировано, чтобы хранить данные, а не удалять. 😃

Проблема

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

Решение

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

Плюсы

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

Минусы

Данные продолжают занимать место на диске. Возникает необходимость в шифровании/дешифровании при каждой записи/чтении.

***

P.s. Сталкивались ли вы с подобной проблемой на практике и как решали? 😉 Однажды наблюдал ситуацию утечки данных, и выяснилось, что база, которая в общем случае деперсонифицирована, в некоторых атрибутах содержала персональную информацию в открытом виде. Эти данные попали туда в ходе интеграции с другими системами, разработчики которой не задумались о необходимости ее шифрования или поиска более подходящего места для ее хранения.

Проблемы изоляции транзакций (1/3)

Меня все никак не отпускает тема транзакций и изоляции. 😃 Сегодняшний пост будет подводкой к двум последующим. Возможно, будет немного "душно", но попрошу потерпеть. 😄

〰️〰️〰️

Конкурентный доступ к данным - одна из основных проблем при реализации изоляции транзакций. Способ решения этой проблемы определяет ключевые характеристики базы данных, на которые мы опираемся при выборе подходящего хранилища для своих проектов. И так повелось, что со времен изобретения SQL-стандарта так и не появилось однозначного определения "уровней изоляции транзакций", благодаря чему у каждой базы данных своё представление относительно этого вопроса. А разбираться с этим многообразием приходится нам - пользователям этих продуктов. 🤷🏻‍♂️

Если посмотреть на определение ACID, то оно не предполагает какой-либо вариативности относительно изоляции транзакций. Тем не менее, реализация таких жестких требований напрямую отражается на пропускной способности. Вследствие этого в SQL-стандарте имеется термин "уровень изоляции транзакции", предполагающий "компромисс", на который может пойти разработчик в случае, если ему потребуется большая пропускная способность. Иначе говоря, нам предлагают улучшить производительность приложения за счет корректности данных, с которыми оно работает. 😬 Ясно, что на подобный компромисс нужно идти осознанно, понимая, что именно может пойти не так при выборе определенного уровня изоляции и устраивает ли нас это.

SQL-стандарт определяет всего три феномена (phenomena), т.е. три типа нежелательных последствий, возможных при снижении уровня изоляции: грязное чтение (dirty read), неповторяющееся чтение (non-repeatable read) и фантом (phantom). Эта слабая категоризация послужила причиной вольных трактовок при реализации уровней изоляции. Вскоре этот момент был подвержен критике, и список возможных последствий был расширен и конкретизирован путем ввода нового понятия - аномалия (anomaly). Аномалии конкретизируют действия, которые могут привести к феномену. Существует замечательный исследовательский проект Hermitage, в котором определена современная классификация аномалий и в разрезе них приведено сравнение одних и тех же уровней изоляции в разных популярных базах данных (Oracle, PostgreSQL, MySQL и др.).

В качестве иллюстрации можно рассмотреть феномен неповторяющегося чтения. Транзакция T1 делает два последовательных чтения значения x: сначала считывает значение 10, затем 20. Так происходит, потому что значение x успели поменять в параллельно выполняющейся транзакции T2.

T1: r[x=10].........r[x=20].
T2: ........w[x=20].........

Краткая запись этого феномена выглядит так: r1[x=10],w2[x=20],r1[x=20]. Данный феномен возможен, например, в режиме Read Committed. Аномалия для этого режима изоляции выглядит так: r1[x=10],w2[x=20],c2,r1[x=20] (т.е. после записи вторая транзакция фиксируется - c2). Примерно в таком стиле происходит формализация аномалий и их тестирование в разных базах данных.

#dev #db

Проблемы изоляции транзакций (2/3)

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

Рассмотрим классические уровни изоляции, которые есть в большинстве баз. 🧐

⭐️ Read Committed. Исключает грязное чтение и запись, т.е. транзакция может читать и изменять только зафиксированные изменения. Ключевой момент в том, что учитываются даже те изменения, которые были зафиксированы во время выполнения текущей транзакции. Обычно на уровне реализации грязную запись исключают за счет использования программных блокировок на уровне редактируемой строки (row-level lock); а грязное чтение - за счет хранения двух версий значения записи: последнее зафиксированное и еще не зафиксированное. Такой уровень изоляции установлен по умолчанию в PostgreSQL, MS SQL и Oracle. Допускает неповторяющееся чтение, потерю изменений (перезапись), искажение чтения/записи (read/write skew).

⭐️⭐️ Repeatable Read. Транзакция может читать только те изменения, которые были зафиксированы до ее начала. Обычно на уровне реализации грязную запись исключают за счет использования программных блокировок на уровне редактируемой строки (row-level lock); а грязное чтение - за счет хранения нескольких версий значения записи - алгоритм MVCC (Multi-Version Concurrency Control). Такой уровень изоляции установлен по умолчанию в MySQL и MariaDB. Допускает искажение чтения/записи (read/write skew), но в MySQL и MariaDB даже потерю изменений (перезапись). Идеально подходит для создания бэкапов или выполнения долгих read-only транзакций (например, сложные аналитические запросы).

⭐️⭐️⭐️ Serializable. Гарантирует, что даже при параллельном исполнении транзакций результат будет точно таким же, как если бы они исполнялись последовательно. Это определение полностью совпадает с определением изоляции в ACID. Позже этот уровень изоляции Daniel Abadi - один из соавторов протокола Calvin - назвал "идеальной изоляцией" (perfect isolation). Такой уровень изоляции установлен по умолчанию в CockroachDB и YDB. По определению он не должен допускать аномалий. (Примечательно, что в Oracle этот уровень изоляции на самом деле соответствует Repeatable Read.)

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

Например, последовательное выполнение трех транзакций w1[x=1],w2[x=2],w3[x=3] может закончиться результатом x=2, поскольку реплика переупорядочила транзакции и в реальности выполнила w1,w3,w2. Такой исход вполне возможен, например, из-за рассинхронизации часов ⏰ на репликах в мультимастер-системах. Причем технически подобный исход будет считаться корректным, т.к. формальные требования упорядоченности транзакций (serializability) не нарушаются.

Решая эти проблемы, разработчики одних распределенных баз данных предпочитают скрыть от пользователя все эти сложности и особенности за привычными уровнями изоляции (CockroachDB, YugabyteDB, YDB); разработчики других, наоборот, изобретают свою классификацию уровней (CosmosDB), предоставляя максимальную гибкость в использовании.

#dev #db

Проблемы изоляции транзакций (3/3)

Надеюсь, что у меня получилось сформировать более целостную картину относительно уровней изоляции транзакций. 😉

Попытаюсь подвести итоги.

1️⃣ Выбирая уровень изоляции, помним про аномалии, оцениваем возможные риски и способы их минимизации.

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

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

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

5️⃣ Помним, что базы данных гарантируют техническую целостность данных, но не их согласованность с точки зрения бизнеса. Однако первое может значительно упростить реализацию второго.

🗂 Пока готовил этот пост, открыл для себя проект Jepsen. Это фреймворк для тестирования распределенных систем на предмет согласованности и корректности работы в условиях сбоев. Инструмент является стандартом де-факто для проверки многих популярных распределённых систем и баз данных. Интересно, насколько реально/удобно использовать этот инструмент для тестирования прикладных проектов... 🤔

〰️〰️〰️

Согласитесь, что жить с таким грузом очень тяжело! 😄 Поэтому в следующий раз я планирую рассмотреть подходы и техники обеспечения согласованности данных с учетом всего вышесказанного. А пока предлагаю делиться своими феноменами и аномалиями. 😉👇

#dev #db

Конкурентный доступ к данным (1/2)

Конкурентный доступ к данным — это драйвер 🚀 всего того, что делается во имя изоляции транзакций. Конечно, речь о транзакциях, которые модифицируют данные (read/write, write/write), поскольку именно в этом случае возникают все те аномалии, о которых шла речь ранее.

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

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

2️⃣ Чаще всего прикладные сценарии реализуются по схеме "read-modify-write": чтение данных из базы, их анализ и модификация, запись данных в базу. Такая схема предполагает, как минимум, два обращения к хранилищу (read/write), которые разнесены по времени.

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

Техники снижения вероятности возникновения конфликтующих изменений:

⭐️ Коммутативные операции. Изменение порядка выполнения транзакций не меняет итоговый результат. Например, увеличение счетчика.

⭐️ Атомарные операции. Все действия с данными выполняются с помощью одной операции, в рамках одного обращения к базе, которая создает эксклюзивную блокировку, исключая одновременный доступ к данным. Пример атомарной операции — SQL-оператор UPDATE. Метод работает идеально, но только в самых простых случаях.

⭐️ Переупорядочивание операций. Производится перестановка шагов алгоритма так, что возникновение конфликта становится невозможным или легко детектируемым. Например, вместо "если не существует, то создать" (SELECT/INSERT) делается "создать, но если появился дубликат, тогда откатить создание" (INSERT/SELECT/ROLLBACK).

⭐️ Хранимые процедуры. Все необходимые действия производятся на стороне базы данных, следовательно, исключаются дополнительные сетевые издержки на взаимодействие между приложением и базой. Чем короче транзакции, тем меньше шансов, что они будут конфликтовать.

#dev #db

Конкурентный доступ к данным (2/2)

Техники исключения одновременных изменений:

☄️ Явная/пессимистичная блокировка. Данные блокируются до начала их изменения. Пример — SQL-оператор SELECT FOR UPDATE с указанием редактируемых строк в условии WHERE. Метод работает хорошо, но есть шанс заблокировать больше или меньше, чем нужно. Большая блокировка — низкая пропускная способность; недостаточная - нарушение изоляции.

☄️ Оптимистичная блокировка. Наличие конфликта доступа к данным производится непосредственно перед или вместе с записью в базу. Например, объект дополняется свойством version, которое увеличивается на единицу при каждом редактировании; соответственно, в момент записи ожидается, что в базе значение version меньше — более старая версия. Метод работает хорошо в условиях низкой конкурентности, однако решение проблемы потери данных из-за перезаписи ложится на прикладной код.

☄️ Материализация конфликтов. Если объект "спора" еще не существует, то для контроля доступа к нему используется вспомогательный объект, который позволяет обнаружить — материализовать — конфликтующие изменения. Например, при покупке билета на концерт блокируется сам билет (уникальная пара "место-концерт"), после чего создается запись о покупке ("место-концерт-зритель"). Блокировка может быть явной или на основе уникального индекса. Работает хорошо, если вспомогательный объект существует в предметной области, а не является синтетической выдумкой, которая служит лишь для контроля доступа.

☄️ Блокировка диапазона индекса. Предикативная блокировка диапазона изменяемых данных на основе индекса. Блокируемый диапазон может указываться явно, например, в условии WHERE оператора SELECT FOR UPDATE, либо неявно при использовании уровня изоляции Serializable. Метод эффективен для борьбы с фантомными чтениями, но может заблокировать слишком большой диапазон объектов (при отсутствии подходящего индекса — всю таблицу).

☄️ Последовательный доступ. Все изменения данных приложение производит последовательно, в рамках одного рабочего потока — обработчика. Метод эффективен в случае коротких транзакций и когда производительности одного обработчика достаточно, иначе он может быстро стать узким местом в системе.

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

При этом в большинстве распределенных баз в общем случае неприменимы:

🕚 Явная/пессимистичная блокировка
🕚 Оптимистичная блокировка
🕚 Материализация конфликтов
🕚 Блокировка диапазона индекса

На мой взгляд, всё это выглядит крайне непросто. Поэтому стоит честно ответить на вопрос: "У меня реально такая конкурентность при записи?" Если ответ "нет", тогда стоит начать с самых простых техник (и до конца придерживаться принципа KISS). Если ответ "да", то стоит подумать о подходе работы с данными, например, посмотреть в сторону append-only-техник (шаблоны Event Sourcing, CQRS). Конечно, это не единственно возможные варианты, и очень важен контекст решаемой задачи. Однако всегда стоит подвергать сомнению и делать ревизию текущего решения и инструментов с учетом имеющегося опыта и появляющихся требований.

〰️〰️〰️

Делитесь своими техниками обеспечения согласованности с использованием архитектурных подходов или средств баз данных. 😉👇

#dev #db

Bubblewrap

Представьте, что вам нужно запустить некоторый процесс Linux в изолированной среде. Так, чтобы он не смог нанести вред системе, на которой запускается. Какие инструменты мы используем в таких случаях? Первое, что приходит в голову, это технологии виртуализации или контейнеризации. Но что, если нам нужно что-то более легковесное и простое в использовании? На самом деле, такой инструмент есть — это утилита командной строки Bubblewrap, один из проектов сообщества Containers (знаменито авторством таких инструментов, как Podman, Buildah, Skopeo и др.).

Когда может быть полезен:
☑️ Невысокие требования к изоляции процесса и системы.
☑️ Недопустимы накладные расходы как у более сложных средств изоляции.
☑️ Тестирование (поведения) программы в разных условиях эксплуатации.
☑️ Запуск программ/скриптов/кода, полученных из ненадежных источников.
☑️ Лимитирование расхода ресурсов для отдельно взятого процесса.
☑️ Изменение структуры файловой системы для запускаемого процесса.
☑️ Разработка изолированных сред типа Flatpack.

Установка:

apt-get install bubblewrap

Использование:

bwrap --ro-bind / / echo 'Hello, Bubblewrap!'

В приведенном примере команда echo выполнится в изолированной среде, в которой структура файловой системы один к одному повторяет структуру host-машины, однако файлы в ней будут доступны только для чтения (--ro-bind, read-only bind). Поэтому следующая команда:

bwrap --ro-bind / / sh -c 'echo Hello, Bubblewrap! > /tmp/out.txt'

выдаст ошибку:

sh: 1: cannot create /tmp/out.txt: Read-only file system

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

Таким образом, используя аргументы командной строки, вы сами определяете уровень изоляции запускаемого процесса. При этом под капотом Bubblewrap использует стандартные средства Linux, которые не требуют повышения привилегий пользователя: chroot, clone, seccomp, cgroups, landlock.

Основные плюсы:
🕚 Не требуются root-привилегии.
🕚 Изолирует работу только одного процесса.
🕚 Может использоваться для изоляции приложений с графическим UI.
🕚 Предоставляет большой спектр настроек лимитирования.
🕚 Простая установка и использование.
🕚 Низкие накладные расходы на изоляцию.

Основной минус — это то, что ограничение на ресурсы системы устанавливаются только с использованием cgroup. Это значит, что для полноценной работы bwrap в Docker/Kubernetes-контейнере последний придется запустить в privileged-режиме или лучше с указанием в capabilities привилегии SYS_ADMIN.

Берегите себя, изолируйте свои процессы и будьте в безопасности! 😉❤️

#tools #devops #untrusted_code

Устранение уязвимостей в коде

Сегодня решил рассказать об одном аспекте в разработке ПО, про который очень часто несправедливо забывают. Это способы изоляции приложения и системы, в которой это приложение исполняется. 📍

Какой бы классный и неуязвимый код мы ни писали ⚡️, мы используем внешние зависимости — сторонние библиотеки, которые могут содержать различные уязвимости. 🐞 Поэтому будет справедливо утверждать, что любой код имеет уязвимости. Раз так, то давайте разберемся с тем, как минимизировать свои риски.

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

1️⃣ Wrapper / Обертка. Изолируемый процесс запускается с помощью программы, которую называют "обертка" (wrapper). Перед запуском изолируемого процесса обертка создает необходимое окружение для его исполнения, что чаще всего заключается в ограничении прав и лимитировании ресурсов. После этого изолируемый процесс запускается внутри предоставленного окружения, т.е. "оборачивается" в него. Этот подход универсальный и простой, используется для изоляции сторонних приложений. По этому принципу сделаны cgroup (cgexec), ранее рассмотренный Bubblewrap, любые другие средства контейнеризации. 🐳 Основной недостаток — окружение создается со всеми правами, которые могут понадобится для работы изолируемого процесса (даже если они нужные ему только однажды, например, при старте или инициализации).

2️⃣ Self-sandboxing / Самоизоляция. Приложение самостоятельно накладывает ограничения на доступ к некоторым аспектам системы. Кто лучше всех знает, что именно нужно приложению для его работы? Правильно, разработчик этого приложения. 🧑‍💻 Если, например, мы знаем, что доступ к файловой системе нам нужен только на этапе запуска, когда мы считываем конфигурационный файл, то сразу после этого мы можем наложить самозапрет на доступ к файлам. Ясно, что такой подход уменьшает уязвимость всего остального кода приложения. Основной недостаток — динамическая самоизоляция может неожиданно нарушить работу других частей приложения, поэтому ее лучше применять для каких-то базовых ограничений (например, доступ к файловой системе) или в простых приложениях.

3️⃣ Broker / Брокер. Изолируемый процесс получает доступ к системе через посредника — брокера. 👨🏻‍⚖️ Таким образом, брокер контролирует все обращения к любым системным ресурсам. Этот подход отлично себя зарекомендовал, используется в Chromium, Firefox, мобильных платформах (Android, iOS). Большие усилия в развитии этого подхода для графических приложений Linux предприняты в рамках проекта D-Bus. Основной недостаток — сложность реализации и снижение производительности приложения из-за накладных расходов брокера на виртуализацию доступа к системным ресурсам.

Все представленные подходы могут комбинироваться друг с другом.

Как мне кажется, "Самоизоляция" — недооцененный подход. Был ли у вас опыт его использования? 😉

#arch #untrusted_code

Структура, высеченная в камне

Сегодня будет небольшой манифест. :) Часто сталкиваюсь с одним очень интересным фактом. Большинство разработчиков с большей охотой идут на изменения в коде, нежели на изменение в структуре проекта. Даже самые очевидные аргументы в этом вопросе работают плохо.

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

Сначала я вижу общую картину — модули системы, названия которых указывают на их функциональную роль или служат заголовком соответствующего поддомена. На уровне модулей я вижу пакеты (или пространства имен), названия которых дают мне четкое представление о их содержимом и позволяют получить базовое представление о внутреннем устройстве модуля. Далее я вижу отдельно взятые компоненты, классы, записи и т.п. Их имена также должны являться отражением содержания и/или намерения. И так вплоть до названий переменных. Всё это должно задавать невидимый вектор, интуитивно направляющий исследователя вашего кода к тому, что он ищет или хочет понять. Всё должно работать, как содержание книги: если мне нужны детали, я перейду в нужный подраздел, но одного содержания мне должно быть достаточно, чтобы понять, о чем книга или глава.

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

Что задаёт структуру проекта и что она отражает?

🟢 Модель предметной области.
🟢 Архитектура и технические решения.
🟢 Внутренние соглашения команды/компании.

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

Точно так же, как мы осуществляем рефакторинг кода, мы должны делать и рефакторинг структуры — реструктуризацию. В противном случае внешняя оболочка и содержимое очень быстро разъедутся, и развитие проекта будет усложняться пропорционально этому разрыву. В какой-то момент уровень входа разработчиков в проект станет слишком высоким, появятся "незаменимые" сотрудники, на которых держится всё. Это путь в один конец, и он достаточно печальный.

Структура проекта не высечена в камне, это такой же код, который должен подвергаться рефакторингу!

P.s. Кстати, залогом успеха в этом деле является унификация, стандартизация и тоталитарный контроль. Все эти вещи очень хорошо поддаются автоматизации и тестированию.

#view #arch #dev