Высоконагруженные приложения финансовой сферы предъявляют жесткие требования ко всем компонентам, особенно к системе хранения данных.
Нужно постоянно и стабильно держать нагрузку, несмотря, а иногда и вопреки отказам, поломкам и внезапным миграциям. О том, как приходится жить 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?Подписывайтесьна нашу рассылку.
