ТехнофITнес | Никита Ульшин

Почему Uber переехал с Postgres на MySQL

Интересная статья о том, какие проблемы в Postgres выявили инженеры Uber при масштабировании. Сейчас Postgres кажется более популярным решением, но важно понимать, что и он далёк от идеала.

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

⭐️ Интересные идеи

➡️ Первой большой проблемой стало раздувание индексов. Индексы в Postgres разрастались, несмотря на то что количество данных в таблице не изменялось. Используемое индексами место освобождается только при выполнении REINDEX или VACUUM FULL. Это поведение вызывает замедление запросов и загруженность хранилища бесполезными данными.

➡️ Одной из главных причин переезда была сложная репликация и обновление версий. Но это было исправлено внедрением логической репликации.

➡️ Приятно видеть, что большинство проблем в Postgres уже давно исправили. Но, по словам автора, проблема с разрастанием индексов всё ещё актуальна.

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи

Паттерн Bulkhead

Продолжаю читать статьи про паттерны отказоустойчивых приложений. На очереди — Bulkhead.

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

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

⭐️ Интересные идеи

➡️ Bulkhead предлагает разделить инстансы на разные группы в зависимости от загрузки и требований к доступности. В таком случае мы изолируем падение одного из сервисов его группой — все остальные группы продолжают функционировать корректно.

➡️ Bulkhead защищает сервис от каскадирования сбоя: если не функционирует всего лишь одна группа, остальная часть работы сервиса продолжит выполняться.

➡️ Одного Bulkhead недостаточно — рекомендуется применять его вместе с Retry, Rate Limiter и Circuit Breaker.

➡️ Для разделения асинхронной коммуникации можно использовать разные очереди и разные consumer groups (что уже реализовано в Kafka).

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи

Как сервера договариваются друг с другом: алгоритм распределённого консенсуса Raft

Распределённый консенсус – один из ключевых терминов дивного мира распределённых систем. Сама по себе тема распределённого консенсуса огромна и сложна, при этом она крайне важна для понимания инженера, работающего в таком окружении.

К счастью, сама проблема распределённого консенсуса в целом понятна, и уже существуют алгоритмы, которые его реализуют (естественно, не бесплатно). Одним из популярных алгоритмов является Raft, и именно ему посвящена сегодняшняя статья.

⭐️ Интересные идеи

➡️ Raft работает на основе лога изменений состояния (напоминает Event Sourcing). Всегда есть лидер, который отвечает за управление этим распределённым логом. При нормальной работе лидер всегда один.

➡️ Raft делит время на отрезки произвольной длины, называемые сроками. Срок – это период, в течение которого выбранный лидер исполняет свои обязанности. По окончании срока выборы происходят заново, и лидер может смениться.

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

➡️ Благодаря тому, что данные хранятся в виде append-only log, работа алгоритма становится очень надёжной: не возникает конфликтов при изменении записей.

➡️ Писать собственную реализацию Raft не стоит: уже есть готовые библиотеки (например, от HashiCorp). Либо можно воспользоваться базой данных, которая использует Raft под капотом (например, etcd).

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи

Микросервисы не подходят стартапам

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

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

⭐️ Интересные идеи

➡️ Даже плохой монолит позволяет поставлять ценность пользователю. Для стартапа главное — сохранять работоспособность и давать людям то, за что они платят. С этими задачами монолит справляется на ура.

➡️ Микросервисы — это не лучшая практика, а инструмент масштабирования. При их использовании организация зачастую платит сложностью за решение тех проблем, которые не решаются иным путём. Не стоит использовать микросервисы просто потому, что «это модно».

➡️ Сложность микросервисов сильно бьёт по поставке команды. Например, они усложняют локальную разработку, требуют изменений в процессах релиза и особого внимания к DevOps-практикам. Их сложнее проектировать, разрабатывать и поддерживать, что негативно сказывается на скорости поставки фич (что критично для стартапа).

➡️ Иногда всё же имеет смысл начинать сразу с микросервисов. Например, когда у разных частей приложения очень разный профиль нагрузки или разные потребности в масштабировании.

➡️ Сначала выживите, потом масштабируйтесь. Оставайтесь на настолько простом технологическом стеке, насколько это возможно. Микросервисы — это налог, который стартап может и не потянуть.

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи

Сколько партиций в Kafka мне нужно?

Партиции — это одна из важнейших частей Kafka. С их помощью обеспечиваются порядок, структура и масштабирование топиков. Но выбор числа партиций может внезапно стать непростой задачей. В статье разбираются основы партиций и «rules of thumb» при работе с ними.

⭐️ Интересные идеи

➡️ Большее количество партиций — это не только увеличенная пропускная способность, но ещё и более длительные даунтаймы, больше открытых файлов на брокерах и более высокое потребление RAM.

➡️ У Kafka нет жёстких лимитов на количество партиций, но есть некоторые общие правила: 4000 партиций на брокер, 200 000 партиций на кластер, 50 брокеров на кластер.

➡️ Не используйте простые числа при определении числа партиций. Они плохо делятся на другие числа, что может приводить к сложностям при изменении количества партиций и «перегретым» партициям.

➡️ Рекомендуется использовать одинаковое количество партиций во всех топиках одного кластера. Это упрощает подключение групп консюмеров.

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

➡️ Не увлекайтесь: для тысячи сообщений в день вряд ли нужны сотни партиций.

➡️ 12 партиций — хороший гайдлайн. Если данных мало, можно сделать и меньше (2/4/6).

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи

Роадмап архитектора

Как вы знаете, иногда я тут делюсь не обзорчиками, а вполне прикладными штуками. Сегодня у нас в гостях роадмап Software Architect.

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

Мне наиболее полезными кажутся разделы Patterns & Design Principles и Important Skills to Learn. Также хорош раздел Operations Knowledge — меня немного пугают архитекторы, которые нихрена не понимают в инфре.

Приятного изучения!

➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи

Нельзя пожертвовать устойчивостью к разделению

Отличная статья, которая показывает, почему теорема CAP на самом деле сводится к выбору между двумя вариантами: Consistency или Availability.

Автор лихо заходит в тему, проезжаясь катком по разработчикам БД, которые позиционируют свои продукты как CA (без Partition Tolerance). По его мнению, они просто не понимают теорему CAP.

⭐️ Интересные идеи

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

➡️ У доступности тоже есть ограничения. Если у вас есть 5 узлов с данными и по какой-то причине все узлы отвалятся, вы потеряете данные. Так что бесконечная доступность — тоже скорее фантастика.

➡️ Устойчивостью к разделению можно пожертвовать только в одном случае: если есть гарантия того, что сеть абсолютно надёжна и ни один узел никогда не умрёт (ха-ха).

➡️ Если один узел работает с надёжностью 99,9%, то кластер из 40 таких узлов будет иметь надёжность 96,1%. Это означает, что с вероятностью в 4% что-то пойдёт не так. И в такой ситуации системе придётся жертвовать либо согласованностью, либо доступностью.

➡️ Но обычно распределённым системам и не нужна идеальная согласованность или абсолютная доступность. Поэтому лучше сосредоточиться на том, чтобы проектировать системы с учётом компромиссов, а не спорить о теоремах.

➡️ В качестве альтернативы автор предлагает рассмотреть две метрики: процент запросов, на которые получен успешный ответ, и процент необходимых данных, включённых в ответ. Чем-то из этого можно пожертвовать при проектировании системы.

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи

Стратегии версионирования событий для event-driven architecture

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

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

В статье разбираются несколько стратегий версионирования событий.

⭐️ Интересные идеи

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

➡️ Вариант попроще — добавить версию события в метаданные. Такие события проще релизить, но появляется усложнение обработки на стороне потребителей, и всё равно придётся публиковать дубликаты для поддержки старых версий.

➡️ Создавать новые топики для новых версий. Такой подход даёт хорошее разделение потоков версий и прозрачность для потребителей. Но раздувается количество топиков и усложняется агрегирование.

➡️ Использовать реестр схем. Очень удобный подход для обеих сторон взаимодействия, но добавляет дополнительную зависимость (и SPOF) в виде реестра схем, а проблему дублирования событий всё равно не устраняет.

➡️ Вывод простой: версионирование событий — это больно, готовьтесь заранее.

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи

Когда неидеальные системы хороши: кейс Bluesky

Разработчики часто стремятся к идеальности. Но иногда trade-off в виде отказа от идеального решения может дать значительные преимущества реальной системе.

В статье автор рассказывает, как снижение требований к консистентности уменьшило P99 latency на 96%. Автор работает в Bluesky — аналоге соцсети с короткими сообщениями (сами знаете, какой).

⭐️ Интересные идеи

➡️ Когда пользователь пишет пост в Bluesky, он вставляется fanout-ом в таблицы таймлайнов подписчиков. Таблица таймлайнов большая и шардирована по юзерам (таймлайн пользователя целиком лежит на конкретном шарде). Сами таймлайны периодически подчищаются от старых постов.

➡️ Шардов — несколько сотен, пользователей — 32 миллиона, и в среднем всё работает нормально. Проблемы начинаются, когда пользователи выбиваются из нормы — например, фоловят сотни тысяч человек. Такой пользователь сильно перегружает шард, ухудшая UX для десятков тысяч других пользователей.

➡️ Также возникают сложности, когда у пользователя очень много подписчиков (миллионы). Статистически, fanout на каждую 1000 запросов получает около 10 long-tail-запросов. При 2 миллионах подписчиков результат получается пугающим :)

➡️ Неидеальное решение для случая с большим количеством подписок: сделать таймлайн не совсем консистентным. При большом числе подписок пользователь вряд ли заметит, что лента не совсем хронологична или неполна (возможно, он вообще не будет её открывать). Поэтому инженеры ввели лимит подписок, до которого таймлайн строится корректно. При превышении этого лимита некоторые записи начинают отбрасываться, что ограничивает нагрузку на один шард. Расчёт: min(reasonable_limit / num_follows, 1).

➡️ Неидеальное решение для популярных пользователей: для выбора стратегии обновления таймлайнов важно знать, сколько у пользователя подписчиков. Но такие чтения сильно нагружали базу (при каждом посте популярного пользователя приходилось делать запрос). Инженеры закешировали количество подписчиков популярных аккаунтов в Redis и обновляли его раз в 30 секунд. Точное значение в моменте не критично, а кэш позволил значительно снизить нагрузку на базу.

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи

Использование Kafka для real-time обработки данных в масштабе

В статье рассказывается о том, как компания SecurityScorecard (предоставляющая услуги в области кибербезопасности) использует Kafka для анализа больших данных в реальном времени.

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

⭐️ Интересные идеи

➡️ Использование Kafka позволило перейти от пакетной (batch) обработки событий к анализу в реальном времени, что стало значимым преимуществом для бизнеса (сильный selling point продукта).

➡️ Данные в Kafka хорошо защищены благодаря гибким механизмам управления доступом на основе RBAC.

➡️ Дополнительно компания получила практически неограниченную масштабируемость — можно распределять клиентов по разным кластерам.

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи

Как Slack переделал архитектуру настроек рабочих пространств на EAV-модель

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

Одной из таких проблем оказались настройки. Их было 165 штук, и хранились они в виде JSON blob’а, достигая размера в 55 КБ. Боль была в том, что доступ к этим данным осуществлялся очень часто. Кэширование помогало, но из-за размеров blob’ов кэш тоже страдал.

⭐️ Интересные идеи

➡️ Была выбрана модель EAV (Entity/Attribute/Value), потому что нужно было поддержать неограниченный рост числа настроек. В обычную таблицу пришлось бы постоянно добавлять новые колонки.

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

➡️ Новая структура позволила разгрузить получение данных — теперь разработчики могли не читать огромный blob, а получать конкретную настройку для своей задачи.

➡️ Интересно, что эти изменения вскрыли несколько багов в продукте и позволили обнаружить 14 устаревших, неиспользуемых настроек.

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи

Секреты стройности монолита: подходы по снятию нагрузки с БД

Одна из причин, почему команды начинают переходить на микросервисы — основная БД захлёбывается под нагрузкой. Масштабировать stateless-сервисы просто, с базой же это делать гораздо сложнее.

В очередной интересной статье инженеры Яндекса разбирают, как можно снизить нагрузку на БД, которая и так уже работает на ~100K RPS, и как её аккуратно распилить на части.

⭐️ Интересные идеи

➡️ Первое, с чего стоит начать — тщательный анализ долгих запросов. Инженеры Яндекса написали для этого свой парсер логов. Это позволило выявить плохо написанные запросы и быстро их поправить, получив буст к производительности.

➡️ Анализ логов также помог узнать, какие таблицы являются самыми нагруженными и востребованными. Выносить в сервисы было долго, поэтому инженеры приняли решение выделить эти таблицы в отдельные базы.

➡️ Интересен также процесс выбора таких таблиц: они должны быть достаточно нагруженными, не слишком сильно связаны с другими таблицами и к ним не должно быть слишком специфичных запросов (попутно ещё и с MySQL на PostgreSQL переезжали).

➡️ Эксперимент пришлось несколько раз откатывать из-за особенностей инфраструктуры. В первом релизе не хватило воркеров, потому что их количество в Яндекс Облаке фиксировано для выбранного флейвора, и двойная запись быстро их исчерпала. Во втором случае master переехал в другой ДЦ, и система несколько минут пыталась писать в slave — с печальными последствиями.

➡️ Была проделана большая работа по очистке базы (потому что исходный вес был 4 ТБ): анализ и удаление исторических данных, анализ неиспользуемых таблиц, даже лишние индексы почистили. В итоге удалось значительно сократить объём занимаемого на диске пространства.

➡️ Финальный аккорд — после выяснения требований оказалось, что не нужно хранить в основной БД данные о заказах старше одного месяца, потому что они используются в основном для аналитики и выборочных проверок. Это позволило уменьшить размер БД до целевого значения в 750 ГБ.

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи

Заметки о распределённых системах для молодёжи

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

⭐️ Интересные идеи

➡️ В распределённых системах гораздо больше ошибок и сбоев. Сборка мусора может заставить master “исчезнуть”, медленное чтение с диска может подвесить всю систему, а заблокированный распределённый мьютекс может вызвать продолжительный сбой. Поэтому при проектировании нужно сразу закладывать отказы.

➡️ Координация – это очень сложно, её по возможности стоит избегать. Необходимость достижения консенсуса сильно усложняет систему. Почитайте про задачу двух генералов или про византийские сбои (или лучше сразу “Распределённые системы” Танненбаума).

➡️ “Тормоза” будут самой сложной проблемой, которую вам доведётся дебажить. Сам процесс обнаружения узкого места уже может стать нетривиальной задачей, потому что проблема может проявляться только в определённых условиях (которые ещё нужно нащупать).

➡️ Без метрик как без рук. Метрики – единственный способ посмотреть, как реально себя чувствует ваша система.

➡️ Перцентили более показательны, чем средние. Средние показатели обычно хороши, если у вас есть нормальное распределение (график-колокол), а в распределённых системах такой роскоши обычно нет.

📎Ссылка на статью

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи

Что делает программистов лучшими?

Интересная статья, в которой отражён личный опыт автора о лучших программистах, которых он встречал в своей жизни.

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

⭐️ Интересные идеи

➡️ Вместо гугления или «насилования» LLM, эти ребята идут в официальную документацию инструментария и читают её. Мало кто так делает сейчас :)

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

➡️ Они умеют выходить из тупика. Эти инженеры разбивают любую проблему на части до тех пор, пока она не становится решаемой (или пока не становится понятен следующий шаг).

➡️ Они всегда учатся. Ни для кого не секрет, что в нашем мире приходится бежать очень быстро только ради того, чтобы оставаться на месте. Эти инженеры бегут.

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

➡️ Они не боятся говорить: «я не знаю». Умные люди осознают ограниченность своих знаний и понимают, что не знать чего-то вовсе не стыдно – наоборот, это возможность узнать что-то новое и обогатить себя.

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи

Перестаньте называть базы CP или AP

Довольно разгромная статья в адрес применения CAP-теоремы к базам данных от Мартина Клеппманна (того самого, который написал книжку с кабанчиком). Стриггерился он на другую статью, которая призывает использовать CAP для критичных систем.

Посыл статьи в целом ясен из заголовка: базы данных не могут быть CA (consistent & available без partition tolerance). Детали — в статье. Рекомендую прочитать хотя бы первый раздел, где Клеппманн разматывает CAP-теорему — чистое удовольствие.

⭐️ Интересные идеи

➡️ Под консистентностью в CAP-теореме обычно подразумевается линеаризуемость, которую практически невозможно гарантировать (даже CPU не гарантирует линеаризуемый доступ к RAM — что уж говорить о больших системах).

➡️ CAP-теорема ничего не говорит о latency, которая для многих даже важнее, чем availability. И в целом её термины весьма относительны и мало что полезного сообщают.

➡️ Доступность в CAP-теореме и доступность в реальной жизни — это два очень разных понятия. В реальности мы обычно смотрим на доступность в рамках некоторого SLA, но с точки зрения CAP любой отказ делает систему недоступной.

➡️ В итоге получается, что многие системы с точки зрения CAP не являются ни C, ни A — они просто P. И это хорошие, надёжные системы. Просто нужно перестать прикладывать к ним неуместную классификацию.

➡️ Даже автор CAP-теоремы Эрик Брюер признаёт, что теорема вводит в заблуждение и чрезмерно упрощена.

➡️ Финальный совет Клеппманна: учитесь думать самостоятельно, вне рамок излишне узких теорем и аббревиатур.

Приятного чтения!

Ссылка на статью: https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html

➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи

Управление рисками. Практический подход

Не одной архитектурой живут сеньёры, техлиды и архитекторы. Одна из задач проектирования — управление рисками (а точнее, тем, чтобы они не сделали нам очень больно). При этом на работу с рисками традиционно все забивают. В лучшем случае — «мы записали этот риск, поехали».

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

⭐️ Интересные идеи

➡️ Первый шаг (на котором чаще всего всё и заканчивается) — собрать вообще все риски, которые видит команда. Для этого можно использовать брейншторм с последующим разгребанием всего нагенерированного.

➡️ Каждый найденный риск нужно оценить по вероятности возникновения и степени влияния на проект. Также важно понимать, на что конкретно и в какой степени повлияет реализация риска (это может быть скоуп проекта, качество продукта или ещё что-то).

➡️ Когда риски готовы и описаны — можно приступать к оценке. Для этого можно взять любую удобную шкалу (главное, чтобы она была одна для всех). На этом этапе каждый риск получает сводную оценку по всем параметрам. Теперь риски можно отсортировать.

➡️ В финале для каждого риска нужно определить стратегию работы и план действий (при необходимости).

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи

Антипаттерн Retry Storm

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

⭐️ Интересные идеи

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

➡️ Делать бесконечные Retry нет смысла, потому что любой запрос валиден только в течение определённого времени. Поэтому всегда нужно ограничивать количество повторных попыток.

➡️ Делайте паузу между повторными попытками — не нужно бомбить страдающий сервис сразу же по тайм-ауту.

➡️ Для защиты от Retry Storm можно использовать gateway, который будет ограничивать нагрузку, отключать соединения при инциденте и даже может посылать в ответ заголовок Retry-After для упрощения коммуникации со стороны клиентов.

➡️ Клиенты должны грамотно обрабатывать полученные ошибки. Например, нет смысла повторно вызывать запрос, в ответ на который уже пришла ошибка 400 — это просто не имеет смысла.

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи

Почему Redis такой быстрый, несмотря на однопоточность?

Redis — очень быстрое in-memory KV-хранилище, которое может выдерживать довольно большие нагрузки. Но удивительнее всего тот факт, что он однопоточный.

Возникает вопрос: а как же однопоточное приложение так быстро работает и справляется с большой нагрузкой? На этот вопрос и отвечает сегодняшняя статья.

⭐️ Интересные идеи

➡️ Redis не совсем уж однопоточный. Однопоточная модель применяется для обработки клиентских запросов, но «под капотом» он использует дополнительные потоки для фоновых задач.

➡️ Главная причина высокой скорости работы — простота. Redis работает с данными в оперативной памяти, у которой очень высокая скорость доступа. Также базовая структура данных Redis — хэш-таблица, которая даёт временную сложность доступа к информации O(1).

➡️ Для более сложных кейсов у Redis есть набор структур данных, специально оптимизированных под его внутренние операции и use cases пользователей.

➡️ Redis активно использует мультиплексирование как на своей стороне (I/O), так и на стороне клиента (мультиплексирование подключения). Это позволяет обслуживать множество клиентских потоков без необходимости создавать подключение для каждого из них. Но у этого подхода есть и минусы: у Redis есть блокирующие операции (BLPOP, BRPOP), а пересылка больших чанков данных может замедлить всю работу.

➡️ Redis разработан так, чтобы как можно меньше нагружать CPU. Он выполняет минимум вычислений, поэтому узким местом чаще всего становятся память или пропускная способность сети.

➡️ В Redis реализованы специальные многопоточные оптимизации. Например, очистку памяти выполняет отдельный фоновый процесс.

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи

PostgreSQL Full-Text Search: быстрый, если делать правильно

Интересная статья о том, как разогнать full-text search в PostgreSQL. FTS в Постгресе традиционно считается не слишком быстрым на больших объёмах данных, из-за чего в инфраструктуру приходится тащить более сложные решения, заточенные под эту задачу.

Авторы статьи делают продукт, направленный на масштабируемый поиск в PostgreSQL, поэтому знают толк в работе с индексами. Сама же статья разбирает тесты скорости FTS, проведённые другой компанией, и показывает, как можно оптимизировать их подход.

⭐️ Интересные идеи

➡️ Первый фикс — сразу же преобразовать сообщение в тип tsvector и сохранить его в отдельной проиндексированной колонке. Затем по этой колонке можно легко осуществлять поиск. Это убирает лишние дорогие касты текста в tsvector и делает GIN-индекс более эффективным.

➡️ У GIN есть настройка fastupdate, которая по умолчанию включена. Она влияет на скорость обновления данных в индексе. Включённая настройка ускоряет обновление, но замедляет поиск. Если нагрузка идёт в основном на чтение, можно отключить fastupdate и получить прирост в скорости поиска.

➡️ Эти два изменения дали х50 прирост производительности FTS.

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи

Техника оптимизации Zero Copy в Kafka

Под высокой нагрузкой даже небольшие оптимизации могут дать заметный прирост производительности и удешевление инфраструктуры. Я помню, как коллеги по цеху за пару недель исследований снизили потребление CPU на 20% на сервисе с 10k RPS — представляете, сколько это в деньгах стоит?

Так вот, Kafka (изначально созданная для высоких нагрузок) под капотом использует много интересных оптимизаций. Одной из таких техник является Zero Copy — техника, направленная на уменьшение количества операций копирования (нет, там не всегда 0 копий).

⭐️ Интересные идеи

➡️ В случае Kafka Zero Copy выглядит так: ОС копирует данные из кэша страницы памяти напрямую в TCP socket buffer, полностью минуя программу на Java. Это позволяет убрать несколько лишних операций копирования и переключения контекста.

➡️ Kafka копирует данные с диска и посылает их по сети. При этом происходит несколько переключений контекста между приложением и ОС, а также множество операций копирования (от четырёх до бесконечности, в зависимости от объёма данных).

➡️ Поскольку Kafka хранит данные в том же формате, в котором и пересылает их, эти данные нет смысла копировать с диска в приложение, а из приложения — в TCP-буфер. Можно сделать загрузку файловых дескрипторов напрямую с диска в буфер сетевой карты (не TCP!), минуя приложение. Сетевая карта вычитывает данные по дескрипторам и отправляет их по сети.

➡️ Печальная правда: CPU редко является бутылочным горлышком Kafka, поэтому такая оптимизация не слишком влияет на общую производительность (перегруз сети случается гораздо чаще).

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи