Внутри S3

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

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

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

➡️ Инженеры Яндекса разработали свой сервис для работы напрямую с жёсткими дисками. Он держит более 1,000,000 RPS и работает с триллионами файлов. Про него есть отдельный доклад, который я позже обязательно посмотрю и напишу обзор. Для особо любопытных — вот ссылка.

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

➡️ Фоном работают несколько процессов: mover перетаскивает чанки между бакетами, splitter делит жирные чанки на более мелкие. Процессы блокируют чанк на запись, но работают единицы секунд, поэтому негативное влияние на клиента незначительно.

➡️ Для многих внутренних процессов важно корректно вычислять счётчики (тот же расчёт квот), но при подсчёте «в лоб» они обычно страдают от конкурентности. Решением стала очередь счётчиков: каждое изменение складывается в специальную очередь, которую разгребает фоновый процесс. Этот же процесс используется для биллинга, потому что видит все изменения в бакетах.

➡️ Паттерны клиентской записи по timestamp и алфавиту неудобны для S3, потому что грузят один шард вместо распределения нагрузки на все шарды равномерно. Решение — вместо ключей использовать их хэши, что помогает избавиться от перегрева одного шарда.

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

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

Прогрев кэша в стиле Netflix

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

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

Проблем добавляла и инфраструктура AWS, которая регулярно вырубает ноды кэша по каким-то своим причинам, что вызывало сильные просадки по latency (представляете, что будет, если на нагрузках Netflix просто погасить кэш?).

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

➡️ В качестве решения была создана инфраструктура прогрева кэша. Она делится на две смысловые части: прогрев реплик и прогрев инстансов.

➡️ Само решение состоит из трёх компонентов: Controller, Dumper, Populator. Controller выполняет роль оркестратора и очищает ресурсы, Dumper создаёт дампы кэша (спасибо, кэп), Populator накатывает дампы на новые реплики.

➡️ Dumper и Populator общаются через SQS-очередь, которая создаётся специально для них контроллером. Dumper заливает данные на S3 и кладёт ID чанка в очередь, Populator вычитывает их и накатывает на ноду. Операция считается завершённой, когда очередь пуста — Controller удаляет её и инстансы Dumper/Populator.

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

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

Как архитектура LinkedIn позволяет находить сообщение за 150мс

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

Инженеры LinkedIn изрядно заморочились над архитектурой поиска. Подробнее — в статье.

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

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

➡️ Для хранения сообщений используется KV store RocksDB. Сообщения хранятся в значениях по ключу вида MemberId | ConversationId | MessageId.

➡️ Для поиска строится инвертированный индекс, используется Apache Lucene (которая, например, лежит в основе OpenSearch). Для построения индекса фразы токенизируются и сохраняются в виде карты токен-сообщения.

➡️ Индекс создаётся лениво — когда пользователь делает запрос на поиск. При запросе вытаскиваются все сообщения пользователя из RocksDB и выстраиваются в in-memory индекс, который используется для ускорения дальнейших операций поиска.

➡️ Индексы партиционируются и распределяются по разным нодам, чтобы не перегружать одну. Для координации используется Zookeeper и sticky routing.

➡️ Про TTL индекса статья умалчивает.

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

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

Тейва Харшани «100 ошибок Go и как их избежать»

Пришло время и в этом канале открыть мою любимую рубрику — обзоры книг!

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

Конечно же, базовые книжки я прочитал ещё на стадии изучения языка. Но с тех пор как-то руки не доходили почитать что-то конкретно про Go — я больше читал про архитектуру, распределённые системы и базы данных. И тут произошло неожиданно приятное событие: ко мне пришли ребята из издательского дома «Питер» и предложили сделать обзор на обновлённое издание книги «100 ошибок Go».

Конечно, я не мог отказаться от обзора очередной интересной книги. Тем более что «100 ошибок Go» — книга не для новичков. Но обо всём по порядку.

⭐️ О чём книга

Как следует из названия, книга посвящена разбору 100 примеров ошибок и неэффективной работы в языке Golang. Глобально ошибки разбиты на смысловые разделы: организация кода, обработка ошибок, конкурентность и так далее.

Что можно узнать из книги:
➡️ Как грамотно использовать интерфейсы
➡️ Как выстрелить себе в ногу, перепутав длину и ёмкость среза
➡️ Чем всё-таки отличается конкурентность от параллелизма
➡️ Как создать race condition с помощью оператора append
➡️ И многое другое :)

⭐️ 3 идеи из книги

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

Называть пакеты в Go нужно ещё тщательнее, чем переменные. Именование пакета должно быть кратким, ёмким и отражать его возможности. Пакеты похожи на namespace из C#, и одновременно не являются ими. Знали бы вы, сколько мы времени на код-ревью тратим, придумывая нейминг пакетов…

Обработка ошибки должна быть выполнена ровно один раз. Знаю-знаю, всегда есть соблазн сделать что-то и передать ошибку дальше, но это не идиоматично. Если код обработал ошибку, то она не должна «лететь» дальше. Является ли дополнительное логирование обработкой — решайте самостоятельно :)

⭐️ Мои впечатления

Книга мне очень понравилась. Она далеко не такая простая и примитивная, как базовые руководства по Go, и посвящена разным хитрым нюансам языка. Некоторые ошибки довольно очевидны, если внимательно пройти A Tour of Go, но многие другие дали мне достаточно интересной пищи для размышлений.

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

Отдельный плюс — перевод книги. Он достаточно хорош: в процессе чтения я не спотыкался на словах и не ловил ступор. Технические книги в целом переводить непросто, и переводчики «100 ошибок Go» хорошо справились со своей задачей.

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

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

#обзор_книги@tech_fit
➖➖➖➖➖➖➖➖➖➖➖
📝 @tech_fit

Проблема long-tail запросов в распределённых системах

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

Одной из таких трудностей являются long-tail запросы. Так называют малую часть запросов, которые выполняются значительно дольше среднего. Этой проблеме и посвящена сегодняшняя статья.

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

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

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

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

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

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

Техника хеджирования для борьбы с long-tail запросами

Проблеме long-tail запросов была посвящена предыдущая статья. В том числе, там были перечислены некоторые стандартные техники борьбы с такими запросами.

Google изобрёл ещё один интересный подход под названием “хеджирование запросов”. Суть его заключается в том, что клиент отправляет один и тот же запрос ко всем узлам и, получив первый ответ, отменяет все остальные запросы. Этому паттерну и посвящена сегодняшняя статья.

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

➡️ Паттерн в первую очередь направлен на получение приемлемой latency. К примеру: у нас есть 20 нод, у каждой P99 составляет 1 секунду. С вероятностью 18,2% мы получим запрос длительностью >1 секунды. Хеджирование позволяет значительно снизить эту вероятность.

➡️ Хеджирование никак не связано с падением сервисов и не обрабатывает подобные ситуации.

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

➡️ В Go есть готовый пакет singleflight, который позволяет избежать дублирования запросов. Остальным придётся мучиться самостоятельно :)

➡️ Альтернативное решение — изначально посылаем только один запрос. Если он вышел за предел P95, то сразу же посылаем ещё один запрос к другой ноде. Так мы получаем более сбалансированное решение: latency будет похуже, но и нагрузка будет гораздо ниже.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перестаньте называть базы 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда неидеальные системы хороши: кейс 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 секунд. Точное значение в моменте не критично, а кэш позволил значительно снизить нагрузку на базу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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