Fernly — операционная система для моих часов

Начинается новый виток гонки операционных систем. Возможно GNU Linux, Android OS, отходят в прошлое, как мамонты, уступая место новым млекопитающим грызунам.

image

Так сколько же микропроцессоров в mtk6260

Ответ на этот вопрос вы можете найти по ссылкам ниже. В комментариях прошу привести ссылку на точный документ от компании Медиатек где этот вопрос проясняется.

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

Nuttx это уже грызун. И видимо таким грызунам и принадлежит будущее.

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

Smart watch with an MT6260

По ссылке находиться форум близкий к одному очень известного в узких кругах специалисту Bunnie. Он со своей подругой и самостоятельно зажигал на всяких краудсоурс платфомах с новыми инициативами которым могли позавидовать да же Adafruit.

Этот человек получил образование в Америке в MIT, хотя является китайцем. И вся его команда практически китайцы:

image

Bunnie принял участие в нескольких пректах по сбору средств:

www.crowdsupply.com/chibitronics/circuit-stickers

www.crowdsupply.com/sutajio-kosagi/novena

Один из самых любопытных из этих проектов The Essential Guide to Electronics in Shenzhen.

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

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

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

Вот в этом собственно и суть новой Революции, которая была объявлена в Декабре 2014 года. Но так и не произошла до прошлой недели. Полтора года усилий китайцев и американцев не помогли.

Но неделю назад, одна добрая душа решила подкормить тараканов а заодно и мышей и выложила старую документацию Медиатека на старые чипы, которые уже не используются. Вот теперь мы можем точно ответить на вопрос — сколько же ядер и IP блоков скопировано Мидиатеком (без лицензии) находиться внутри SoC mtk6260. Надеюсь что в комментариях, кто нибудь укажет и название документа и количество IP блоков.

ссылка на оригинал статьи https://geektimes.ru/post/275142/

BlackBox Challenge: Что внутри черного ящика?

Всем привет!

Сегодня речь пойдет о состязании, в области машинного обучения, BlackBox Challenge, а также о самом черном ящике, механизмах его работы, изменения состояний, начисления вознаграждений и конечно о том, что же там внутри.
Чуть ниже я опубликую решение, входящее, на момент публикации, в 5-ку лучших.
Уверен оно поможет другим участникам улучшить свои результаты, а возможно и отыскать новый подход.


Что же такое Black Box Challenge?

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

Что мы имеем?

Итак, нам даны тестовый и обучающий уровень, состоящих из 1,214,494 и 1,258,935 шагов соответственно. Как говорилось выше, на каждом шаге, агент может узнать вектор состояний, содержащий 36 элементов и выбрать одно из 4-х действий.
Если решение готово, участник загружает его на сервер организаторов, где результат проверяется на тестовой и валидационной выборке, на основе результата на последней и строится лидерборд.
Время тестирования на серверах ограниченно 1200 секундами, чего более чем достаточно даже для сложных моделей, при использовании cython.
Использование фреймворков, любого open-source кода не ограничивается, предустановлены sklearn, xgboost, pybrain, theano etc.
Победитель определится в начале июня, по результатам финального тестирования.
Размерность вектора состояний, действий и сами правила игры, при финальном тестировании, меняться не будут, что неоднократно подчеркивали кураторы челеджа.

Базовый агент. Почему линейная регрессия не спасет мир?

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

Как успехи у других участников?

Из 1200 участников превзойти результат базового агента удалось лишь 65.
Обычные подходы оказались не очень-то успешны, люди, привыкшие получать результат, нажимая на кнопки в нейропрограммах/фреймворках, по сути обучая один черный ящик, для «победы» над другим, не достигли заметных результатов.
Попытки применения Q/Deep Q Learning также оказались безуспешны.
Сложные рекуррентные архитектуры из-за раннего переобучения демонстрировали далеко не лучшие результаты.
Большая часть участников, которые немного превзошли базовый рекорд, сделали это лишь благодаря небольшим изменениям коэффициентов примера с линейной регрессией.

Какова структура уровня?

Все уровни в целом однотипны и по всей видимости состоят из некоторых подуровней.
Каждые ~140к итераций происходит обнуление 36-й переменной вне зависимости от действий агента, в тестовой и обучающей выборке таких подуровней 10.

Как изменяется состояние среды в зависимости от действий агента?

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

Первые 35 переменных всегда идут в одной и той же последовательности, согласно предопределенным данным уровня, и не зависят от действий агента.
36-я переменная представляет большой интерес и возможно приблизит нас к ответу на вопрос о том, что же внутри черного ящика.
Её состояние изменяется в промежутке [-1.1;1.1], в зависимости от действий.
3-е действие оставляет переменную без изменений.
2-е действие уменьшает значение на 0.1
1-е действие увеличивает значение на 0.1
0-е действие изменяет переменную на «случайную» величину в ту или иную сторону.
Чуть ниже мы рассмотрим влияние 36-ой переменной на вознаграждение.

Как изменяется вознаграждение?

Чем больше значение 36-ой переменной по модулю, тем больше вознаграждение/штраф за действие.
Стоит отметить, что в игровой среде предусмотрен штраф за бездействие, который начинает начисляться при многократном выполнении 3-го действия >~100 раз подряд.
Вознаграждение не зависит от номера текущего хода и напрямую не зависит от количества набранных очков, также, вероятно, существует комиссия за действие.
Награда начисляется не сразу, а с некоторой задержкой, иногда, после десятков выполненных действий, чаще всего однотипных.
Ниже приведен график счета, при выполнении, на всех итерациях, действий 1 и 2 соответственно:

Что же внутри черного ящика?

Компенсируем комиссию и инвертируем второй график:

Попробуем еще раз, с первыми 50к итераций тестовой выборки:

Трудно сделать однозначные выводы, однако весьма заметно, что полученные графики напоминают изменение котировок некого торгового инструмента.
В таком случае 36-ая переменная означает общую позицию, баланс между открытыми сделками buy/sell, действие 3 равнозначно бездействию, а первое и второе действие это лонг и шорт соответственно.
Остается действие 0, можно предположить, что это открытие сделки в случайном направлении, однако, как показывает опыт, оно благоприятно сказывается на наборе очков.
Вероятно положительный эффект достигается за счет более быстрого сбрасывания/наращивания агентом позиции, при выполнении нулевого действия или же оно просто пересчитывает позицию согласно некому техническому индикатору.
В любом случае, роль 0-го действия пока не ясна.
Также стоит заметить, что кураторы соревнования не раз подчеркивали однородность уровней, гарантируя, что игра, которая скачивается в качестве примера — это та же игра, которая идёт в зачет, пусть с другими данными.
С реальными рыночными данными никаких гарантий быть не может, а следовательно существует несколько вариантов. Возможно это эмулятор, построенный на основе модели рынка с определенными законами или же используются коррелирующие валютные пары, акции из одной индустрии.
Однако все это лишь предположения, уверен, по окончанию соревнования, организаторы приоткроют тайну черного ящика 🙂

Готовое решение

Исходя из таблицы лидеров, многим участникам так и не удалось превзойти возможности линейного робота. Приведенная ниже модель, написана на cython/c и представляет собой быструю и простую реализацию многослойного персептрона с сигмоидальной функцией активации.
Исходный код обучения не привожу, однако замечу, что имел место довольно сложный алгоритм, включающий мутацию, обратное распространение и прюнинг потенциально некорректных изменений весов, все это для уменьшения эффекта переобучения, который, как заметили многие, в данной задаче крайне выражен.
Обратите внимание, в директорию levels необходимо поместить test_level.data и train_level.data из оригинального архива.
Кстати, линейная регрессия легко обобщается до однослойной нейросети, так что вы можете использовать уже имеющиеся коэффициенты (к примеру из базового агента).
Время итерации на обучающей выборке, на VM с Xeon E5-2673 в Microsoft Azure, около двух секунд.
Если желаете протестировать или разобраться в работе сети — добро пожаловать на GitHub:
CyMLP (исходный код сети), BlackBox Solver (код самого решения).

Заключение

В Black Box Challenge от участников требуется наблюдательность, находчивость и оригинальность.
Здесь нет готового решения или «модного чудо-фреймворка», который сделает вас лидером.
Однако, при достаточном упорстве и изобретательности, результат не заставит себя ждать.
На текущий момент ни один из участников не превзошел базовый агент на требуемые 1000 очков.
Надеюсь эта публикация поможет вам улучшить свои результаты, а возможно и отыскать новый подход.

Благодарности и ссылки

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

Благодарю Игоря Водопьянова за график корреляций, Константина Софиюка (cosionix) за графики счета, а также всех участников канала Telegram и форума за идеи.

ссылка на оригинал статьи https://habrahabr.ru/post/282802/

Как мы пока ещё не сделали трафарет для UX-проектирования

Захотели сделать трафарет для упрощения бумажного проектирования интерфейсов. По образцу тех, что можно найти на UIStencils.com, но с местной спецификой.

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

Требования осознали вот такие.

  1. Металлический. А то пластиковый выглядит скучной дешёвкой.
  2. Только со сложными силуэтами. Квадратики-кружочки-стрелочки лучше всё-таки от руки рисовать.

Как видите, немного.

Что ставить, какие силуэты?
Обсудили и составили гигантский список.

  1. Социальные сети: ВКонтакте, Facebook, Instagram, LinkedIn, «Одноклассники», Twitter, Pinterest, Google+.VK
  2. Мессенджеры: WhatsApp, Skype, Телеграм, Viber, Slack, «Сообщения» на iOS, LiveTex.
  3. Операционки: Apple (да, мы знаем, что это фирма), Windows, Android, Ubuntu.
  4. Браузеры: Chrome, Safari, MS Edge, Firefox, Яндекс.Браузер, Opera.
  5. Жесты смартфона: тап, свайп, зум, скролл, курсор рука, курсор стрелка.
  6. Сервисы (инфраструктура): Dropbox, 1C, Google Drive, Яндекс.Диск, Яндекс.Маркет.
  7. Монстры отрасли: Google, Яндекс, Mail.ru, Wikipedia, Pornhub.
  8. Символы-полезняшки: загрузка, WiFi, Bluetooth, батарейка, облачко, календарь, комментарий, кошелёк, банковская карта, фотоаппарат, звёздочка, сердечко, Fb-лайк, круговая диаграмма, ключ, QR-код.
  9. Крупное: линейка пиксельная, линейка обычная, контуры iPhone, контур России, символ Петербурга, символ Москвы.

Из итогового варианта многое повычёркивали — не влезло или расхотелось.

Один из первых вариантов — ещё до выравнивания и подготовки под лазерную резку — выглядел вот так.

На производстве ждали сюрпризы.

  1. Принимают только файлы в формате CorelDraw.
  2. Долго (около недели) возятся с созданием пробной версии.
  3. И только после пробника готовы называть цену.

Пробник получился таким.

Производство посчитало и цену: 800 руб./штука.
Дорого, но пока не об этом речь.

Мы взяли пробник в руки и начали тестировать.
Вот одна из бумажек с выведенными по трафарету силуэтами.

На ней видны основные проблемы трафарета.

  1. Ручка уменьшает контур. Чтобы результат был как надо, нужно раздвигать границы фигур на трафарете. Причём под фиксированную толщину стержня. А если хочется не так сильно зависеть от стержня, то придётся упрощать прорисовываемые объекты.
  2. Некоторые контуры слишком сложные, ручка скачет. Заштриховать можно, а вот обвести никак не получается. Выбрасываем.
  3. Кое-что (календарь, жесты), возможно, стоит заметно увеличить. В маленьком варианте они не особо нужны.
  4. Очень трудно делать мелкие скругления. Если не увеличить, то выбрасываем.
  5. Может быть, сделать трафарет вовсе не под ручку-карандаш? Существуют, например, трафаретные кисти — вдруг они тут поуместней будут?

Проблемы, которые не видны.

  1. Верно ли мы подобрали набор контуров на трафарете? Что убрать, что добавить?
  2. Нужна ли людям такая штуковина?

Про востребованность — рынок решит. Может быть, через Boomstarter. Посмотрим.

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

ссылка на оригинал статьи https://megamozg.ru/post/25960/

Русский перевод выступления Алекса Ионеску «Сумасшедшая попытка переписать Windows с нуля»

image 12 ноября 2013 года мы опубликовали видео выступления Алекса Ионеску (который известен российской аудитории, в первую очередь, как соавтор книг серии Windows Internals), посвященное операционной системе ReactOS. К сожалению, тогда в нашем распоряжении не было качественных субтитров на английском, а тем более перевода на русский язык. Но теперь, благодаря помощи волонтеров, эти упущения были исправлены. Юзер Black_Fox на сервисе translatedby.com создал правильные английские субтитры на основе автоматических субтитров youtube, а сообщество переводчиков ресурса Notabenoid перевело их на русский язык.

Переводчики: gste, leha_bot, Goudron, elnardu, x4fab, music_maniak, rumorukato, AHgpyxA, steven_quartz, jeditobe, Ctulhu31, RooGLM, peterder72, mariocca

Скачать через торрент magnet:?xt=urn:btih:15E110B8DA04E6907FC4AE07C90C180FCE3E590C&dn=ReactOS%20Alex%20Ionescu&tr=udp%3a%2f%2ftracker.openbittorrent.com%3a80%2fannounce&tr=udp%3a%2f%2ftracker.opentrackr.org%3a1337%2fannounce



В этой беседе Алекс Ионеску, ведущий разработчик ядра для проекта ReactOS с 2004 года (и недавно вернувшийся после долгого перерыва) расскажет про текущее состояние проекта, который уже прошёл 60000 ревизий в репозитории SVN. Алекс также охватит некоторые цели проекта и методологию разработки и тестирования, являющейся в таком проекте широкомасштабным мероприятием (open-source проект по имплементации всей ОС Windows с нуля!), в содействии с другими open-source проектами (MinGW, Wine, Haku и т.д.).

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

Алекс также покажет, как новые сборки ReactOS могут быть собраны прямо из Visual Studio, и как можно заниматься отладкой ядра стандартным отладчиком Microsoft WinDBG, проходя по коду практически-ядра-Windows для отладки проблем с реальными драйверами или приложениями. Если позволит время, Алекс коснётся вопросу реверс-инжиниринга функций Windows или драйверов для целей понимания их логики работы, что может помочь с отладкой проблем вне поля использования ReactOS.

ссылка на оригинал статьи https://habrahabr.ru/post/282800/

Работа с MySQL: как масштабировать хранилище данных в 20 раз за три недели

Ранее в блоге на Хабре мы рассказывали о развитии нашего продукта — биллинга для операторов связи «Гидра», а также рассматривали вопросы работы с инфраструктурой и использования новых технологий. К примеру, мы рассмотрели плюсы Clojure, ситуации, когда стоит и не стоит использовать MongoDB и ограничения в PostgreSQL.

Сегодня речь пойдет о масштабировании. Разработчики open-source почтового приложения Nylas опубликовали в своем блоге материал о том, как им удалось масштабировать систему в 20 раз за три недели с помощью инструмента ProxySQL. Для этого им пришлось переехать с Amazon RDS на MySQL на EC2. Мы представляем вашему вниманию основные моменты этой интересной заметки.

Одним прекрасным днем…

История началась летом 2015. Солнце пробивалось сквозь туман, зависший над Сан-Франциско, по радио играл хит Bad Blood Тейлор Свифт и Кендрика Ламара. В распоряжении Nylas были лишь две машины синхронизации и одна база MySQL, управляемая через Amazon RDS. Это было самое простое решение, которое компании удалось на тот момент найти.

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

А затем появились пользователи

Все изменилось 5 октября 2015. В этот день вышел Nylas N1 – открытое email-приложение с красивым пользовательским интерфейсом и современной архитектурой с использованием плагинов. Ссылка на продукт была опубликована в Hacker News. По заверениям команды Nylas, это привело к появлению десятков тысяч новых пользователей за считанные минуты. А вместе с пользователями пришли большие объемы новой информации.

За час база на MySQL перестала справляться с такими объемами, а задержка работы API побила все рекорды. Пришлось временно отключить возможность регистрации. В компании еще не осознали всю глубину проблм, но одна вещь была очевидна всем: нужно масштабироваться как можно скорее.

На баррикады

В течение нескольких дней после запуска Nylas N1 удалось обнаружить сразу несколько узких мест в коде. Пришлось столкнуться с ограничениями Redis и MySQL на объемы вкладок. Инженеры узнали много нового и о работе с AWS.

Но самой серьезной проблемой была база данных. День и ночь команда Nylas пыталась исправить ошибки вроде утечки MySQL-соединений, а также плохо оптимизированные запросы, негативно влиявшие на производительность. Помимо того, чтобы залатать дыры, нужно было подумать о перспективе. Единственный вариант – применить горизонтальное масштабирование данных, чтобы обеспечить качественную поддержку новых пользователей. То есть все-таки пришло время шардинга системы.

Почему MySQL

В 2013, когда компания Nylas была основана, ее инженеры выбрали MySQL, не только исходя из специфических характеристик, но и потому что этот инструмент зарекомендовал себя в работе высоконагруженных проектов. Технологии Cassandra, MongoDB, и Postgres выглядели впечатляющими и быстро прогрессировали, но инженеры были уверены, что с помощью MySQL смогут создать систему обрабатывающую петабайты данных. Об этом говорил и опыт таких компаний как Facebook, Dropbox, Pinterest, и Uber. Использование MySQL позволяло опираться на опыт этих технологических гигантов.

Эта база проста в работе, а требования Nylas изначально были не особенно масштабными. Исходя из этого, было решено использовать хостинг Amazon RDS. RDS не дает root-доступа к хосту MySQL, зато многие процессы автоматизированы. Например, бэкапы и точечные обновления.

Время масштабировать

К моменту возникновения сложностей с производительностью инженеры уже сжали длинные текстовые колонки в базе, что помогло сэкономить 40% места на диске, а также перешли на использование 6-терабайтных дисков. Но InnoDB в СУБД MySQL имеет ограничение 2 ТБ на таблицу, что представляло собой проблему.

Инженеры рассматривали вариант с использованием Amazon Aurora — MySQL-совместимого хранилища с автомасштабированием до 64 Тб. Однако даже в этом случае, при превышении заданного лимита в 64 терабайта, чтобы уместиться в ограничения InnoDB, пришлось бы разбивать данные по различным таблицам. К тому же команде не хотелось настолько сильно зависеть от технологий Amazon в долгосрочной перспективе.

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

Прощай, RDS

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

Кроме того, в RDS крайне ограничены возможности настройки репликации. Да, в ней есть опция multi-AZ для синхронного копирования данных, но производительность таких операций оставляла желать лучшего. Однажды ее использование привело к 3-часовому простою в работе приложения Nylas. Пришлось связаться с инженерами Amazon и ждать, пока они исследуют проблему.

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

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

Запуск MySQL на EC2

Перевод MySQL на EC2 – не совсем простой процесс. Нужно было написать собственные скрипты для управления задачами, которые в RDS были автоматизированы — например провижининг новых серверов, создание и распределение slave-инстансов в случае сбоя master-базы и создание и восстановление резервных копий. В Nylas написали такие скрипты с нуля, но существует и ряд открытых инструментов, решающих те же задачи.

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

Аварийное переключение

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

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

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

Шардинг приложения

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

Инженеры Nylas подобрали простое решение этой задачи: значение первичного ключа таблицы — это 64-битное целое число, верхние же биты содержат ID шарда, нижние биты являются локальным счетчиком автоматических числовых ключей.

|<--16bits-->|<--------48bits------->| +------------+-----------------------+ |  shard id  |     autoincrement     | +------------+-----------------------+

Это позволяет легко рассчитывать шард-ID по первичному ключу. Запрос на любой объект может быть направлен в правильный шард просто через первичный ключ. Чем проще система – тем надежнее работа с ней в перспективе.

Например, уровень аутентификации приложения способен конвертировать хэшированные токены доступа в ID аккаунта для доступа к API. Команде проекта удалось провести шардинг сервиса без изменения ключевых его компонентов. Поскольку движок Nylas так же как и приложение — открытый продукт, любой желающий может изучить особенности реализации такой системы на GitHub.

Создание новых шардов

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

При создании нового шарда рассчитать биты высокого порядка просто через:

N = (shard_id<<48) + 1

Значение автоматических чистовых ключей рассчитывается так:

ALTER TABLE mailsync_<shard_id>.<tablename> AUTO_INCREMENT=N 

Новые ряды в таблице, соответственно, будут иметь первичные ключи N, N+1 и так далее. В данном случае таблицы базы имеют автоматические ключ, начинающиеся со значения 1. Инженеры Nylas советуют при использовании этого метода обращать внимание на ошибку MySQL под номером #199. Этому багу уже 13 лет, но он до сих пор не исправлен. Чтобы избежать проблем с ним, код приложения должен быть защищен от некорректных значений автоматических ключей — вот здесь представлено описание решения этой задачи (на английском).

Минимизация времени ожидания при отказе

После проведения шардинга, была обнаружена еще одна проблема. Конфигурация mysqlfailover использовала вторичный IP-адрес Amazon VPC в качестве виртуального IP, чтобы отправлять трафик приложения к узлу мастера. Но обнаружение сбоя в узле и переключение трафика через этот виртуальный айпи занимало порядка 10 минут. Все запросы в течение этого промежутка, разумеется, отклонялись.

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

Здесь можно использовать HAProxy в сочетании с хранилищем значений ключей, а можно использовать кластерные инструменты MySQL: Orchestrator или Galera. В данном случае компания выбирала самое простое решение из доступных. В идеале – чтобы не было дополнительных сервисов, которые надо обслуживать.

ProxySQL

Такое решение было найдено в ProxySQL – новом инструменте с открытой лицензией. Если не вдаваться в подробности, его можно рассматривать как HAProxy, только заточенный под запросы SQL. После того, как Nylas перешла на работу с ProxySQL, время ожидания при переключении узлов снизилось с 10 минут до 10 секунд.

image

Переключение без ProxySQL (простой 10 минут)

image

Переключение с ProxySQL (простой 10 секунд)

В процессе обнаружились другие преимущества работы с ProxySQL:

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

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

Перевод данных на другую платформу

В марте 2016 года компания осуществила миграцию шард 0 (RDS) на “in-house” MySQL на EC2 посредством функции репликации. Это позволило обновить первичные ключи для самой крупной таблицы с 32 до 64 бит, чего нельзя было представить с RDS. Первичное пространство ключей (4 млрд рядов) было выбрано полностью за пару месяцев.

Планы

Облачная инфраструктура Nylas продолжает динамично развиваться. После обновления уровня базы данных пришло время обновления уровня самого приложения. Текущий проект включает разделение логики синхронизации по нескольким микросервисам и обновление топологии процессов с магистральным источником данных, типа Kafka. Есть также вариант реализовать денормализацию схем для уровня хранилища API, чтобы сделать дальнейшую работу с приложением более гибкой.

Другие технические статьи от «Латеры»:

ссылка на оригинал статьи https://habrahabr.ru/post/282798/