Оптимизация времени отклика с переворотом

1. Задача оптимизации производительности чаще всего сводится к оптимизации пропускной способности (Throughput, X) или времени отклика (Response Time, R).
Смотрите например у М.Фаулера "...под производительностью можно понимать один из двух параметров — время отклика или пропускную способность...".
2. Оптимизация начинается с локализации проблемы. Нужно найти проблемный участок и оптимизировать его. В противном случае на оптимизацию всей системы вы потратите слишком много ресурсов.
3. В случае пропускной способности проблемный участок находится легко (сравнительно). Этим участком является бутылочное горлышко системы. (Смотрите на эту тему QNM или ТОС).
То есть участок системы с максимальной потребностью в обслуживании (Service Demand, D).
4. Случай оптимизации времени отклика намного сложнее. Но есть один трюк:
- Время отклика задается для определенной нагрузки (R для X)
- Выворачиваем схему. Находим X0 при котором RT удовлетворительно и оптимизируем X (пропускную способность)
- Сводим задачу к "простому" поиску бутылочных горлышек.

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

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

Представление vs Модель

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

Я считаю такие "терминологические" споры бессмысленными.
Это примерно как спорить о смысле термина "Account", приводя определения из разных доменов (привет Эвансу). В доменах "Авторизация" и "Банк" эти сущности имеют разные смыслы.

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

Представление vs Модель (2)

В моём архитектурно-методологическом домене картина такая:

1. Представление и модель (в терминологии ИСО/ГОСТ) - суть оба модели. То есть предоставляют знание о проектируемой системе.

2. Модель (model) это "Big Data", llm системы. Накапливается непрерывно. Включает онтологию и структуру сущностей. Чаще всего это ментальная модель, но может быть оцифрована.
Назначение: накопление данных для формирования ответов на еще не заданные вопросы стейкхолдеров. Связывание и аппроксимация.
Характеристика: сложная, не чёткая.
Аналогия с данными: Озеро

3. Представление (view) это ответ на заданный стейкхолдерами вопрос. Выражено определенной нотацией. Объективизировано и материализовано.
Назначение: Закрыть потребности стейкхолдеров.
Характеристика: предельно простая, ясная и консистентная модель.
Аналогия с данными: Ответ на запрос.

4. Точка зрения, аспект (view point) это часть модели заточенная на конкретного стейкхолдера.
Назначение: Ограничение большой модели, выделение в большой модели независимых ограниченных контекстов.
Характеристика: большая, но консистентная модель.
Аналогия с данными: Витрина.

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

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

На втором этапе архитектор на базе накопленных знаний формирует новые модели (проектирование) и представляет их стейкхолдерам (документирование).

Представление vs Модель (3)
Практические выводы.

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

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

Что я собираюсь зафиксировать на этой диаграмме: model, viewpoint, view?

1. Model фиксируется с трудом. Нет общей для всех аспектов нотации. Масштаб огромен.
Можно зафиксировать часть модели с целью объективизации своих знаний. Например, только онтологию (см. инструменты арх. моделирования).

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

3. View отвечает на конкретный запрос пользователя. Не стоит забивать его деталями не относящимися к запросу.
Ясно и лаконично.

Общий анти-паттерн - смешение на диаграмме view и viewpoint моделей.
Ответы на вопросы с большим количеством избыточной информации.

Безопасности с нулевым доверием (zero-trust security model)

Редко пишу про безопасность. Однако это тоже архитектурно значимое качество.)

Здесь мой чеклист начинается с определения того, что охраняем.
Варианта два:
1. По старинке, охраняем периметр.
2. Охраняем каждый сервис (zero-trust security model).

Второй случай жуткий, но даже при использовании Docker можно кое-что предложить.

1. Docker Desktop
- Air-gapped containers в Docker Desktop version 4.29.0
Независимое конфигурирование безопасности каждого сервиса.
- Драйвер Macvlan, который позволяет рассматривать контейнеры как физические устройства с разными MAC-адресами
2. Kubernetes
- тут я знаю только service mesh

Возможно, Вы сталкивались с этой проблемой и сможете дополнить мой крайне короткий список)

Enterprise Security

К слову о безопасности.
На DZone вышел очередной сборник Enterprise Security (август 2024).
- Тут, как обычно, опрос с учетом угроз OWASP.
- Хорошая статья про упомянутый выше "Zero Trust".
- Замечательный материал по построению модели угроз "Full-Stack Security Guide"

В общем рекомендую )

Серьезные дискуссии
(ворчалка)

- В средние века ни одна приличная дискуссия не проходила без цитирования Книги.
- В век просвещения Книгу заменили списком литературы.
- С приходом интернета этот список сократился до одного источника - википедии.

Господа, пора переходить на llm.
Обсуждение не будет серьезным, если мы не дадим слово AI.

Говоря серьезно, устал от пустых обсуждений с перебором случайно обнаруженных вариантов.
Хочется видеть классическую постановку задачи. Декомпозицию задачи на подзадачки и основательное обоснованное решение.
Разучились?

Все доклады в одном месте

В связи с замедлением ....

Собрал всё в одном месте
https://vk.com/video/@id83992027

Архитектурная проблема

- Как исследователь, я должен подвергать сомнению любое свое решение.
- Как руководитель, я должен продвигать свое решение, как несомненно верное.
- Не успеваю переключаться (

Балансировка нагрузки

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

В подтверждение сказанного приведу несколько активно продвигаемых утверждений по поводу балансировки нагрузки:

1. Балансировка нагрузки не важна
Нет, если вы предполагаете масштабировать систему по нагрузке. Несбалансированная система не масштабируется.
2. Балансировка не имеет смысла, если один сервис способен вытянуть всю нагрузку
Нет,
- если нагрузка высока, то есть высока вероятность попасть в очередь.
- если ваша нагрузка не представляет собой строго периодическую подачу одинаковых запросов.
- если вы не исключили все возможные "шумы" со стороны.
Любой всплеск породит рост очереди, которая может никогда не рассосаться. Это сразу ухудшит перцентили по времени отклика. Хуже того, рано или поздно в это состояния перейдут все сервисы.
3. Сервис Kubernetes справится с балансировкой без нашего вмешательства.
Нет. Сервис кубера - эфемерная штучка. По умолчанию нагрузкой управляет IPTables, используя правила полученные от kube-proxy. Любой входящий коннект намертво привязывается к случайному поду.
4. Случайная/карусельная балансировка вполне подойдёт для высоконагруженных систем.
Нет. см. п.2.
5. Под кубер для балансировки лучше всего использовать Service Mesh (Istio)
Нет, если Вам дороги ваши ядра )
Если вы уже используете Istio, то логично использовать его возможности по балансировке. Если же нет, то намного логичнее заюзать возможности ОС (IPVS).
6. Предлагаемые из коробки алгоритмы балансировки оптимальны (см. Istio (least request) и IPVS (least connection))
Нет. Хуже того, "идеального" алгоритма не существует. Для каждого сервиса оптимальным будет являться алгоритм учитывающий особенности этого сервиса и особенности нагрузки. В большинстве случаев алгоритм least request/connection дает приемлемый (удовлетворительный) результат.

Извините, что много букв )

Кто кому модель?

Тут подумалось, а можно ли архитектуру называть моделью (моделями) системы.
Изначально то и системы никакой нет.

Архитектура это первая формируемая Система.

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

Часто хреновая модель )

Архитектура архитектуры

Часто попадаю на обсуждение одних и тех же вопросов по ИТ архитектуре.
Попытаюсь ответить на несколько из них здесь, используя архитектурный подход.
То есть представив архитектора как систему и накидав архитектуру архитектуры.

Контекст (зачем и кому нужно?)
Система: Архитектор
Акторы: Стейкхолдеры реализуемой системы
Основной сценарий: Стейкхолдеры получают ответы на вопросы по реализуемой системе (технологии, структура, поведение, ожидаемые качества и т. д.)

Информационное представление (что оно такое?)
- Для ответа на вопросы архитектор строит архитектуру (tobe) как некоторую модель (модели) будущей системы.
...
____________________

Часто задаваемые вопросы:

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

Архитектура архитектуры (аспекты)

Коллеги, спасибо всем кто принял участие в голосовании/обсуждении.

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

Можем расширить нашу модель рассмотрев разные аспекты архитектуры (информационный, философский, физический, аспект хранения, аспект реализации и т. д.)

Для затравки хочу привести точку зрения стандарта (argumentum ad verecundiam).

Итак ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011

1. Эфемерность архитектуры
Архитектура не эфемерна. Она "представляет собой абстракцию, состоящую из понятий и свойств".То есть как минимум это определённый информационный продукт.
2. Архитектура как описание
Архитектура не тождественна своему представлению.
"Настоящий стандарт отличает архитектуру системы от описания архитектуры".
Где описание архитектуры это совокупность ее представлений.
3. Архитектура как свойство системы
Архитектура связанна с системой, но не является ее свойством (атрибутом).
Любая система имеет архитектуру. Но обратное не верно. Архитектура может существовать без реализованной системы. Более того здесь связь многое ко многому:
"Та же самая система может быть понятной с помощью несколько отличающихся архитектур (например, когда они рассматриваются в различных окружающих средах).
Та же самая архитектура может характеризовать более чем одну систему (например, семейство систем деления какой-то общей архитектуры)."
4. Приземление архитектуры
Стандарт относится к описанию архитектуры и мало что говорит про архитектуру саму по себе.
Однако, зафиксировав изложенные факты
- архитектура это информация
- архитектура не тождественна своему описанию
- архитектура не атрибутивное свойство системы
Можно сделать вывод:
Из положений стандарта следует что информационный объект архитектура может быть физически приземлён...

Не буду делать вывод.
Оставлю диаграмму развёртывания на ваше усмотрение )

Архитектура архитектуры (историческая ретроспектива)

1. Мне повезло работать во времена, когда архитектуры еще не было, и разработка ПО относилась к инженерным практикам.
Перед тем как сесть за терминал, мы прорабатывали детальный проект будущей системы (с точностью до кода).
Зачастую такие проекты сопровождались мат. моделями, включающими расчет производительности (до такта), надежности, безопасности (категория A) и т. п.

2. На моих глазах инженерия деградировала. Нехватка времени/сроков приводила к тому, что многие проекты стали менее детальными. Инженера срезали углы. Многие разделы писались для галочки - от балды.

3. В скором времени этот подход узаконили. Принимали только основные решения: структура, контуры системы, тех. стек и т. п. Тут и появилось модное западное словечко "архитектор".

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

5. Конкуренция росла. Требования по срокам/деньгам становились жестче. И вот уже аджайл выдвинул лозунг: "никакого предварительного проектирования". Но это уже другая история...

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

Архитектура архитектуры (физика явления)

С точки зрения физика архитектура объясняется просто.)

— Система имеет некоторую энтропию (мера хаоса).
— Эта энтропия тем выше, чем сложнее система, то есть чем больше система содержит элементов.
— Высокая энтропия порождает высокую неопределённость. Мы не можем предсказать, как поведёт себя система в дальнейшем, и чего нам ждать от неё.
— Устранить риск можно, получив информацию об элементе системы. Чем больше информации мы имеем, тем меньше у системы шансов «взбрыкнуть».
— Однако для полного контроля над системой нужна вся информация об её элементах и об элементах, с которыми система взаимодействует. Это трудно достижимо.
— Решение: связываем элементы системы, подчиняем их нашим правилам. Чем меньше у элементов степеней свободы, тем предсказуемее их поведение.
Получившийся набор правил нарекаем архитектурой.
Если система реализует архитектуру, то её энтропия снижена и вместе с энтропией смягчены риски.

Ну а архитектор в этом случае — борец с энтропией.)

Архитектура как компромисс

1. Ожидания стейкхолдеров выражаются многочисленными требованиями, из которых архитектор выхватывает архитектурно значимые (в основном - нефункциональные).
2. Большинство методик сходится на том, что именно нефункциональные требования определяют архитектуру.
3. Нефункциональные требования группируются вокруг основных качеств системы, таких как производительность, надёжность, сложность, модифицируемость и т. д. (-ility).
4. При этом опыт подсказывает, что вытягивая одно из качеств, мы обычно топим другие (система "хвост-нос").
5. На этом основании многие авторы делают вывод о том, что "всё в архитектуре - компромисс".
(см. Современный подход к программной архитектуре: сложные компромиссы)
6. Декларируется следующий постулат: "В архитектуре нет правильного или неправильного ответа, все может быть компромиссом".

IMHO
Я описываю эту концепцию несколько со стороны.)
Вспоминая закон Джухэни ("Компромисс всегда обходится дороже, чем любая из альтернатив"), я предпочитаю обходится без компромиссов.

Без компромиссов

Сказав А, спешу сказать Б )

В предыдущем посте зафиксировал свою позицию:
"По возможности обходится без компромиссов"
Реально ли это?

Да, если не принимать на веру постулат о взаимозависимости качеств системы.

Качества системы безусловно связаны, но как ?

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

То есть вытянуть все хвосты, не жертвуя ни одним качеством (хотя вложится зачастую придётся).

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

И еще один трюк:
Если мы правильно проведем декомпозицию, то разные качества распределятся по разным модулям.

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

Архитектурный квант

Обратил внимание, что концепция архитектурного кванта не знакома многим архитекторам.

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

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

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

То есть, правильная микросервисная архитектура это много квантов, а распределенный монолит это один квант (хоть и много сервисов).

Кванты относятся к доменам отношением многое на многое.
- Можно все домены затолкать в один монолит.
- Можно, напротив, один домен расщепить на несколько квантов.

В итоге, объем кванта может быть существенно меньше ограниченного контекста диктуемого предметкой.

Могут существовать различные причины для тонкой декомпозиции.

Собственно и в самом DDD домен раскидывается на поддомены ради извлечения смыслового ядра. )

Компоненты программной системы

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