Использовали оракл экспортер для мониторинга своих высоконагруженных баз и корректности объектов по бизнес процессам своими кастомными запросами. В результате обнаружили что экспортер начинал глючить если запросы по метрикам, коих под сотню, не успевали супер быстро исполняться. Ничего не помогало особо ибо метрик очень много и почти все они непростые. В результате страданий написали на джобах свою систему сбора метрик в оракл в одном месте, а уже собранные показатели супер быстро вытаскивали экспортером. Это я к тому, что экспортеры написаны не лучшим образом и под хайлоад нужно или писать свой/переписывать чужой или подстраивать метрики.
Основная проблема оптимизаторов что в оракле что в постгрес для больших таблиц с постоянно меняющимися большими объёмами данных это когда собиралась статистика для выполняющегося запроса.
Я правильно понял, что у вас тоже сбор идет по каким то своим эвристикам с не очень прозрачным итоговым прогнозом по частоте сбора? Ну то есть план может спокойно плавать на одних и тех же запросах в зависимости от того когда собиралась статистика, что там в ней сейчас, и насколько она соответствует текущей ситуации в таблице?
Я приверженец канбана для опытных и сработанных команд с понятным скоупом возможных задач по продукту.
Вижу регулярно коллег соседей, работающих по скраму. Так вот мы с командой даем результат для бизнеса существенно быстрее, так же быстрее переключаемся на более приоритетные задачи, но работать как на конвейере без пауз для людей не просто, выгорают. Ну и у менеджера команды работа с бэклогом считай постоянная при канбане, потому что нужно нагружать команду задачами, а даже бизнес не всегда поспевает, тогда приходиться набрасывать оптимизации, тюнинг, рефакторинг в промежутках между фичами и релизами для бизнеса.
Ещё, если у вас есть работа с внешним вендором в команде от которой зависит и ваша работа, то как по мне спринты при таком варианте вообще не подходят, ну или вы будете для бизнеса крайне медленными.
Слабо представляю себе систему, где нужно, чтобы бизнес событие вычитывалось рандомно разными сервисами 1 раз. Всё остальное реализуется в amqp типа кролика как отправление конкретного типа события для конкретного подписчика, и там наоборот нужно поприседать чтобы отправить 1 событие на 2 и более подписчиков, когда сначала архитектура предполагала одного получателя, а потом вдруг нарисовались ещё, а последовательно отсылать по цепочке не вариант.
Ну и ещё нужно помнить про то, что если заранее в кролике не позаботиться о персистентности хранения события сначала на диске, то развал кластера с потерей всех событий что были в тот момент в памяти невычитанными при потере сетевой коннективности с необходимостью пересоздания кластера это прям реальность, о которой почему-то многие умалчивают.
Плюс нюансы с отдельными ретрай очередями на повтор, когда нарушается порядок вычитывания событий при восстановлении подписчика после сбоя.
Я к тому, что любую систему нужно уметь хорошо готовить под целевое использование, и не всегда эта цель видится в самом начале отчётливо )
Делать разработку по скраму эффективно можно только если нет зависимостей от внешних команд. Как только сроки вашей реализации зависят от чего-то внешнего (вендор, другая команда), то скрам превращается в профанацию и постоянные переносы, так как вы не можете обеспечить выход запланированного бизнесом в спринт, а команда и все планы бизнеса были сфокусированы на конкретной цели в спринте, и тогда существенно эффективнее канбан, где каждый ресурс команды постоянно нагружается потоком работы вне зависимости от планов на спринт и бизнес фичи сразу выпускаются по мере готовности. TTM проектов/фич для бизнеса в целом по году получается значительно лучше. Да, больше переключений контекста и релизов не всем по душе, да и следить одновременно нужно за большим количеством фич. Но с точки зрения именно бизнес результата ИТ тогда выглядит как неостанавливающаяся фабрика постоянно дающая результат. По крайней мере мой опыт именно такой.
Я бы не торопился с темпорал. В статье не указано на чём, то есть где темпорал хранит все сценарии и статусы у себя внутри. Допустим это постгрес или мускуль, а значит о простом горизонтальном масштабировании с ростом нагрузки можно забыть. Это ещё не упомянуто о том, что как и в любом оркестраторе, с ростом количества систем растет количество не только сценариев, но и шагов даже в старых сценариях, а при хайлоаде скажем даже в 50000 сценариев в секунду там всё лежать будет. А с учётом, что там основные бизнес процессы, то считай и вся компания.
Моё мнение, что единая оркестрация не подходит под действительно серьёзные нагрузки. Да, можно несколько оркестраторов использовать, но там другие вопросы возникнут...
С другой стороны, указанные в начале статьи проблемы можно было бы решить разбиением всех систем на продукты со своими командами системных архитекторов и разработки со связующим звеном в виде солюшен/ентерпрайз аналитиков и архитекторов. И тогда верхний уровень бизнес процессов описывается кубиками достаточно просто и внутренняя хореография командами продуктов тоже ведется с прекрасным пониманием что где как точно работает, и погружение новичков не проблема. Зато масштабирование систем продуктов с ростом бизнеса вообще не будет вызывать вопросов при хореографии и никогда весь бизнес не встанет из-за одного узкого места.
Моё мнение, вы просто ошиблись с архитектурой решения и не учли потенциальную нагрузку с учетом роста. По факту просто уперлись в производительность постгреса. Даже если вы сейчас потюните что-то, то это спасёт только на время. При подаче нагрузки ещё x2 у вас опять всё сляжет. Тут или использовать in-memory оркестраторы бп с такими же бд или всю оркестрацию бизнес процессов строить самим на базе Кафки.
Слышал, что сбер сделал свой bpmn движок platform v flow как раз на базе Кафки избавившись от бд, где все состояния бп в кафке и хранятся. Видимо тоже уперлись в бд...
Наконец-то адекватный комментарий от человека с хайлоад нагрузкой и про финансовые данные.
Отсутствие хранимок при crud операциях это точно не про хайлоад Энтерпрайз.
Автор просто не сталкивался с грамотным их использованием, где и масштабирование в кубере сервисов с логикой обеспечивается и горизонтальное масштабирование стейтфул адаптеров к бд.
Скажу с позиции работодателя. Перечислены действительно базовые классические скилы для бэка. Обладая практическим инженерным опытом от 1 года по всем из них (автоматизация это отдельный стрим всё таки) без интересной и хорошо оплачиваемой работы вы никогда не останетесь.
Полезная статья для тех, кто в теме и вынужден решать подобные проблемы.
Однако, простая фоновая джоба хоть на обработке хоть на отсылке, да ещё однопоточная, просто не будет справляться при действительно высоких нагрузках. И начнется следующий этап борьбы - распараллеливание джоб и опять решение вопросов строгой упорядоченности и неповторов при успехе и повторов при определенных ошибках.
Кроме того, в статье возможно умышленно опущены вопросы идемпотентности ибо я слабо себе представляю чтобы сервис при схеме запрос-ответ молча проглотил повтор запроса и не выдал ответа.
Было бы круто в конце статьи увидеть обзор решений, которые частично или полностью решают подобные проблемы в распределенных системах с использованием асинхронного взаимодействия с брокерами сообщений и/или шинами данных.
Например, на сайте Temporal пример с переводом денег между счетами описан в качестве демо того как эта проблема там решается.
Использовали оракл экспортер для мониторинга своих высоконагруженных баз и корректности объектов по бизнес процессам своими кастомными запросами. В результате обнаружили что экспортер начинал глючить если запросы по метрикам, коих под сотню, не успевали супер быстро исполняться. Ничего не помогало особо ибо метрик очень много и почти все они непростые. В результате страданий написали на джобах свою систему сбора метрик в оракл в одном месте, а уже собранные показатели супер быстро вытаскивали экспортером. Это я к тому, что экспортеры написаны не лучшим образом и под хайлоад нужно или писать свой/переписывать чужой или подстраивать метрики.
Основная проблема оптимизаторов что в оракле что в постгрес для больших таблиц с постоянно меняющимися большими объёмами данных это когда собиралась статистика для выполняющегося запроса.
Я правильно понял, что у вас тоже сбор идет по каким то своим эвристикам с не очень прозрачным итоговым прогнозом по частоте сбора? Ну то есть план может спокойно плавать на одних и тех же запросах в зависимости от того когда собиралась статистика, что там в ней сейчас, и насколько она соответствует текущей ситуации в таблице?
Я приверженец канбана для опытных и сработанных команд с понятным скоупом возможных задач по продукту.
Вижу регулярно коллег соседей, работающих по скраму. Так вот мы с командой даем результат для бизнеса существенно быстрее, так же быстрее переключаемся на более приоритетные задачи, но работать как на конвейере без пауз для людей не просто, выгорают. Ну и у менеджера команды работа с бэклогом считай постоянная при канбане, потому что нужно нагружать команду задачами, а даже бизнес не всегда поспевает, тогда приходиться набрасывать оптимизации, тюнинг, рефакторинг в промежутках между фичами и релизами для бизнеса.
Ещё, если у вас есть работа с внешним вендором в команде от которой зависит и ваша работа, то как по мне спринты при таком варианте вообще не подходят, ну или вы будете для бизнеса крайне медленными.
Слабо представляю себе систему, где нужно, чтобы бизнес событие вычитывалось рандомно разными сервисами 1 раз. Всё остальное реализуется в amqp типа кролика как отправление конкретного типа события для конкретного подписчика, и там наоборот нужно поприседать чтобы отправить 1 событие на 2 и более подписчиков, когда сначала архитектура предполагала одного получателя, а потом вдруг нарисовались ещё, а последовательно отсылать по цепочке не вариант.
Ну и ещё нужно помнить про то, что если заранее в кролике не позаботиться о персистентности хранения события сначала на диске, то развал кластера с потерей всех событий что были в тот момент в памяти невычитанными при потере сетевой коннективности с необходимостью пересоздания кластера это прям реальность, о которой почему-то многие умалчивают.
Плюс нюансы с отдельными ретрай очередями на повтор, когда нарушается порядок вычитывания событий при восстановлении подписчика после сбоя.
Я к тому, что любую систему нужно уметь хорошо готовить под целевое использование, и не всегда эта цель видится в самом начале отчётливо )
Делать разработку по скраму эффективно можно только если нет зависимостей от внешних команд. Как только сроки вашей реализации зависят от чего-то внешнего (вендор, другая команда), то скрам превращается в профанацию и постоянные переносы, так как вы не можете обеспечить выход запланированного бизнесом в спринт, а команда и все планы бизнеса были сфокусированы на конкретной цели в спринте, и тогда существенно эффективнее канбан, где каждый ресурс команды постоянно нагружается потоком работы вне зависимости от планов на спринт и бизнес фичи сразу выпускаются по мере готовности. TTM проектов/фич для бизнеса в целом по году получается значительно лучше. Да, больше переключений контекста и релизов не всем по душе, да и следить одновременно нужно за большим количеством фич. Но с точки зрения именно бизнес результата ИТ тогда выглядит как неостанавливающаяся фабрика постоянно дающая результат. По крайней мере мой опыт именно такой.
Я бы не торопился с темпорал. В статье не указано на чём, то есть где темпорал хранит все сценарии и статусы у себя внутри. Допустим это постгрес или мускуль, а значит о простом горизонтальном масштабировании с ростом нагрузки можно забыть. Это ещё не упомянуто о том, что как и в любом оркестраторе, с ростом количества систем растет количество не только сценариев, но и шагов даже в старых сценариях, а при хайлоаде скажем даже в 50000 сценариев в секунду там всё лежать будет. А с учётом, что там основные бизнес процессы, то считай и вся компания.
Моё мнение, что единая оркестрация не подходит под действительно серьёзные нагрузки. Да, можно несколько оркестраторов использовать, но там другие вопросы возникнут...
С другой стороны, указанные в начале статьи проблемы можно было бы решить разбиением всех систем на продукты со своими командами системных архитекторов и разработки со связующим звеном в виде солюшен/ентерпрайз аналитиков и архитекторов. И тогда верхний уровень бизнес процессов описывается кубиками достаточно просто и внутренняя хореография командами продуктов тоже ведется с прекрасным пониманием что где как точно работает, и погружение новичков не проблема. Зато масштабирование систем продуктов с ростом бизнеса вообще не будет вызывать вопросов при хореографии и никогда весь бизнес не встанет из-за одного узкого места.
Моё мнение, вы просто ошиблись с архитектурой решения и не учли потенциальную нагрузку с учетом роста. По факту просто уперлись в производительность постгреса. Даже если вы сейчас потюните что-то, то это спасёт только на время. При подаче нагрузки ещё x2 у вас опять всё сляжет. Тут или использовать in-memory оркестраторы бп с такими же бд или всю оркестрацию бизнес процессов строить самим на базе Кафки.
Слышал, что сбер сделал свой bpmn движок platform v flow как раз на базе Кафки избавившись от бд, где все состояния бп в кафке и хранятся. Видимо тоже уперлись в бд...
Полностью согласен.
Наконец-то адекватный комментарий от человека с хайлоад нагрузкой и про финансовые данные.
Отсутствие хранимок при crud операциях это точно не про хайлоад Энтерпрайз.
Автор просто не сталкивался с грамотным их использованием, где и масштабирование в кубере сервисов с логикой обеспечивается и горизонтальное масштабирование стейтфул адаптеров к бд.
Скажу с позиции работодателя. Перечислены действительно базовые классические скилы для бэка. Обладая практическим инженерным опытом от 1 года по всем из них (автоматизация это отдельный стрим всё таки) без интересной и хорошо оплачиваемой работы вы никогда не останетесь.
Полезная статья для тех, кто в теме и вынужден решать подобные проблемы.
Однако, простая фоновая джоба хоть на обработке хоть на отсылке, да ещё однопоточная, просто не будет справляться при действительно высоких нагрузках. И начнется следующий этап борьбы - распараллеливание джоб и опять решение вопросов строгой упорядоченности и неповторов при успехе и повторов при определенных ошибках.
Кроме того, в статье возможно умышленно опущены вопросы идемпотентности ибо я слабо себе представляю чтобы сервис при схеме запрос-ответ молча проглотил повтор запроса и не выдал ответа.
Было бы круто в конце статьи увидеть обзор решений, которые частично или полностью решают подобные проблемы в распределенных системах с использованием асинхронного взаимодействия с брокерами сообщений и/или шинами данных.
Например, на сайте Temporal пример с переводом денег между счетами описан в качестве демо того как эта проблема там решается.