Архитектор-пропагандист

Хочу представить очень распространенный анти-паттерн "Архитектор-пропагандист".

Проблема:
"Специалист" вместо поиска решения активно продвигает "правильный" вариант, забыв основную мантру архитектора "It depends".

Симптомы:
Фразы типа:
- Это best practices, так все делают
- Это паттерн взятый у [имярек] и он не может быть неправильным
- Мы делали так на предыдущем проекте, и это великолепно работает

Решение:
Любое правильное "решение" должно быть взвешено в конкретном контексте и подвергнуто сравнению с другими решениями.

Следствие:
Приведенное выше решение тоже не всегда верно)

#Антипаттерны

Логический и физический уровни системы

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

Бизнес процесс состоит из атомарных действий, которые отображаются на физические транзакции и (сюрприз!) не один в один.

Варианты:
Действие1. Идеальный расклад однозначного соответствия. Атомарность действия и атомарность реализации.
Действие 2. Грустный случай разбиения атомарного действия на две не атомарные транзакции. Этого стоило бы избегать, но не всегда возможно.
Можно попытаться связать физические транзакции блокировками (распределённая транзакция) - но получится нестабильно и медленно.
Делаем сагу. На логическом уровне атомарность. На физическом отменяемость (abortability у Martin Kleppmann).
Есть масса способов не дать клиенту увидеть проблемы реализации.
И пусть специалисты спорят атомарна ли сага))
3. Действия 3,4. Чрезмерное усложнение. Так лучше не надо.
Два неатомарных действия лучше догнать по итогу (eventually), чем мучиться с откатом и возможным неуспешным откатом.

#Сага #Saga

Контроль потока

При формировании сервисной архитектуры одним из первых стоит вопрос о механизме взаимодействия.
И перед тем как снизойти до технологии нужно определить что это будет sync или async.
То есть будет клиент ждать ответ или отпустит ресурсы и займется своими делами.

Критерии выбора описаны во множестве пособий.
За асинку - эффективность (низкая ресурсоемкость), надежность, безопасность.
За синку - простота (обработка ошибок, отладка), распространённость.

Хотел бы подсветить еще один, редко упоминаемый фактор.

Синк формирует т.н. закрытую модель взаимодействия с предсказуемой нагрузкой.
Пропускная способность здесь пропорциональна количеству пользователей и обратно пропорциональна времени оборота запроса - X <= M/T (до участка насыщения)
Синхронная система саморегулируема.
Появляются новые пользователи -> растет нагрузка -> растет время оклика -> снижается нагрузка. Клиент не шлет новый запрос не дождавшись завершения предыдущего.

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

Выбирая асинк честный архитектор должен сразу же усложнить нагруженную систему механизмом контроля потока.
Реализовать контроль потока можно по разному:
1. Ограничением нагрузки (rate limiting)
2. Ограничением времени выполнения (deadline)
3. Дросселированием участников (throttling)
4. Обратным давлением (back pressure)
Но сделать это нужно обязательно.

Так что выбирая async на нагруженном участке вы заодно принимаете и усложнение системы. (

#производительность

"Типы" производительности

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

Многие при этом догадываются, что под словом "производительность" скрываются абсолютно разные хотелки заказчика.

Розански и Вудс выделили целых шесть типов заинтересованности:
1. Приемлемое время отклика (Фаулер называет это Отзывчивостью, Responsiveness)
2. Приемлемая пропускная способность (Мощность, Capacity)
3. Способность системы справляться с ростом нагрузки (Масштабируемость, Scalability)
4. Приемлемый разброс минимальных и максимальных времен отклика (Предсказуемость, Predictability)
5. Низкая потребность в аппаратных ресурсах (Эффективность, Efficiency)
6. Приемлемое поведение при пиковых нагрузках (Нил Форд и Марк Ричардс называют это качество Адаптируемостью, Adaptability)

Список большой, но на мой взгляд всё-таки не полный 🙂

Часто сталкиваюсь с заинтересованностью заказчика в справедливости (fairness):
Маленькие задачи должны обрабатываться быстро, вне зависимости от наличия больших задач.

У справедливости есть своя метрика - slowdown (отношение времени отклика к размеру задачи).
Желательно, чтобы это отношение было константой.

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

Так что справедливость вполне состоявшееся качество.

Включаю в свой список.)

#производительность

Задачка на справедливость

Реальная задача из прошлого:
Есть кластер БД (Postgres), который кормится с очереди (Kafka).
Высокая нагрузка. И очень высокие требования по производительности.
Заказчик желает минимизировать задержку.
Неповторяющиеся запросы поступают через случайные промежутки времени (М) и имеют существенный разброс по времени выполнения (G).
То есть очередь M/G/N.
В плюс: запросы регламентированы и можно оценить время их выполнения.

Мы не можем улучшить эффективность выполнения запросов.
Мы не можем докинуть железа.

Что остается?
Играть с планировщиком запросов.
Многие недооценивают этот механизм, но он реально позволяет в разы улучшить среднее время выполнения запросов .

Идеальное решение:

По условию задачи идеальной политикой балансировки/планировщика должна быть общая очередь на SQRT(1) (Central-Queue-SRPT)
Не тут то было (. Сыграть на Postgres "мелодию" с вытеснением запросов - нереально.
- ограничение №1 - слоник.

Можно было бы использовать TAGS(2):
Поставить в ряд несколько инстансов с возрастающими таймаутами и тот, кто не успел обработать свой запрос, передает следующему.
Postgres вполне может прервать задачу по таймауту.
Но нет (
ограничение №2 кластер PG чужой (AD) и кроме тупого FIFO ничего не умеет.

Остаются самые скучные варианты: SJF(3) и FSFC (FIFO).
По среднему времени отклика в наших условиях SJF чуть лучше и вроде бы игра не стоит свеч.
Однако здесь вспоминаем о справедливости.

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

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

Но будь моя воля, разобрал бы кластер и поставил цепь из инстансов PG с мапом на размер запроса.
Получил бы очень хорошие показатели )

(1) SQRT - вытесняющий алгоритм планирования, пропускающий вперед запросы с минимальным оставшимся временем обработки
(2) TAGS - “Task Assignment by Guessing Size” успешно используется в Microsoft и Unix системах
(3) SJF - Вначале обрабатывает быстрые запросы

#производительность

Иллюстрация к предыдущему посту

Зависимость среднего времени отклика от нагрузки для разных алгоритмов планировщика

Source: Prof. Mor Harchol-Balter, http://www.cs.cmu.edu/~harchol/


P.S. Заменил на гифку - чтобы оценить масштаб проблемы при увеличении вариативности времени выполнения

БД и алгоритмы планирования

К слову, вот такая интересная табличка по БД

👆 Ну да.)

Любимый "Слоник" вытягивает вариативность за счет многопоточности. Вероятность того что одновременно придет 16 "аналитических" запросов не должна быть высокой.

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

Кстати, в следующую пятницу т.е. 27.10.2023
читаю доклад на ArchDays 2023

Простая «архитектурная» задача и немного ТРИЗ

Заходите, пообщаемся )

https://archdays.ru/?speaker=1346&session=1469

Наблюдаемость
(Observability)

1. Широко известно, что наблюдаемость необходимое качество системы.
2. Ведем журналы, фиксируем показатели, навешиваем метрики.
3. На вопрос какие метрики стоит навешивать легко отвечаю:
Включайте GOLD. Это правильный набор метрик.

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

5. Для успеха любого действия нужны
- как минимум цель(стакан),
- возможность определить движемся ли мы к цели (глаза)
- и возможность скорректировать движение (руки).
То есть нужно сформировать механизм называемый в кибернетике "положительная обратная связь".

6. Наблюдение имеет смысл, если включено в этот механизм. А то получается как в анекдоте:
- Петька, приборы?
- 40
- Что 40?
- А что приборы?

7. То есть наблюдаемость не тянет на самостоятельность.
Я бы сказал, что это только часть качества.
Само качество надо назвать как-то иначе. (корректируемость ?)

8. Ну и в заключении процитирую один разговор:
- Какие метрики мы должны добавить в нашу систему ?
- Нужные метрики. Те, что позволят вам корректировать качества продукта.
- Это слишком умно (
- Включайте GOLD. Это правильный набор метрик. (сарказм)

#Наблюдаемость

Материалы по модели производительности

Вчера на конференции ArchDays2023 пообещал выложить материалы по мат. моделированию.
Вот то, что мне зашло больше всего:

1. Model-Based Software Performance Analysis
by Vittorio Cortellessa, Antinisca Di Marco, Paola Inverardi
https://www.amazon.com/Model-Based-Software-Performance-Analysis-Cortellessa/dp/3642136206
рассмотрены различные подходы к моделированию производительности

2. Performance Modeling and Design of Computer Systems: Queueing Theory in Action
by Mor Harchol-Balter
https://www.amazon.com/Model-Based-Software-Performance-Analysis-Cortellessa/dp/3642136206
ИМХО одна из лучших книг по QNM модели

3. Вообще все, что читал у Harchol-Balter мне нравится.
Рекомендую её сайт, где много материалов для свободного скачивания.
В том числе презентации, "разжевывающие" предыдущую книгу.
https://www.cs.cmu.edu/~harchol/

4. Baron Schwartz практик, использующий модели в проектировании
Его книги есть в свободном доступе
Выкладывал на канале -
- The Essential Guide to Queueing Theory
https://news.1rj.ru/str/rect_arrow/159
Книга по теории массового обслуживания
- Practical Scalability Analysis With The Universal Scalability Law
https://news.1rj.ru/str/rect_arrow/167
по USL (масштабирование)

#Книга #производительность

Зачем нужен архитектор

Возвращаясь к вопросу.
Хотел накидать список полезностей архитектора, но решил проверить в интернете и нашел готовый )

На картинке карта компетенций по solution architecture.

Отвечает на вопросы: что нужно уметь и как себя продавать.

Архитектура как клиническая практика

Работа архитектора в чем-то схожа с работой врача.
Можно найти те же паттерны.
Например:
Пациент жалуется на головную боль
(Заказчику не достает производительности)
1. Подход "технология вперед"
Выпей аспирину - в прошлый раз помогло.
А еще лучше фуфломецин - его везде рекламируют
2. Подход "очевидное решение"
Головная боль - очевидно простуда. Выпей аспирин.
3. Архитектурный подход.
А какие симптомы кроме этого? Кашель, насморк?
Нога болела два дня назад?
Гугл подсказывает, что при таких симптомах нужен аспирин.
4. Инженерный подход.
Симптомы наводят на мысль, но точного диагноза поставить нельзя. Нужно сдать анализы.
Все хором - анализы это же дорого и долго - выпей аспирин.

В общем - очень похоже.
Разница только в том, что архитектор зачастую работает с еще не родившимся "пациентом".

#Сарказм

Отличная высокопроизводительная система

На одной встрече резануло слух следующее высказывание:
Задача архитектора построить высокопроизводительную систему.
Хмм.

В моём понимании задача это:
1. Цель
2. Данность (условия)
3. Метод решения

Цель
- Казалось бы просто:
- Цель - построение высокопроизводительной системы.
- Однако это не цель архитектора.
Архитектору производительность не нужна.
- Точнее:
- Цель - удовлетворение хотелок заказчика в контексте производительности.
- Увы, зачастую заказчику производительность тоже не нужна, его чаще интересуют деньги.
- Еще точнее:
- Цель - удовлетворение хотелок стейкхолдеров в контексте производительности.
- Предполагая связь: удовлетворенный стейкхолдер - счастливый заказчик (что в общем то не всегда так)

И отсюда сразу много выводов:
1. Первая активность это не натягивание редиски на слона, а выявление и объективизация заинтересованностей стейкхолдеров.
2. Далее надо сопоставить выявленные хотелки с возможностями и желаниями заказчика.
3. И наконец, сопоставить оставшиеся требования с нашими возможностями и желаниями.

Моё желание построить отличную высокопроизводительную систему (и получить с этого определенный драйв/опыт) - обычно никого не интересует.
Я могу сделать это за счёт заказчика, но это как-то не профессионально.

Вместо отличной системы я должен построить систему удовлетворительную - удовлетворяющую в разной степени стейкхолдеров проекта.

Резюмируя:
Цель архитектора (в контексте производительности) построить систему удовлетворяющую заказчика и прочих стейкхолдеров оптимальную с т. з. производительности.

Не сочтите за занудство )

Оптимизация задержки (latency)

Прикинул показатели задержки по простенькому сервису.

Дано:
Нагрузка (X) - 70 tps
Время обслуживания (без нагрузки) (S) - 10 ms
Коэффициент вариации по размерам задач (C2) - 50 (характерный разброс для задач под unix)

Вопрос:
Что улучшать?
Уменьшать нагрузку, уменьшать время обслуживания, или снижать вариативность?

График зависимости задержки от каждого из этих параметров (в процентах) на картинке

Казалось бы ответ однозначный. Задержка более всего зависит от S - нужно повышать эффективность системы.

Ан, нет )

Зачастую повышение эффективности стоит очень дорого, и в конечном счете упирается в стороннее ПО.
Например, в какую-нибудь криптопро.

Уменьшить пропускную способность можно масштабированием. Это железо.
Плюс к этому здесь вступают в действие всякие USL и прочие Амдалы, которые могут украсть весь выигрыш.

Свести же вариативность к около нулевым показателям - дело элементарное. Достаточно поставить умный планировщик.

Рекомендую.)

В догонку к предыдущему посту

Читаю очередную книгу по моделям производительности и вижу у автора мысль, типа "от S(размер задачи) latency зависит сильнее всего, значит прежде всего оптимизируем S".

Но, черт побери, это так не работает!

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

Я работаю по следующему сценарию:
1. В начале расправляюсь с антипаттернами
Например: Разраб заюзал чужой запрос в стиле n+1 - переписываем на жадность.
2. Когда очевидные косяки устранены, вытягиваю список тактик и смотрю какая из них эффективнее и безвреднее в конкретных условиях.
Например: мне нужна низкая задержка, смотрю на повторное использование результатов, повышение эффективности, масштабирование, умное планирование и т.п.

Эффективность тактики прикидываю на модели.
Безвредность определяю по матрице.

3. Если ничего не помогает изобретаю новое решениение или, чаще всего, уговариваю заказчика о смягчении требований.

Каждый раз приходится думать.

Пропагандируемые в книжках механические алгоритмы не срабатывают.(

Презентация с HL++
С тремя бонусными слайдами )