Двадцать шестого февраля прошла конференция MariaDB M|18, в которой участвовали 330 ИТ-компаний. На конференции выступил представитель ServiceNow. Он поделился кейсом по управлению «85 тысячами БД по всему миру». Среднее количество запросов в час — 25 миллиардов. Как в ServiceNow работают с такими нагрузками, расскажем под катом.
/ Flickr / Tethys. / CC
Представитель ServiceNow Тим Йим (Tim Yim) рассказал об использовании MariaDB. По словам Йима, компания выбрала MariaDB, потому что эта БД отличается стабильностью и высокой доступностью. В ServiceNow нацелены на обеспечение доступности систем 99,999%, поскольку этот показатель критически важен для таких клиентов, как больницы, фабрики, банки и электростанции.
Выгоду от использования MariaDB уже оценили в сингапурском банке DBS Bank, отказавшись от DB2 и Oracle Enterprise. За два года банк развернул более 700 экземпляров БД MariaDB, на которых работают 54% бизнес-критических сервисов, ежедневно проводящих транзакции на 70–80 млрд долларов. Компания в семь раз увеличила производительность приложений, а инструменты для их тестирования смогли выдерживать в десять раз большую нагрузку. При этом системы автоматизированного выпуска приложений стали в два раза эффективнее.
В компании говорят, что не используют multi-tenant- и single-tenant-архитектуру. Вместо этого, ServiceNow придумали свой вариант – multi-instance. Модель развертывания multi-instance позволяет каждому клиенту получить собственную базу данных и клиентское приложение.
Йим поясняет: «Обычно компании развертывают multi-tenant-архитектуру, когда все клиенты делят одну большую базу данных. Представим, что клиентов тысяча. Тогда сбой в работе одного из них повлияет на 999 других: в итоге вместо единичного простоя получается тысяча».
В случае multi-instance каждый экземпляр БД клиента работает на «bare metal» для лучшей производительности. При этом ресурсы аппаратного обеспечения делятся между уровнями приложений и БД, а процессы «контейнеризуются». Йим прокомментировал: «Мы дублируем каждую конфигурацию, каждый узел клиентских приложений и каждую базу данных. Каждую ночь мы создаем резервные копии всех БД».
Такой подход позволяет наращивать вычислительную мощность с «хирургической точностью». В отдельно взятый момент времени можно масштабировать инфраструктуру и устранять неполадки одного клиента.
/ Flickr / David Goehring / CC
Йим заявляет, что для эффективной работы такого решения «нужно автоматизировать всё». В ServiceNow так и сделали. Все активы загружаются в CMDB, чтобы их можно было отслеживать в одном месте, а затем происходит настройка и автоматизация рабочих процессов: систем высокой готовности, систем восстановления после отказа и др. В последних релизах платформы ServiceNow разработчики добавили возможность автоматизации на естественном языке, позволяющую «неспециалистам» автоматизировать нужные процессы в своем отделе.
Управление таким количеством БД приводит к возникновению ряда проблем. Тим Йим поясняет: «Динамичность ServiceNow позволяет нашим клиентам масштабировать сервисы, но из-за этого меняются шаблоны запросов. Поэтому такой платформой очень сложно управлять».
Решить все возникающие проблемы ServiceNow помогают сотрудники MariaDB: они проводят тренинги для администраторов БД, системных администраторов и специалистов по обеспечению надежности инфраструктуры (site reliability engineer), а также помогают ServiceNow разбираться в технических вопросах.
Компании планируют продолжить сотрудничество и внедрить такие фичи, как DDL для описания структуры БД и более надежное шифрование данных в облаке. Кроме того, представитель ServiceNow заявил, что не против внедрения систем на базе машинного обучения: «Я думаю, что любой администратор БД был бы заинтересован в работе с более «умной» базой данных, которая может помогать в распределении нагрузки». И разработчики MariaDB уже работают над внедрением инструментов для мониторинга, которые позволят повысить производительность и масштабируемость системы.
Еще несколько постов из корпоративного блога ИТ Гильдии:
/ Flickr / Tethys. / CC
Почему в ServiceNow используют MariaDB
Представитель ServiceNow Тим Йим (Tim Yim) рассказал об использовании MariaDB. По словам Йима, компания выбрала MariaDB, потому что эта БД отличается стабильностью и высокой доступностью. В ServiceNow нацелены на обеспечение доступности систем 99,999%, поскольку этот показатель критически важен для таких клиентов, как больницы, фабрики, банки и электростанции.
Выгоду от использования MariaDB уже оценили в сингапурском банке DBS Bank, отказавшись от DB2 и Oracle Enterprise. За два года банк развернул более 700 экземпляров БД MariaDB, на которых работают 54% бизнес-критических сервисов, ежедневно проводящих транзакции на 70–80 млрд долларов. Компания в семь раз увеличила производительность приложений, а инструменты для их тестирования смогли выдерживать в десять раз большую нагрузку. При этом системы автоматизированного выпуска приложений стали в два раза эффективнее.
Что такое multi-instance-архитектура
В компании говорят, что не используют multi-tenant- и single-tenant-архитектуру. Вместо этого, ServiceNow придумали свой вариант – multi-instance. Модель развертывания multi-instance позволяет каждому клиенту получить собственную базу данных и клиентское приложение.
Йим поясняет: «Обычно компании развертывают multi-tenant-архитектуру, когда все клиенты делят одну большую базу данных. Представим, что клиентов тысяча. Тогда сбой в работе одного из них повлияет на 999 других: в итоге вместо единичного простоя получается тысяча».
В случае multi-instance каждый экземпляр БД клиента работает на «bare metal» для лучшей производительности. При этом ресурсы аппаратного обеспечения делятся между уровнями приложений и БД, а процессы «контейнеризуются». Йим прокомментировал: «Мы дублируем каждую конфигурацию, каждый узел клиентских приложений и каждую базу данных. Каждую ночь мы создаем резервные копии всех БД».
Такой подход позволяет наращивать вычислительную мощность с «хирургической точностью». В отдельно взятый момент времени можно масштабировать инфраструктуру и устранять неполадки одного клиента.
/ Flickr / David Goehring / CC
Йим заявляет, что для эффективной работы такого решения «нужно автоматизировать всё». В ServiceNow так и сделали. Все активы загружаются в CMDB, чтобы их можно было отслеживать в одном месте, а затем происходит настройка и автоматизация рабочих процессов: систем высокой готовности, систем восстановления после отказа и др. В последних релизах платформы ServiceNow разработчики добавили возможность автоматизации на естественном языке, позволяющую «неспециалистам» автоматизировать нужные процессы в своем отделе.
«Скрытые» сложности и дальнейшие планы
Управление таким количеством БД приводит к возникновению ряда проблем. Тим Йим поясняет: «Динамичность ServiceNow позволяет нашим клиентам масштабировать сервисы, но из-за этого меняются шаблоны запросов. Поэтому такой платформой очень сложно управлять».
Решить все возникающие проблемы ServiceNow помогают сотрудники MariaDB: они проводят тренинги для администраторов БД, системных администраторов и специалистов по обеспечению надежности инфраструктуры (site reliability engineer), а также помогают ServiceNow разбираться в технических вопросах.
Компании планируют продолжить сотрудничество и внедрить такие фичи, как DDL для описания структуры БД и более надежное шифрование данных в облаке. Кроме того, представитель ServiceNow заявил, что не против внедрения систем на базе машинного обучения: «Я думаю, что любой администратор БД был бы заинтересован в работе с более «умной» базой данных, которая может помогать в распределении нагрузки». И разработчики MariaDB уже работают над внедрением инструментов для мониторинга, которые позволят повысить производительность и масштабируемость системы.
Еще несколько постов из корпоративного блога ИТ Гильдии:
Комментарии (15)
romy4
04.03.2018 21:12Очень интересен процесс апдейта схем БД. Пусть есть app1 работающая на scheme1 и app2, которая работает на scheme2 без обратной совместимости со scheme1 (пускай добавлена новая таблица, требуемая в app2). Как это вот всё на 85тысячах машин одновременно разворачивается и как паузится работа всей банковской системы?
JuriM
05.03.2018 00:47Надежность это конечно хорошо, но читая чейнджлог очередного обновления mariadb, становится както не по себе
shushu
05.03.2018 09:40+1Я не совсем понял, они делают инстанс базы данных для каждой организаци? Или всё таки просто база данных в одном большом инстансе?
Скорее всего у них есть мастер база данных где всекие глобальные настройки и т.д.
Если первое: Они держат отдельное соеденение для этой мастер БД? А что если надо заджоинить что то на мастер БД?
Ну и интересно было бы услышать как они роутинг делают (в первом варианте)
datacompboy
Ммм… Что-то я не понимаю…
Миллион запросов в секунду может один тазик давать.
25 миллиардов в час = 7 миллионов в секунду.
Они говорят про 85 тысяч баз по миру — это, простите, 82 запроса в секунду на базу.
Дикая нагрузка, ага.
mediaman
Ну получили мы среднее значение, как это применимо к конкретным кейсам? Иначе как в случае со средней зарплатой по стране получается
datacompboy
вот что-то я вообще кейсов не вижу. «у нас 25ккк запросов в час!» и «всё надо автоматизировать!».
учитывая что больше ничего не сказано, цифра в 25ккк явно просто искали чтоб такого по-больше скзаать. потому что иначе имело бы смысл пиковое число запросов в секунду показывать, чтоб нагрузку показать.
статья вообще ни о чем, и единственные цифры сами по себе — шлак.
mediaman
Ну помимо 25ккк в посте есть и другие цифры, например тот факт, что 700 инстансов MariaDB держат 54% buisness-critical сервисов банка, ворочая по $70 млрд ежедневно. А ваш комментарий определенно внес вклад в обсуждение вопроса: нашли среднее, сорвали покровы, указали всем как и что. Люблю такие треды
datacompboy
Да, только эти цифры никакого отношения к ServiceNow не имеют.
Это в разделе объяснения почему SN решили взять марию.
Проще говоря, вся статья умещается в:
— мы автоматизировали деплой в контейнерах.
всё. ничего более не сказано, цифры не имеют отношения к тексту и вообще непонятно за чем.
каким образом контейнеры и bare metal связаны тоже непонятно — обычно под bare metal понимают отсутствие слоя виртуализации каких бы то ни было сортов, но они явно говорят что железки делят. или они докер уже за виртуализацию не считают?
самое интересное — как они скалят инстанс за пределы машины — про это тоже не слова. не скалят? то есть таких задач не было?
antonn
Справедливости ради надо заметить, что суммы в долларах никак не относятся к характеристикам БД (ее отказоустойчивость и загруженность), они добавлены для напускной значимости.
А вот про это было бы интересно почитать, но технические детали не написали.
AmberSP
А я вот наброшу на вентилятор вопросом «сколько SQL запросов выполняется, когда инженер в интерфейсе кликает на номере инцидента и открывает его?».
Достоверно ответ не знаю.
datacompboy
по хорошему или на самом деле? :D
africaunite
25 млр в час, 85 тыс серверов, "Trusted by 3,300+ Industry Leaders (и 85К серверов?). We handle 8 billion transactions every month for 17 million licensed users." (баннер на сайте ServiceNow).
Можно было бы прикинуть, очень-очень приблизительно (с пролетом в три порядка), но страшновато.
Murimonai
По личным наблюдениям, типичный таймер в этом случае вроде такого: «Response time(ms): 4071, Network: 16, server: 2110, browser: 1945». Не в курсе, насколько кастомизация сервиса в каждом конкретном случае сильно влияет на server-часть, но тот факт, что она зачастую сопоставима с бразерными затратами — выглядит не плохо.
Думается, полезнее было бы узнать, за сколько запросов справляется сервис, когда скрипт через API этот инцидент, к примеру, резолвит.