Высоконагруженные финансовые приложения предъявляют жесткие требования ко всем компонентам, особенно к системе хранения данных.
Необходимо постоянно и стабильно поддерживать нагрузку, несмотря, а иногда и вопреки сбоям, поломкам и резким миграциям.
О том, как администраторам баз данных приходится жить в мире быстро растущих рабочих нагрузок и высоких требований к стабильности, рассказал эксперт по базам данных ECOMMPAY IT Владимир Федорков в своем докладе на конференции Saint HighLoad++ Online 2020. 
Работа администратора базы данных очень похожа на работу уборщика: пока все убрано, все довольны.
Но как только появляется проблема с чистотой, возникают вопросы, и все сразу вспоминают, что DBA — слово недоброе, порой матерное.
Почему это происходит? Дело в том, что системы хранения и поиска данных сегодня являются основой приложений.
Нет быстрого доступа к данным – приложению нечего обрабатывать – нечего показывать пользователю.
И весь код и архитектура становятся бесполезными.
Поэтому работа современного администратора базы данных заключается в обеспечении стабильной основы для активно строящегося здания приложений.
Зачастую здание не просто строится, а активно используется, где-то ремонтируется, где-то перестраивается, где-то расширяется, а иногда разрезается и перевозится вместе с жильцами, не выселяя их, в другое место.
И все это должно быть сделано так, чтобы не создавать неудобств для населяющих его людей.
А в идеале провести все работы так, чтобы жильцы этого просто не заметили.
Конечно, с обычным зданием эти действия выполнить не получится.
А вот в ИТ, особенно в случае разработки на основе гибких методологий, это вполне возможно.
Конечно, если уделить должное внимание деталям.
Как создать прочную основу для вашего приложения? Успешная работа состоит из двух составляющих: реактивной и проактивной.
По их соотношению в повседневной работе можно судить как о стабильности приложения в целом, так и об эффективности администратора базы данных.
Реактивность — это реакция на текущие события, которые каким-либо образом влияют на работу базы данных, а значит и приложения (в основном речь идет об оповещениях системы мониторинга).
Если вы получаете информацию об отказах от вашего руководства или, тем более, от клиентов, система для вас совершенно непрозрачна.
Это значит, что вы не сможете им управлять без риска что-то сломать на уровне базовых операций.
Задача реактивной работы — максимально быстро обработать событие в соответствии с его приоритетом.
Согласно методологии работы отдела ИТ-операций ECOMMPAY, в случае воздействия на клиента сотрудники обязаны устранить это воздействие в кратчайшие сроки.
А затем в рабочем порядке устранить последствия происшествия.
В этом случае бизнес несет минимальные потери как в финансовом, так и в репутационном плане.
Реактивная работа включает в себя множество методологий, которые, хотя и интересны, но выходят за рамки описательных целей этой статьи.
Но одно утверждение обязательно нужно запомнить: если критические сбои не начинают обрабатываться в течение трех минут с момента их возникновения, деньги бизнеса не обрабатываются должным образом.
При всей своей важности, наглядности и ясности для руководства и бизнеса реактивная работа сама по себе не является гарантией стабильности системы.
За это отвечает менее заметная, но гораздо более важная часть работы администратора базы данных: проактивная или творческая работа.
Он заключается в анализе текущей ситуации, поиске узких мест и обнаружении потенциальных проблем, которые могут возникнуть завтра, на следующей неделе, через месяц или даже через год. Чем масштабнее проблема, которую удастся обнаружить заранее, тем больше денег бизнес сэкономит на прямых потерях и тем больше времени персонал будет занят продуктивной работой, а не борьбой с последствиями инцидентов.
Что такое проактивная работа в случае с базами данных? Как и в любом другом деле, он делится на поиск ответов на два вопроса: «Где мы сейчасЭ» и «Куда нам идтиЭ» Оба вопроса одинаково важны, но без ответа на первый мы не можем ответить на второй, поэтому начнем с него.
Метрики
Для анализа работы базы данных необходимы метрики: они делают работу системы прозрачной, визуализируют состояние системы и позволяют понять, что происходит здесь и сейчас.
Метрики обеспечивают важнейший компонент работы системного администратора — осведомленность о ситуации.
Ситуационная осведомленность – это набор параметров, знание которых позволяет оценить работу основных компонентов системы и определить состояние системы? в целом.
Без визуализации этих параметров? систему нельзя считать прозрачной и не только проактивная, но и реактивная работа будет невозможна.
Для систем на базе MySQL абсолютно критическими параметрами являются:
- Базовые метрики: Threads_running и Threads_connected;
- Загрузка ЦП (средняя нагрузка), переключение контекста;
- Загрузка дисковой подсистемы (чтение/с, запись/с, среднее время записи, среднее время чтения);
- Количество запросов в заблокированном состоянии.
Это может быть фаза выполнения запроса или фаза ожидания блокировки: речь идет о результате выполнения, которого приложение ждет прямо сейчас.
Эта метрика важна еще и потому, что внутри MySQL каждый запрос (точнее, соединение) обрабатывается одним потоком, а значит, и одним ядром ЦП.
Поэтому, когда количество активных потоков приближается к количеству ядер на машине, это можно считать тревожным сигналом.
В ситуации, когда количество активных запросов во много раз превышает количество ядер, операционная система вынуждена делить процессорное время между запросами, что приводит к менее эффективному выполнению, увеличению Load Average, увеличению переключений контекста, метрика Threads_connected и последовательное ухудшение производительности системы.
Такое состояние системы характеризуется экспоненциальным увеличением времени отклика, падением пропускной способности сервера и с точки зрения приложения и пользователей это равносильно сбою.
Загрузка дисковой подсистемы показывает, насколько быстро записываются изменения и насколько эффективно читаются данные, не кэшированные в памяти MySQL. Приближение метрик read/s, writes/s (они же Read IOPS и Write IOPS) к предельному значению для текущего сервера (они определяются бенчмарками) означает увеличение очереди активных запросов, а дальше мы увидим увеличение Threads_running. Отдельно можно выделить количество запросов в статусе блокировки.
Блокировки могут быть разными, и несмотря на то, что каждый конкретный запрос в заблокированном состоянии практически не потребляет ресурс системы, заблокированный запрос может повлиять на время ответа клиенту, замедлить синхронные операции и сохранить ценные ресурсы, как на стороне базы данных и приложений.
И в конечном итоге это может привести к тем же последствиям, что и большое количество активных запросов.
Радости от блокировки тоже нет. Итак, если SELECT .
FOR UPDATE кажется отличной идеей, у меня для вас плохие новости.
Запросы
Одни только показатели вас не удовлетворят. Недостаточно знать, что нагрузка на основание допустима и нет перегрузок.Если кто-то будет писать в базу данных, объём данных вырастет. Это означает, что в какой-то момент плавное и зачастую незаметное увеличение времени исполнения запросов, подчиняясь правилу материалистической диалектики, перейдет из количественного в качественное, а при резком скачке времени реагирования будет свидетельствовать о том, что наступили мирные времена.
над. 
Вот почему DBA каждый день готовится к войне.
А для этого нужно посмотреть сами запросы, даже если сейчас все в порядке.
Какие запросы мы рассматриваем:
- Те, которые нагружают процессор;
- Те, что загружают диск;
- Все запросы длительностью более ста миллисекунд.
Более того, одиночный запрос может быть очень быстрым, а вот большое количество очень быстрых запросов может съесть значительное количество системных ресурсов.
И это может внезапно и очень неприятно аукнуться вам в момент небольшой перегрузки.
Такие запросы можно идентифицировать по большим значениям времени Exec в выводе pt-query-digest, в PMM, через Performance_schema или по значению sum_time в ProxySQL. Какие запросы грузят диск? Этот вопрос немного сложнее.
Запись всегда нагружает диск, но запросы на чтение могут выполняться в памяти только в том случае, если ее (в случае InnoDB за кэширование данных отвечает настройка innodb_buffer_pool_size) достаточно для хранения всех «горячих» данных.
Интересно, что для чтения с диска требуются не только SELECT, но и команды записи данных.
INSERT, чтобы записать данные, нужна страница с местом в таблице, в которое эти данные записываются.
UPDATE и DELETE также запросят с диска данные, которые необходимо изменить (удалить), а ALTER вообще может потребовать всю таблицу.
Писать почти всегда медленнее, чем читать.
Исключением является запись в кэш ОЗУ контроллера диска и в кэш-память сетевого диска.
За этим и некоторыми другими редкими исключениями можно смело предположить, что в первую очередь следует смотреть записывающую нагрузку.
Особенно это актуально для систем виртуализации, где настройки драйверов могут сильно влиять на производительность базы данных.
В общем, наличие в боевой базе запросов длиной более ста миллисекунд — хороший повод задуматься либо о добавлении необходимого индекса, либо об оптимизации схемы, либо об изменении логики приложения.
В запущенных случаях может потребоваться перенести запрос на отдельную чертову реплику, которую обычно называют «аналитической» репликой.
Исторические данные
Мгновенный снимок метрик и запросов позволяет увидеть текущее состояние системы, но современные системы не просто работают 24/7. Нагрузка на них может колебаться в любой момент, и мгновенный снимок не покажет этих изменений.Поэтому базовую информацию о производительности необходимо собирать на постоянной основе.
Эту информацию чрезвычайно удобно визуализировать в виде графиков.
Многие системы мониторинга сейчас предоставляют такую возможность: OkMeter, Prometheus + Grafana, графики в Zabbix и многое другое.
Напишите, пожалуйста, в комментариях, какую систему визуализации метрик вы можете порекомендовать.
Мой личный фаворит — PMM — чрезвычайно удобная штука, которая показывает все необходимые метрики от уровня операционной системы до внутренних метрик MySQL и ProxySQL. Какую степень детализации следует выбрать для графиков? Короткие интервалы опроса (до 5 секунд) позволяют увидеть единичные мгновенные всплески, но серьезно увеличивают объем хранимых исторических данных и создают видимую нагрузку на исследуемую систему.
Длительные периоды опроса (более минуты) удобны для хранения, но есть риск пропустить значительные скачки нагрузки.
Мы остановились на детализации 20-30 секунд. Такой интервал сбора данных позволяет увидеть все более или менее серьезные всплески, не нагружая клиентские системы и базы данных мониторингом.
Диаграммы нагрузки решают несколько ключевых проблем:
- Просмотр сезонности;
- Увидеть всплески от одиночных запусков скриптов и запросов;
- Увидеть работу коронок;
- Оценить влияние развертывания;
- Оцените общее увеличение нагрузки.
Сезонность позволяет как минимум планировать работу.
Для высоконагруженных систем попытка выполнить миграцию отдельных баз данных во время ежедневного пика равносильна сбою системы.
Бизнесу это точно не понравится.
Этой же цели могут служить и некоторые кронные задачи, запускаемые в периоды экстремальной нагрузки.
Исторические данные особенно хороши для быстрой визуальной оценки качества нового кода.
Они помогут вам принять решение об откате неудачного развертывания.
Это касается не только метрик базы данных, но и бизнес-метрик, без которых мониторинг сейчас нельзя считать полноценным (но этот вопрос выходит за рамки статьи).
Одним из наиболее важных параметров является ретроспективный рост нагрузки.
Насколько увеличилась (или уменьшилась) рабочая нагрузка за последний месяц, квартал или шесть месяцев? Этот вопрос является ключевым для долгосрочного планирования, особенно в индустрии баз данных, где масштабирование представляет собой многогранный процесс и часто требует значительной поддержки со стороны приложения.
Важность общения и открытости
Если вы посмотрите на список опций, то увидите, что немногие из них можно реализовать, используя только администратора базы данных.Самая большая и эффективная часть решений может быть реализована только на уровне кода и логики приложения.
Здесь мы подходим к самой главной идее всего нашего повествования: парадигме «один человек в поле – не воин».
В современном мире, особенно с увеличением количества людей в компании, наблюдается тенденция к обособлению разработки от эксплуатации и наоборот. Такая ситуация может привести к потере понимания разработчиками нюансов функционирования приложения в продакшене.
В то же время операторам может не хватать знаний о функциональных взаимодействиях внутри приложения.
Проблемы в коммуникации могут влиять как на скорость разрешения функциональных и нагрузочных сбоев, так и на архитектурные решения, что приводит к долгосрочным негативным последствиям как для эксплуатации, так и для развития.
Трансформация продукта частично решает такие проблемы за счет создания центров компетенций и повышения эффективности межкомандных коммуникаций.
В этом смысле администраторы баз данных и SRE являются центром получения информации о производительности приложений.
Это заставляет их работать совместно с командами разработчиков, чтобы выявлять проблемы с производительностью как можно раньше, в идеале на стадии концепции.
Такой подход, помимо снижения стоимости эксплуатации ПО за счет оптимизации, позволяет на ранней стадии избежать архитектурных проблем и существенно ускорить разработку.
Говоря простым языком, прозрачность коммуникаций между разработкой и эксплуатацией позволяет решить значительное количество проблем на ранней стадии и относительно спокойно жить с ростом нагрузки и объема данных.
Заключение
Производительность, устойчивость и стабильность не являются чем-то особенным.
Это целый комплекс ежедневных процедур и аналитики, направленный на выявление как текущих, так и потенциальных узких мест, которые могут появиться через месяц, два, шесть или даже год. В основе этих мер лежит прозрачность заявок для всех команд, коммуникация и бесперебойное взаимодействие между всеми заинтересованными сторонами.
Разработчики знают, как должна работать система, операторы знают, как она работает на самом деле.
Обмен знаниями и взаимопонимание являются ключом к успеху в любой ИТ-компании.
Конференция HighLoad++ 2020 пройдет 20 и 21 мая 2021 года.Теги: #ИТ-компании #ИТ-компании #Администрирование баз данных #Высокая производительность #sre #инжиниринг надежности сайта #MySQL #производительность mysqlКупить билеты ты можешь сделать это сейчас.
Хотите получить бесплатные материалы с мини-конференции Saint HighLoad++ 2020? Подписаться в нашу рассылку.
-
Dynamics Gp Работа С Заявлениями Клиентов
19 Oct, 24 -
Ведение Блога: Преимущества Типов Блогов
19 Oct, 24 -
Разнонаправленный Перевод
19 Oct, 24 -
Создание Warcraft (Часть 1)
19 Oct, 24 -
Что Происходит С Oracle?
19 Oct, 24 -
Притча
19 Oct, 24
