Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Как Mail.Ru и AT Consulting перевели профили абонентов Beeline на Tarantool / А.Дроздов, Ю.Гейниш

306 views

Published on

РИТ++ 2017, Web-scale IT Сonference
Зал Владивосток, 6 июня, 17:00

Тезисы:
http://webscaleconf.ru/2017/abstracts/2553.html

Платформа виртуализации данных на основе Tarantool - система, созданная в Mail.Ru Group в прошлом году. Cовместно с АТ Consulting было создано и запущено в production решение для хранения 100 млн. профилей абонентов компании Beeline, выдерживающее значительные нагрузки.
...

Published in: Engineering
  • Be the first to comment

Как Mail.Ru и AT Consulting перевели профили абонентов Beeline на Tarantool / А.Дроздов, Ю.Гейниш

  1. 1. Как Mail.Ru и AT Consulting перевели профили абонентов Beeline на Tarantool Андрей Дроздов, Mail.Ru Group Юлия Гейниш, AT Consulting
  2. 2. Наш клиент миллионов активных абонентов 58+ 270+ тысяч корпоративных клиентов 300+ информационных систем и приложений 500+ различных продуктов и услуг 1000+ новых проектов в год
  3. 3. Цель клиента •Unified customer profile •Общий API для всех систем •Контроль нагрузок на источники •Версионирование данных •Входящая нагрузка 300000 TPS
  4. 4. Боль клиента
  5. 5. Решение
  6. 6. Зачем мы объединились? •Существующие решения не имели требуемого функционала или не обеспечивали нагрузку •Опыт создания highload систем •Опыт внедрения решений в Enterprise •Разделение рисков и работ
  7. 7. Как поделили задачи? • Сбор бизнес-требований • Совместное ТЗ и архитектура • Разработка data-ландшафта • Разработка discovery service • Тестирование бизнес логики • Запуск системы в production • Сбор технических требований • Совместное ТЗ и архитектура • Разработка платформы • Кастомизация open source решения • QA и решение технических проблем • Запуск системы в production
  8. 8. Влияние на результат • При запуске потребовались доработки discovery service и сервиса авторизации • Вывод: ключевую инфраструктуру нужно разрабатывать совместно
  9. 9. Архитектура системы IVR/SMS/USSD Social Nets WidgetsDesktops / WEBs Mobile Devices In-door digital Partners DIGITAL CHANNELS Step 1Step 2
  10. 10. Источники данных • Биллинг: абонентские данные • Препейд биллинг: абонентские данные • Регионы: принадлежность номера к региону • Продуктовый каталог: информация о продуктах • Личный кабинет: доступные услуги и тарифные планы • Платформа RBT: задолженность по услуге RBT • Возможно подключение новых источников
  11. 11. Все пошло не так • Для преобразования, «на лету», native данных в SID реализован особый коннектор, при этом клиентский интерфейс остался единым
  12. 12. Синхронизаторы • Слишком медленные источники данных оповещают об изменениях через синхронизатор
  13. 13. Инфраструктура • Для поддержания справочника в актуальном состоянии организована интеграция с системой мониторинга, для постоянного контроля доступности сервисов.
  14. 14. Ядро платформы
  15. 15. Версионирование данных
  16. 16. Лента сообщений
  17. 17. Проблемы мышления
  18. 18. Пример задачи • «Добрый день, коллеги. Уже несколько часов наблюдаем медленные ответы клиентам от платформы, приоритет КРИТИЧЕСКИЙ» • Начали искать проблему в коде платформы, нужно было диагностировать все решение
  19. 19. Пример задачи •«Добрый день, коллеги. Просьба прислать ваши тест кейсы для анализа и передачи клиенту» •Ожидали документы, получили код
  20. 20. Почему так? • В интернет-компаниях другая модель управления рисками • В Enterprise компаниях начинают копать проблему со всех сторон и иногда описывают проблему без полной диагностики • Интегратор работает с множеством продуктов и времени проводить диагностику во всех продуктах сразу может не быть (SLA) • Вендор мыслит в терминах продукта • Интегратор мыслит в терминах решения
  21. 21. Правильный пример •«В решении наблюдаются проблемы c производительностью, нужно подтвердить, что компоненты платформы не являются источником. Просим подключить ваших экспертов к диагностике решения»
  22. 22. Разница в мышлении • Делаем решение, а не продукт • Минимизируем доработки смежных систем • Приоритет: time to market • Меньше дефектов - лучше • Делаем продукт, а не решение • Изменяем смежные системы • Приоритет: качество и производительность • Больше найденных дефектов – лучше
  23. 23. Хотелки • Клиент: • Больше функциональности в том же контракте • Интегратор: • Поддержка решения и управляемость • Вендор: • Качество и возможность создания универсальных компонент
  24. 24. Доработка ключевого компонента •За месяц до запуска заказчик попросил изменить логику работы с правами, что повлекло доработку сервиса авторизации и платформы
  25. 25. Влияние на результат •Изменения могли существенно повлиять на сроки проекта •Обе команды должны были доработать свои компоненты •В тестово-промышленную эксплуатацию выходили с заглушкой
  26. 26. Доработка платформы • Для корректной работы с сервисами биллинга нужно было добавить возможность обогащения данными из других источников
  27. 27. Влияние на результат • Влияние такой доработки на производительность и общее поведение системы не было проработано и протестировано в полном объеме • После запуска в продакшн пришлось столкнуться с рядом проблем
  28. 28. Чеклист вендора • Скорость реакции/решения вопросов проблем 2 и 3 уровня поддержки • Доступность и активность в консультациях по развитию • Готовность делиться экспертизой • Возможность кастомизации продукта • Готовность к постоянной коммуникации со всеми участниками процесса
  29. 29. Чеклист интегратора • Умение переводить с языка клиента на язык вендора • Готовность к решению спорных и конфликтных ситуаций • Опыт координации рабочего процесса команд • Готовность дать вендору возможность сконцентрироваться на технологиях • Готовность перенимать новые знания и менять подходы к разработке
  30. 30. Передача знаний • Опыт внедрения решений виртуализации данных и Tarantool • Lua • Avro schema • Эксплуатация Tarantool • IT процессы в телекомах • Подходы к работе в Enterprise • Подход к эксплуатации решений в Enterprise • Умение внедряться в бизнес- процессы других компаний
  31. 31. Влияние на результат • Поддержка 2 уровня выполняется командой AT Consulting. Команда DevOps в AT Consulting автоматизировала процесс эксплуатации решения • Настройки платформы, добавление новых источников и новых версий схем данных выполняются без привлечения вендора. • Mail.Ru получила огромный опыт работы в Enterprise и возможности для привлечения новых клиентов • В команде Tarantool сформировался отдел Solution Engineering для кастомизации Open Sourсe продукта под Enterprise заказчиков
  32. 32. Почему важен прототип? • Возможность пробовать любые идеи и проверять их за несколько минут • Большая часть автоматизации от прототипа пошла в боевую версию без изменений • MVP лучше прототипа «на выброс» • Вся разработка строилась итерациями от прототипа
  33. 33. Как было устроено тестирование?
  34. 34. Как было устроено тестирование?
  35. 35. Как было устроено тестирование?
  36. 36. Как было устроено тестирование?
  37. 37. С чем столкнулись после запуска? •Чем раньше был предложен и продуман тот или иной функционал, тем меньше проблем возникает после запуска •И наоборот…
  38. 38. Источники данных • Проблема: • Из-за возможности выполнять запросы во внешние источники, проявлялись проблемы с пиковой производительностью • Решение: • Мониторинг всех компонент системы, анализ и выявление узких мест • Мораль: • Без хорошего мониторинга мы бы не решили проблему • Как можно раньше нужно делать feature freeze
  39. 39. Крэши отдельных узлов кластера •Проблема: •Более свежая версия tarantool могла в редких случаях приводить к падению узла •Решение: •Отказоустойчивость внутри ЦОД •Реакция команды эксплуатации AT Consulting •Предоставление максимально подробного описания проблемы •Мораль: •Enterprise не должен отказываться от более современных и выгодных бизнесу решений, но это требует детальной проработки архитектуры
  40. 40. Итоги ✓В production с ноября 2016 года ✓Загружено ~100 млн абонентов ✓Подключено 6 источников ✓Производительность платформы: 300000 tps
  41. 41. Заключение Текущий подход Новый тренд

×