Цифровая трансформация является глобальной тенденцией для крупного бизнеса и жизненно важна для адаптации предприятия к современным потребностям клиентов.
К обычным для крупных компаний проблемам централизации систем и объединения биллинговых систем и абонентских баз добавляются требования к высокой доступности и работе в режиме реального времени, к которым клиенты уже привыкли со стороны лидеров отрасли (Google, Amazon, Netflix).
Новые задачи требуют новых технологий и подходов, которые необходимы для сокращения времени на внедрение удобных для клиента функций, персонализированных коммерческих предложений, быстрого реагирования на предложения конкурентов, а также контроля затрат на системы, ИТ-инфраструктуру, центры обработки данных и квалифицированный персонал.
У этих тенденций есть и большой недостаток: возрастающая сложность архитектуры и раздутые транзакционные базы данных, которые не справляются с потоком и обработкой информации.
Технологии предыдущего поколения имеют потолок вертикального масштабирования.
Например, экземпляр СУБД Oracle работает на пределе мощнейшего сервера на процессорах x86 с нагрузкой в миллиард транзакций в сутки.
Чтобы выдержать такую нагрузку, с которой интернет-индустрия сталкивается уже долгое время, используется новый стек технологий, таких как кэши In-Memory и базы данных NoSQL. Так, Apple использует Cassandra, Сбербанк использует Ignite (GridGain), а в МегаФоне мы используем Couchbase и Tarantool. МегаФон использует различные архитектурные схемы In-Memory СУБД:
- Простой кэш, обновляемый по расписанию или событию из базы данных и приложений.
- Все изменения в базе данных производятся через кэш (скрипт сквозной записи), например, подключение клиента Oracle к DCP Couchbase.
Ведь все абоненты мобильных операторов после пополнения баланса хотят сразу быть на связи и совершать звонки.
Благодаря отдельному приложению и Couchbase нам удалось сократить время выхода из блокировки с 90 секунд до 30, и это не предел.
В основную базу данных будет включена только запись об изменении статуса абонента (рис.
1).
Рисунок 1 (Пример взаимодействия) Используя новые технологии, нам удалось сократить время преодоления финансового блока в 3 раза.
Но чтобы получить текущие результаты, мы прошли долгий путь архитектурного преобразования схемы биллинга и выбора NoSQL базы данных.
Почему мы выбрали Couchbase? На это есть несколько причин.
Требования к производительности
- Обработка до 200 000 запросов в секунду.
- Среднее время отклика (50%) – до 5 мс (в пределах одного дата-центра).
- Максимальное время отклика (99%) – до 15 мс (в пределах одного дата-центра).
- Максимальная производительность вставки 500 МБ/сек.
- Максимальное количество операций вставки 100000/с
- Максимальное количество операций изменения (обновления документов) 100000/с.
- Максимальная скорость внесения изменений (обновлений документов) 500 МБ/сек.
- Максимальное количество операций чтения 100000/с
- Максимальная скорость чтения 500 МБ/сек.
KV-хранилище — это чрезвычайно простой подход к управлению данными, при котором вместе с фрагментом произвольной информации сохраняется уникальный идентификатор (ключ).
Само хранилище KV может принимать любые данные, будь то двоичный объект или документ JSON. Благодаря простоте реализации KV доступ к данным обеспечивается с минимальной задержкой.
Наш опыт показывает, что задержка в сети часто в 2–3 раза выше, чем при предоставлении ключевых данных на стороне Couchbase. Динамическая схема хранения( JSON) Документы хранятся на сервере Couchbase в формате JSON. Формат поддерживает как базовые типы данных, такие как числа, строки и комплексные типы, так и встроенные словари и массивы.
Схема данных в Couchbase — это логическая конструкция, определенная приложением и разработчиком.
Благодаря своей гибкости и возможности использовать несколько вариантов, мы можем использовать тег в документе, например, с информацией о версии.
Это позволяет приложению определить, в каком режиме обрабатывать документ, а также обеспечить плавный переход базы данных на новую схему данных.
Высокая доступность Одним из составляющих параметров информационной системы является ее доступность.
Couchbase обеспечивает высокую доступность данных благодаря множеству различных функций.
Один из них — репликация данных (распределение нескольких копий данных на разные серверы кластера), что позволяет предоставлять услуги во время планового обслуживания или при выходе из строя некоторых серверов.
Рисунок 2 (Реплики сервера Couchbase) Второй важной функцией высокой доступности является внутренний DCP (протокол изменения базы данных).
Он обеспечивает высокоскоростное распространение изменений на все копии данных, вторичные индексы (GSI), межкластерную репликацию (XDCR) и внешних потребителей.
Двунаправленная репликация Хорошей практикой в компаниях является использование резервирования всех бизнес-процессов и оборудования.
В идеале это резервирование в режиме Active-Active, когда переключение между проблемными узлами происходит автоматически.
Двунаправленная репликация в Couchbase допускает режим A-A. Но тестирование репликации показало, что она эффективна только в близлежащих дата-центрах.
При расстоянии более 100 км возникают конфликты.
Couchbase имеет механизмы разрешения конфликтов, основанные на временной метке и порядковом номере.
Однако из-за временной задержки в сети в базу данных попадают устаревшие данные.
Мы отказались от использования двунаправленной репликации (межкластерной согласованности).
Все изменения проводятся только на одном кластере.
Доступность данных в режиме чтения обеспечивается во всех дата-центрах (А-А).
Горизонтальное масштабирование Одной из важных характеристик большинства баз данных NoSQL является горизонтальное масштабирование (рис.
3).
Основное отличие Couchbase — поддержка многомерного масштабирования, когда в кластере мы можем повысить производительность только того сервиса, который нам нужен.
Например, игра Pokemon GO использует разделение архитектуры.
На старте проекта использовалось 5 серверов с комбинированным сервисом.
После увеличения нагрузки использовали распределенную архитектуру: 5 серверов с данными и 55 серверов для обработки запросов и индексов.
Одним из недостатков масштабирования с помощью Couchbase является то, что оркестратор может столкнуться с проблемами, если в кластере более 50 узлов данных.
Рисунок 3. МДС Требования информационной безопасности Требования информационной безопасности повлияли на наш выбор в меньшей степени, но их наличие в системе выступило дополнительным аргументом в пользу той или иной базы данных.
Поскольку в кэше могут содержаться персональные данные, мы должны соблюдать требования регулятора.
Стоит решить: будем ли мы использовать дополнительное оборудование или сможем обеспечить это самой базой данных?! В корпоративной версии Couchbase поддерживает шифрование трафика, шифрование данных и персонализированный доступ.
Это позволяет сэкономить на оборудовании, например Cisco ASA. Легко обновить Одним из существенных преимуществ Couchbase является прозрачный механизм обновления и поддержка API старых версий.
Пока кластер обновляется, он работает в режиме совместимости.
Новые механизмы заработают только после полного обновления кластера.
Влияние на запуск приложений минимально благодаря поддержке старого API. ПС: Обновление/понижение разрешено только для смежных основных версий.
Дополнительный функционал Логическое распределение Еще одна интересная особенность — объединение серверов в кластере в логические группы с прикрепленными к ним репликами.
Это позволяет распределять полные копии реплик одного кластера по разным автокомнатам.
Это позволяет иметь полную копию данных в секунду, если один из автосалонов выйдет из строя.
Рис.
4. Группа серверов Резервное копирование и восстановление Couchbase содержит готовые инструменты для резервного копирования и восстановления.
Процесс резервного копирования может работать в трех режимах: полном, дифференциальном и накопительном.
Это позволяет в некоторых случаях сэкономить дисковое пространство и ресурсы процессора.
Couchbase против Монго На вопрос выбора альтернативных баз данных NoSQL ответить сложно, и зачастую лучший Unix — это тот, который знает ваш администратор.
Попробуем сформулировать, почему мы выбрали Couchbase, а не другую очень популярную платформу — MongoDB. Сравнивать два разных проекта с разной архитектурой и функциональностью довольно сложно.
Одним из параметров, на который мы обратили внимание, была простота обслуживания и возможность быстрой перенастройки системы под нужды бизнеса.
Таблица 1. Сравнение
| Коучбейс | МонгоБД | |
| Масштабирование | Автоматически для всего набора данных | Ручной выбор ключа |
| Распределение данных | Данные всегда равномерно распределяются по всем узлам данных.
|
Неправильная разметка может привести к искаженному распределению данных.
|
| Добавить/удалить узел или реплику | Добавлено за один шаг через графический интерфейс с ребалансировкой | Довольно сложная задача с расчетами веса для каждой коллекции.
|
| Распределение реплик по стойкам/ЦОДам | Реализуется через логические группы | Не реализована |
| Автоматическое распределение нагрузки | Каждый узел имеет одинаковое количество активных записей, доступных для чтения и записи.
|
Не сбалансировано.
Вторичные узлы не поддерживают запись |
| Масштабирование индексов | Гибкость: вы можете добавлять отдельные узлы индекса благодаря распределенной архитектуре.
|
Масштабирование жесткого индекса связано с масштабированием данных.
|
| Метаданные кластера | Распределяется по всем узлам кластера | Требуются серверы конфигурации |
| Интегрированный поиск | N1LQ(SQL++) | JSON-запрос |
| Коучбейс | МонгоБД | |
| Архитектура | Межкластерная репликация не имеет зависимостей, кластеры независимы друг от друга.
|
Только внутрикластерное расширение |
| Гибкость настройки | Гибкость (настройка отдельных сегментов, фильтров, настройка) | Настройка скорости |
| Топология | Двунаправленная репликация, звезда, цепочка и т. д. | Звезда |
| Активный-активный режим | Поддерживается | Не поддерживается |
Опыт эксплуатации Для начала хотелось бы привести цифры, с которыми на данный момент работает система и кластер на Couchbase.
- Более 80 миллионов подписчиков [я]
- 380 миллионов документов JSON с информацией о клиентах
- HDD 3,5 ТБ (используем memcached, информация хранится на диске для быстрого запуска)
- 3 ТБ ОЗУ
- 50 тысяч операций в секунду (рисунок 5)
- 50 микросервисов, обрабатывающих весь поток сообщений
Рисунок 5. Нагрузка Мы начали первые этапы трансформации с третьей версии Couchbase. На первом этапе при запуске проекта все приложения работали стабильно.
Но при переносе дополнительной логики в новый механизм мы столкнулись с тем, что механизм View стал работать непредсказуемо.
Те.
в какой-то момент процесс повесить трубку и данные представления из такого узла перестали возвращаться.
При этом доступ к данным и их обработка не были прерваны.
Проблема решилась довольно легко — перезапуском узла, что в целом снизило доступность сервиса.
При общении с техподдержкой Couchbase нам предложили недокументированную команду, перезапускающую только процесс просмотра.
curl -s --data 'cb_couch_sup:restart_couch().
' -u Администратор: пройти http://127.0.0.1:8091/diag/eval [ii] Команда действительна только в версиях 3.x. curl -s --data 'couch_server_sup:restart_core_server().
' -u Администратор:Администратор http://127.0.0.1:8091/diag/eval Команда действительна только в версиях 4.x. Еще одной проблемой третьей версии стал сломанный механизм сжатия данных (компрессия).
Его пришлось запускать вручную на основе сработавших метрик мониторинга.
Обе проблемы держали в напряжении не только дежурную смену, но и функциональных инженеров.
В связи с этим мы решили перейти на четвертую версию.
Миграция заняла около двух недель с минимальным влиянием на сервис.
Сам процесс обновления не требует сложных действий и контроля, но при добавлении или удалении узла запускается ребалансировка, которая занимает не менее двух часов.
В процессе мы нашли способ ускорить процесс обновления через буферный сервер: в этом случае запускается не чистый процесс ребалансировки, а передача данных с одной ноды на другую.
Это позволило нам сократить процесс обновления до 30 минут. При обновлении промышленного кластера необходимо учитывать следующий нюанс: работа в режиме совместимости, когда кластер работает в режиме самой младшей версии ПО.
Положительной стороной является то, что процесс обновления происходит плавно и безболезненно, но тем не менее новые функции, такие как новый механизм сжатия N1QL, нельзя использовать до полного обновления всего кластера.
После обновления нам удалось исправить только одну проблему — сжатие.
Он начал работать правильно.
Проблема с механизмом просмотра все равно осталась, хотя и повторялась гораздо реже.
Исправить это удалось только разработчикам Couchbase в версии 4.6.4. В рамках решения проблем с техподдержкой выяснилось, что механизм просмотра больше не будет обновляться.
Это было сделано на том основании, что большинство клиентов Couchbase не используют представления для тех целей, для которых они были созданы, и Couchbase создал новый механизм N1QL. Оно было выполнено отдельным сервисом и теперь не зависит от узлов с данными (рис.
7).
Рисунок 7. Роли узлов Мы закрыли все критические проблемы в версии 4.6.4. Но из-за увеличения объёма данных мы решили перейти на пятую версию, где добавили новую базу для индексов и на основе наших данных объём в памяти и на дисках уменьшился в полтора раза.
Но, к сожалению, уменьшения объёма данных на узлах данных мы не увидели.
выводы В целом Couchbase показала себя зрелой системой, способной справиться с высокой нагрузкой даже в неспецифических случаях (в качестве базы данных используется Viber).
В рамках гибридной архитектуры «МегаФона» кластер легко адаптируется под любые цели без простоя оборудования и без серьезной реконфигурации серверов, что в целом позволяет компании сократить расходы на персонал и сделать обслуживание максимально удобным для абонента.
ПАО «МегаФон» 2018 Ковальчук Егор [я] Система обрабатывает не только абонентов, но и устройства со встроенными SIM-картами, модемы и т. д. [ii] Перед применением проконсультируйтесь со специалистом Теги: #Сотовая связь #Разработка систем связи #NoSQL #стандарты связи #мегафон #couchbase #nosql базы данных
-
Google Adsense –
19 Oct, 24 -
Мы Используем 2+ Провайдеров (Первая Часть)
19 Oct, 24 -
Выручка Ibm Падает 13 Кварталов Подряд
19 Oct, 24 -
Доверяете Ли Вы Антивирусной Защите?
19 Oct, 24 -
Гибридная Реализация Русской Морфологии
19 Oct, 24
