Comments 32
Вы ошибку проектирования системы — «функционал магазина вытащен на федеральный уровень, нет деления на бэк магазина и бэк бизнеса» прикрываете заклинанием «ты 1Сник, ты не поймешь». Объясните, почему так сделано, попробую понять. Может быть и фронт нужно в ту же одну базу тащить, может теперь так принято. Я же как бы не только 1С-ник, могу и SAP тот же поковырять, например ковырял базу одного сотового оператора из большой тройки. Постараюсь понять.
Тут недавно SAPовцев из одного ИТ-отдела попросили накидать конфигурацию сервера для дочки, 20 пользователей, 100 отгрузок в месяц. Получилось 3,5 млн. Ок ок ок.
P.S. ниже автор уже написал, что у магазинов свои базы, с ЦБ общаются через шину. Видимо 500 000 запросов в секунду не из-за количества пользователей и процессов в базе, а из-за архитектуры этих процессов.
Про 1с скажу так — центральная база с парой сотней пользователей была под терабайт, прирост порядка 2 гигов в день, суммарное количество пользователей по всей сети — около 1000. А дело в том, что в каждом из полусотни магазинов работал «сервер» на уровне хорошей офисной машины (ну разве что оперативки побольше, аж 8гб). В центре да, железяки помощнее — аж два сервера на 16 ядер и 96гигов оперативы в сумме. Оперативность появления данных конечных узлов в центре — от 10 до 20 минут при условии неотваливания каналов связи. В обратную сторону — также. Про функционал — я не в курсе, в чем он «несравним». почему-то все об этом пишут, но конкретных прикладных функций, которых нет в типовых и которые принципиально не реализуются при внедрении — не встречал.
Ну а в хайлоад я не лезу, да.
1. Добавление поля в detail-таблицу. В результате чего фильтровали сразу по detail-таблице.
2. Создание custom-таблицы с уникальным ключом из detail-таблицы и полями из master- и detail- таблиц, используемыми для фильтра (по сути кластерный индекс). В результате фильтруем по custom-таблице и соединяем с master- и detail- таблицами по ключу.
По поводу рисков при обновлении/установке патча:
В SAP эти проблемы решаются при корректной имплементации изменений. В подобных таблицах зачастую в словаре на уровне приложения предусмотрен инклюд для custom-полей. В функциональных модулях обновления предусмотрены так называемые user-exit'ы — фрагменты для custom-кода, в которых мы и обеспечиваем заполнение новых полей. Если custom-доработки стандарта реализованы в предназначенных для этого местах, то они не воспринимаются, как модификация («подлом») стандартных объектов и при апгрейде/установке патча можно избежать «танцев с бубнами».
В прочих же системах — да, стоит учитывать риски, которые могут возникнуть при обновлении, если они существуют.
Нагрузочное тестирование состоит из двух этапов:
1. Запуск полного профиля нагрузки, приблизительно как в продуктиве. Профиль включает в себя критичные бизнес-процессы (те самые расчёты на тысячах магазинов, по которым есть строгий SLA), TOP 80% потребителей ресурсов (по результатам анализа почасовой раскладки продуктивной нагрузки в разрезе программ/бизнес-процессов), новый функционал (если в релизе есть не только доработка существующих процессов, но и внедрение новых).
2. Профилирование единичных запусков расчётов по избранным магазинам (single thread тест).
На каждом из этапов выполняются тесты до внесения изменений и после (по сути эталонное тестирование).
На этапе полномасштабного теста после тестирования анализируется почасовая раскладка потребителей ресурсов в разрезе программ/бизнес-процессов, выявляются новые участники в TOP 80% источниках нагрузки и фиксируется необходимость выполнения их профилировки.
На этапе single thread теста по результатам профилировки программ анализируется TOP 80% конструкций отдельно по каждому запуску, выявляются новые конструкции в TOP 80%, влияющие на нагрузку, определяются дальнейшие меры по их оптимизации.
Описанные выше тесты выполняются в тестовой системе, по мощности равной продуктивной.
Наряду с этими тестами обязательным является профилирование меняемых/разрабатываемых программ в системе оценки качества до того, как они переносятся в тестовую систему. Т.е. в менее производительной системе выполняются single thread тесты на ограниченном объёме данных и по результатам профилировки ещё на этапе разработки выявляются неоптимальные конструкции и типовые ошибки, методы борьбы с которыми мы описали в применяемом у нас кодексе разработчика. Каждое изменение проходит через так называемый чек-лист.
>Даже до окончания его согласования нужно было продержаться несколько месяцев и не уронить SLA.
Можно пару слов про это, что такое «уронить SLA» и чем это чревато?
>Уровень нагрузки – 500 000 запросов в секунду
Получается около сорока запросов в секунду с магазина, можете поподробнее рассказать про эти запросы, что в них «запрашивается» с такой скоростью?
Про SLA:
Есть SLA по ряду процессов (например, расчёт цен или планирование пополнения запасов): к открытию каждого магазина расчёты должны быть завершены и их результаты должны дойти через систему интеграции до магазина. В последнем разделе статьи описывается период развития системы, в котором запас по времени выполнения процессов до нарушения SLA был невелик и бездействие привело бы в скором к срывам сроков завершения ежедневных регулярных процессов. Чем чревато — описано в первом разделе статьи: «если вовремя не будет посчитано, какие товары в каком количестве должны быть завтра доставлены в магазин либо какая цена должна быть на товары, покупатели не найдут на полках то, что искали, либо не смогут приобрести товар по цене действующей промо-акции»
Про уровень нагрузки:
500.000 запросов — это интенсивность обращений с серверов приложений к БД. Они порождаются разнородными процессами:
— регулярные расчёты, некоторые из которых описаны выше (например, в ходе расчётов по каждому товару, которых тысячи в ассортименте, запрашиваются мастер-данные с настройками, используемыми при прогнозировании, данные о действующих промо-акциях, данные по продажам и т.д.);
— интеграционные процессы (например, обращения к БД, выполняемые при отправке заказов в магазины или получении ответов от магазинов с подтверждением заказов)
— пользовательские процессы (например, запуск программ, формирующих налоговые декларации на основе первичных финансовых документов и т.п.)
— процессы обновления мастер-данных и т.д.
Относительно расчётов при миграции на HANA: расчёты могут достаточно точно показать размер БД после миграции (такие расчёты выполняются скриптами, поставляемыми вендором), но оценить прирост производительности наиболее точно помогут тесты на стенде, методики таких расчётов нет. Расчёты помогут лишь оценить ту долю нагрузки, на которую повлияет миграция (без рефакторинга процессов): например, если процесс проводит 30% времени в БД, а 70% — на сервере приложений, то не стоит ожидать кратного ускорения его выполнения после миграции на другую СУБД.
По ERP таких планов пока нет. Scale-out OLTP очень скользкий вопрос, а на наших объемах у нас выйдет немало нод. Субъективно, пока наш ERP не готов к HANA, да и HANA, скорее всего, не готова конкретно к нему.
Ну и выбор 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 рассматривается как альтернатива?
"Эта архитектура – гетерогенная среда. Каждый из компонентов кроссплатформенный, мы можем перемещать его на разные платформы, выбирать оптимальные и т.д." — от этого абзаца мой кот заплакал. Набор слов.
Оптимизация join ов… В сап.
Использование перебора в циках?!?!? Это в толстом клиенте запускается скрипт, который тянет херову тучу ненужных данных на клиент, из разных мест, а потом на клиенте их в цикле join ит???!!! Видал я такое в axapta и прочих конструкторах.
Мне интересно, как вы оптимизируете штатный функционал ерп, который написан на каком то своем диалекте. Он закрытый. Чтобы оптимизировать запросы, нужно мочь в семантику структуры.
Зачем толстые клиенты? В рдп никак? Тогда ваши терабайты превратятся в мкгабайты.
При чем здесь графана? Это надстройка над заббиксом для отображения метрик. Вы ей что ускопяли?
"например время отклика и пропускная способность специфичных компонентов SAP" время отклика чего? Пропускная способность чего? Накормить доп железом не получилось по причине дороговизны, по этому использовали графану для ускорения пропускной способности кнопочек в сап.
"приоритет запуска новых пакетов выстраивался не по этапам, а по магазинам" — это вообще тривиально. И как оно у вас работало в разных часовых поясах?.. Ах да… Вы с ДВ ещё не работали, когда мск ночь там день… И дни разные, а соотв и цены, акции и т.д.
" идентичные обращения к БД с одними и теми же условиями в рамках одного процесса.." — делается самой БД. Другое дело, что у вас супер сап и толстые клиенты со своим диалектом.
"частые join-запросы..." вообще жесть… Перекладывание на сервера приложений прямые функции субд.
Это ещё раз говорит о том, что сап использует субд просто как хранилище.
В итоге, у вас обна бд, пусть и с бэкапами на которую идёт вся нагрузка от толстых клиентов. То есть горячей замены нет?
Highload++: Как помочь ERP-системе справиться с 500 000 запросов в секунду