«Завтра 20-е число, а значит снова будет шторм. Остановить его невозможно, только подготовиться и надеяться, что в этот раз пронесет, случится чудо, и наш озерный паром покорит океан». Такие мысли одолевали команду, занимающуюся поддержкой портала муниципальных услуг еще несколько лет назад. Как мы попали в эту ситуацию и как мы из нее нашли выход будет рассказано ниже.
Как всё начиналось
В далеких 1990-х годах область ЖКХ испытывала бум развития, внедрялись новые технологии, автоматизированные информационные системы, закупалась новая техника. Но кое-что оставалось долгое время практически без изменений, а именно платежки за квартиру. Да-да, те самые квиточки за квартиру, трансформировавшись в платежные документы, обретя штрих-коды, детальную расшифровку, оставались по-прежнему бумажками. Типовая схема работы расчетного центра предприятия ЖКХ или ресурсоснабжающего предприятия была следующей:
Постепенно модемный интернет заменялся на широкополосный доступ, возникла мысль — почему бы не получать онлайн платежные документы в электронном виде? В это же время сферу ЖКХ трясло и в организационном виде, МПП ЖКХ (муниципальное производственное предприятие жилищно-коммунального хозяйства) сменяли МУПы (муниципальные унитарные предприятия), ДЕЗы (дирекции единого заказчика). По итогам всех трансформаций произошло отчуждение ИТ-отделов предприятий ЖКХ, и на их базе родились всевозможные расчетные центры. Суть расчетных центров заключалась в, собственно, расчете квартплаты и информационном обеспечении населения.
Этап роста, 00-ые
Именно тогда родились первые информационные порталы, предоставляющие населению услуги в электронном виде. Число первых пользователей измерялось десятками, не все доверяли платежным документам в электронном виде, другие еще не слышали о новшествах, мобильные приложения в сфере госуслуг были редкостью. Работа информационных порталов не сильно отличалась от работы привычных информационных систем и, конечно, ни разу не являлась хайлоад архитектурой.
Шли годы, порталы совершенствовались, появились возможности принимать показания приборов учета, формировать справки и т.д. Именно в это время на горизонте появились первые «тучки», все больше и больше пользователей начали регистрироваться на порталах и запрашивать данные. Вдали показалась первая волна приближающихся нагрузок.
Команда (далее — Команда 1) предприняла следующие меры по оптимизации:
- Изменение размера платежного документа в PDF с 0.5Мб до 0.2Мб
- Создание очереди формирования платежных документов
- Хранение сформированных платежных документов для повторного запроса
- Создание реплики основной базы, только для нужд портала
Несколько лет ситуация казалась стабильной, количество пользователей отдельных порталов измерялось тысячами, еще не штормило, но покачивало существенно, децентрализация расчетных центров играла на руку разработчикам.
Этап большого скачка
Новой вехой в истории стало развитие портала муниципальных услуг на уровне региона. Включение единой точки входа для любого жителя республики было заманчивой идеей, дополнительно это позволило бы поднять рейтинг государственного сайта на уровень лучших коммерческих или банковских сайтов, где каждый житель региона получал бы множество различного рода услуг. Одной из самых востребованных могла стать оплата жилищно-коммунальных услуг и внесение показаний приборов учета.
Таким образом, следующим этапом стало отделение оперативной информации расчетных центров от информации, отображаемой в платежном документе. Для этого были разработаны простой формат передачи данных и база для хранения информации, проведен расчет необходимого для хранения места на 5 лет эксплуатации.
Ключевые решения, предпринятые на этом этапе:
- Отделение части информации оперативной базы данных;
- Разработка базы данных для хранения этого формата;
- Объединение данных расчетных центров регионов в единую базу данных;
- Интеграция с процессами портала, разработка сервисов.
На этом этапе решение из полноценного превратилось в бэкенд, так как портал предоставлял пользователям единый интерфейс. У портала была своя команда, которая разрабатывала его независимо от текущего решения расчетных центров. В нашей истории появляется вторая команда (далее — Команда 2) и новый вендор. Как увидим далее, это существенным образом повлияло на развитие и решение проблем. Суть проектного решения была следующей:
При проектировании БД принималось простое отображение формата в базу данных, в качестве СУБД был выбран PostgreSQL 9.3 (на тот момент вполне актуальная версия). Формат состоял из 9 плоских файлов, каждый из которых загружался командой COPY (читаем — очень быстро) в множество таблиц конкретного расчетного центра (у каждого расчетного центра был свой регистрационный номер) базы портала. В некоторых расчетных центрах количество записей, необходимых для формирования платежных документов, доходило до 1 000 000. В год это составляло до 12 000 000, за 5 лет -60 000 000. Количество запросов к данной базе увеличивалось до суммы всех пользователей районных порталов и могло составить десятки тысяч. Было, о чем задуматься.
Не имея подобного опыта, Команда 1 предприняла следующие шаги для снижения потенциальной нагрузки:
- Таблицы были разделены по расчетным центрам и месяцам партиционированием;
- Процесс загрузки данных разнесен по времени для разных расчетных центров.
Проблемы слишком быстрого роста
Портал был запущен, и подготовленные планы столкнулись с реальностью:
- Число пользователей превысило расчетное очень быстро
- Запросы шли к мастер таблице, но СУБД все равно опрашивало все таблицы
- Паразитная нагрузка на сервер БД. На этом сервере существовали другие, несравненно большие БД, информация в которые поступала в случайные моменты, загрузка ее забирала все доступные ресурсы
- Сервис формирования платежного документа тормозил вследствие неэффективной реализации
- Нагрузка от пользователей не равномерно раскладывалась по месяцу, а концентрировалась в двух периодах:
Этот момент и описан в начале поста. Сложно было диагностировать проблему, потому что проблемы казались во всех местах сразу. Команда 1 и Команда 2, одинаково любимые своим руководством, предпринимали шаги для выхода из ситуации, но общения между собой практически не было:
Команда 2 предприняла, казалось, логичный и полезный шаг: формирование платежного документа стало запрашиваться сразу после захода пользователя в систему, в расчете на то, что пока он по страницам доберется до нужного места, ПД уже сформируется, а готовый документ подтянуть можно быстро.
В это время Команда 1 каждый месяц героически решала по одной проблеме в месяц, каждый раз убеждая заказчика, что именно там скрывался корень проблемы:
- Оптимизировали SQL (получили рост производительности в разы);
- Отделили сервер базы данных для портала от остальных баз данных;
- Вынесли формирование платежного документа в отдельное приложение и тоже оптимизировали;
- Пересмотрели обращение к мастер таблице, поменяли версию PostgreSQL;
- Еще раз пересмотрели обращение (теперь от мастер таблицы запрашивалась только 1 конкретная партиция — еще ускорение в разы).
Героические усилия команд приводили к локальным успехам (2-3 месяца казалось, что проблема решена). Но реальность все время подбрасывала новые вводные:
- База данных уже содержала несколько лет и выросла более 1 Тб;
- Количество пользователей составляло уже сотни тысяч.
Пока шла борьба, Команда 2 настроила автоматический тест сервисов, так что о любой проблеме производительности становилось известно в считанные минуты и эскалация проблемы на самые верхние уровни управления происходила автоматически через электронную почту.
В это время в Команде 1:
- Время архивации БД стало превышать допустимы пределы (сервис становился недоступен);
- Одно обращение к сервису сразу затрагивало много месяцев, соответственно генерировало много запросов;
- СУБД стало хуже отрабатывать запросы из-за роста числа таблиц (партиций);
- Пользователи, которые хотели только внести показания приборов, все равно запрашивали формирование платежных документов (вспомним решение Команды 2).
Стало ясно, что с технической точки зрения решение подошло к своему пределу и пора приниматься за анализ поведения пользователей с целью оптимизации процессов или кардинальной смене технологий.
В результате анализа (тут тема для отдельной статьи) предприняли следующие действия:
- Выполнили отсечение данных до 3-х последних лет, так как в предыдущий период обращений не было; тех пор ежегодно отсекается старый период;
- Переделали обращение к мастер таблице на обращение к конкретной партиции напрямую (снизили нагрузку на СУБД).
Настоящее время
Сейчас система достаточно стабильна, укладывается в регламентные сроки и требования по нефункциональным характеристикам, но на горизонте снова появились тучи:
- Дальнейший рост числа пользователей;
- Рост числа обслуживаемых домохозяйств;
- Увеличение сложности предоставляемых услуг;
- Рост детализации данных, доступных для пользователей.
Поэтому составляется план и подготавливается реализация следующих мер:
- Анализ поведения пользователей: сколько из них действительно просматривают платежный документ, а сколько — просто платит сумму, как за сотовый телефон;
- Предварительное формирование платежных документов по тем пользователям, которые обычно смотрят платежные документы, в момент наименьшей нагрузки;
- Переход на альтернативные технологии (да-да, многие из дошедших до этого пункта имеют гораздо более совершенные решения, решивших все вопросы изначально, на ресурсах мобильного телефона).
Казалось бы, на этом можно поставить большую оптимистичную точку. Все молодцы: и те, кто делал и те, кто сделал бы сразу лучше. Но завтра будут новые Highload проекты, новые незнакомые еще проблемы. Как к ним подготовиться сейчас, что можно предусмотреть, когда еще нет данных?
Системный подход к решению проблем
Можем ли мы превратить опыт в методологию подхода к проблемам в Highload-проектах? Как ни странно, ответ ДА, все уже придумано за нас и находится в рамках Теории ограничений Э.Голдратта (Theory of Constraint TOC). Всего 5 простых шагов:
- Найти ограничение (ограничения) системы.
- Решить, как максимально использовать ограничение (ограничения) системы.
- Подчинить все остальное этому решению.
- Расширить ограничение (ограничения) системы.
- ВНИМАНИЕ! Если за предыдущие 4 шага ограничение было устранено, вернуться к шагу 1, но не позволить инерции стать причиной возникновения ограничения системы.
Описание этой теории и суть шагов достаточно хорошо описаны в литературе в конце статьи, я же напишу свое видение в рамках текущего процесса:
- Ограничение: время формирования платежного документа.
- Решение: Формировать все платежные документы заранее, при загрузке данных.
- Подчинить решению: При обращении пользователя выдавать готовый документ.
- Расширить ограничение: Оптимизировать время формирования платежного документа.
- Отказаться от системы предварительного формирования по ВСЕМ домохозяйствам, определить новое ограничение.
Такой подход позволил бы сократить время решения на несколько лет, при минимальных затратах труда программистов. В посте указаны далеко не все возникшие проблемы и нет некоторых деталей решений, так как они не столь существенные в предлагаемом подходе.
Что почитать по теме:
- «Цель. Процесс непрерывного совершенствования», Элияху Голдратт
- «Теория ограничений. Основные подходы, инструменты и решения», Дмитрий Егоров
- «Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию», Уильям Детмер
Комментарии (28)
samaksyutin Автор
10.01.2020 11:1480к в сутки распределены неравномерно, пик нагрузки приходится на отдельные часы. На тот момент это было для нас достаточно высоконагруженной системой, генерирующей в пик несколько сотен обращений в секунду, в будущем нагрузка будет только возрастать. Кроме того, на графике зафиксированы не сами запросы или загрузки страницы, а количество сформированных платежных документов.
sentyaev
10.01.2020 13:4980к в сутки распределены неравномерно, пик нагрузки приходится на отдельные часы.
Даже если 80к в час — это чуть больше 20 запросов в секунду, это совсем мало.
Мне кажется у вас не должно быть проблем с нагрузкой, из текста сделал вывод, что, скорее всего, есть какие-то фундаментальные проблемы со структурой БД.
Например это:
за 5 лет -60 000 000
— Таблицы были разделены по расчетным центрам и месяцам партиционированием;
Делать партиционирование на десятках миллионов — уже возникают вопросы.
— Одно обращение к сервису сразу затрагивало много месяцев, соответственно генерировало много запросов;
Как я понял это для формирования платежных документов. Тоже ворос — зачем формировать платежные документы при заходе на сайт? Можно же их заранее нагенерить. Закончился отчетный период — запустили джобу и все.
Ну и если геренируется много запросов, смотрели ли в сторону денормализации данных, в отдельных случаях это может ускорить систему не в разы, а в сотни и тысячи раз.samaksyutin Автор
10.01.2020 15:05+1Даже если 80к в час — это чуть больше 20 запросов в секунду, это совсем мало.
Запросов было гораздо больше в секунду. Стоит учитывать неравномерное распределение по времени, к тому же здесь речь идет про сформированные платежные документы. Физически запросов было на порядок больше — кроме формирования платежного документа пользователь выполнял много других запросов: просмотр размера оплаты по услугам, внесение показаний прибора учета и так далее…
Делать партиционирование на десятках миллионов — уже возникают вопросы.
Вопросы партиционирования в первую очередь были связаны с возможностью независимо обновлять данные районов и во вторую очередь с тем, что время выполнения запроса к БД PostgreSQL (актуальной на тот момент версии) существенно выше при десятке миллионов записей в таблице по сравнению с сотней тысяч записей в таблице.
Как я понял это для формирования платежных документов. Тоже вопрос — зачем формировать платежные документы при заходе на сайт? Можно же их заранее нагенерить. Закончился отчетный период — запустили джобу и все.
Да, этот вариант был бы хорошим решением, кроме потребности в дисковой памяти, нужно учитывать, что запрос на формирование платежного документа может быть осуществлен за любой месяц в пределах 3-х лет.
Ну и если геренируется много запросов, смотрели ли в сторону денормализации данных, в отдельных случаях это может ускорить систему не в разы, а в сотни и тысячи раз.
Данные денормализованные, в максимально простом виде, для того чтобы в одном запросе участвовала только 1 таблица.sentyaev
10.01.2020 16:39Запросов было гораздо больше в секунду.
Да я просто сделал прикидку. У вас на графике пик в 80к запросов в месяц, поэтому сложно угадать сколько в секунду.
время выполнения запроса к БД PostgreSQL (актуальной на тот момент версии) существенно выше при десятке миллионов записей
Ок. Без разбора конкретного кейса спорить неочем.
Да, этот вариант был бы хорошим решением, кроме потребности в дисковой памяти, нужно учитывать, что запрос на формирование платежного документа может быть осуществлен за любой месяц в пределах 3-х лет.
— Изменение размера платежного документа в PDF с 0.5Мб до 0.2Мб
Кол-во документов: 100000 * 12 * 3 = 3600000
3600000 * 0.2 = 720000 Мб или примерно 700 гигов
Это будет стоить меньше сотни баксов в месяц если в облаке хранить. Да и современные диски стоят копейки.
Данные денормализованные, в максимально простом виде, для того чтобы в одном запросе участвовала только 1 таблица.
Так у вас вообще тогда проблем быть не должно)))samaksyutin Автор
10.01.2020 17:26количество документов, на тот момент да около того. Если брать на текущий момент (>1 000 000 в месяц), то около 7 Тб получится, что достаточно весомо для нас. Я согласен с вами, при отсутствии ограничений по железу, этот вариант очень хорош.
sentyaev
10.01.2020 17:41Я так понимаю в вашем случае Cloud — не вариант? Интересно было бы узнать какие подвижки в госсекторе по этому поводу…
DrunkBear
10.01.2020 17:51*мрачно* Никаких.
СБ не знает что такое облака, ставок «админстратор облачных данных» в тарифной сетке нет, денег на облака — тоже.
Становиться облачным провайдером для госструктур с перспективой оплаты за год во второй половине декабря тоже стремятся не только лишь все.
Да и к тому же, есть полугосударственный ростелеком, не?
samaksyutin Автор
11.01.2020 09:38В государственном облаке. Претензий к качеству ЦОДа работы нет, но это конечно не SSD и изменение конфигурации тот еще процесс :)
DrunkBear
10.01.2020 11:56Самый простой вариант борьбы, после разделения базы на актуальную и архив — раскатить БД на кластер и расширять кластер при необходимости — не пробовали?
samaksyutin Автор
10.01.2020 12:46Согласен, это простой вариант и первый приходит на ум. Частично мы так и сделали:
«Ключевые решения, предпринятые на этом этапе:
— Отделение части информации оперативной базы данных»
К сожалению, на полноценный кластер не было возможности перейти по техническим причинам (ресурсы серверов ограничены), кроме того в этом случае усложнялась процедура обновления данных. В качестве альтернативы рассматриваем выделение «горячих» данных в NoSQL базу данных в памяти, этого должно хватить при росте нагрузки в 3-5 раз от текущего.
Плюс, главным потребителем времени является не столько обращение к БД, сколько формирование файла платежного документа.somurzakov
11.01.2020 01:04а что именно затрагивало время при генерации файла?
если данные для платежки уже предрассчитаны и лежат в таблице, значит основное время это запросить данные по платежному документу и сформировать PDF.
вы смотрели способы оптимизировать формирование PDF? есть 2 альтернативы:
1. использовать высокоскоростную библиотеку формирования ПДФ, учитывая что формат открытый и генерацию PDF можно на коленке набросать практически с plain-text
2. переложить формирование ПДФа на клиента, используя javascript — parall.ax/products/jspdf например
если же вы не предрассчитываете платежные данные по клиенту (примерно как это делается при закрытии месяца в 1С), то это очень большой минус. Перерассчитывать все начисления, перевытаскивать все платежи, пересчитывать остатки на каждый запрос пользователя — неудивительно что будут ужасные тормоза. Даже удивительно как ваша система справлялась с нагрузкойsamaksyutin Автор
11.01.2020 09:421. использовать высокоскоростную библиотеку формирования ПДФ, учитывая что формат открытый и генерацию PDF можно на коленке набросать практически с plain-text
вариант хорош, но труднее поддерживать, формы часто меняются, пока используем FastReport.
переложить формирование ПДФа на клиента, используя javascript — parall.ax/products/jspdf например
а вот это не вариант, клиенты даже не знают, что формируется PDF пока они заняты другими разделами сайта, нагружать слабые мобильные приложения (такие тоже имеют доступ к порталу) не есть хорошо
если же вы не предрассчитываете платежные данные по клиенту
нет, мы давно отделили оперативные данные, тут проблемы нет, да и в основной системе принцип другой не как в 1Сsomurzakov
13.01.2020 18:59ФастРепорт это что-то такое больно старое знакомое из Дельфи… возможно это и есть №1 причина в тормозах. Особенно если ваш репорт напичкан картинками-логотипами и выбраны не самые оптимальные настройки экспорта в ПДФ- то будет отжирать много CPU на генерацию
samaksyutin Автор
14.01.2020 09:55Да, давно развивается, выбран как универсальное решение для формирования печатных шаблонов еще на заре проекта, картинок нет, только QR код и линейный штрих-код, да отнимает достаточно ресурсов техники, но экономит ресурсы разработки, готовых дизайнеров отчетов местной прописки не так уж и много.
Jungo
11.01.2020 10:21На мой взгляд вы боретесь с последствиями целого ряда направильных управленческих решений, коррупции и раздолбайства, взять хотя бы передачу показаний счетчиков и расчет потребления, на этом целую индустрию поборов сделали
изготовление счетчиков — продажа потребителю, осблуживание ремонт и поверка
но вода ресурс неограниченный по сути, при ссср не было никаких счетчиков, и мы потребляли воду без ужимок.
а сейчас? мало того что дискомфорт от потребления есть, постоянная неходимость экономии, так еще и ресурсоснабжающие организаци получили меньший расход и скорее всего проблем от этого им стало не меньше
в цепочке задействовано слишком много лишних людей и поборов, а платит за все конечный потребитель, в его тарифе все заложено, это просто бизнес на людях.
С этим мусором ситуация тоже не лучше, для нас, как для конечных потребителей ничего не изменилось, а тарифы вырасли в разы, по соотношению к средней ЗП. Ведь можно было хотя бы приложение запилить чтобы повысить грамотность населения, внедрить программу лояльности, какие-то госпрограмы сделать с партнерами на измельчители пищевых отходов, и переложить часть работ по сортировке на конечного пользователя тем самым уменьшив нагрузку впоследствии.
Как пример — живу в современном бутафорском эконом доме переменной этажности высотой до 24 этажей на 1600 квартир, это было ошибкой и я ее исправлю. Нас облуживает знаете сколько людей? 15 консьержей, 4 инженера, 4 уборщика, бухгалтер-кассир, тракторист, 3 охранника, лифтовая огранизация и возможно кто-то еще, почти 30 человек всего набирается, а может и больше. Думаю начинать надо отсюда, разгребать эту ж. идти по пути аутсорса или найма, постройки действительно комфортного жилья и не разгребать потом героически эти горы «добра».samaksyutin Автор
11.01.2020 11:15Не все вопросы решаются IT, но мы хотим сделать жизнь людей лучше, хоть в чем-то. Кстати, тоже живу в 24 этажном доме, причем сменили управляющую компанию и ситуация в разы улучшилась, как с мусором, так и с другими вопросами.
sneka
11.01.2020 11:28Вот давно сижу и думаю у меня хайлоад или не хайлоад. А тут вот прямо челюсть отпала.
У меня в среднем 500 запросов в секунду к серверу приложений, это примерно х10 к серверу БД. Рост базы пара терабайт в год. Ну приложение и приложение пашет и пашет. Архитектура «срали мазали». А это оказывается раз в 100 хайлоадней чем хайлоад :)
Вообще классное решение 5 лет кормить две команды вместо разовой покупки FullSSD полки за 5 мультов. Главное убедительно втирать руководству про «хайлоад» и про героическое решение проблем по модным методикам. Ыххх.
ЗЫ: А если даунгрейднуться на БУшные целероны с двумя винтами в зеркале — команду можно удвоить и еще 10 лет героически бороться. Зато если такое решение продать любому адекватному заказчику — у него все будет летать!
ЗЗЫ: У меня МФЦ, если что.samaksyutin Автор
11.01.2020 11:50Все относительно, две команды не кормили фул тайм, каждый этап занимал в среднем от 40 до 80 часов разработки.
По поводу хайлоад или нет можно долго спорить, для себя критерий вывел, когда число пользователей превышает 100 000, но это только мое мнение.
По поводу покупки SSD, довольно не бюджетно, кроме того гос ЦОД ( к примеру в одном из государственных ЦОД мы ждали замены обычного жесткого диска в течении 5 месяцев) не сильно заинтересован в покупке дорогих дисков и, что самое главное, резервирования таких дисков, на случай выхода из строя.sneka
11.01.2020 12:33Ну у нас тоже закупка месяца 3+поставка, НО. Два диска из 24-х на горячую замену. Как отработало — пошли закупать. При закупке полки можно закупить +пару дисков и положить на полочку.
DrunkBear
13.01.2020 10:41Знаю одну компанию в мск, у которой хайлоад и дикие потери денег в случае downtime, так они закупают железо стойками (x2 — прод/резерв) и по окончанию гарантии ( 3 года) и приближению периода, когда железо начинает часто умирать от нагрузок — списывают и покупают новое.
Завидую таким процессам…
samaksyutin Автор
11.01.2020 12:39Замечательно, в нашем случае ситуация была такая: диски старой модели, запасов не осталось, бюджет ЦОД на год утвержден и потрачен, планово диски купят в следующем году (на всякий случай, не в этом проекте), по замерам IOPS в момент проблем был в районе 180, СУБД при это хорошо упиралась в диск.
summit
13.01.2020 10:28Хороший сторадж всегда был дорогим. И это одно из самых ответственных мест любого ЦОДа. Проект изначально не прощитан.
Gromph
13.01.2020 10:28Генерировать документы, каждый раз это действительно больно. Мы пришли к тому что генерирует документы в конце отчётного периода и храним за последние 3 месяца т. к. по статистике более старые документы у нас практически не востребованы, но если они все же требуются, генерация начинается только по нажатию кнопки пользователем.
samaksyutin Автор
13.01.2020 10:31Логично, хорошая стратегия, единственный нюанс, если одновременно нажмут кнопку 1000 пользователей, то возникнет очередь формирования и пользователь может получить чуть позже чем привык
Gromph
13.01.2020 22:56Вероятность того что большому количеству пользователей одновременно понадобится информация из старых периодов очень мала. У нас стоит по серверу отчётности на макрорегион, это более 1кк пользователей. Стало интересно, и глянул мониторинг в МРЦ (самый крупный регион) пик очереди 96 докуметов, скорость выдачи документа пользователю к сожалению немониторим, но жалоб не разу не получали.
п. с. фикса одного из операторов большой тройкиsamaksyutin Автор
14.01.2020 11:45Согласен. Более того сценарий, когда все зарегистрированные пользователи хотели бы видеть платежный документ перед оплатой, сомнителен. Например, за сотовый телефон я счет детальный не смотрю, плачу по выставляемой сумме. Так что, по идее, следует изменить сам процесс, исключить формирование платежного документа в принципе, оставив только по запросу. Но, чтобы принять такое решение, нужна статистика и согласие заказчика.
SLASH_CyberPunk
80k обращений в сутки и это highload?