Есть в российских регионах то, в чём они могут переплюнуть обе столицы – это умение совместить полезное, хайповое, душевное и ламповое. Недавно мы побывали в Самаре на фестивале интернет-деятелей 404, который стал ярким тому подтверждением. Ниже – пять характерных особенностей «выездных» программистских тусовок, создающих нужный градус конструктивного релакса.

1. Мероприятия с изюминкой

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

С 404Fest как раз такая история. Он вырос из ежегодных встреч самарских «технарей», после окончания института разъехавшихся по всему миру. Кто-то живет в Норвегии, кто-то – строит свой бизнес в США и Канаде. Собираясь на родине, они делятся своим уникальным опытом друг с другом. Фестиваль – это удачный способ увеличить масштаб и аудиторию такого междусобойчика. В итоге в центре обсуждения на мероприятии не способы перенести иностранные наработки на российскую почву, а проблемы западного бизнеса, работающего на острие технологического прогресса. Информация из первых рук, на русском, прошедшая через привычный нам культурный дешифратор.

2. Привычный городской комфорт на природе

Не стоит думать, что всё кроме Москвы и Питера в России – тлен и разруха. В крупных провинциальных городах, особенно тех, по которым прокатился чемпионат мира по футболу, сложилась качественная городская среда, привычная столичному жителю. Добраться до такого города просто: доехал до вокзала, заснул в комфортабельном поезде, наутро уже на месте. А там всё те же привычные сервисы: такси, навигаторы и тд. Всё те же привычные торговые сети кофеен, пиццерий, ресторанов, магазинов. Словно попал в еще один район Москвы.

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

3. Меньше пафоса, больше нетворкинга

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

На региональных тусовках обычно всё весьма демократично. Выступающие спокойно относятся и к своей теме, и к своему месту в профессиональном сообществе, они открыты для общения. Нетворкинг на таких тусовках проходит очень продуктивно. И не забываем, что программисты кроме личного «общения в кулуарах» очень любят отправлять свои вопросы в мессенджеры. Наш корпоративный архитектор Александр Трехлебов (holonavt), выступивший на 404Fest с докладом по микросервисам, потом весь вечер в Telegram отвечал на вопросы слушателей. Так как конференция была посвящена фронтенду, его выступление было по большей части ознакомительным. UI-специалистам полезно знать, что находится под капотом современных web-решений.

Содержание вступительной части мы ранее описали в статье Эволюция декомпозиции: от Linux-серверов до Kubernetes. Александр подробно рассказал о компонентах современного микросервисного приложения, это Discovery-сервис, Config-сервер, Gateway, Auth-сервис и система мониторинга. Показал, как они взаимодействуют с прикладными элементами и внешним миром.

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

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

Кстати, вот выступление Александра, можете посмотреть сами и задать свои вопросы в комментариях к статье.

4. Удобное планирование

Когда параллельно идет 6-10 выступлений, сложно успеть побывать на всех интересных. А при этом же есть и другие важные активности: кофе-брейки, обеды, розыгрыши ништяков, которые не стоит пропускать. Хорошо продуманные региональные мероприятия оставляют после себя ощущение, что вроде всё успел.

На 404Fest очень помогало мобильное приложение, специально написанное к мероприятию. В нем была вся нужная информация по выступлениям, возможность сформировать список избранных докладов, напоминалки, гид по городу, собственный Фестограм (лента фотографий участников) и чат для общения с любым участником фестиваля. И никаких бумажных расписаний!

5. Лекции от смузи до хардкора

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

На 404Fest поднимались разные темы: от бэкенда до дизайна, UX, стартапов и интернет-маркетинга. Представительные спикеры, злободневные серьезные темы – и при этом очень доступное и человеческое изложение фактов. Залы были забиты битком.

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

Есть что вспомнить

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

На выставке в холле были креативные стенды ключевых партнёров мероприятия. Стенд Промсвязьбанка стал центром оригинальных фотосессий. На фоне пресс-вола с Зайцем Несудьбы можно было сфотографироваться с оригинальными табличками и в подарок получить фотомагнит со своей фотографией.

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

История моей сверхсекретной чашки для кофе

«Пожалуйста, слушайте внимательно и не вешайте трубку». Это первые слова, которые неизвестный мужчина произнёс по телефону, когда брат передал мне трубку.

Были выходные на праздник 4 июля 2000 года, плюс-минус день, и мистер Икс знал: нужно начать именно с этих слов, потому что он звонил за полночь на домашний телефон моего брата в Коннектикуте. Это было особенно жутко, потому что я жил в Калифорнии, и никто не знал, что я в Коннектикуте, за исключением моих ближайших родственников, которые все были там в доме со мной. Я приехал накануне, как обычно делаю во время нашего ежегодного семейного пикника на День независимости.

Зачем он звонил?

Это был вопрос национальной безопасности.

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

Некоторые из моих родных начали собираться рядом с кухней, где я стоял у стены с телефоном. Чёрт возьми, что происходит? Я посигналил брату принести ручку.

Я пытался осмыслить происходящее. Как ни странно, даже не догадался спросить у Дэйва, как он получил этот номер. Мужчина казался серьёзным и говорил авторитетным голосом; думаю, я уже поверил, что он имеет на это право.

Окей, готов записывать.

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

Перезвоните

Дэйв сказал повесить трубку, набрать 411 (справка) и спросить у оператора основной номер военно-морской базы в Бетесде, штат Мэриленд. Затем позвонить по этому номеру, пройти через нескольких других операторов на базе, попросив каждого по очереди подключить меня к следующему в цепочке. Он продиктовал точные слова для каждого такого прыжка, потому что я буду просить о перенаправлении на защищённый объект.

Адреналин ударил в голову и я проснулся.

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

Через несколько минут я снова разговаривал по телефону с Дэйвом. Обалдеть, АНБ. Это происходило на самом деле.

Нам нужна ваша помощь

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

Если АНБ не получит доступа к файлам, случатся неприятности.

SafeHouse был (и до сих пор остаётся) популярной утилитой Windows, которую я разработал для шифрования приватных файлов, она распространяется как shareware. В бесплатной версии шифрование специально ослаблено в соответствии с требованиями Госдепа на экспорт вооружений, а также чтобы подтолкнуть пользователей к покупке продвинутой платной версии. Клиенты разные, от домашних юзеров до крупных финансовых организаций.

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

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

Конечно, Дэйв сразу спросил, есть ли бэкдор для расшифровки, потому что это сэкономит много времени. Но нет. SafeHouse разработан по самым высоким стандартам и передовым практикам с использованием сильного 256-битного шифрования.

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

Звонок. Письмо. Готово.

Я попробовал прощупать почву: ребята, так вы действительно способны взломать 256-битное шифрование? Дэйв хранил молчание. В криптосообществе давно обсуждают эту тему; и я подумал, что стоит попробовать. Даже не рассчитывал на ответ.

Когда этот парень с ноутбуком купил SafeHouse? Какая у него версия? Чем больше я знаю, тем лучше смогу вам помочь.

И вот тогда Дэйв признался, что у чувака на ноутбуке shareware-версия. Что, серьёзно? Это всё меняет. Условно-бесплатная версия поддерживала только слабенькое 40-битное шифрование. Большинство хакеров могут взломать его за пару дней. И я думаю, что секретным шифровальщикам АНБ потребуется гораздо меньше времени.

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

Тупые преступники

Но серьёзно, этот идиот с ноутбуком планировал взорвать здание или что-то такое, но у него не хватило мозгов или денег, чтобы купить нормальную версию программы за $39,99 с максимальным шифрованием?

На этот раз Дэйв ответил: «Удивительно, но такое происходит постоянно. Их называют тупыми преступниками не просто так. Невероятно, но это правда».

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

Подарок

Через несколько дней я вернулся домой в Калифорнию, и в моём офисе стояла коробка без опознавательных знаков, с указанием моего имени. Внутри, завёрнутая в белую папиросную бумагу, лежала синяя чашка для кофе АНБ с рукописной запиской на обычной белой бумаге: «Спасибо. Дэйв».

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

Ещё раз я попытался вытянуть детали и спросил, означает ли «сработало», что они взломали шифр; но конечно, он ничего не сказал. Молчалив как обычно. Наверное, с ним весело на вечеринках. Дэйв вообще его настоящее имя?

Когда я поблагодарил за подарок, то не мог умолчать о тайной записке, которую он положил в коробку. Дэйв просто рассмеялся и сказал: «Это мои обычные бланки в АНБ».

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

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

Но одна вещь сидит у меня в голове все эти годы: как, чёрт возьми, Дэйв выследил меня за 3000 миль от дома посреди ночи в тот жаркий летний вечер в Бристоле, штат Коннектикут?

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

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

Конвой Эйзенхауэра, Великая депрессия, и стройка Рузвельта

34 президент США Дуайт Эйзенхауэр во время своей службы в бронетанковом корпусе, 1919 год

Сложно спорить с тем, что культура профессиональной релокации пришла к нам из США. В начале 20 века произошло событие, которое изменило не только историю Соединенных Штатов и, в итоге, сделало их великой державой, но повлияло на профессиональную жизнь всего мира. Речь идет об автомобильном конвое Эйзенхауэра, который стартовал в 1919 году от стен Белого дома с целью пересечь всю страну от Вашингтона до Сан-Франциско. Носит он такое название, так как молодой Эйзенхауэр, которому будет суждено стать 34 президентом США, тоже принимал в нем участие. Цель конвоя была проста: 80 грузовиков, 258 солдат и 24 офицера проедут всю страну, чтобы не только показать простым американцам героев Первой Мировой, но и доказать важность строительства трансконтинентальных шоссе. И конвой справился с последней задачей на «отлично».

Начавшийся было бодро автопробег по территории США с углублением в территорию страны превратился для его участников из легкой прогулки в форменный кошмар. Если на атлантическом побережье в начале века у Соединенных штатов была достаточно развитая транспортная инфраструктура, то при приближении к пункту назначения дороги становились все хуже и хуже, превращаясь, в итоге, в так знакомые нам «направления».

Конвой настолько увяз в грязи бездорожья, что автопробег «от края до края» протяженностью чуть менее 5000 километров занял у военных два месяца. То есть можете себе представить: подготовленные, неприхотливые в дороге солдаты на спецтехнике того времени потратили 62 дня на дистанцию, которая сейчас занимает максимум неделю-полторы.

Часть маршрута конвоя совпала с современным шоссе 66 — дорогой, объединяющей восток и запад США. Но до 1936 года заасфальтировано было всего 800 из 4000 километров шоссе. В остальном была либо гравийка, либо кирпичная кладка, либо просто «направление», на котором легко увязнуть:

Фото сделано в 1930-х

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

С обвалом бирж и наступлением Великой депрессии внутри страны начались миграционные процессы, которые легли в основу современного образа жизни множества американцев. Сотни тысяч людей покидали свои дома в поисках работы, чтобы банально выжить. Масла в огонь подлили пыльные бури 1930-1936 годов, которые вошли в историю как «пыльный котел«. В результате этой погодной аномалии почти 2,5 млн жителей штатов, расположенных в прериях, бежали из своих домов в другие, более благополучные регионы страны.

Техника, занесенная пыльной бурей, Южная Дакота, 1936 год

Совокупность этих природных и экономических факторов показала руководству страны важность обеспечения свободного перемещения населения на большие расстояния и с 1936 по 1938 год, под патронажем тогдашнего президента Рузвельта в рамках мер по борьбе с Великой Депрессией, шоссе 66 было полностью заасфальтировано, что положило начало эпохе дорог США в частности и началу свободного перемещения широких слоев работников в целом.

Президентство Эйзенхауэра

Проект, начатый Рузвельтом в виде создания асфальтированной «Route 66», несомненно важен, но полную «дорогофикацию» всей страны, которая изменила экономические предпочтения США и показала миру, что такое гибкость кадрового вопроса, затеял именно Эйзенхауэр.

Во время своих президентских сроков в период с 1953 по 1961 годы, уже умудренный опытом и прошедший три войны Эйзенхауэр (обе мировые плюс корейская) заявил, что Америке жизненно необходима разветвленная сеть качественных и доступных для населения дорог. Это особенно удивительно на фоне того, что Эйзенхауэр был республиканцем, то есть придерживался мнения, что федеральный бюджет должен нести минимальные издержки на социальное обеспечение. В 1956 году с подачи Эйзенхауэра Соединенные Штаты начали одну из крупнейших строек в истории, по масштабу с которой на тот момент были сравнимы только советские проекты транссиба и массовой электрификации.

Командой Эйзенхауэра был разработан, а в 1956 году конгрессом принят законопроект под названием Federal Aid Highway Act, также известный как «Закон о национальных межштатных автомобильных и оборонительных магистралях» (National Interstate and Defense Highways Act), согласно которому в стране началось строительство Системы межштатных автомагистралей США. В пересчете на современные цены на строительство 77 500 километров дорог в США с 1956 по 1992 годы было потрачено 500 млрд долларов. Как итог США получили сеть федеральных бесплатных дорог, которые, по мнению множества экономистов, обеспечили США не только связность регионов, но и немалый экономический подъем за счет мобильности товаров и кадров.

Каким образом президент-республиканец решился на такую колоссальную трату федеральных денег? Сам Эйзенхауэр говорил, что пришел на вершину политики «из вне», что было правдой. Также 34 президент США заявлял, что «ничего не смыслит в экономике». Но у настойчивости Эйзенхауэра в трате федеральных денег было несколько причин. Первая — упоминаемый нами ранее автопробег, который Дуайт вспоминал до самой смерти, в том числе и в своих мемуарах. Второе — опыт Эйзенхауэра во время Второй Мировой в Европе, где он увидел рейхавтобаны и был весьма впечатлен нацисткой концепцией быстрого перемещения сил внутри страны по хорошим дорогам. Ну и третье — корейский опыт командования, который показал Эйзенхауэру важность мобильности войск. Именно благодаря вышеописанным событиям Эйзенхауэр был глубоко убежден в пользе проекта сетей шоссе для экономики и армии, и оказался абсолютно прав.

Сеть скоростных шоссе США

Проект оказался настолько громоздким, что его строительство затянулось до 1992 года, при этом часть магистралей так и не была достроена до конца и объединена в единую сеть из-за сопротивления стройке со стороны местных жителей. Однако разветвленная сеть дорог открыла перед жителями новые возможности в плане релокации и трудовой миграции, хотя почти и убила железнодорожную систему страны. Случилось это в первую очередь потому, что почти все железнодорожные магистрали в США находились в частной собственности и не могли конкурировать с бесплатными федеральными дорогами, а массовость автомобилей в США только подстегивала население к отказу от железнодорожного транспорта дальнего следования.

Опыт Китайской Народной Республики

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

До конца 1980-х в Китае вообще не было скоростных магистралей. Для достижения «дорожного превосходства» на вооружение был принят опыт Соединенных Штатов и в 1989 году власти КНР начали самый масштабный транспортный проект в истории человечества, который продолжается до сих пор. По статистике в 1988 году в китае было 0 километров скоростных магистралей. В 1989 году было построено всего 147 километров дорог, к 2000 году общая протяженность скоростных магистралей в Китае выросла до чуть более внушительных 11 600 километров. Но это было только начало. За следующие 17 лет, то есть к 2017 году, автомагистральная сеть разрослась до 136 000 километров.

Сеть Скоростных автотрасс Китайской Народной Республики

Строительство дорог в Китае стимулировало урбанизацию страны и миграцию кадров, что дало очередной толчок экономике КНР. При этом строительство скоростных магистралей в Поднебесной продолжается до сих пор и судя по настрою председателя Си Цзиньпина в плане развития страны и повышения качества жизни китайцев, прекращаться не намерено. Цель Китая — для начала объединить все сравнительно крупные населенные пункты (от 100-200 тыс. населения) одной сетью магистралей.

Удаленная работа как обратная сторона медали релокации

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

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

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

Недавно Google предоставил бесплатный доступ к своим тензорным процессорам (tensor processing unit, TPU) на облачной платформе для машинного обучения Colaboratory. Тензорный процессор — это специализированная интегральная схема (ASIC), разработанная Google для задач машинного обучения с использованием библиотеки TensorFlow. Я решил попробовать обучить на TPU сверточную сеть на Keras, которая распознает объекты на изображениях CIFAR-10. Полный код решения можно посмотреть и запустить в ноутбуке.

Фото cloud.google.com

Тензорные процессоры

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

Сейчас есть три поколения тензорных процессоров, производительность TPU последнего, третьего поколения составляет 420 TFlops (триллионов операций с плавающей точкой в секунду), он содержит 128 ГБ памяти High Bandwidth Memory. Однако на Colaboratory доступны только TPU второго поколения, у которых 180 TFlops производительности и 64 ГБ памяти. В дальнейшем я буду рассматривать именно эти TPU.

Тензорный процессор состоит из четырех чипов, каждый из которых содержит два ядра, всего в TPU восемь ядер. Обучение на TPU ведется параллельно на всех ядрах с помощью репликации: на каждом ядре работает копия графа TensorFlow с одной восьмой объема данных.

Основа тензорного процессора — матричное устройство (matrix unit, MXU). Оно использует хитрую структуру данных систолический массив размером 128х128 для эффективной реализации операций с матрицами. Поэтому, чтобы наиболее полно использовать ресурсы оборудования TPU, размерность мини-выборки или признаков должна быть кратна 128 (источник). Также из-за особенностей системы памяти TPU желательно, чтобы размерность мини-выборки и признаков была кратна 8.

Платформа Colaboratory

Colaboratory — это облачная платформа от Google для продвижения технологий машинного обучения. На ней можно получить бесплатно виртуальную машину с установленными популярными библиотеками TensorFlow, Keras, sklearn, pandas и т.п. Самое удобное, что на Colaboratory можно запускать ноутбуки, похожие на Jupyter. Ноутбуки сохраняются на Google Drive, можно их распространять и даже организовать совместную работу. Вот так выглядит ноутбук на Colaboratory (картинка кликабельна):

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

Подробные инструкции по работе на платформе Colaboratory есть здесь, здесь и здесь.

Подключаем тензорный процессор на Colaboratory

По умолчанию Colaboratory не использует ускорителей вычислений GPU или TPU. Подключить их можно в меню Runtime -> Change runtime type -> Hardware accelerator. В появившемся списке выбираем «TPU»:

После выбора типа ускорителя виртуальная машина, к которой подключается ноутбук Colaboratory, перезапустится и станет доступен TPU.

Если вы загружали на виртуальную машину какие-то данные, то в процессе перезапуска они будут удалены. Придется загружать данные заново.

Нейронная сеть на Keras для распознавания CIFAR-10

В качестве примера попробуем обучить на TPU нейронную сеть на Keras, которая распознает изображения из набора данных CIFAR-10. Это популярный набор данных, содержащий небольшие изображения объектов 10 классов: самолет, автомобиль, птица, кот, олень, собака, лягушка, лошадь, корабль и грузовик. Классы не пересекаются, каждый объект на картинке принадлежит только одному классу.

Загружаем набор данных CIFAR-10 средствами Keras:

(x_train, y_train), (x_test, y_test) = cifar10.load_data()

Для создания нейронной сети я завел отдельную функцию. Мы будем создавать одинаковую модель два раза: первый вариант модели для TPU, на котором будем обучать, а второй для CPU, где будем распознавать объекты.

def create_model():     input_layer = Input(shape=(32, 32, 3), dtype=tf.float32, name='Input')     x = BatchNormalization()(input_layer)     x = Conv2D(32, (3, 3), padding='same', activation='relu')(x)     x = Conv2D(32, (3, 3), activation='relu', padding='same')(x)     x = MaxPooling2D(pool_size=(2, 2))(x)     x = Dropout(0.25)(x)     x = BatchNormalization()(x)     x = Conv2D(64, (3, 3), padding='same', activation='relu')(x)     x = Conv2D(64, (3, 3), activation='relu')(x)     x = MaxPooling2D(pool_size=(2, 2))(x)     x = Dropout(0.25)(x)     x = Flatten()(x)     x = Dense(512, activation='relu')(x)     x = Dropout(0.5)(x)     output_layer = Dense(10, activation='softmax')(x)     model = Model(inputs=[input_layer], outputs=[output_layer])     model.compile(         optimizer=tf.train.AdamOptimizer(0.001),         loss=tf.keras.losses.sparse_categorical_crossentropy,         metrics=['sparse_categorical_accuracy'])     return model

Пока на TPU нельзя использовать оптимизаторы Keras, поэтому при компиляции модели указывается оптимизатор из TensorFlow.

Создаем модель Keras для CPU, которую на следующем этапе преобразуем в модель для TPU:

cpu_model = create_model()

Конвертируем нейросеть на Keras в модель для TPU

Модели на Keras и TensorFlow можно обучать на GPU без каких-либо изменений. На TPU пока так делать нельзя, поэтому придется преобразовать созданную нами модель в модель для TPU.

Для начала нужно узнать, где находится доступный нам TPU. На платформе Colaboratory это можно сделать следующей командой:

TPU_WORKER = 'grpc://' + os.environ['COLAB_TPU_ADDR']

В моем случае адрес TPU оказался таким — grpc://10.102.233.146:8470. Адреса отличались для разных запусков.

Теперь можно получить модель для TPU с помощью функции keras_to_tpu_model:

tf.logging.set_verbosity(tf.logging.INFO) tpu_model = tf.contrib.tpu.keras_to_tpu_model(     cpu_model,     strategy=tf.contrib.tpu.TPUDistributionStrategy(         tf.contrib.cluster_resolver.TPUClusterResolver(TPU_WORKER)))

В первой строке включено логирование на уровне Info. Вот что в логе конвертации модели:

INFO:tensorflow:Querying Tensorflow master (b'grpc://10.102.233.146:8470') for TPU system metadata.
INFO:tensorflow:Found TPU system:
INFO:tensorflow:*** Num TPU Cores: 8
INFO:tensorflow:*** Num TPU Workers: 1
INFO:tensorflow:*** Num TPU Cores Per Worker: 8
...
WARNING:tensorflow:tpu_model (from tensorflow.contrib.tpu.python.tpu.keras_support) is experimental and may change or be removed at any time, and without warning.

Можно видеть, что найден TPU по указанному нами ранее адресу, в нем 8 ядер. Также мы видим предупреждение, что tpu_model является экспериментальной и может быть изменена или удалена в любое время. Надеюсь, что со временем можно будет обучать модели Keras напрямую на TPU без всякого преобразования.

Обучаем модель на TPU

Модель для TPU можно обучать обычным для Keras образом с помощью вызова метода fit:

history = tpu_model.fit(x_train, y_train,     batch_size=128*8,     epochs=50,     verbose=2)

Какие здесь особенности. Мы помним, что для эффективного использования TPU размер мини-выборки должен быть кратен 128. Кроме того, на каждом ядре TPU выполняется обучение с использованием одной восьмой всех данных в мини-выборке. Поэтому размер мини-выборки при обучении задаем в 128*8, получается по 128 картинок для каждого ядра TPU. Можно использовать больший размер, например, 256 или 512, тогда производительность будет выше.

В моем случае на обучение одной эпохи требуется в среднем 6 с.

Качество обучения на 50 эпохе:
Epoch 50/50
- 6s - loss: 0.2727 - sparse_categorical_accuracy: 0.9006

Доля верных ответов на данных для обучения составила 90,06%. Проверяем качество на тестовых данных используя TPU:

scores = tpu_model.evaluate(x_test, y_test, verbose=0, batch_size=batch_size * 8) print("Доля верных ответов на тестовых данных: %.2f%%" % (scores[1]*100))

Доля верных ответов на тестовых данных: 80.79%

Теперь сохраним веса обученной модели:

tpu_model.save_weights("cifar10_model.h5")

TensorFlow выдаст нам сообщение, что веса переданы с TPU на CPU:
INFO:tensorflow:Copying TPU weights to the CPU

Следует отметить, что веса обученной сети сохранились на диск виртуальной машины Colaboratory. Когда виртуальная машина будет остановлена, то все данные с нее сотрутся. Если вы не хотите терять обученные веса, то сохраните их на свой компьютер:

from google.colab import files files.download("cifar10_model.h5")

Распознаем объекты на CPU

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

model = create_model() model.load_weights("cifar10_model.h5")

Модель готова к использования на центральном процессоре. Давайте попробуем распознать с ее помощью одно из изображений тестового набора CIFAR-10:

index=111 plt.imshow(toimage(x_test[index])) plt.show()

Картинка маленькая, но можно понять, что это самолет. Запускаем распознавание:

# Названия классов из набора данных CIFAR-10 classes=['самолет', 'автомобиль', 'птица', 'кот', 'олень', 'собака', 'лягушка', 'лошадь', 'корабль', 'грузовик'] x = x_test[index] # Добавляем размерность, т.к. Keras распознает массив изображений x = np.expand_dims(x, axis=0) # Запускаем распознавание prediction = model.predict(x) # Печатаем значения на выходе из сети print(prediction) # Печатаем название класса объекта prediction = np.argmax(prediction) print(classes[prediction])

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

[[9.81738389e-01 2.91262069e-07 1.82225723e-02 9.78524668e-07
5.89265142e-07 6.76223244e-10 1.03252004e-10 9.23009047e-09
3.71878523e-05 3.16599618e-08]]
самолет

Распознавание прошло успешно!

Итоги

Удалось продемонстрировать работоспособность TPU на платформе Colaboratory, его вполне можно применять для обучения нейронных сетей на Keras. Однако набор данных CIFAR-10 слишком маленький, его недостаточно для полной загрузки ресурсов TPU. Ускорение по сравнению с GPU получилось небольшим (можете проверить сами выбрав в качеству ускорителя GPU вместо TPU и переобучив модель заново).

На Хабре есть статья, в которой измеряли производительность TPU и GPU V100 на обучении сети ResNet-50. На этой задаче TPU показал такую же производительность, как и четыре GPU V100. Приятно, что Google дает такой мощный ускоритель обучения нейронных сетей бесплатно!

Видео с демонстрацией обучения нейросети Keras на TPU.

Полезные ссылки

1. Ноутбук Colaboratory с полным кодом обучения модели Keras на TPU.
2. Ноутбук Colaboratory с примером обучения на TPU модели Keras для распознавания одежды и обуви из Fashion MNIST.
3. Тензорные процессоры в облаке Google.
4. Особенности архитектуры и использования тензорных процессоров.

К сожалению в интернете довольно мало информации по миграции реальных приложений и продакшн эксплуатации Percona XtraDB Cluster (далее PXC). Своим рассказом я постараюсь исправить эту ситуацию и рассказать о нашем опыте. Тут не будет пошаговой инструкции по установке и статью следует рассматривать не как замену офф документации, а как сборник рекомендаций.

Проблема

Я работаю системным администратором в ultimate-guitar.com. Так как мы предоставляем веб сервис у нас естественно есть бэкенды и БД, которая является ядром сервиса. Аптайм сервиса напрямую зависит от работоспособности БД.
В качестве БД использовался Percona MySQL 5.7. Резервирование было реализовано с помощью мастер-мастер схемы репликации. Слейвы использовались для чтения некоторых данных.

Но данная схема не устраивала нас следующими минусами:

• Из-за того, что в MySQL репликация асинхронная слейвы могли отставать на неопределенное время. Все критичные данные приходилось читать с мастера.
• Из предыдущего пункта вытекает сложность разработки. Разработчик не мог просто сделать запрос к БД, а был обязан продумать готов ли он в каждом конкретном случае к отставанию слейва и если нет, то читать данные с мастера.
• Ручное переключение в случае аварии. Автоматическое переключение реализовать было проблематично из-за того, что в архитектуре MySQL нет встроенной защиты от split brain. Пришлось бы самим писать арбитра со сложной логикой выбора мастера. При записи в оба мастера одновременно могли возникнуть конфликты, ломающие мастер-мастер репликацию и приводящие к классическому split brain.

Немного сухих цифр, чтобы вы понимали с чем мы работали:
Размер БД: 300 Гб
QPS: ~10к
RW ratio: 96/4%
Конфигурация мастер серверов:
CPU: 2x E5-2620 v3
RAM: 128 Gb
SSD: Intel Optane 905p 960 Gb
Сеть: 1 Гбит/с

У нас классическая OLTP нагрузка с большим количеством чтения, которое необходимо выполнять очень быстро и небольшим количеством записи. Нагрузка на БД достаточно маленькая из-за того, что активно применяется кэширование в Redis и Memcache.

Выбор решения

Как вы уже наверное догадались из заголовка мы выбрали PXC, но тут я объясню почему мы выбрали именно его.
У нас было 4 варианта:

1. Смена СУБД
2. MySQL Group Replication
3. Накручивать необходимый функционал самим с помощью скриптов поверх мастер-мастер репликации.
4. MySQL Galera cluster (или его форки, например PXC)

Вариант со сменой БД практически не рассматривался, т.к. приложение большое, во многих местах завязано на функционал или синтаксис mysql и миграция например на PostgreSQL займет кучу времени и ресурсов.

Вторым вариантом был MySQL Group Replication. Несомненным его плюсом является то, что он развивается в ванильной ветке MySQL, а значит в перспективе он получит широкое распространение и будет иметь большой пул активных пользователей.
Но у него есть несколько минусов. Во-первых он накладывает больше ограничений на приложение и схему БД, а значит произвести миграцию будет сложнее. Во вторых Group Replication решает проблему отказоустойчивости и split brain, но репликация в кластере по-прежнему асинхронная.

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

Galera позволяла полностью решить проблему с отказоустойчивостью MySQL и частично решить проблему с актуальностью данных на слейвах. Частично, потому что асинхронность репликации сохраняется. После коммита транзакции на локальной ноде изменения разливаются на остальные ноды асинхронно, но кластер следит что бы ноды не сильно отставали и если они начинают отставать, то он искусственно замедляет работу. Кластер гарантирует, что после коммита транзакции никто не сможет закоммитить конфликтующие изменения даже на ноде, которая еще не реплицировала изменения.
После миграция схема работы нашей БД должна выглядеть так:

Миграция

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

• Движок InnoDB для всех таблиц. MyISAM, Memory и прочие бэкенды не поддерживаются. Исправляется довольно просто — конвертируем все таблицы в InnoDB.
• Binlog в ROW формате. Кластеру для работы не требуется бинлог и если вам не нужны классические слейвы, то вы можете его выключить, но формат бинлога должен быть ROW.
• Все таблицы должны иметь PRIMARY/FOREIGN KEY.Это требуется для правильной конкурентной записи в одну таблицу с разных нод. Для тех таблиц, которые не содержат уникальный ключ можно использовать составной Primary key или авто инкремент.
• Не использовать ‘LOCK TABLES’, ‘GET_LOCK()/RELEASE_LOCK()’, ‘FLUSH TABLES {{table}} WITH READ LOCK’ или уровень изоляции ‘SERIALIZABLE’ для транзакций.
• Не использовать ‘CREATE TABLE… AS SELECT’ запросы, т.к. они объединяют изменение схемы и данных. Легко разбивается на 2 запроса, первый из которых создает таблицу, а второй наполняет данными.
• Не использовать ‘DISCARD TABLESPACE’ и ‘IMPORT TABLESPACE’, т.к. они не реплицируются
• Установить опции ‘innodb_autoinc_lock_mode’ значение ‘2’. Эта опция может повреждать данные при работе со STATEMENT репликацией, но поскольку в кластере разрешено использовать только ROW репликацию, то проблем не будет.
• В качестве ‘log_output’ поддерживается только ‘FILE’. Если у вас запись логов велась в таблицу, то придется это убрать.
• XA транзакции не поддерживаются. Если они использовались, то придется переписать код без них.

Должен заметить, что почти все эти ограничения можно убрать, если установить переменной ‘pxc_strict_mode=PERMISSIVE’, но если вам дороги ваши данные, то лучше этого не делать. Если у вас установлен ‘pxc_strict_mode=ENFORCING’, то MySQL не даст выполнить вышеуказанные операции или не даст запустить ноду.

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

Развертывание и конфигурация кластера

У нас на серверах БД работает несколько баз данных и другие БД не нужно мигрировать в кластер. Но пакет с MySQL кластером заменяет классический mysql. У нас было несколько вариантов решения этой проблемы:

• Использовать виртуализацию и запускать кластер в VM. Этот вариант нам не нравился большими (в сравнении с остальными) накладными расходами и появлением еще одной сущности, которую необходимо обслуживать
• Собрать свою версию пакета, которая будет ставить mysql в нестандартное место. Таким образом появится возможность иметь несколько версий mysql на одном сервере. Неплохой вариант если у вас много серверов, но постоянная поддержка своего пакета, который необходимо регулярно обновлять может отнимать достаточно большое ко-во времени.
• Использовать Docker.

Мы выбрали Docker, но используем его в минимальном варианте. Для хранения данных используются локальные volume. Используется режим работы ‘—net host’ для уменьшения сетевых задержек и нагрузки на CPU.
Нам пришлось так же собрать свою версия Docker образа. Причина в том, что стандартный образ от Percona не поддерживает восстановление позиции при запуске. Это означает, что при каждом перезапуске инстанса выполняется не быстрая IST синхронизация, которая заливает только необходимые изменения, а медленная SST, которая полностью перезаливает базу.

Еще один вопрос это размер кластера. В кластере каждая нода хранит весь набор данных. Поэтому чтение отлично масштабируется с увеличением размера кластера. С записью же ситуация обратная — при коммите каждая транзакция валидируется на отсутствие конфликтов на всех нодах. Естественно чем больше нод, тем больше времени будет занимать коммит.
Тут мы тоже имеем несколько вариантов:

• 2 ноды + арбитр. 2 ноды + арбитр. Хороший вариант для тестов. На время развертывания второй ноды на мастер не должна производиться запись.
• 3 ноды. Классический вариант. Баланс скорости и надежности. Обратите внимание, что в данной конфигурации одна нода должна вытягивать всю нагрузку, т.к. в момент добавления 3ей ноды вторая будет донором.
• 4+ ноды. При четном числе нод необходимо добавлять арбитра, чтобы избежать split-brain. Вариант, который хорошо подходит для очень большого количества чтения. Так же растет надежность кластера.

Мы пока остановились на варианте с 3 нодами.

Конфигурация кластера почти полность копирует конфигурацию standalone MySQL и отличается только некоторыми опциями:
«wsrep_sst_method = xtrabackup-v2» Эта опция задает способ копирования нод. Другие возможные варианты это mysqldump и rsync, но они блокируют ноду на время копирования. Не вижу причин использовать не «xtrabackup-v2» метод копирования.

«Gcache» это аналог кластерного бинлога. Представляет собой кольцевой буфер (в файле) фиксированного размера в который записываются все изменения. Если вы выключите одну из нод кластера, а потом включите обратно она попытается прочитать недостающие изменения из Gcache (IST синхронизация). Если в нем нет нужных ноде изменений, то потребуется полная перезаливка ноды (SST синхронизация). Размер gcache задается следующим образом: wsrep_provider_options=’gcache.size=20G;’.

wsrep_slave_threads В отличие от классической репликации в кластере возможно параллельно применять несколько «write сетов» к одной БД. Это опция указывает число воркеров применяющих изменения. Лучше не оставлять дефолтное значение 1, т.к. во время применения воркером большого write сета остальные будут ждать в очереди и репликация ноды начнет отставать. Некоторые советуют выставлять этот параметр равным 2 * CPU THREADS, но я думаю необходимо смотреть на количество выполняющихся у вас параллельных операций записи.
Мы остановились на значении 64. При меньшем значении кластер иногда не успевал применять все write сеты из очереди при всплесках нагрузки (например при запуске тяжелых кронов).

wsrep_max_ws_size Размер одной транзакции в кластере ограничен 2 Гб. Но большие транзакции плохо вписываются в концепцию PXC. Лучше выполнить 100 транзакций по 20 Мб, чем одну на 2 Гб. Поэтому мы сначала ограничили размер транзакции в кластере до 100 Мб, а потом снизили лимит до 50 Мб.
Если у вас включен strict mode, то можно установить переменной «binlog_row_image» значение «minimal». Это снизит размер записей в бинлоге в несколько раз (в 10 раз в тесте от Percona). Это сэкономит место на диске и позволит проводить транзакции, которые не влезали в лимит при «binlog_row_image = full».

Лимиты для SST. Для Xtrabackup, который используется для заливки нод можно задать лимит на использование сети, число потоков и способ компрессии. Это необходимо для того, что бы при заливке ноды сервер-донор не начал тормозить. Для этого в файл my.cnf добавляется секция «sst»:

[sst] rlimit = 80m compressor = "pigz -3" decompressor = "pigz -dc" backup_threads = 4 

Мы ограничиваем скорость копирования до 80 Мб/сек. Для сжатия используем pigz, это многопоточная версия gzip.

GTID Если вы используете классические слейвы, то рекомендую включить GTID на кластере. Это позволит подключать слейв к любой ноде кластера без перезаливки слейва.

Дополнительно хочу поговорить про 2 механизма кластер, их значение и конфигурирование.

Flow control

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

1. Запись в кластере будет происходить со скоростью самой медленной ноды. (Но это можно подкрутить.)
2. Если у вас происходит много конфликтов при коммите транзакций, то вы можете настроить Flow Control более агрессивно, что должно уменьшить их число.
3. Максимальное отставание ноды в кластере является константой, но не по времени, а по количеству транзакций в очереди. Время отставания зависит от среднего размера транзакции и количества «wsrep_slave_threads».

Посмотреть настройки Flow control можно так:
mysql> SHOW GLOBAL STATUS LIKE 'wsrep_flow_control_interval_%';
wsrep_flow_control_interval_low | 36
wsrep_flow_control_interval_high | 71

В первую очередь нас интересует параметр «wsrep_flow_control_interval_high». Он регулирует длину очереди, по достижении которого включается FC pause. Вычисляется этот параметр по формуле: gcs.fc_limit * √N (где N=число узлов в кластере.).
Второй параметр это «wsrep_flow_control_interval_low». Он отвечает за значение длинны очереди, по достижении которого выключается FC. Рассчитывается по формуле: wsrep_flow_control_interval_high * gcs.fc_factor. По умолчанию gcs.fc_factor=1.

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

Можно установить сессионную переменную «wsrep_sync_wait=7″. Это заставит PXC выполнять запросы на чтение или запись только после применения всех write-set’ов в текущей очереди. Естественно это увеличит latency запросов. Увеличение latency прямо пропорционально длине очереди.

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

EVS или Auto Evict

Данный механизм позволяет выкидывать ноды, с которыми неустойчивая связь (например потери пакетов или большие задержки) или которые медленно отвечают. Благодаря ему проблемы связи с одной нодой не положат весь кластер, а позволять отключить ноду и продолжить работу в нормальном режиме. Особенно полезен данный механизм может быть при работе кластера через WAN или неподконтрольные вам участки сети. По умолчанию EVS выключен.
Чтобы включить его необходимо добавить в параметр wsrep_provider_options опции «evs.version=1;» и «evs.auto_evict=5;» (число срабатываний, после которого нода отключается. Значение 0 выключает EVS.) Есть также несколько параметров, которые позволяют тонко настроить EVS:

• evs.delayed_margin Время, которое отводится ноде на ответ. По дефолту 1 сек., но при работе в локальной сети его можно снизить до 0.05-0.1 сек или ниже.
• evs.inactive_check_period Период проверок. По умолчанию 0.5 сек

Фактически время, которое нода может работать при проблемах до срабатывания EVS равно evs.inactive_check_period * evs.auto_evict. Также можно задать «evs.inactive_timeout» и нода не отвечавшая это время будет сразу выкинута, по умолчанию 15 сек.

Важный нюанс в том, что данный механизм сам не вернет ноду обратно при восстановлении связи. Ее необходимо перезапустить руками.
У себя мы настроили EVS, но испытать его в бою еще не довелось.

Балансировка нагрузки

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

• ProxySQL. Это L7 прокси для MySQL.
• Haproxy. Но Haproxy не умеет проверять статус ноды кластера и определять готова ли она к выполнению запросов. Для решения этой проблемы предлагается использовать дополнительный скрипт percona-clustercheck

Сначала мы хотели использовать ProxySQL, но после тестирования производительности выяснилось, что по latency он проигрывает Haproxy примерно 15-20% даже при использовании режима fast_forward (в этом режиме не работают реврайты запросов, роутинг и многие другие функции ProxySQL, запросы проксируются as-is).

Haproxy работает быстрее, но у скрипта от Percona есть несколько минусов.
Во-первых он написан на bash, что не способствует его кастомизируемости. Более серьезная проблема в том, что он не кэширует результат проверки MySQL. Таким образом если у нас есть 100 клиентов, каждый из которых проверяет состояние ноды раз в 1 секунду, то скрипт будет делать запрос к MySQL каждые 10 мс. Если по каким-то причинам MySQL начнет медленно работать, то скрипт проверки начнет создавать огромное количество процессов, что точно не улучшит ситуацию.
Было решено написать свое решение, в котором проверка состояния MySQL и ответ Haproxy не связаны друг с другом. Скрипт проверяет состояние ноды в бэкграунде через равные промежутки времени и кэширует результат. Веб сервер отдает Haproxy закешированный результат.

Мониторинг

Для мониторинга состояния кластера мы использовали Prometheus + mysqld_exporter и Grafana для визуализации данных. Т.к. mysqld_exporter собирает кучу метрик создавать дашборды самостоятельно довольно утомительно. Можно взять готовые дашборды от Percona и кастомизировать их под себя.
Для сбора основных метрик кластера и алертинга мы также используем Zabbix.

Основные метрики кластера, которые желательно мониторить:

• wsrep_cluster_status На всех нодах должна иметь значение «Primary». Если значение «non-Primary» значит эта нода потеряла связь с кворумом кластера.
• wsrep_cluster_size Число нод в кластере. Сюда также входят «потерянные» ноды, которые должны быть в кластере, но почему-то не доступны. При мягком выключении ноды значение этой переменной уменьшается.
• wsrep_local_state Показывает, является ли нода активным членом кластера и готова ли к работе.
• wsrep_evs_state Важный параметр, если у вас включен механизм Auto Eviction (по умолчанию выключен). Данная переменная показывает, что EVS считает эту ноду здоровой.
• wsrep_evs_evict_list Список нод, которые были выкинуты EVS из кластера. В нормальной ситуации список должен быть пустым.
• wsrep_evs_delayed Список кандидатов на удаление EVS’ом. Также должен быть пустым.

Основные метрики производительности:

• wsrep_evs_repl_latency Показывает (минимальную/среднюю/максимальную/ ст. отклонение/размер пакета) задержу коммуникаций внутри кластера. То есть измеряет задержку сети. Увеличение значений может говорить о перегрузке сети или нод кластера. Данная метрика записывается даже при выключенном EVS.
• wsrep_flow_control_paused_ns Время (в нс) с запуска ноды, которое она провела в Flow control pause. В идеале должно быть 0. Рост этого параметра говорит о проблемах с производительностью кластера или о недостатке «wsrep_slave_threads». Определить какая нода тормозит можно по параметру «wsrep_flow_control_sent«.
• wsrep_flow_control_paused Процент времени с последнего выполнения «FLUSH STATUS;», которая нода провела в Flow control pause. Также, как и предыдущая переменная должна стремится к нулю.
• wsrep_flow_control_status Показывает, работает ли в данный момент Flow Control. На инициировавшей FC pause ноде значение данной переменной будет ON.
• wsrep_local_recv_queue_avg Средняя длина очереди на прием. Рост этого параметра говорит о проблемах с производительностью ноды.
• wsrep_local_send_queue_avg Средняя длина очереди на отправку. Рост этого параметра говорит о проблемах с производительностью сети.

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

Резервное копирование

Резервное копирование кластера практически не отличается от standalone mysql. Для продакшн использования у нас есть несколько вариантов.

• Снимать бэкап с одной из нод «наживую» при помощи xtrabackup. Самый простой вариант, но во время бэкапа будет просаживаться производительность кластера.
• Использовать классические слейвы и снимать бэкап с реплики.

Бекапы со standalone и с кластерной версии созданные с помощью xtrabackup переносимы между собой. То есть снятый с кластера бэкап можно развернуть на standalone mysql и наоборот. Естественно мажорная версия MySQL должна совпадать, желательно и минорная. Бэкапы сделанные с помощью mysqldump естественно тоже переносимы.
Единственный нюанс в том, что после разворачивания бэкапа необходимо запустить скрипт mysql_upgrade который проверит и исправит структуру некоторых системных таблиц.

Миграция данных

Теперь, когда мы разобрались с конфигурированием, мониторингом и прочими вещами можно приступать к миграции на проде.
Миграция данных в нашей схеме выполнялась достаточно просто, но мы немного накосячили;).
Легенда — мастер 1 и мастер 2 связаны мастер-мастер репликацией. Запись идет только на мастер 1. Мастер 3 это чистый сервер.
Наш план миграции (в плане я опущу операции со слейвами для простоты и буду рассказывать только о мастер серверах).

Попытка 1

1. Снимаем бэкап БД с мастера 1 с помощью xtrabackup.
2. Копируем бэкап на мастер 3 и запускаем кластер в режиме single-node.
3. Настраиваем мастер-мастер репликацию между мастерами 3 и 1.
4. Переключаем чтение и запись на мастер 3. Проверяем работу приложения.
5. На мастере 2 выключаем репликацию и запускаем кластерный MySQL. Ждем пока он скопирует БД с мастера 3. Во время копирования у нас был кластер из одной ноды в статусе «Donor» и одной еще не работающей ноды. Во время копирования мы получили кучу блокировок и в конце концов обе ноды упали с ошибкой (создание новой ноды невозможно завершить из-за dead локов). Этот маленький эксперимент стоил нам четырех минут даунтайма.
6. Переключаем чтение и запись обратно на мастер 1.

Миграция не получилась из-за того, что при тестировании схемы в dev среде на БД практически не было трафика на запись, а при повторении этой же схемы под нагрузкой вылезли проблемы.
Мы немного поменяли схему миграции, что бы избежать этих проблем и повторили попытку, на 2ой раз удачно;).

Попытка 2

1. Перезапускаем мастер 3, что бы он работал опять в режиме single-node.
2. Заново поднимаем на мастере 2 кластерный MySQL. В данный момент на кластер шел трафик только от репликации, поэтому повторения проблем с локами не было и вторая нода успешно добавилась в кластер.
3. Опять переключаем чтение и запись на мастер 3. Проверяем работу приложения.
4. Отключаем мастер-мастер репликацию с мастером 1. Включаем на мастере 1 кластерный mysql и ждем пока он запустится. Чтобы не наступить на теже грабли важно, чтобы на Donor ноду не писало приложение (подробности в разделе про балансировку нагрузки). После запуска третьей ноды у нас будет полностью работоспособный кластер из трех нод.
5. Можно снять с одной из нод кластера бэкап и создать нужное вам количество классических слейвов.

Отличие второй схемы от первой в том, что мы переключили трафик на кластер только после поднятия в кластере второй ноды.
У нас данная процедура заняла примерно 6 часов.

Multi-master

После миграции наш кластер работал в режиме single-master, то есть вся запись шла на один из серверов, а с остальных только читались данные.
После переключения продакшена в режим мульти мастер мы столкнулись с проблемой — конфликты транзакций возникали заметно чаще, чем мы предполагали. Особенно плохо было с запросами, которые изменяют много записей, например обновляют значение всех записей в таблице. Те транзакции, которые успешно выполнялись на одной ноде последовательно на кластере выполняются параллельно и более долгая транзакция получает ошибку deadlock. Не буду тянуть, после нескольких попыток исправить это на уровне приложения мы отказались от идеи с multi-master.

Другие нюансы

• Кластер может быть слейвом. При использовании этой функции рекомендую добавить в конфиг всех нод, кроме той, которая является слейвом опцию «skip_slave_start = 1». Иначе каждая новая нода будет запускать репликацию с мастера, что вызовет либо ошибки репликации, либо порчу данных на реплике.
• Как я уже говорил Donor нода не может нормально обслуживать клиентов. Необходимо помнить, что в кластере из трех нод возможны ситуации, когда одна нода вылетела, вторая является донором и остается только одна нода для обслуживания клиентов.

Выводы

После миграции и некоторого времени эксплуатации мы пришли к следующим выводам.

• Galera кластер работает и достаточно стабилен (по крайней мере пока нештатных падений нод или их нештатного поведения не было). В части отказоустойчивости мы получили именно то, что хотели.
• Заявления Percona про multi-master являются в основном маркетингом. Да, кластер возможно использовать в таком режиме, но это потребует глубокой переделки приложения под данную модель использования.
• Синхронной репликации нет, но теперь мы контролируем максимальное отставание нод (в транзакциях). Вместе с ограничением максимального размера транзакции в 50 Мб мы можем достаточно точно предсказать максимальное время отставания нод. Разработчикам стало легче писать код.
• В мониторинге мы наблюдаем кратковременные пики роста очереди репликации. Причина в нашей 1 Gbit/s сети. Эксплуатировать кластер на такой сети возможно, но при всплесках нагрузки проявляются проблемы. Сейчас планируем апгрейд сети до 10 Gbit/s.

Итого из трех «хотелок» мы получили примерно полторы. Самое главное требование — отказоустойчивость выполнено.

Наш конфигурационный файл PXC для интересующихся:

Источники и полезные ссылки

Наш Docker image
Percona XtraDB Cluster 5.7 Documentation
Monitoring Cluster Status — Galera Cluster Documentation
Galera Status Variables — Galera Cluster Documentation