инфраструктура как док

В эпоху этих ваших кубернетесов хочется иметь возможность быстро делать доку и получать верхнеуровневое описание архитектуры.
Оказывается, с помощью Plantuml можно изящно переживать кучу helm chart-ов и получить красивую картинку:
https://github.com/Alfresco/alfresco-anaxes-chartmap

#sre https://www.youtube.com/watch?v=TJLpYXbnfQ4

#sre https://www.youtube.com/watch?v=A1zRkSdWPJg

#sre #network https://www.youtube.com/watch?v=5Qld5krWjvQ

Господа, я тут себе поставил vector.dev - это такая молотилка логов. Ей задаешь source, filter, sink, она переваривает логи из источника и отправляет в ваш сервис. Порядка 50 синков и сорцов. У меня стоит в кубе и читает логи со всех подов с stdout/stderr, отфильтровывает только те, которые нужны и отправляет в datadog.

Можно слать в s3, datadog, google cloud logger и еще куча всегда. Удобно, что можно одним конфигом сменить то, куда поедут логи. В куб поставилось хелмом легчайшим образом

Короче, всем советую хотя бы поковырять.

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

Минутка tech porn.

У нас огромная multi-tenant реляционная база данных. Таблицы по 200 ГБ - рехнуться, если честно. При этом для multi-tenant архитектуры мы юзаем самую тупую модель - "Pool" - это когда во все таблицы добавляется ключик "tenant_id". Модель неэффективная, но зато простая в реализации и поддержке.

(кстати у AWS пролетала классная дока про дизайн multi-tenant систем, где разобраны все варианты, мастрид для всех CTO)

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

И тут нам пришло Великое Озарение [sarcasm], которое рано или поздно приходит любому DBA - о том, что основная работа всегда ведется с "верхушкой" данных. А огромный "long tail" всегда лежит мертвым грузом и нахуй не нужен юзается только в отчетах.

Первая мысль - надо сделать "вертикальный" партишенинг. Т.е. "старые" данные спихивать куда-то за горизонт (на отдельный диск или даже сервер), а "активные" данные держать где-то под рукой.

Мысль правильная, но нет.

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

Я уже слышу крики из зала: "шардинг", "кликхаус", "разделяй OLTP и DWH". И прочий оверинжиниринг. Сразу нет. У нас есть self-hosted версия, которая должна заводиться в один клик даже у домохозяек. Хотелось простой хак, который решит все проблемы одной строчкой.

И тут я случайно вспомнил про офигенный читкод - фильтрованные индексы. Ведь по умолчанию индекс делается по всей таблице. Но зачем, если можно индексировать только 0.1%?

В коде любого CRUD-приложения, в бизнес-логике всегда есть признак, который отличает "старые" данные от "новых". Ну типа "статус проекта = сдан". Или "статус заказа = обработан". И это условие уже есть в большинстве ваших SELECT'ов. В нашем случае это был "статус тикета = закрыт".

Что делает DBA-джун? Создает индекс по этой колонке. Чтобы, значит, поиск незакрытых тикетов был быстрым и классным.

CREATE INDEX myIndex
ON messages (processed)

Что делает прошаренный DBA-синьор? Создает еще "filtered index" с этим условием

CREATE INDEX myIndex
ON messages (column1, column2...)
WHERE processed = 0 --вот так

И следит, чтобы это условие было в селектах.

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

Когда мы прикрутили первый фильтрованный индекс и стали смотреть статистику использования, мы офонарели - SQL Server бросил все дела, и стал жадно его жрать. Приложение ускорилось в разы, нагрузка на проц снизилась на 80%. Посмотрите график - до и после внедрения только ОДНОГО пробного индекса.

Наш бд-сервер имеет всего 4 ядра и 32 гига памяти, при этом запросто тянет базу в несколько терабайт и сотни тысяч DAU. У нас в команде есть негласный челлендж - сколько можно протянуть на этом железе без апгрейдов? Уже годы держимся))

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

PS. "Filtered/partial index" есть в SQL Server, PG и в Монге. В мускуле есть воркераунд

PPS. есть нюанс, кстати. Когда делаете filtered index, обязательно включайте фильтрованную колонку в "include". Так мы заставляем сервер поддерживать "статистику" по колонке. Без статистики все это великолепие работать не будет, сервер индекс не заметит.

CREATE INDEX myIndex
ON Messages (Column1, Column2...)
INCLUDE (Processed) --важно
WHERE Processed = 0

Всем привет. Я думаю многие из тех кто интересуется микросервисной архитектурой знает, такой сайт https://microservices.io/ на котором собраны все основные паттерны применяемые при разработке микросервисов.

🌐 Если вы вдруг не знаете о таком сайте, советую его посетить. У меня конечно есть вопросы к его визуальной составляющей💩, однако информация там собрана вполне себе годная 👍🏻, хоть и в достаточно урезанном объеме. Я частенько использую данный сайт как справочник.

📚 Но речь не столько о сайте, а вот о чем. У Криса Ричардсона, автора данного ресурса, есть отличная книга которая называется “Microservices Patterns”. Вот ее то я вам и хочу порекомендовать.

❓Если вы читали только классику, а именно “Building Microservices: Designing Fine-Grained Systems”, у вас скорее всего осталось достаточно много практических вопросов типа: “А как быть с распределенными транзакциями?”, “А где должна быть бизнес-логика?”, “Как работать с доменными событиями?”, “А внешний API как предоставлять”?

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

💡 Во первых, я бы рекомендовал оригинальный вариант книги. Я сам приобрел перевод от издательства “Питер” и он оказался местами кривоват. Например в разделе о тестировании “stubs” и “mocks” переводятся как “заглушки” и внимание... “макеты” (wat?) 🤨.

💡 Во вторых, особенно новичкам я рекомендовал бы критически отнестись к первой главе. В русской версии она называется “Побег из монолитного ада”. Имея некоторый опыт такого “побега”, могу с уверенностью сказать о том, что может случиться так, что из монолитного ада вы прибежите в распределенный. И это значительно хуже монолитного ада. В остальном книга годная в особенности что касается деталей работы с распределенными транзакциями, Service Discovery, проектировании внешних API и т.д.

На этом у меня все. Всем добра! 👋

большой список практический занятий по технологиям aws
https://awsworkshop.io/

📺 Больше Брендана в ленте!

▶️ Весь плейлист YOW! September Online 2020.

#linux #видео #фидбечат

🔩 Awesome eBPF: https://github.com/zoidbergwill/awesome-ebpf #ebpf #линк

🔍 A tcpdump Tutorial with Examples — 50 Ways to Isolate Traffic - интересный материал с примерами применения tcpdump. #tcpdump #напочитать

🔧 https://slowfil.es/ - интересный ресурс, позволяющий вызвать файл с задержкой и нужным кодом ответа.

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