Highload++

Миллионы запросов в секунду. Сотни серверов с десятками ядер и терабайтами оперативной памяти. Много пользователей и данных. И их становится всё больше. Да, это всё HighLoad. Но HighLoad не только это.

В основе хороших высоконагруженных систем лежит тщательно спроектированная архитектура. Благодаря этому, системы постоянно масштабируются, а их ресурсов хватает для работы с текущими нагрузками. И тогда HighLoad-конференции не превращаются в дискуссии Как сэкономить на ресурсах при штатно выросшей нагрузке или Куда девать все имеющиеся у нас мощности.

Но что насчет безопасности и защиты данных при высоких нагрузках? Что думают разработчики и эксперты о внешних угрозах, которые тоже могут вывести систему из строя? О сохранении данных, их правильной передаче и использовании? Артём Гавриченков в Программном комитете отвечает за эту область на конференции HighLoad++. Сегодня он расскажет, чем наша долгожданная офлайн-встреча Highload++ Весна 2021 будет интересна и полезна любому разработчику. Доклады на конференции будут и о безопасности, и о шифровании, и о биометрии, и, конечно, о многих других смежных с безопасностью темах.

Артем, чем ты сейчас занимаешься и какое отношение имеешь именно к высоким нагрузкам?

На протяжении 10 лет я строил продукт Qrator по защите DDoS-атак. Тут, наверное, сразу понятно, где высокие нагрузки. Последние 5 лет был техническим директором этого продукта, даже больше пяти. В данный момент я директор по продукту в Servers.com это компания, которая занимается предоставлением инфраструктурных решений (bare metal cloud, облачное хранение данных, фаерволы, Managed Kubernetes), то есть опять же решения для больших нагруженных проектов.

Как давно ты в Программном комитете и как ты в него пришел?

Я выступал несколько раз на Highload, начиная с 2011 года. А в 2018-м мы пообщались с Олегом Буниным, и он пригласил меня в ПК как эксперта по защите информации, по высоким нагрузкам в плане DDoS-атак и по масштабируемым системам по сети и инфраструктуре.

Чем тебе нравится быть в ПК? Что это для тебя?

Это возможность пообщаться с очень интересными людьми, высокими профессионалами своего дела, как с членами ПК, так и докладчиками. Вы можете увидеть прямо весь bleeding edge технологий самые модные, и при этом уже немного проверенные в деле. То есть можно узнать, какие направления есть в индустрии, куда это все идет, что появляется каждый год, а на что не стоит тратить время. Программа HighLoad++ сама по себе дает такое понимание людям, поэтому и стоит на него ходить.

А в программном комитете я могу дополнительно пообщаться со всеми докладчиками. Конференция идет всего 2 дня, хоть и в несколько потоков при всем желании вы не успеете со всеми пообщаться. А у членов ПК есть возможность общаться с интересными докладчиками на протяжении полугода, пока мы отбираем доклады, а потом помогаем спикерам готовиться к выступлению. То есть здесь я снова получаю полный обзор всех актуальных технологий, которые существуют и появляются. Это, в том числе, и инструмент поддержания собственной компетентности и уровня awareness по технологиям.

Какие темы нас ждут в разделе безопасности в этом году на конференции?

В первую очередь, мы говорим про крупные системы, которые выдерживают серьезные нагрузки, то есть хорошо спроектированные системы. В рамках проектирования, создания архитектуры системы, написания кода необходимо решать и вопросы безопасности.

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

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

Еще будет близкая к этому тема шифрования соединений. Сейчас практически все соединения в интернете от браузера или мобильного приложения до сервера надежно шифруются, но криптография всегда повышает нагрузку. У нас будет Александр Крижановский (Tempesta Technologies) с рассказом о том, как написать быстрый TLS-хендшейк в ядре Linux. Это такой хендшейк, который эффективней на десятки процентов, чем стандартное решение он дает меньшее время задержки, то есть готов работать под большой нагрузкой.

Будет доклад от РТЛабс про единую биометрическую систему. Это мультивендорная система, которая обеспечивает возможность работы с любыми модальностями биометрии (лицо, голос и т.д.). Биометрия в последнее время в России это очень активный хайп, развертывание биометрической аутентификации в приоритете у правительства. И конечно, у людей есть опасения, как это может работать и что может пойти не так вопрос на самом деле серьезный. Поэтому мы включили в программу этот доклад, чтобы люди, кому важно и/или интересно устройство единой биометрической системы, могли узнать, как она работает.

Система РТЛабс рассчитана на 150 млн человек, и этого должно хватить для 136 миллионов россиян. Хотя в реальности, конечно, будет меньше. Но, с другой стороны, может быть, ее удастся расширить и на таможенный союз, например, на Беларусь.

Будут ли какие-нибудь новинки в решении известных задач безопасности?

На эту тему будет доклад от Касперского про быстрое детектирование спам-писем. Проблеме спама столько же лет, сколько электронной почте. Она никуда не уходит, с годами становится сложнее, потому что, например, Gmail или Яндекс собирают почту в большом объеме и более-менее умеют детектировать спам с минимальным количеством ошибок первого и второго рода. Но в финале это приводит к ситуации как с Ковидом. Иммунитет летучих мышей совершенно адский он выжигает вирусы каленым железом! Это очень стойкое животное. Но по каким-то эволюционным причинам эта иммунная система выборочно оставляет некие вирусы, которые летучей мыши уже вреда не причиняют, но там живут.

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

Хочу заметить, что проблема спама никогда никуда не уйдет. Есть даже категория шуток в IT-сообществе про Final Ultimate Solution to the Spam Problem. Примерно раз в год в каких-нибудь списках рассылки появляется человек, который утверждает, что он нашел уникальное полное решение проблемы спама и чего на практике никогда не случается.

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

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

Какие доклады, не связанные с безопасностью, тебе интересны самому?

По смежной теме будет доклад Василия Сошникова про API Gateway. Эта технология реально популярный хайп последних лет. Она очень часто встречается, в том числе, в over-engineering проектах. Поэтому в докладе будет обзор концепции и того, какие плюшки это нам дает и какие сложности возникают в эксплуатации. Что поможет найти ответ на вопрос: для нашего проекта API Gateway это полезный момент или просто хайп, на который не нужно тратить время?

Это действительно интересно. А ты сам на HighLoad++ собираешься посетить только то, что описал, или тебя интересуют еще какие-то доклады и мероприятия?

Уже принято 75 докладов, и есть, конечно, интересные и не только про безопасность. Например, доклад Сбербанка про борьбу с TCP Incast. Это как раз инфраструктурная часть как устроены центры обработки данных и как устроена сеть на большом проекте. Там возникают разные проблемы.

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

Ты часто бываешь на конференциях?

С 2017 года я не пропускал ни одного HighLoad++, в том числе ни одного питерского, и ни одного РИТа, правда, в Сибирь я не ездил ни разу.

Ты сам предпочитаешь онлайн или офлайн?

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

Когда ты сам выступал в качестве спикера, что самое важное в построении докладов? Какие-то фишки есть, чтобы выступление было запоминающимся и интересным?

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

Доклад не должен быть комедийным. Если посмотрим, например, боевики последних лет (Мстители и т.д.), увидим, что там много времени уходит на юмор, перебивки, прибаутки и прочие штуки. То есть доклад не должен быть совсем уж развлекательным, но крайне желательно, чтобы часть entertainment в нем тоже присутствовала.

Что такое Highload лично для тебя? Как бы ты описал его человеку, который не член ПК, а просто приходит туда по собственному желанию?

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

Конференция HighLoad++ 2021 пройдет уже 17 и 18 мая в Москве, в Крокус-экспо. Сейчас открыт дополнительный прием докладов по новым темам. Если вы хотите поделиться тем важным и интересным, что вы нашли, разработали и открыли во время онлайна в пандемию мы вас ждем!

Билеты можно купить здесь. И да, цена с 30 апреля вырастет, для решения осталось 2 недели.

Подписывайтесь на наши новости о конференции, чтобы быть в курсе всех изменений, новинок и интересностей!

Телеграм здесь и здесь, FaceBook, VK, Twitter.

Как считает Евгений Россинский, СТО должен быть одновременно и стратегом в настоящем, и мечтателем, смотрящим в будущее. Стратег должен очень хорошо понимать, где находится сейчас чтобы что-то улучшить, надо сначала померить и найти метрику качества. А мечтатель должен любить свое дело, чтобы заряжать людей вокруг и двигать дело вперед.

Евгений основал компанию по разработке высоконагруженных проектов Netstream (online-вещание и видео), а в 2012 году вместе со всей командой перешел в ivi, где является СТО до сих пор. C 2006 года преподает в МГТУ им. Баумана авторский курс Технологии командной разработки ПО, потому что однажды обнаружил, что не может найти грамотных разработчиков в команду.

Такой же стиль у него в Программном комитете HighLoad++ находить интересных спикеров и животрепещущие темы, чтобы показать их широкой аудитории и продвинуть в будущее. Накануне конференции мы встретились с Евгением, чтобы расспросить о докладах и спикерах HighLoad++ Весна 2021. Что было бы интересно, а что просто обязательно надо идти и слушать, если вы разработчик высоконагруженных систем.

Женя, расскажи, чем ты занимаешься и какое отношение имеешь именно к высоким нагрузкам?

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

Какие доклады HighLoad++ ты курируешь как член Программного комитета?

3-4 года назад я пришел в Программный комитет на историю с бэкендом. Но так как с тех пор в ivi много чего интересного появилось, в ПК я теперь занимаюсь и другими темами докладов от баз данных до платежных систем.

Тебе нравится быть в ПК? Что это для тебя?

Да, мне нравится. Это прекрасное времяпрепровождение по четвергам вечером :)

Но на самом деле это дает много возможностей.

Во-первых, я встречаю много интересных людей, которые стараются в своих выступлениях показать то, что сообщество считает интересным. Во-вторых, так я могу свое видение интересного вывести на широкую аудиторию. А третий пункт это дает развитие мне самому. У нас распределение докладов между членами ПК происходит не только по принципу мне интересно и/или я разбираюсь в этом. Бывает, что хочешь тему понять глубже и становишься куратором докладчика.

Ты сам часто бываешь на конференциях?

На наших да. На HighLoad стараюсь попасть, но даже если не попадаю, всегда смотрю интересные доклады в записи. Некоторые вещи даже пересматриваю и делаю себе пометки.

Но офлайн круче онлайна?

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

Я и выступать онлайн не люблю, потому что ты не понимаешь аудиторию. Говорить в монитор можно 5 минут или даже 10. Но за 40 минут, пока что-то рассказываешь, ты знать не знаешь может, все уже ушли кофе пить, а ты распинаешься. Я предпочитаю видеть аудиторию. Поэтому я за то, чтобы люди приходили и смотрели офлайн. Плюс я считаю, что конференция хороша, когда это совместная работа с обеих сторон и докладчиков, и слушателей которые к тому же находятся в одном помещении. Когда ты пришел, тебе уже, черт возьми, неудобно перед человеком, который стоит на сцене! Ты, конечно, в телефончике можешь что-то тыкать, но общий коэффициент полезного действия от слов докладчика сильно выше.

Как часто ты сам выступаешь?

На HighLoad я выступал последний раз в 2018 году, и у меня было 3 доклада. Пару раз был спикером на TeamLead Conf. А сейчас у меня пока нет таких вещей, которыми хотелось бы похвастаться. Можно, конечно, из пальца высосать какую-то тему. Даже она кому-то будет интересна потому что всегда найдутся люди, у которых нет твоего опыта и твои слова будут им нужны и интересны. Но хочется же, чтобы доклад нравился самому себе.

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

Как построить доклад, чтобы выступление было запоминающимся и интересным? Какие-то фишки есть у тебя?

Доклад должен нравиться мне самому. То есть я должен любить и верить в то, о чем я говорю. Если мне это нравится, я этим горжусь, то расскажу красиво, ярко и людям тоже понравится. Но я не люблю повторяться и мусолить одну и ту же тему на десятках конференций. Это неинтересно, так как доклад уже публичный, его теперь любой может найти и посмотреть. Можно рассказать примерно о том же самом и под другим углом, но максимум два раза. Потому что хочется больше новых интересных докладов.

В целом же ты должен понимать запросы аудитории, чтобы предложить конкретный практический опыт в том, о чем говоришь. Тогда можно привести примеры, которые зайдут аудитории и люди поймут, зачем им это нужно. Важно говорить на одном языке с аудиторией. И подсвечивать, не скрывая, проблемы, которые были у тебя. Есть доклады: У нас было все прекрасно! Сейчас мы сделали все еще более замечательно! но так не бывает. У всех всегда есть большая бочка дегтя и всего одна ложка меда, а все только про нее и рассказывают. А самое важное это как раз то, как бочку расхлебать.

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

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

Что же ждет нас в этом году на HighLoad++ 2021?

Подготовка к HighLoad++ Весна 2021 из-за пандемии безумно растянулась во времени. Но зато и программа получилась плотная, классная. Сейчас самое время обкатать все сложившиеся темы, даже если некоторые подустарели за полтора года.

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

Хороший доклад от Ozon про Data Management Platform. Будет интересно узнать, как ребята автоматизировали фильтрацию пользовательских событий. Сама тема мне тоже довольно близка, поэтому я с удовольствием послушаю.

Очень интересный доклад Математика и разработка быстрых TLS-хендшейков. Мы в ivi довольно много в свое время помучились с хендшейками и тем, как разные устройства их осуществляют. Да и в общем сама тема о том, на чем построены все защищенные соединения очень животрепещущая.

Также всегда очень интересно послушать Андрея Аксенова даже когда он несет какую-то дичь, все равно это интересная дичь. В этот раз у него будет прикладная эзотерика. Хочу это послушать, потому что 80% его докладов фееричные. Ну и просто интересно узнать, что у человека в голове.

Доклад Погружение в Helm package manager пришел к нам по рекомендации, и после проверки тоже вошел в программу. Олег Вознесенский из X5 Retail group расскажет про Helm. Это как раз тот случай, когда мне интересно послушать конкретные use case и какие-то вещи, которых в документации нет, а человек уже их попробовал и у него есть экспертиза. И Олег очень просто и на пальцах объясняет те штуки, которые надо долго пробовать, чтобы накопить эту экспертизу.

Также всегда приятно послушать Алексея Миловидова. Он говорит про интересные вещи, которые иногда становятся основой для философии. К тому же мне очень интересно всё, что касается ClickHouse. В ivi мы его применяем тоже, и поэтому эта тема всегда очень острая для нас.

Еще в этом году будут выступать Коля Самохвалов, а Костя Осипов покажет паксос в картинках. Костя блестящий инженер и всегда режет правду-матку, не стесняясь ни регалий, ничего. Хочет кого-то отчихвостить расскажет всё, что думает. У него может быть честный, искренний доклад, а я такие люблю.

Денис Рожков и Георгий Тарасов в Информационной безопасности против HighLoad раскроют нужную и одновременно интересную тему про кибербезопасность. А Mail.ru расскажет историю про версионирование данных на Tarantool.

А еще Саша Тоболь! Мой хороший друг, прекрасный инженер, который великолепно рассказывает, прекрасно разбирается в материале и всегда очень глубоко погружается во все темы. Саша бывший лид Одноклассников, а сейчас СТО в ВК. Его всегда классно послушать, у него редкое сочетание, когда и докладчик хороший, и инженер классный.

Также у Яндекс.Такси будет пара интересных докладов. Про рефакторинг в большом проекте и отказоустойчивость сервиса. И особенно мне интересно, как аудитория воспримет доклад Максима Педченко. Его тема очень интересная, и работая с ним, я видел, что Максим старается сделать из своего выступления действительно нужный и полезный материал, рассказывая о проблемах популярного сервиса и способах решения типовых проблем.

В общем и целом какие боли затрагивает эта конференция и чем она поможет слушателям?

Как и в прошлый раз, будут тонны кейсов, которые рассмотрят тонны проблем. Начиная от баз данных, масштабирования, и заканчивая какими-то узкоспециализированными вещами про архитектуру или математику. Направленность конференции та же. Инженеры по-прежнему регулярно сталкиваются с кучей проблем: об одних им рассказывали в институте, о других не знает никто, но зато по части третьих уже есть опыт и практика. Ценность конференции в том, что ты приходишь, слушаешь и понимаешь ага, такой-то кластер проблем такая-то компания решила так-то и так-то.

И даже если у тебя была аналогичная задача, в твоей коллекции появится еще одна тропинка, по которой кто-то сходил и чего-то добился (либо нет). Ты можешь свое текущее решение сравнить с тем, что рассказывают коллеги на сцене. И даже можешь подойти потом и сказать: Ребята, вы идиоты! Зачем вы это сделали, можно ведь так, так и так. Тут неожиданно выясняется, что у тебя одна специфика, а у них другая, но вы находите какие-то интересные мысли друг у друга, и всем становится хорошо. Где вы такое найдете в онлайне или в статье?

Последний вопрос: что HighLoad лично для тебя?

Сначала это была просто тусовочка, а сейчас это работа, хобби, увлечение и сообщество.

HighLoad++ довольно интересная конференция, которая позволяет тебе посмотреть на свои проблемы под другим углом. Ты, может, и не найдешь решения своей конкретной задачи, но другие use cases могут тебя подтолкнуть на идеи, что можно еще и по-другому сделать. И в том направлении, о котором ты совсем не думал. Это и ценно в любой конференции. На HighLoad у меня было много таких открытий.

А самое интересное это люди, у которых можно проконсультироваться в случае чего. Даже когда ты сам выступаешь, к тебе постоянно приходят люди и спрашивают а это как? Постепенно у тебя нарабатывается свой ближний круг общения, чтобы можно было у кого-то что-то спросить и с кем-то поделиться.

С каким настроением идти на HighLoad++?

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

КонференцияHighLoad++ Весна 2021уже готовится к посадке 17 и 18 мая в Москве в Крокус-экспо мы все встретимся и обсудим всё то, что невозможно было обсудить в чатиках. Расписание ждет вас, а там в течение всех двух дней 8 потоков выступлений, 6 мастер-класов и пивная вечеринка!

Билеты можно купитьздесь. А подписавшисьна нашу рассылку, можно получить материалы мини-конференции Saint HighLoad++ 2020 :)

При поиске проблем в RDBMs разработчик обычно подозревает медленные запросы. А что, если дело не в них? О том, какого типа запросы дают нагрузку на базу данных, не позволяя вашему приложению работать должным образом, рассказал в своем докладе на конференции Saint HighLoad++ Online 2020 администратор баз данных Data Egret Андрей Сальников.

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

До момента всеобщей изоляции на поддержке Data Egret был сервис, на котором мастер-база держала где-то 50 тысяч транзакций в секунду.

Когда наступила изоляция, и онлайн-сервисы обрели особенную популярность, на этой базе данных компания уперлась в процессорный потолок, после чего появилось решение переехать на новое оборудование. Количество транзакций, обрабатываемых базой данных, после переезда скакнуло выше 100 тысяч в секунду, и это только на Master Server.

Что было сделано

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

• Увеличение количества приложений, потому что нужно обслуживать более мощную онлайн-нагрузку.

Казалось бы, все работает хорошо: конечная онлайн-нагрузка, которая идет к сервису, на тот момент увеличилась в три раза. Но увеличение транзакций вдвое выглядело подозрительным. Дело в том, что читающая нагрузка на базу данных распределена между несколькими, поэтому пишущая нагрузка, характерная для Master Server БД, растет слабо при большом росте онлайна на сервисе.

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

В первую очередь в компании обратились к данным мониторинга:

• Среднее время выполнения запросов уменьшилось на 10 мс по сравнению с предыдущим оборудованием и предыдущей нагрузкой;

• Сетевой трафик почти не изменился;

• Количество запросов стало больше. Использование ресурсов трудно оценить, потому что изменилось оборудование, и однозначной оценки, больше или меньше ресурсов используется, в такой ситуации дать сложно;

• Не получилось оценить и изменение параметров сервера.

Вроде бы, все хорошо. Но проблема осталась не решенной.

Так как речь идет о базе данных, нужно было посмотреть, что изменилось с профилем нагрузки на БД, и что случилось с запросами. Мониторинг результатов не дал. Но есть и другие инструменты.

Например, pgstatstatements.

В Data Egret этот инструмент используется постоянно, так как в нем есть три приятных бонуса:

1. Отчеты за прошлые периоды обновляются каждые сутки;

2. pgstatstatements логирует абсолютно все, в том числе, частые запросы. В отличие от pgBadger, который зависит от настроек;

3. Можно оценить влияние запросов на серверные ресурсы и соответственно на базу данных, потому что БД использует серверные ресурсы (дисковая память и процессорное время).

Что же удалось обнаружить в pgstatstatements?

До того, как в компании начала расти нагрузка, стандартный отчет, который формируется на основании pgstatstatements, выглядел так:

Есть общая нагрузка по количеству запросов, которая прилетела в база данных за сутки. Здесь это total queries: 3,555,539,206 (unique: 2,268).

Есть специальная позиция other, в которую группируются запросы, не дающие существенную нагрузку на БД: calls: 1,977,858,485 (43.42%) avg_time: 0.06ms (IO: 33.3%).

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

Все остальные запросы в отчете выглядят примерно так: SELECT field1, field2 FROM table1 WHERE field3 = ? and field4 between ? and ?

Они несложные: какая-то выборка по простым условиям, иногда 1-2 joinа ничего сверхъестественного, что могло бы вредить базе данных и требует нашего разбирательства.

После того, как вырос онлайн, отчет изменился:

Что изменилось после начала самоизоляции

• Время на запросы уменьшилось

В отчетах есть общее время, за которое база данных потратила больше ресурсов на выполнение запросов. В старом на это ушло 90 часов, в новом 60.

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

• Количество запросов выросло

Общее количество запросов, которые прилетели в базу данных, стало существенно больше (примерно в 1,5 раза). Это видно на графиках.

• Отсутствие пропорций

Если сравнивать позицию по запросам, которые не оказывают существенного влияния на БД, то тут рост не такой пропорциональный:

Казалось бы, должно быть 3 млрд запросов, но на самом деле рост всего несколько процентов. Значит, что-то изменилось в нагрузке на базу данных, и нужно смотреть отчет дальше.

Смотрим вглубь

Просматривая отчет, мы долистали до 17 позиции и увидели запрос, который вызывается 1,5 млрд раз и выглядит как SELECT 1:

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

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

В итоге SELECT 1, являясь стандартным пингом коннекта, и, в то же время, приводит к негативным результатам. Ведь на время этого пинга мы:

• Теряем возможность использовать это соединение для действительно полезного запроса;

• Даем лишнюю нагрузку на CPU (серверные ресурсы БД);

• Имеем лишнюю нагрузку на сеть, потому что нам нужно пообщаться между бэкендом приложения и БД, чтобы выяснить, что произошло и доступна ли база данных. Это бестолковая трата ресурсов.

По факту произошло следующее: при переносе приложения потерялся патч на ORM, который немного срезал такие пинги.

После правок

Давайте посмотрим на график по количеству транзакций, после того, как были внесены правки в ORM:

Выглядит не очень впечатляюще. Подумаешь, стало на 20 тысяч транзакций меньше! Но с точки зрения процессорного времени на баунсерах, после выкатки патча стало гораздо лучше.

Можно отследить результат и по общей нагрузке:

До 4 апреля в приложении был не патченный ORM. После этого пика в 100 тысяч транзакций больше не было. База отдана только под полезные запросы, которые необходимо выполнять.

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

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

SELECT 1 реальный случай. На его месте могут быть более простые запросы. Например, в ситуации, когда для отрисовки веб-формы необходимо вычитывать справочники. Не смотря на то, что они дают полезную информацию, она никогда не меняется. Желательно кэшировать ее на стороне бэкенда, а не ходить за ней в базу данных.

Маленькие запросы могут принести большие проблемы, которые можно сразу не разглядеть.

Мы поговорили о быстрых запросах. Теперь перейдем к мертвым.

Быстрый и Мертвый

В какой-то момент на сервере базы данных резко стало использоваться много процессорного времени. Этот вариант более тривиальный с точки зрения расследования далеко копать не надо:

План действий тот же самый:

• Изучаем мониторинг;

• Смотрим статистику в pgstatstatements;

• Чиним;

• Говорим об обнаруженной проблеме разработчикам.

Как выглядит отчет теперь?

В самой топовой позиции дается самая большая нагрузка. Исключение other, там аккумулируется вся оставшаяся нагрузка, которая не является топовой. Он может находиться в любой позиции отчета.

Сразу видим pos:1 total time: 02:05:26 (20.3%, CPU: 38.6%, IO: 2.0%). База данных тратит на этот запрос 38% процессорного времени.

Допустим, мы с определенной частотой ищем в платежной системе последние транзакции, созданные по каждому платежному сервису отдельно:

select distinct on (paymentsystem), * from transactions order by createdat desc;

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

Починка будет выглядеть так:

Из маленького запроса, который работает 1 с, мы получаем большой запрос на 2 мс. Идем в комнату к разработчикам и просим их переписать запрос. Деплоим, и ситуация возвращается в привычное русло.

Отчет pgstatstatements позволяет довольно быстро находить запросы, которые портят нам жизнь.

Инструменты

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

pgBadger

Плюсы:

• Полная информация обо всех запросах;

• Красивые картинки.

Посмотреть на работу pgBadger можно на тестовой странице.

Минусы:

• Специальный конфиг для логов;

• Дополнительная нагрузка на диски, потому что количество пишущихся логов резко возрастает;

• Анализ запросов постфактум;

• Для pgBadger нужно большое количество места.

pgstatstatements

Плюсы:

• Стандартное расширение PostgreSQL, идет из коробки;

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

• Собирает информацию по всем запросам;

• Группирует одинаковые запросы;

• Можно сбрасывать статистику;

• Можно сделать свой отчет на основе pgstatstatements.

Минусы:

• Оверхед на выполнение запроса 2-5%;

• Запросы обезличенные;

Чтобы разбираться с каким-то запросом, придется все-таки включить логирование в PostgreSQL и забрать из логов запрос с параметрами, которые нужно подставлять.

• Несущественные запросы вымываются;

• Почти нет мониторингов, которые умеют с ним работать;

• Не видит разницы между SELECT и SELECT FOR UPDATE;

• В сыром виде данные неудобны для восприятия.

В мониторинге картинка по одному запросу выглядит следующим образом:

Такие картинки можно собирать по всем запросам, которые зафиксированы в pgstatstatements, а потом смотреть в динамике, сколько времени тратится на выполнение того или иного запроса, какие ресурсы он потребляет, как часто вызывается.

Типичные проблемы

Какие же проблемные запросы можно встретить на практике?

Давайте рассмотрим самые распространенные из них.

• Результат запроса нигде не используется;

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

• Неоптимально работающий запрос;

Например, distinct.

• Постоянное обращение к справочникам;

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

• Нехватка индексов на простеньких запросах;

Что-то задеплоили, но забыли индекс. Это можно увидеть в отчете и исправить.

• Смешивание нагрузки OLTP и OLAP на репликах.

Эта проблема связана с общением разработчиков с бизнес-экспертами. Последним бывает трудно объяснить, что OLAP нагрузка не может выполняться на реплике, которая отстает на 3 секунды.

Если отчет выполняется 2 часа, то информация в нем уже на 2 часа устарела. Соответственно, когда одного сервера не хватает, нагрузку OLTP и OLAP нужно разделять по разным серверам.

Не путайте причины проблем с запросами и с длительными транзакциями в базе данных.

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

Выглядит это так: существуют длительные транзакции, которые длятся 30-40 минут, и в это же время есть миллисекундные всплески запросов.

Если в это время посмотреть на состояние соединения в базе данных, мы увидим много простаивающих соединений (они отмечены желтым цветом):

idle in transaction это соединение, когда приложение открыло транзакцию в БД, выполнило один запрос и ушло заниматься своими делами, забыв закрыть транзакцию. Именно это, в основном, и является первопричиной многих проблем. Как только она решается, можно заниматься тем, с чего начинается статья: искать запросы, которые мешают вам жить.

Вместо заключения

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

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

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

А интересующихся миром Java ждем на онлайн-митапе Luxoft TechFest #2: Java with Ontico. На нем поговорим о приватных полях-константах в Jira, неочевидных нюансах Java Reactive Stack и работе с распределенным кешем. А после своих выступлений звезды митапа ответят на самые животрепещущие из ваших вопросов. До встречи 10 февраля в 19:00 мск.