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

В данном случае речь о системе с СУБД DSE — удобной, отлично адаптированной к использованию под наши задачи, распределенной СУБД NoSQL-типа на базе Apache Cassandra с пудовыми рисками прекращения лицензирования со стороны Datastax.

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

В статье начальник группы внедрения и тестирования продуктов и услуг Nexign Анна Алешина рассказывает, почему мы выбрали Scylla и решили прокачать ее до собственной «фирменной» СУБД Nexylla. Однако это уже вторая миграция, про первую рассказывали здесь. Материал будет полезен всем, кто тоже задумывается о миграции на более надежные с точки зрения лицензирования СУБД.

Направо пойдешь…или какие альтернативы у нас были

Как варианты ближайших сходных решений у нас рассматривались опенсорсная Cassandra и Scylla — тоже, в общем-то Cassandra, но на C и с фитильком в виде шустрого алгоритма эффективной/интенсивной утилизации железных ресурсов.

Оценив вариант с ванильной версией Cassandra, мы его довольно быстро откинули. Из коробки, что у бесплатной Cassandra, что у Scylla одинаково нет необходимых нам энтерпрайзных опций (о критериях расскажу чуть ниже в таблице) типа аналога OpsCenter DSE для управления кластером или поддержки LDAP-авторизации, что, в свою очередь является функциями необходимыми для качественной эксплуатационной поддержки и маст хэв для соблюдения требования ИБ. Однако в пользу Scylla сыграло заявленное преимущество в виде улучшенных алгоритмов, потенциально позволяющих нам сократить ТСО.

Проверка гипотез: сравнительное нагрузочное тестирование на кластерах DSE и Scylla

Далее, определившись с кандидатом, мы перешли к фазе реальной проверки мифов и легенд. Я сразу подчеркну, что если бы тестирование проводилось между Кассандрой и Scylla, отличия были бы еще более ярко выраженными. В DataStax в момент тестов за счет оптимизации использования CPU и пересмотра структуры хранения данных DSE, была разница примерно 10-20% по сравнению с OpenSource Cassandra в операциях обслуживания данных. Этот показатель сильно зависит от версии C. Datastax активно комитят в upstream и свежие версии по производительности могут не сильно отставать от DSE, а на момент тестов разница была примерно 10-20%.

Сравнительное тестирование проводили на следующей конфигурации кластера: шесть серверов в одной стойке, одна стойка и один дата-центр. Фактор репликации — 3.

Настройки DSE соответствуют промышленному кластеру, настройки Scylla — по умолчанию.

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

Основные сценарии:

• пул GET запросов (запросы потребленного трафика, история балансов);

• генерация звонкового трафика для вставки в БД.

Что в результате получилось:

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

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

Если сложить в кучку и вакуумировать то, что мы узнали, протестировали и подтвердили во время своих экспериментов, получается следующее:

1. У Scylla на чтение не существует уровня консистентности такого, как Each Quorum (он есть, но только на запись). Если очень важна согласованность чтения данных из разных ЦОДов — готовьтесь к тому, что придется сделать нелегкий выбор в пользу ALL_QUORUM, и настороженно следить за здравием каждой ноды в своем кластере. Может быть, когда-нибудь реализация Each Quorum будет сделана в продукте Nexign — Nexylla.

2. ScyllaDB обеспечивает совместимость протокола взаимодействия с Cassandra, однако для ScyllaDB есть ответвление Java-драйверов, оптимизированных для работы с кластером Scylla. Они обеспечивают минимальные задержки и максимальную общую пропускную способность при распределении запросов по кластеру. За счет этого клиентов подключают напрямую к конкретному CPU на конкретном узле, отвечающем за данные. При использовании DSE-драйвера запросы отправляются к случайно выбранным CPU на нодах отвечающих за данные. Далее запрос передается на нужный CPU, отвечающий за данные, и это создает дополнительную нагрузку и снижает производительность. Клиенты, подключающиеся к Scylla, конечно, тоже лучше подправить для использования этих драйверов.

3. Из-за особенностей Scylla не рекомендуется размещать на серверах с ней какие-либо другие сервисы, соответственно потребуется вынести любые сервисы типа агрегатора или шедулера на отдельные серверы.

4. Для Scylla официально рекомендовано использовать SSD-накопители. Использование HDD возможно, но производительность чтения за пределами кэша просадит это чтение до панического нуля.

5. Мониторинг, предлагаемый вендором в корпоративной сети, использовать не получится из-за необходимости доступа к github и docker hub.

6. В случае использования Scylla максимальный размер нод будет ограничен балансом между SLA и пропускной способностью сети/дисков/CPU.

Просчитываем на несколько шагов вперед

Кроме того, смена СУБД в том числе, в перспективе решает проблемы, которые неизбежно настигли бы нас в будущем в силу специфики use-cases функционала:

1. Большие партиции

Партиционирование у нас было построено по составному ключу – id абонента + дата активности. Причем дата – просто натуральное число, по сути календарный день. Но, как оказалось, некоторые клиенты могут проявлять повышенную активность (например, SMS подтверждения, нотификации или OTP), что в итоге дает большой перекос и перевес размера партиции в разы сверх рекомендованных значений.

Миграция на другую СУБД с сопутствующим пересмотром PARTITION KEY снимает эту проблему естественным образом.

2. Отсутствие собственного ЦК по технической поддержке СУБД

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

3. Раздутый ТСО

За время жизни системы на СУБД DSE наш парк машин существенно разросся, что учитывая распределенность на три ЦОДа + тестовые зоны очень сильно влияло на стоимость владения всем этим богатством. Scylla с ее оптимизацией очень сильно привлекала перспективами компактизации этот парка.

Что в итоге

И вот, плюсы, как в доброй сказке, перевесили минусы, и решение переезжать на Scylla было принято. И, кстати, основные проблемы из таблички выше, такие как отсутствие аудита и LDAP-авторизации и необходимость в удобном инструменте администрирования, мы решили, доработав решение из коробки и снабдив его нужными плюшками. Так получилась наша собственная СУБД — Nexylla, о ней подробнее расскажем в будущих материалах.

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