Попробовать
демоверсию
Бесплатная демоверсия позволяет ознакомиться со всеми возможностями нашего биллинга
+7 499 940-95-05

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

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

История началась летом 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, чтобы сделать дальнейшую работу с приложением более гибкой. 

Подписывайтесь на наш блог, чтобы не пропустить ничего нового!

30.04.2016

Другие публикации

По определению консалтинговой компании Deloitte, текущий период в мировой экономике характеризуется неопределенностью. Поэтому бизнес во всем мире стремится к оптимизации и снижению издержек. Сегодня мы рассмотрим несколько способов, с помощью которых компании из разных стран экономят уже сейчас.
В новой версии Гидры мы по традиции продолжили работу над коммерческими возможностями биллинга. Встречайте контрактные тарифы! Другие мелкие улучшения упрощают интеграцию Гидры с внешними системами.
Компании из самых разных отраслей бизнеса сталкиваются с часто повторяющимися бизнес-процессами, связанными с обработкой заявок. В большинстве отраслей выполнение типовых работ и услуг — это сложный и разветвленный бизнес-процесс. Мы много размышляли об этих проблемах и создали инструмент, который каждая компания могла бы легко адаптировать под себя — новый продукт Гидра OMS
В одном из наших постов мы уже описывали ситуацию, в которой бесконтрольный рост таблиц в базе данных одной компании-пользователя нашей системы привел к настоящему DoS. Сегодня речь пойдет о еще одном интересном случае внезапного сбоя, который сделал «день смеха» 1 апреля этого года совсем не смешным для службы поддержки «Латеры».
В Instagram развертывание backend-кода (основная программно-аппаратная часть, с которой работают клиенты) происходит от 30 до 50 раз в день, каждый раз, когда инженеры подтверждают изменение оригинала. И, по большей части, без участия человека — сложно в это поверить, особенно учитывая масштабы соцсети, но факт остается фактом.
Интересный материал о работе с JSON, и в частности, о применении ограничений опубликовал в своем блоге разработчик Магнус Хагандер (Magnus Hagander) — в нашем блоге мы решили представить его основные идеи.
Успешно завершили интеграцию биллинга Гидра с порталом NEXT TV.
В этой заметке мы рассказываем о плюсах и минусах денормализации баз данных. Разработчик баз данных и финансовый аналитик Эмил Дркушич (Emil Drkušić) написал в блоге компании Vertabelo материал о том, зачем, как и когда использовать этот подход. Мы представляем вашему вниманию главные тезисы этой заметки и делимся своим опытом.
Разработчики из американской компании Gaslight написали интересный материал о том, почему организация, известная своей любовью к Ruby и Ruby on Rails, решила инвестировать в освоение новых технологий — например, Clojure. Мы тоже работаем с этим языком программирования, поэтому решили выделить главные тезисы команды Gaslight в отдельный материал.
Разработчик и сотрудник проекта CouldBoost.io Наваз Дандала (Nawaz Dhandala) написал материал о том, почему в некоторых случаях не стоит использовать MongoDB. Мы в «Латере» уже много лет работаем с этой СУБД, поэтому решили представить и свое мнение по данному вопросу.
Немецкий журналист и хакер Ляйф Риге (Leif Ryge) написал для издания Ars Technica интересный материал о том, что современный подход к организации обновлений программного обеспечениях несет в себе серьезные риски информационной безопасности. Мы представляем вашему вниманию главные мысли этой заметки.
Инженер проекта Haleby.se написал материал, в котором рассказал о причинах выбора в качестве инструмента оркестрации Docker-контейнеров технологии Kubernetes. Мы представляем основные мысли этой заметки.
Адаптация заметки бывшего сотрудника Amazon про то, почему плохие продукты пользуются большим успехом, опубликованная в авторской колонке Дмитрия Копловича на Rusbase.
Поучительная история из жизни нашей техподдержки про то почему операторам нужно мониторить размеры таблиц в своих базах.
Инженер компании Akalak & Neo Technology Горка Садаковски (Gorka Sadakowski) написал интересный материал о том, как использование графовых баз данных может в режиме реального времени предотвращать мошенничество в сфере электронной коммерции. Мы представляем вашему вниманию основные мысли этой заметки.
Платежные протоколы уязвимы — об этом рассказали немецкие исследователи информационной безопасности на конференции Chaos Computing Club. Предлагаем вам адаптированный перевод их выступления.
Наша адаптация заметки разработчика и системного архитектора Михаэля Виттига о наиболее распространенных ошибках в использовании Amazon Web Services.
Наш адаптированный перевод заметки главного разработчика Azure Джеффа Уилкокса, о том, как более двух тысяч членов команды проекта переезжали на GitHub.
Представляем вашему вниманию адаптированный перевод одной из глав книги «Архитектура open-source-приложений», в которой описываются предпосылки появления, архитектура и организация работы популярного веб-сервера nginx.
Наш сегодняшний пост посвящен тому как мы писали софт для контроля работы удаленных сотрудников.
Сегодня мы расскажем про устройство системы подпольного банкинга Хавала, которая возникла еще в VIII веке и до сих пор пользуется большой популярности в странах Среднего Востока, Азии и Африки.
Мы уже рассказывали о том какие проблемы могут возникнуть у компании при саомостоятельной разработке сложных систем. Сегодня мы поговорим о том, как мы работали над повышением отказоустойчивости «Гидры».
Адаптированный перевод заметки главного инженера LinkedIn Джоша Клемма о процессе масштабирования инфраструктуры социальной сети.
Адаптированный перевод заметки инженера финансового стартапа Stripe о том, как его команда мигрировала огромное количество записей в базе данных.
По нашим оценкам, около половины российских операторов связи используют самописный (или переписанный до неузнаваемости простенький «покупной») софт. Сегодня мы поговорим о возможных минусах такого подхода.
Появились маркетинговые инструменты для сегментации абонентской базы, управления скидками и пакетными предложениями.
Подробнее читайте в блоге.
В новой версии мы полностью переработали механизм работы с услугами. Это сразу дало несколько серьезных улучшений, но полностью все заложенные в новой версии возможности будут раскрыты в следующих версиях.
В новой версии была полностью переработана система прав доступа. Новая система уникальна и позволяет реализовать самые смелые замыслы по разграничению доступа сотрудников к биллингу.

Начните знакомство с Гидрой прямо сейчас

Попробовать демоверсию Купить Гидру

Оформление демоверсии

Пожалуйста, укажите реальный email, на него придут данные для доступа в демо.
Все поля являются обязательными для заполнения.
.hydra-billing.com

Для вас будет развернута персональная облачная версия Гидры.
Нажимая кнопку "создать демоверсию" вы соглашаетесь с
Политикой обработки персональных данных.

Мы можем вам перезвонить

Нажимая кнопку "отправить" вы соглашаетесь с
Политикой обработки персональных данных.

Напишите нам!

Ваша компания

Услуги, которые вы предоставляете:

Нажимая кнопку "отправить" вы соглашаетесь с
Политикой обработки персональных данных.

Скачать буклет

Ваш адрес:

Хотите узнать больше?

Рассылка делается примерно раз в месяц. Мы обещаем бережно хранить ваш электронный адрес и никому его не выдавать даже под пытками.