Это небольшое отступление в продолжающейся серии статей о том, как избежать внедрения сервисов для различных сущностей.
Интересный разговор за ужином привел к мыслям, которые я решил записать.
Закон Амдала В 1967 году Джин Амдал представил аргумент против параллельных вычислений.
Он утверждал, что прирост производительности ограничен, поскольку распараллелить можно только часть проблемы.
Размер оставшейся «последовательной части» различается в разных задачах, но он всегда есть.
Этот аргумент стал известен как закон Амдала.
Если построить график «ускорения» задачи в зависимости от количества выделенных ей параллельных процессоров, то вы увидите следующее: 
Это асимптотический график для нераспараллеливаемого фрагмента («последовательная часть»), поэтому существует верхний предел максимального ускорения.
От Амдала до USL Что интересно в законе Амдала, так это то, что в 1969 году на самом деле было очень мало многопроцессорных систем.
Формула основана на другом принципе: если последовательная часть в задаче равна нулю, то это не одна задача, а несколько.
Нил Гюнтер расширил закон Амдала, основываясь на наблюдениях за измерениями производительности многих машин и вывел универсальный закон масштабируемости (Закон универсальной масштабируемости, USL).
Он использует два параметра: один для «конкуренции» (что аналогично последовательной части) и один для «некогерентности».
Несогласованность связана со временем, затраченным на восстановление согласованности, то есть общего взгляда на мир разных процессоров.
На одном процессоре из-за кэширования возникают накладные расходы на когерентность.
Когда одно ядро изменяет строку кэша, оно дает команду другим ядрам извлечь эту строку из кэша.
Если всем нужна одна и та же строка, они тратят время на ее загрузку из основной памяти.
(Это несколько упрощенное описание.
но в более точной формулировке все же есть переговорные издержки).
Все узлы базы данных несут накладные расходы на сверку из-за алгоритмов согласования и поддержания согласованности данных.
Штраф выплачивается при изменении данных (как в случае транзакционных баз данных) или при чтении данных в случае окончательно согласованных хранилищ.
? Эффект USL
Если вы построите USL в зависимости от количества процессоров, вы увидите следующую зеленую линию: 
Фиолетовая линия показывает, что предсказывает закон Амдала.
Обратите внимание, что зеленая линия достигает максимума, а затем снижается.
Это означает, что существует определенное количество узлов, на которых производительность максимальна.
Добавьте больше процессоров, и производительность упадет. .
Я видел, как это происходило в реальном нагрузочном тестировании.
Люди часто хотят увеличить количество процессоров и улучшить производительность.
Это можно сделать двумя способами:
- Уменьшить серийную часть
- Сокращение затрат на одобрение
Если вычислительная «задача» представляет собой проект, то мы можем думать о количестве людей, участвующих в проекте, как о количестве «процессоров», выполняющих работу.
В данном случае последовательная часть — это часть работы, которую можно выполнить только последовательно, шаг за шагом.
Возможно, это тема для будущей статьи, но суть последовательной части нас пока не интересует. Кажется, мы видим прямую аналогию с издержками на координацию.
Независимо от того, сколько времени члены команды тратят на восстановление общего взгляда на мир, затраты на согласование присутствуют. Для пяти человек в номере эти затраты минимальны.
Пять минут рисования маркером на доске примерно раз в неделю.
Для большой команды в нескольких часовых поясах штраф может вырасти и стать формализованным.
Документы и пошаговые руководства.
Презентации для команды и так далее.
В некоторых архитектурах координация не так важна.
Представьте себе команду, в которой сотрудники находятся на трёх континентах, но каждый работает над одним сервисом, который использует данные в строго определённом формате и создаёт данные в строго определённом формате.
Они не требуют последовательности в отношении изменений в процессах, но требуют последовательности в отношении любых изменений в форматах.
Иногда инструменты и языки могут изменить накладные расходы на переговоры.
Одним из аргументов в пользу статической типизации является то, что она помогает совместной работе команды.
По сути, типы в коде — это механизм трансляции изменений в модель мира.
В динамически типизированном языке нам либо нужны вторичные артефакты (юнит-тесты или сообщения чата), либо нам нужно создать границы, где некоторые отделы очень редко восстанавливают согласованность с другими.
Все эти методы направлены на снижение издержек на переговорах.
Напомним, что чрезмерное масштабирование приводит к снижению пропускной способности.
Поэтому, если у вас высокие затраты на одобрение и слишком много людей, команда в целом работает медленнее.
Я видел команды, где казалось, что мы можем сократить вдвое людей и работать вдвое быстрее.
USL и затраты на сверку теперь помогают объяснить, почему это происходит – это не просто уборка мусора.
Речь идет о сокращении накладных расходов на обмен мысленными моделями.
В «Петля страха» Я имел в виду базы кода, где разработчики знали, что необходимы крупномасштабные изменения, но боялись случайно причинить вред. Это означает, что раздутая команда так и не достигла согласованности.
Потерянную последовательность, кажется, очень трудно восстановить.
Это означает, что затраты на координацию нельзя игнорировать.
USL и микросервисы Я думаю, что USL объясняет интерес к микросервисам.
Разделив большую систему на все более мелкие части, которые развертываются независимо друг от друга, вы сокращаете последовательную часть работы.
В большой системе со многими участниками последовательная часть зависит от объема усилий по интеграции, тестированию и развертыванию.
Преимущество микросервисов заключается в том, что они не требуют работы по интеграции, интеграционному тестированию или задержки синхронизированного развертывания.
Но накладные расходы на переговоры означают, что вы можете не получить желаемого ускорения.
Возможно, аналогия здесь несколько натянута, но я думаю, что можно рассматривать изменения интерфейса между микросервисами как требующие повторного согласования между командами.
Если их слишком много, то желаемой пользы от микросервисов вы не получите.
Что с этим делать? Мое предложение: посмотрите на архитектуру, язык, инструменты и используемую команду.
Подумайте, где теряется время при восстановлении последовательности, когда люди вносят изменения в системную модель мира.
Поиск разрывы .
Разрывы между внутренними границами системы и расколы внутри команды.
Используйте среду для сообщения об изменениях, чтобы процесс утверждения происходил для всех, а не индивидуально.
Посмотрите на коммуникации вашей команды.
Сколько времени и усилий уходит на обеспечение последовательности? Может быть, внести небольшие изменения и уменьшить в этом необходимость? Теги: #Менеджмент #последовательность #закон Амдала #распараллеливание работы #большие команды #раздутый персонал #микроформаты #Управление развитием #Управление проектами #Управление персоналом
-
Онлайн И Локальный Хостинг Quickbooks
19 Oct, 24 -
Ваш Собственный Aws. Часть 1
19 Oct, 24 -
Chromium 9 И Синхронизация Паролей
19 Oct, 24 -
Почему Я Не Дизайнер?!
19 Oct, 24 -
Тенденции В Дизайне Электронной Коммерции
19 Oct, 24
