Как стать автором
Обновить
419.37
Конференции Олега Бунина (Онтико)
Профессиональные конференции для IT-разработчиков

MySQL в финансах: реакция или созидание?

Время на прочтение9 мин
Количество просмотров4.1K

Высоконагруженные приложения финансовой сферы предъявляют жесткие требования ко всем компонентам, особенно к системе хранения данных.

Нужно постоянно и стабильно держать нагрузку, несмотря, а иногда и вопреки отказам, поломкам и внезапным миграциям. О том, как приходится жить DBA в мире стремительного повышения нагрузок и высоких требованиях стабильности, в своем докладе на конференции Saint HighLoad++ Online 2020 рассказал эксперт по базам данных ECOMMPAY IT Владимир Федорков.

Работа DBA очень похожа на работу уборщицы: пока везде вымыто, все довольны. Но как только появляется проблема с чистотой, возникают вопросы, и все сразу вспоминают о том, что есть DBA недобрым, иногда матерным, словом. Почему так происходит? Дело в том, что системы хранения и поиска данных на сегодняшний день являются  фундаментом приложений. Нет быстрого доступа к данным — нечего обрабатывать приложению — нечего показать пользователю. И весь код с архитектурой становятся бесполезными. 

Поэтому работа современного DBA — обеспечить стабильный фундамент активно строящемуся зданию приложения. Часто здание не просто строится, но активно эксплуатируется, местами ремонтируется, кое-где перестраивается, где-то расширяется, а иногда разрезается и вывозится вместе с жильцами, без их выселения, в другое место. И все это нужно сделать так, чтобы не создать населяющим его людям неудобств. А в идеале провести все работы так, чтобы жильцы их просто не заметили. Конечно, с обычным здание выполнить эти действия не получится. А вот в IT, особенно в случае разработки по принципу гибких методологий, такое вполне возможно. Конечно, если уделять должное внимание деталям.

Как же построить надежный фундамент для приложения? Компонентов успешной работы два: реактивный и проактивный. По их соотношению в ежедневной работе можно судить и о стабильности приложения, в целом, и об эффективности работы DBA. 

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

Задача реактивной работы: отработать событие как можно быстрее в соответствии с его приоритетом. Согласно методологии работы департамента эксплуатации ECOMMPAY IT, в случае аффекта клиентов  сотрудники обязаны за минимально возможное время снять этот аффект.  А дальше, в рабочем порядке, ликвидировать последствия инцидента. В этом случае бизнес несет минимальные потери как в финансовом, так и в репутационном выражении. 

У реактивной работы есть множество методологий, которые несмотря на свою увлекательность, не входят в описательные цели этой статьи. Но однозначно нужно помнить одно утверждение: если критические отказы не начинают обрабатываться в течении трех минут с момента появления, деньги бизнеса не отрабатываются должным образом.

При всей своей важности, видимости и понятности для начальства и бизнеса, реактивная работа сама по себе не является залогом стабильности работы системы. За это ответственна менее заметная, но гораздо более важная часть работы DBA: проактивная или созидательная работа. 

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

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

Метрики

Для того, чтобы производить анализ работы БД нужны метрики: они делают работу системы прозрачной, визуализируют состояние системы и дают возможность понимания того, что происходит здесь и сейчас.

Метрики обеспечивают крайне важную составляющую работы системного администратора — ситуационную осведомленность. Ситуационная осведомленность — это набор параметров, знание которых позволяет оценить работу основных компонентов системы и определить состояние системы? в целом. Без визуализации этих параметров? система не может считаться прозрачной и будет невозможна не только проактивная, но и реактивная работа. 

Для систем на основе MySQL абсолютно критичными параметрами являются:

  • Метрики базы: Threads_running и Threads_connected; 

  • Загрузка CPU (Load Average), context switches;

  • Загрузка дисковой подсистемы (read/s, writes/s, avg write time, avg read time);

  • Количество запросов в статусе блокировки.

Threads_running показывает, сколько запросов в настоящее время находятся в активной фазе. Это может быть фаза исполнения запроса или ожидание блокировки: речь идет о результате исполнения, который прямо сейчас ожидает приложение. Эта метрика важна еще и потому, что внутри MySQL каждый запрос (точнее, подключение) обрабатывается одним потоком, а значит, одним ядром CPU. Поэтому приближение количества активных потоков к количеству ядер на машине можно считать тревожным сигналом. В ситуации, когда количество активных запросов в разы превышает количество ядер, операционная система вынуждена делить время процессора между запросами, что приводит к менее эффективному их выполнению, увеличению Load Average, росту context switches, метрики Threads_connected и последовательной деградации производительности системы. Такое состояние системы характеризуется экспоненциальным ростом времени отклика, падением пропускной способности севера и, с точки зрения приложения и пользователей, это равнозначно отказу. 

Загрузка дисковой подсистемы показывает, как быстро записываются изменения и насколько эффективно читаются незакешированные в памяти MySQL данные. Приближение метрик read/s, writes/s (они же Read IOPS и Write IOPS) к предельным значением для текущего сервера (они определяются бенчмарками) означает рост очереди активных запросов, и далее нас ждет рост Threads_running.

Отдельно можно выделить количество запросов в статусе блокировки. Блокировки бывают разными, и несмотря на то, что каждый конкретный запрос в состоянии блокировки практически не отъедает ресурс у системы, заблокированный запрос может влиять на время ответа клиенту, тормозить синхронные операции, удерживать ценные ресурсы, как на стороне базы данных, так и на стороне приложения. И, в конечном итоге, это может привести к тем же последствиям, что и большое количество активных запросов. Радости от блокировок тоже никакой. Поэтому если SELECT … FOR UPDATE кажется Вам отличной идеей, у меня для вас плохие новости.

Запросы

Одними метриками сыт не будешь. Недостаточно знать, что нагрузка на базу приемлема и перегруза нет. Если в базу данных кто-то пишет, то объемы данных будут расти. Это значит, что в какой-то момент плавный и часто незаметный глазу рост времени выполнения запросов, повинуясь правилу материалистической диалектики, перейдет из количественного в качественный, и резким скачком времени ответа сообщит о том, что мирные времена закончились.

Поэтому DBA каждый день готовится к войне. А для этого нужно смотреть сами запросы, даже если прямо сейчас все хорошо.

Какие запросы смотрим: 

  • Те, которые нагружают CPU;

  • Те, которые нагружают диск;

  • Все запросы, длиннее ста миллисекунд.

Как узнать, что нагружает CPU? Процессор нагружают все запросы, но смотреть в первую очередь нужно те, у которых большое суммарное время выполнения. Причем отдельный запрос может быть очень быстрым, но большое количество очень быстрых запросов может отъедать значительное количество ресурсов системы. И это может внезапно и очень неприятно аукнуться в момент легкой перегрузки. Идентифицировать такие запросы можно по большим значениям Exec time в выводе pt-query-digest, в PMM, через Performance_schema или по значению sum_time в ProxySQL.

Какие запросы нагружают диск? Этот вопрос чуть более сложный. Запись нагружает диск всегда, а вот запросы на чтение могут выполнятся только в памяти, если ее (в случае InnoDB за кэширование данных отвечает настройка innodb_buffer_pool_size) достаточно для хранения всех «горячих» данных. Интересно, что чтения с диска требуют не только SELECT’ы, но и команды записи данных. INSERT’у, чтобы записать данные, нужна страничка с тем местом таблицы, в которую эти данные пишутся. UPDATE и DELETE также будут запрашивать с диска данные, которые нужно поменять (удалить), а ALTER’у вообще может потребоваться вся таблица.

Запись почти всегда медленнее чтения. Исключение составляет запись в RAM-кэш дискового контроллера и в кэш-память сетевого диска. За этим и некоторыми другими редкими исключениями мы можем смело считать, что нагрузку на запись нужно смотреть в первую очередь. Особенно это касается систем виртуализации, где настройки драйвера могут сильно сказаться на производительности базы.

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

Исторические данные

Моментальный снапшот метрик и запросов позволяет увидеть текущее состояние системы, однако современные системы не просто работают 24/7. В каждый момент нагрузка на них может плавать, и моментальный снапшот эти изменения не покажет. Поэтому основную информацию о производительности нужно собирать на постоянной основе. Эту информацию крайне удобно визуализировать в виде графиков. 

Такую возможность предоставляют сейчас многие системы мониторинга: OkMeter, Prometheus + Grafana, графики в Zabbix и многое другое. Напишите, пожалуйста, в комментариях, какую систему визуализации метрик вы можете порекомендовать. Моей персональной любовью является PMM — крайне удобная штука, которая показывает все необходимые метрики от уровня операционной системы до внутренних метрик MySQL и ProxySQL. 

Какую гранулярность выбрать для графиков? Короткие интервалы опроса (до 5 секунд) позволяют увидеть единичные моментальные всплески, но серьезно увеличивают количество хранимых исторических данных и создают видимую нагрузку на исследуемую систему. Длинные периоды опроса (больше минуты) комфортны для хранения, но появляется риск пропустить существенные всплески нагрузки. 

Мы остановились на гранулярности в 20-30 секунд. Такой интервал сбора данных позволяет увидеть все более-менее серьезные всплески, при этом не нагружая клиентские системы и базы мониторингом. 

Графики нагрузки позволяют решить несколько ключевых проблем: 

  • Посмотреть сезонность; 

  • Увидеть всплески от единичных запусков скриптов и запросов; 

  • Увидеть работу кронов; 

  • Оценить влияние деплоя; 

  • Оценить общий рост нагрузки. 

Сезонность позволяет как минимум планировать работы. Для высоконагруженных систем попытка выполнения отдельных миграций БД в момент суточного пика равнозначна отказу систем. Бизнесу это точно не понравится. Такую же службу могут сослужить и некоторые крон задачи, запущенные в момент экстремальной нагрузки. 

Особенно хороши исторические данные для быстрой визуальной оценки качества нового кода. Они помогут принять решение об откате неудачного деплоя. Это касается не только метрик базы, но и бизнес метрик, без которых мониторинг сейчас не может считаться полноценным (но этот вопрос выходит за рамки статьи). 

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

Важность коммуникаций и открытости

Если посмотреть на список вариантов, можно увидеть, что немногие из них могут быть реализованы силами только DBA. Большая и самая эффективная часть решений может быть реализована только на уровне кода и логики приложения. Здесь мы подходим к самой важной идее всего нашего повествования: парадигме «один в поле не воин». 

В современном мире, особенно с увеличением количества людей в компании, наблюдается тенденция к изоляции разработки от эксплуатации и наоборот. Такая ситуация может привести к потере осведомленности разработки о нюансах функционирования приложения в проде. В то же время эксплуатация может недополучать знания о функциональных взаимодействиях внутри приложения. 

Проблемы в коммуникации могут сказываться как на скорости решения отказов функционального и нагрузочного характера, так и в решениях по архитектуре, что приводит к долговременным негативным последствиям как для эксплуатации, так и для разработки. 

Частично с такими проблемами борется продуктовая трансформация, создавая центры компетенций и делая кросс-командные связи более выраженными. В этом смысле администраторы баз данных и SRE являются точкой, где концентрируется информация о производительности приложений. Это делает необходимым их совместную работу с командами разработки по выявлению проблем производительности на как можно более ранней стадии, в идеале еще на этапе концепта. Такой подход помимо удешевления стоимости эксплуатации ПО, за счет оптимизации, на ранней стадии позволяет избежать архитектурных проблем и существенно ускорить разработку.

Говоря простым языком — прозрачность коммуникаций между разработкой и эксплуатацией позволяет на ранней стадии решить значительное количество проблем и относительно спокойно жить с ростом нагрузки и количества данных.

Заключение

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

Основа этих мер — прозрачность приложений для всех команд, коммуникация и налаженное взаимодействие между всеми заинтересованными лицами. Разработка знает, как система должна работать, эксплуатация знает как она работает по факту. Обмен знаниями и взаимная осведомленность —ключи к успеху в работе любой IT компании.

Конференция HighLoad++ 2020 пройдет 20 и 21 мая 2021 года. Приобрести билеты можно уже сейчас.

Хотите бесплатно получить материалы конференции мини-конференции Saint HighLoad++ 2020? Подписывайтесь на нашу рассылку.

Теги:
Хабы:
Всего голосов 11: ↑10 и ↓1+14
Комментарии18

Публикации

Информация

Сайт
www.ontico.ru
Дата регистрации
Дата основания
Численность
31–50 человек
Местоположение
Россия