Хабрахабр

[Из песочницы] Couchbase в телекоме

Кроме обычной для крупных компаний проблематики централизации систем и объединения биллинговых систем и абонентских БД добавляются требования к высокой доступности и режиму работы в реальном времени к которому клиенты уже привыкли у лидеров индустрии (Google, Amazon, Netflix). Цифровая трансформация является мировым трендом для крупного бизнеса и жизненно важна для адаптации  предприятия к современным потребностям клиента.

Эти тенденции несут и большой минус: усложнение архитектуры и раздутые транзакционные базы данных, которые не справляются с потоком и обработкой информации. Новые вызовы требуют новых технологий и подходов, которые необходимы для сокращения времени внедрения удобных клиенту функций, персонализированных коммерческих предложений, быстрой реакции на предложения конкурентов, а так же контроля затрат на системы, ИТ инфраструктуру, датацентры  и квалифицированного персонала. К примеру, экземпляр СУБД Oracle работает на пределе самого мощного сервера на процессорах x86 при нагрузке в миллиард транзакций в сутки. Технологии предыдущего поколения имеют потолок вертикального масштабирования.

Так, Apple применяет Cassandra, Сбербанк – Ignite (GridGain), в МегаФон мы применяем Couchbase и Tarantool. Для того, чтобы выдержать подобную загрузке с которой уже давно сталкивается интернет индустрия используется новый стек технологий, таких как In-Memory кэши и NoSQL базы данных.

В МегаФон используются разные архитектурные шаблоны для In-Memory СУБД:

  1. Простой кэш, обновляемый по расписанию или по событию из БД и приложений
  2. Все изменения в БД осуществляются через кэш (write-through сценарий), например, подключение Oracle клиента к DCP Couchbase

Один из ярких кейсов использования жизненного цикла абонента – это блокировка и разблокировка по отрицательному балансу. Для одной из наших систем принятия решений по жизненному циклу абонента мы используем первый шаблон, так как только одно приложение по совокупности данных принимает решение и отправляет его на все системы, в том числе и БД Oracle. В основную базу попадет только запись об изменении статуса абонента (рис. Ведь все абоненты сотовых операторов после пополнения баланса хотят сразу быть на связи и совершать звонки.  Благодаря вынесенному отдельному приложению и Couchbase, мы смогли сократить время выхода из блокировки с 90 секунд до 30 и это еще не предел. 1)

Рисунок 1 (Пример взаимодействия)

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

Для этого существует несколько причин. Почему мы остановили выбор именно на Couchbase?

Требование к производительности

  1. Обработка до 200000 запросов в секунду.
  2. Среднее время отклика (50%) — до 5 мс (в рамках одного ЦОД).
  3. Максимальное время отклика (99%) — до 15 мс (в рамках одного ЦОД).
  4. Максимальная производительность вставки 500 MB/sec
  5. Максимальное количество операций вставок 100000/с
  6. Максимальное количество операций изменений (обновлений документов) 100000/с
  7. Максимальная производительность изменений (обновлений документов) 500 MB/sec
  8. Максимальное количество операций чтений 100000/с
  9. Максимальная скорость чтения 500 MB/sec

Высокопроизводительный поиск по ключу и доступ к данным

Хранилище KV представляет собой чрезвычайно простой подход к управлению данными, который хранит уникальный идентификатор (ключ) вместе с частью произвольной информации. В основе Couchbase лежит распределенное хранилище ключей (KV). Благодаря простоте реализации KV доступ к данным обеспечивается с минимальной задержкой. Само хранилище KV может принимать любые данные, будь то бинарный blob или JSON-документ. Как показывает наш опыт, чаще задержки по сети в 2-3 раза выше, чем предоставление данных по ключу на стороне Couchbase.

Динамическая схема хранения(JSON)

Формат поддерживает как базовые типы данных, такие как числа, строки, и сложные типы, так и встроенные словари и массивы. Документы хранятся на сервере Couchbase в формате JSON.

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

Высокая доступность

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

Рисунок 2 (Реплики сервера Couchbase)

Он обеспечивает высокоскоростную передачу изменений во все копии данных, вторичные индексы (GSI), межкластерную репликацию (XDCR) и внешним потребителям. Второй важной функцией для обеспечения высокой доступности является внутренний протокол DCP (Database Change Protocol).

Двунаправленная репликация

В идеальном варианте это резервирование в режиме Active-Active, когда переключение между проблемными узлами происходит автоматически. Правильной практикой в компаниях является использование резервирования всех бизнес-процессов и оборудования. Но тестирование репликации показало, что она эффективна только в близко стоящих ЦОД. Двунаправленная репликация в Couchbase позволяет обеспечить режим A-A. У Couchbase есть механизмы решения конфликтов: на основе Timestamp и Sequence Number. При разнесении более 100 км появляются конфликты. Мы отказались от использования двунаправленной репликации (cross-cluster consistency). Однако, из-за временной задержки на сети, в базу попадают устаревшие данные. Доступность данных в режиме «чтение» обеспечивается во всех ЦОДах (A-A). Все изменения проводятся только на одном кластере.

Горизонтальное масштабирование

3). Одной из важных характеристик большинства NoSQL БД является горизонтальное масштабирование (рис. Основным отличием

Рисунок 3 MDS

Требования ИБ

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

 Это позволяет сэкономить на оборудовании, например Cisco ASA. В энтерпрайз версии Couchbase поддерживает шифрование трафика, шифрование данных и персонализированный доступ.

Простота обновления

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

PS: Обновление/даунгрейд допускается только на соседних мажорных версиях

Дополнительная функциональность

Логическое распределение

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

Рисунок 4 Server Gropus

Резервное копирование и восстановление

Процесс бекапа может работать в трёх режимах: полном, дифференциальном и накопительном. Couchbase содержит в себе готовые инструменты для резервного копирования и восстановления. Это позволяет в некоторых случаях сэкономить место на дисках и процессорные ресурсы.

Couchbase vs Mongo

Попытаемся сформулировать почему мы отдали предпочтение Couchbase, а не другой очень популярной платформе – MongoDB. На вопрос выбора альтернативных NoSQL БД ответить сложно, и зачастую лучший Unix – тот, который знает твой админ.

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

Таблица 1 Сравнение

 

Couchbase

MongoDB

Масштабирование

Автоматическое для всего набора данных

Ручной выбор ключа

Распределение данных

Данные всегда равномерно распределены по всем дата нодам

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

Добавление/удаление узла или реплики

Добавляется в один шаг через GUI, с ребалансировкой

Довольно сложная задача с расчетами веса для каждой коллекции

Распределение реплик по стойкам/ЦОД

Реализовано через логические группы

Не реализовано

Автоматическое распределение нагрузки

Каждая нода имеет одинаковое количество активных записей доступных на чтение и запись

Вторичные узлы не поддерживают запись Не сбалансировано.

Масштабирование индексов

Гибкое, можно добавлять отдельные индекс ноды за счет разнесенной архитектуры

Жесткое, масштабирование индекса связано с масштабирование данных.

Метаданные кластера

Распределяются по всем узлам кластера

Требуются сервера конфигурации

Интегрированный поиск

N1LQ(SQL++)

JSON запрос

Таблица 2 Сравнение репликации

 

Couchbase

MongoDB

Архитектура

Межкластерная репликация не имеет зависимостей, кластера независимы друг от друга

Только внутрикластерное расширение

Гибкость настройки

Гибкая(настройка отдельных бакетов, фильтры, тюнинг)

Тюнинг скорости

Топология

Двунаправленая репликация, звезда, цепь и т.д.

Звезда

Режим Active-Active

Поддерживается

Не поддерживается

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

Опыт эксплуатации

Для начала нам бы хотелось привести цифры, с которыми сейчас оперирует система и кластер на Couchbase.

  1. Более 80 миллионов абонентов[i]
  2. 380 миллионов JSON документов с информацией о клиентах
  3. 3,5 ТБ HDD (мы используем memcached, информация на диске хранится для быстрого старта)
  4. 3 ТБ ОЗУ
  5. 50 тыс. операций в секунду (рис 5)
  6. 50 микросервисов, обрабатывающих весь поток сообщений

Рисунок 5 Нагрузка

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

0. curl -s --data 'cb_couch_sup:restart_couch().' -u Administrator:pass http://127. 1:8091/diag/eval[ii] 0.

Команда действует только в версиях 3.x.

0. curl -s --data 'couch_server_sup:restart_core_server().' -u Administrator:Administrator http://127. 1:8091/diag/eval 0.

Команда действует только в версиях 4.x.

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

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

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

Оно стало работать исправно. После обновления у нас получилось исправить только одну проблему – сжатие. Скорректировать её удалось только силами разработчиков Couchbase в версии 4. С механизмом View проблема всё же осталась, хотя повторялась гораздо реже. 4. 6.

Сделано это было на основании того, что большинство клиентов Couchbase используют вьюхи не для тех целей, для которых создавались, а Couchbase сделал новый механизм N1QL. В рамках решения проблем с техподдержкой выяснилось: механизм вьюх больше обновляться не будет. 7) Выполнен он отдельным сервисом и теперь не зависит от нод с данными (рис.

Рисунок 7 Роли нод

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

Выводы

В рамках гибридной архитектуры МегаФона кластер можно легко адаптировать под любые цели без простоя оборудования и без серьезной реконфигурации серверов, что в целом дает возможность компании сократить затраты на персонал и сделать сервис для абонента максимально удобным. В целом, Couchbase показал себя зрелой системой, держащей высокую нагрузку, даже в неспецифичных кейсах (Viber – используется как БД).

ПАО МегаФон

2018 Ковальчук Егор

[i] Системой обрабатываются не только абоненты, но и устройства со встроенными симкартами, модемы и прочее

[ii] Перед употреблением проконсультируйтесь со специалистом

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»