Pull to refresh

Comments 32

Интересно, что highload'у есть место и в «кровавом энтерпрайзе»
У нас на полусотне магазинов мы просто сделали двухуровневый РИБ на 1с, никаких особых проблем не было.
Тоже в шоке, четырехуровневая (федеральный-областной-районный-магазин) база Центросоюза на 1С держит сопоставимое количество (тысячи) торговых объектов и не кашляет. SAP не может в иерархию? Обязательно цены пересчитывать по всей сети на одном железе?
У вас «иллюзия одинесника». Функционал не сопоставим. Понятно, что если передавать просто регистр сведений с остатками и реестр проданных товаров, то тут даже просто одна база MS SQL справится. SAP у них делает не то же самое.
Какой регистр сведений с остатками? Какая иллюзия? В ЦБ «Центросоюза» все документы всех магазинов. Какое не то же самое? Какой такой функционал есть в конкретном магазине в Пятерочке, что он кардинально отличается от функционала в соседнем магазине, например «Красное и белое» (6000 штук, топ-5), который весь на 1С?

Вы ошибку проектирования системы — «функционал магазина вытащен на федеральный уровень, нет деления на бэк магазина и бэк бизнеса» прикрываете заклинанием «ты 1Сник, ты не поймешь». Объясните, почему так сделано, попробую понять. Может быть и фронт нужно в ту же одну базу тащить, может теперь так принято. Я же как бы не только 1С-ник, могу и SAP тот же поковырять, например ковырял базу одного сотового оператора из большой тройки. Постараюсь понять.

Тут недавно SAPовцев из одного ИТ-отдела попросили накидать конфигурацию сервера для дочки, 20 пользователей, 100 отгрузок в месяц. Получилось 3,5 млн. Ок ок ок.

P.S. ниже автор уже написал, что у магазинов свои базы, с ЦБ общаются через шину. Видимо 500 000 запросов в секунду не из-за количества пользователей и процессов в базе, а из-за архитектуры этих процессов.
«У нас на полусотне магазинов» звучит почти как " я дома сделал из тележки и пылесоса электромобиль, поэтому не понимаю, что мешает Маску выпускать 5000 электромобилей. Плюс, как верно заметили ниже — функционал SAP и 1С несравним
Я просто задал вопрос — сап умеет в иерархию или нет? Зачем держать все эти сотни тысяч пользователей в одном месте?
Про 1с скажу так — центральная база с парой сотней пользователей была под терабайт, прирост порядка 2 гигов в день, суммарное количество пользователей по всей сети — около 1000. А дело в том, что в каждом из полусотни магазинов работал «сервер» на уровне хорошей офисной машины (ну разве что оперативки побольше, аж 8гб). В центре да, железяки помощнее — аж два сервера на 16 ядер и 96гигов оперативы в сумме. Оперативность появления данных конечных узлов в центре — от 10 до 20 минут при условии неотваливания каналов связи. В обратную сторону — также. Про функционал — я не в курсе, в чем он «несравним». почему-то все об этом пишут, но конкретных прикладных функций, которых нет в типовых и которые принципиально не реализуются при внедрении — не встречал.
Ну а в хайлоад я не лезу, да.
UFO just landed and posted this here
Денормализацию в этой истории применяли в единичных случаях. Варианты реализации были следующие:
1. Добавление поля в detail-таблицу. В результате чего фильтровали сразу по detail-таблице.
2. Создание custom-таблицы с уникальным ключом из detail-таблицы и полями из master- и detail- таблиц, используемыми для фильтра (по сути кластерный индекс). В результате фильтруем по custom-таблице и соединяем с master- и detail- таблицами по ключу.

По поводу рисков при обновлении/установке патча:
В SAP эти проблемы решаются при корректной имплементации изменений. В подобных таблицах зачастую в словаре на уровне приложения предусмотрен инклюд для custom-полей. В функциональных модулях обновления предусмотрены так называемые user-exit'ы — фрагменты для custom-кода, в которых мы и обеспечиваем заполнение новых полей. Если custom-доработки стандарта реализованы в предназначенных для этого местах, то они не воспринимаются, как модификация («подлом») стандартных объектов и при апгрейде/установке патча можно избежать «танцев с бубнами».
В прочих же системах — да, стоит учитывать риски, которые могут возникнуть при обновлении, если они существуют.
UFO just landed and posted this here
А как происходит установка обновлений и тестирование нового функционала? т.е. как выявляются случаи, когда допустим небольшая доработка механизма расчета цен при умножении на 5000 магазинов приводит к перегрузке сервера БД
Разработка нового функционала и установка обновлений у нас проводятся в рамках релизных циклов. Длительность одного цикла в среднем один месяц. В течение одного цикла выполняется две-три итерации накатки релизных изменений и тестирования.

Нагрузочное тестирование состоит из двух этапов:

1. Запуск полного профиля нагрузки, приблизительно как в продуктиве. Профиль включает в себя критичные бизнес-процессы (те самые расчёты на тысячах магазинов, по которым есть строгий SLA), TOP 80% потребителей ресурсов (по результатам анализа почасовой раскладки продуктивной нагрузки в разрезе программ/бизнес-процессов), новый функционал (если в релизе есть не только доработка существующих процессов, но и внедрение новых).

2. Профилирование единичных запусков расчётов по избранным магазинам (single thread тест).

На каждом из этапов выполняются тесты до внесения изменений и после (по сути эталонное тестирование).
На этапе полномасштабного теста после тестирования анализируется почасовая раскладка потребителей ресурсов в разрезе программ/бизнес-процессов, выявляются новые участники в TOP 80% источниках нагрузки и фиксируется необходимость выполнения их профилировки.
На этапе single thread теста по результатам профилировки программ анализируется TOP 80% конструкций отдельно по каждому запуску, выявляются новые конструкции в TOP 80%, влияющие на нагрузку, определяются дальнейшие меры по их оптимизации.

Описанные выше тесты выполняются в тестовой системе, по мощности равной продуктивной.
Наряду с этими тестами обязательным является профилирование меняемых/разрабатываемых программ в системе оценки качества до того, как они переносятся в тестовую систему. Т.е. в менее производительной системе выполняются single thread тесты на ограниченном объёме данных и по результатам профилировки ещё на этапе разработки выявляются неоптимальные конструкции и типовые ошибки, методы борьбы с которыми мы описали в применяемом у нас кодексе разработчика. Каждое изменение проходит через так называемый чек-лист.
Спасибо за ответ. я так понял для п.1 требуется восстановление копии БД с какими-то настроенными данными. Сколько вообще оно занимает по времени при таком объеме(в 100ТБ)? это часы или дни?
Регулярно, раз в месяц мы проводим копирование продуктивной системы в тестовую путём восстановления копии системы из бэкапа. Непосредственно восстановление БД занимает порядка 12-14 часов. Дополнительно после восстановления выполняются технические операции по подготовке тестовой среды, которые занимают ещё несколько часов (смена имени логической системы, настройка соединений с тестовыми средами и т.д. и т.п.); большинство этих операций у нас автоматизировано. После копирования системы, в основном, все необходимые данные для тестирования есть — мастер-данные по товарам, промо-акциям и т.д. В дополнение к этим данным перед каждым тестом генерируются данные по продажам за день для обеспечения нагрузочного тестирования функционала планирования пополнения товарных запасов (эти данные генерируются по запросу программой не дольше часа).
Очень интересная статья, но кое-что непонятно.

>Даже до окончания его согласования нужно было продержаться несколько месяцев и не уронить SLA.

Можно пару слов про это, что такое «уронить SLA» и чем это чревато?

>Уровень нагрузки – 500 000 запросов в секунду

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

Про SLA:
Есть SLA по ряду процессов (например, расчёт цен или планирование пополнения запасов): к открытию каждого магазина расчёты должны быть завершены и их результаты должны дойти через систему интеграции до магазина. В последнем разделе статьи описывается период развития системы, в котором запас по времени выполнения процессов до нарушения SLA был невелик и бездействие привело бы в скором к срывам сроков завершения ежедневных регулярных процессов. Чем чревато — описано в первом разделе статьи: «если вовремя не будет посчитано, какие товары в каком количестве должны быть завтра доставлены в магазин либо какая цена должна быть на товары, покупатели не найдут на полках то, что искали, либо не смогут приобрести товар по цене действующей промо-акции»

Про уровень нагрузки:
500.000 запросов — это интенсивность обращений с серверов приложений к БД. Они порождаются разнородными процессами:
— регулярные расчёты, некоторые из которых описаны выше (например, в ходе расчётов по каждому товару, которых тысячи в ассортименте, запрашиваются мастер-данные с настройками, используемыми при прогнозировании, данные о действующих промо-акциях, данные по продажам и т.д.);
— интеграционные процессы (например, обращения к БД, выполняемые при отправке заказов в магазины или получении ответов от магазинов с подтверждением заказов)
— пользовательские процессы (например, запуск программ, формирующих налоговые декларации на основе первичных финансовых документов и т.п.)
— процессы обновления мастер-данных и т.д.
Недавно были опубликованы планы по переходу X5 на SAP HANA. Делали ли расчет, как изменится производительность в этом случае?
Уточните, пожалуйста, о какой публикации идёт речь. Вероятно, это давняя публикация о переходе на SAP HANA системы BW, не имеющая отношения к системе ERP, о которой рассказано в данной истории.
Относительно расчётов при миграции на HANA: расчёты могут достаточно точно показать размер БД после миграции (такие расчёты выполняются скриптами, поставляемыми вендором), но оценить прирост производительности наиболее точно помогут тесты на стенде, методики таких расчётов нет. Расчёты помогут лишь оценить ту долю нагрузки, на которую повлияет миграция (без рефакторинга процессов): например, если процесс проводит 30% времени в БД, а 70% — на сервере приложений, то не стоит ожидать кратного ускорения его выполнения после миграции на другую СУБД.
Мы перевели BW на HANA, и это хорошая тема для отдельной статьи. Она прекрасно проявляет себя в OLAP'е, хотя есть и свои нюансы и слабые места.
По ERP таких планов пока нет. Scale-out OLTP очень скользкий вопрос, а на наших объемах у нас выйдет немало нод. Субъективно, пока наш ERP не готов к HANA, да и HANA, скорее всего, не готова конкретно к нему.
А почему СУБД хотя бы на master-slave не пробовали кластеризовать (на мастер только UPDATE/INSERT отправлять, а SELECT'ы на слэйвы)? А тем более RAC раз у вас Oracle для master-master попробовать? Так и отказоустойчивость бы повысилась…

Ну и выбор ERP-решения/framework'а с логическими блокировками на уровне сервера приложений для Highload'а это конечно такое себе решение… То есть что вы будете в следующий раз когда нагрузка дорастет до критического объема с сервером блокировок делать? Не говоря уже о том что это опять таки дополнительная точка отказа.
Очень хорошие вопросы, спасибо.
Есть стоп-факторы, кроющиеся в объеме данных и интенсивности изменений, а также в самой платформе приложения. SAP ABAP позволяет выполнять достаточно глубокую интервенцию в логику и архитектуру, но с определенного уровня она ограничена технически и, так сказать, лицензионно.
Например, развертывание того же active standby было бы удобным, если бы не итоговая стоимость инфраструктуры и ограниченность применения из-за задержки накатки изменений, а также необходимости «костылей» в приложении.
К проработке RAC возвращаемся регулярно. Пока это оказывалось спорным решением, несмотря на киллер-фичу с потенциальным zero-DT. Например, на текущих объемах и интенсивности нужно далеко не 2 ноды, и на нагрузочных тестах того же ночного профиля наблюдали очень большие потери на sync. В итоге, как бы это странно не звучало, дешевле, стабильнее и эффективнее оказывался scale-up. Но мы продолжаем думать о RAC.
История с резким повышением интенсивности роста компании, превращением системы в highload, и вылезшим лимитом enqueue server здорово нас «взбодрила». Сейчас он достаточно мощный и в отказоустойчивой конфигурации, но мы осознаем «тупик» с ним в будущем.
Сейчас мы активно работаем над уменьшением объема горячих данных, прорабатываем вынос части функционала в отдельные системы, ETL и эффективный sync мастер-данных, чтобы сделать решение гибким и горизонтально масштабируемым, как в целом, так и в слое СУБД.
Не совсем понял в чем заключается проблема лицензионности, если только там привязки к железу СУБД нет конечно. Я конечно слышал легенды, что САП лицензии даже к прокаченной нефти привязывает, но в данном случае это было бы выстрелом себе в ногу.

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

Кстати раз уж пошла такая пьянка, что-то у меня цифры не сходятся, вы говорите что на 13000 магазинов у вас 5000 одновременных подключений (или вы что-то другое имеете ввиду под 5000 толстых клиентов), хотя по идее должно быть минимум 50000. Правда если учесть
— интеграционные процессы (например, обращения к БД, выполняемые при отправке заказов в магазины или получении ответов от магазинов с подтверждением заказов)

получается у вас сами магазины не в этой ERP системе работают? И если так, то как вы ограничения (и вообще операции которые должны приводить к отмене транзакции) обрабатываете? Самый тупой пример — 2 магазина заказывают один и тот же товар с распредцентра и им обоим его не хватает?
По вопросам:

5000 — примерное количество пользователей, одновременно работающих через толстый клиент SAPGUI. Это пользователи центрального и региональных офисов (логистика, транспорт, бухгалтерия и т.д.)

Магазины и распределительные центры напрямую в ERP не работают. Специализированные системы, используемые в магазинах и РЦ, общаются с ERP через шину интеграции.

Как обрабатываются ограничения: в процессе пополнения обработка таких ограничений обеспечивается статусной схемой заказов — ERP получает от систем РЦ и магазинов сообщения со статусами и корректировками заказов, в результате обработки которых меняет соответствующим образом заказы.

О примере про 2 магазина, которые заказывают один и тот же товар с РЦ и обоим его не хватает: это исключительно редкая ситуация, т.к. пополнение запасов РЦ рассчитывается на основе прогноза пополнения магазинов на несколько дней вперёд и, кроме того, на РЦ присутствует страховой запас на случай открытия магазинов или повышенного спроса. Обработка ситуаций нехватки товара на РЦ зависит от стратегии комплектации на конкретном РЦ (например, в случае нехватки распределить товар равномерно между магазинами / отгрузить товар на магазин с минимальным запасом и т.п.).
Магазины и распределительные центры напрямую в ERP не работают. Специализированные системы, используемые в магазинах и РЦ, общаются с ERP через шину интеграции.


А они в одной базе работают или в разных, потому как если в одной — то там кейс с 50к одновременных подключений возможно даже интересней, чем кейс этой статьи с 5к подключений. Если в разных — то еще интересней, как вы администрируете / обновляете / хостите 13к баз, учитывая что у вас каждую неделю по новому релизу?

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

Но вообще с нехваткой остатка это один из примеров. Ведь во многом смысл борьбы за одну базу и заключается в возможности создавать глобальные «гарантированные» ограничения, которые не могут быть нарушены из-за задержек в интеграционных процессах.
Про работу магазинов/РЦ:
Магазины и РЦ работают в разных базах (у каждого объекта своя система — т.е. да, у нас более 13000 систем со своей базой, которые являются клиентами в интеграционных процессах с ERP), асинхронно общаясь с ERP через шину интеграции. Релизы у нас в среднем раз в месяц (об этом мы писали ранее в комментариях). Описание процессов обновления/администрирования такого количества систем — это хорошая тема для отдельной статьи.

Про решение ограничений при изменении заказов и борьбу за общие ресурсы:
Интеграция магазинов с центральной системой (ERP) асинхронная, борьбы за общий ресурс в интеграционных процессах нет, изменения статусов и корректировки заказов доходят не моментально, а с гарантированной доставкой в течение короткого промежутка времени в соответствии с SLA, который обеспечен отказоустойчивой конфигурацией системы интеграции. И это тоже хороший материал для отдельной статьи.
Спасибо за ответ, тогда все встало на свои места, а то мне было непонятно, как такая крупная компания могла жить три года в режиме, что в течении следующего условного месяца-двух, весь ее бизнес может тупо встать. А тут получается речь шла не о «втором» уровне — бэке («первый» — фронт), а о «третьем» — управленческом уровне. Конечно при его клинче, приятного тоже мало было бы, но запасной план можно было придумать.

В любом случае было реально интересно, буду ждать ваши следующие статьи.

У вас Oracle сейчас на POWER работает?
Переход на Exadata рассматривается как альтернатива?

Да, сейчас БД на POWER. Exadata полноценно тестировали 3 года назад, показала хорошую производительность на нашем профиле, но сопоставимую с single x86_64 на «флешах». Регулярно, как говорил выше в комментариях, возвращаемся к мыслям и просчетам RAC, как на кастомной инфраструктуре, так и appliance от вендора. Но пока остаемся в текущей архитектуре после оценок рисков, например, таких как смена профиля нагрузки вместе с архитектурой/ОС, усложнение инфраструктуры, высокие расходы на sync нод под высоконагруженый OLTP на текущем объеме и потенциальные проблемы, и прочих прочих плюсов-минусов, нюансов миграции и т.п.
А классический вопрос — вы в ЦО остатки по магазинам видите? с какой задержкой?
В ERP в процессе пополнения запасов при составлении прогноза учитываются текущие остатки товаров и продажи за предыдущие дни. Данные об отгрузках или возвратах товаров приходят в течение дня в систему POS DM, в которой уже агрегируются (в разрезе магазинов по товарам) и передаются в ERP. Основная часть данных по продажам приходит в POS DM и в агрегированном виде передаётся в ERP после закрытия кассового дня (в конце рабочего дня), обрабатывается и приводит к обновлению остатков перед запуском процесса расчёта пополнения запасов. Таким образом, актуальные данные по остаткам на конкретную дату в ERP мы видим с задержкой не более суток.

"Эта архитектура – гетерогенная среда. Каждый из компонентов кроссплатформенный, мы можем перемещать его на разные платформы, выбирать оптимальные и т.д." — от этого абзаца мой кот заплакал. Набор слов.
Оптимизация join ов… В сап.
Использование перебора в циках?!?!? Это в толстом клиенте запускается скрипт, который тянет херову тучу ненужных данных на клиент, из разных мест, а потом на клиенте их в цикле join ит???!!! Видал я такое в axapta и прочих конструкторах.
Мне интересно, как вы оптимизируете штатный функционал ерп, который написан на каком то своем диалекте. Он закрытый. Чтобы оптимизировать запросы, нужно мочь в семантику структуры.
Зачем толстые клиенты? В рдп никак? Тогда ваши терабайты превратятся в мкгабайты.
При чем здесь графана? Это надстройка над заббиксом для отображения метрик. Вы ей что ускопяли?
"например время отклика и пропускная способность специфичных компонентов SAP" время отклика чего? Пропускная способность чего? Накормить доп железом не получилось по причине дороговизны, по этому использовали графану для ускорения пропускной способности кнопочек в сап.


"приоритет запуска новых пакетов выстраивался не по этапам, а по магазинам" — это вообще тривиально. И как оно у вас работало в разных часовых поясах?.. Ах да… Вы с ДВ ещё не работали, когда мск ночь там день… И дни разные, а соотв и цены, акции и т.д.
" идентичные обращения к БД с одними и теми же условиями в рамках одного процесса.." — делается самой БД. Другое дело, что у вас супер сап и толстые клиенты со своим диалектом.
"частые join-запросы..." вообще жесть… Перекладывание на сервера приложений прямые функции субд.
Это ещё раз говорит о том, что сап использует субд просто как хранилище.
В итоге, у вас обна бд, пусть и с бэкапами на которую идёт вся нагрузка от толстых клиентов. То есть горячей замены нет?

Планируете как-нибудь бороться с дичайшими тормозами BO2/BI2 по утрам вторников? Отчеты формируются в 10-20-30 раз дольше и не факт, что не вывалятся с какой-нибудь ошибкой. В итоге сервер просто умирает и не дает даже залогиниться.
Sign up to leave a comment.