Как строить архитектуру для отказоустойчивой службы такси / How to Build a Fallover System for the Taxi Company
•Download as PPTX, PDF•
0 likes•785 views
Доклад с конференции Highload++ 2015 об отказоустойчивой архитектуре A report from the Highload++ 2015 conference in Moscow, describing the fallover architectures Автор: Андрей Минкин / Andrew Minkin http://www.highload.ru/2015/abstracts/1661.html
Как строить архитектуру для отказоустойчивой службы такси / How to Build a Fallover System for the Taxi Company
- 1. Как строить архитектуру для отказоустойчивой службы такси Минкин Андрей NambaTaxi
- 2. Частник
- 4. Uber
- 5. О нас • 300k довольных клиентов • 600+ водителей на линии • Не менее 8k заказов в сутки
- 6. Суточная нагрузка 0 500 1000 1500 2000 2500 3000 3500 4000 5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 0:00 Запросов в секунду
- 7. AVG response time on backends • Водители - 20 ms • Операторы - 2.5 ms
- 8. О чем доклад • Как строили архитектуру • Как делали WebRTC
- 10. Workflow на софте поставщика Клиент Оператор Заказ Водитель Принял заказ Приехал на место Забрал клиента Привез клиента Менеджер видит отчет
- 11. Фичи софта поставщика • Call-центр • SMS оповещения • Автоматизация workflow • Много китайских навигаторов (Shturmann, A500)
- 12. Оповещения по SMS • Водитель принял заказ на исполнение • Водитель приехал на место
- 13. Почему отказались • Нестабильная работа • Долгий даунтайм • Перестал удовлетворять нашим требованиям роста и бизнеса
- 14. Требования к системе • Минимум изменений в workflow водителей и операторов • Гибкость разработки и добавления новых фич
- 15. • Водители должны остаться на навигаторах на WinCE • Заложить поддержку Android для водителей
- 16. • Реалтайм в операторской • Работающая телефония • Возможность сразу перейти на свое решение
- 17. Ограничения • Цена на мобильный интернет • Серверные ресурсы • Маленькая команда • Результат в кратчайшие сроки
- 19. Что выбрали • Python/Django для Ядра • Redis для Publish/Subscribe • Node.js – событийный реалтайм в операторской • Twisted – socket server для водителей • Ruby для SMS • WebRTC для телефонии
- 20. Почему так? • Ruby -> Ruby-smpp для sms • Node.js -> socket.io для реалтайма • Twisted – потому что клевый
- 21. Зачем sip через WebRTC • Open Source решение • Нет привязки к железу и ОС • Экономия рабочих мест в офисе • Экономия на коммутационном оборудовании
- 22. Реализация Django Менеджеры Операторы Водители Платежи
- 24. SMS оповещения Twisted Django Ruby SMSSMSC
- 25. SMS заказы Клиент SMS SMSC Ruby SMSDjango
- 29. Percona 5.5 HA • Master-slave replication • Virtual IP for Master
- 30. Первая проверка • Проверили продукт в реальных условиях • Стабилизировали WebRTC
- 31. Перевод бизнеса на свое решение
- 32. Задача по переносу • Перенести 2 000 водителей • Перенести все короткие смс номера • Перенести телефонию • Перенести 20 операторов
- 33. • 7 дней • Техническая команда • Начальник транспортного отдела • Начальник call центра
- 35. Как выглядели водители TCP proxy Twisted
- 36. Первые глаза • Sentry • Nagios • Collectd
- 37. День 1 20 20 20 20 5 4 2 ОПЕРАТОРЫ 2000 2000 1500 1000 500 250 100 ДЕНЬ 7 ДЕНЬ 6 ДЕНЬ 5 ДЕНЬ 4 ДЕНЬ 3 ДЕНЬ 2 ДЕНЬ 1 ВОДИТЕЛИ
- 38. День 2 20 20 20 20 5 4 2 ОПЕРАТОРЫ 2000 2000 1500 1000 500 250 100 ДЕНЬ 7 ДЕНЬ 6 ДЕНЬ 5 ДЕНЬ 4 ДЕНЬ 3 ДЕНЬ 2 ДЕНЬ 1 ВОДИТЕЛИ
- 39. День 3 20 20 20 20 5 4 2 ОПЕРАТОРЫ 2000 2000 1500 1000 500 250 100 ДЕНЬ 7 ДЕНЬ 6 ДЕНЬ 5 ДЕНЬ 4 ДЕНЬ 3 ДЕНЬ 2 ДЕНЬ 1 ВОДИТЕЛИ
- 40. День 4 20 20 20 20 5 4 2 ОПЕРАТОРЫ 2000 2000 1500 1000 500 250 100 ДЕНЬ 7 ДЕНЬ 6 ДЕНЬ 5 ДЕНЬ 4 ДЕНЬ 3 ДЕНЬ 2 ДЕНЬ 1 ВОДИТЕЛИ
- 41. Performance проблемы водителей • Некоторые водители не могут взять заказ • У некоторых водителей не обновляется список заказов
- 42. Причина • Socket timeout на навигаторах • Twisted синхронный
- 44. День 5 20 20 20 20 5 4 2 ОПЕРАТОРЫ 2000 2000 1500 1000 500 250 100 ДЕНЬ 7 ДЕНЬ 6 ДЕНЬ 5 ДЕНЬ 4 ДЕНЬ 3 ДЕНЬ 2 ДЕНЬ 1 ВОДИТЕЛИ
- 45. Проблемы операторов • Периодически не обновляется список заказов • Некоторые события не доходят до операторов
- 46. Причина • Node.js не справляется
- 48. День 6 20 20 20 20 5 4 2 ОПЕРАТОРЫ 2000 2000 1500 1000 500 250 100 ДЕНЬ 7 ДЕНЬ 6 ДЕНЬ 5 ДЕНЬ 4 ДЕНЬ 3 ДЕНЬ 2 ДЕНЬ 1 ВОДИТЕЛИ
- 49. День 6. Проблемы • У некоторых водителей не обновляется список заказов • У операторов медленно оформляются заказы
- 50. Причина • Django не успевает отвечать на запросы
- 51. Выход
- 54. Но это не все 0 50 100 150 200 250 300 Node.js Bandwidth
- 55. Выход • Socket.io -> surepost- socket.io
- 56. День 7 • Все стабилизировалось
- 57. Итог • -8% заказов за время переезда • Время подачи машины сократилось с 8 до 5 минут
- 58. Ошибки на начальном этапе • Twisted синхронный • Вместо Nodejs erlang или Python • Нагрузочные тесты не из реального мира
- 60. Mobile Apps
- 61. Архитектура после Nginx Ядро Node.js Apps
- 62. Наблюдаем рост 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 Chart Title Заказы Пользователи приложений
- 63. 0 100 200 300 400 500 600 700 800 1 2 3 4 5 6 7 8 9 10 11 12 Водители на линии
- 64. Проблемы роста • Подводит Синхронный Twisted нас
- 65. План действий • Используем Twisted правильно • Сделать равномерную балансировку • Построить HA под шумок
- 66. При этом • 1 сервер загруженнее другого • 1 точка входа для операторов, клиентов
- 68. Схема водителей на этот момент Haproxy Twisted1 Django1 Twisted2 Django2
- 70. Nginx • 2 nginx с keepalived • DNS round robin
- 71. HA для Nginx
- 73. Правильный Twisted • Async HTTP • Async Redis • Random upstream
- 75. Итог
- 76. Что еще не HA • СМС демоны • Redis
- 78. Минусы • Много коннектов по TCP • Нет масштабируемости
- 81. Профит • Persistent connect к redis • Publish/Subscribe • Масштабируемость
- 82. Redis Failover
- 83. Percona 5.6 HA • Master-Master (GTID) • Virtual IP for Master • Virtual IP for Slave • Master – write • Slave – read for reports
- 84. Что получилось • Высоко масштабируемый продукт • Отказоуйстойчивый • С sip без flash
- 87. Минусы • Не можем подключать больше номеров • Не можем балансировать исходящую связь • 1 номер = 1 webrtc2sip
- 89. Плюсы • Можем подключать новые номера • Можем балансировать нагрузку • Получили полноценную АТС
- 90. Проблемы • Срывается звонок • Нет гудков • Нет правильной работы со статусами прогресса SIP • Долгое время бриджа аудио • Входящий звонок мог крашнуть asterisk
- 92. Плюсы • Звонок не срывается • Asterisk не падает • Audio бриджуется отлично
- 93. Минусы • Нет гудков и служебных ответов • Нет правильной работы со статусами прогресса • Одностороннее аудио
- 95. Плюсы • Статусы работают • Есть гудки • Нет проблем с односторонним аудио • Все работает
- 97. Почему не починили • Нет документации • Плохое качество кода
- 99. Плюсы • Стабильно работает • Поддерживает webrtc полностью • Все работает, но…
- 100. Минусы • Нет гудков и служебных ответов от операторов
- 101. Решение • FreeSWITCH берет трубку при исходящем звонке
- 102. Проблемы • Звонок не больше 2х минут из-за SipML5
- 103. Выход • Sipml5 -> JSSIP
- 105. HA sip
- 106. Начальная нагрузка • До 25k звонков в сутки
- 107. Итоги проделанной работы • Сократили количество звонков с 25к до 12к за счет автоматизации процессов и мобильных приложений • Сократили 30% операторов • Увеличили количество заказов на 40%
- 108. Подводные камни • WebRTC • Отказоустойчивость • Concurrency
- 109. Борьба с Concurrency • Redis -> setnx • Percona -> Atomic transactions + select … for update
- 110. Какие ошибки? • Не учли быстрого роста • Не было хорошей балансировки
- 111. Наши глаза • Nagios -> Sensu • Collectd -> Graphite • Newrelic -> Node.js • Cprofilemiddleware -> Django • Opbeat -> Django
- 112. Учебные тревоги • До 2х раз в неделю проверяем отказоустойчивость любого сервиса • До 2х раз в месяц перезагружаем любой физический сервер
- 113. Выводы • Архитектура должна подстраиваться под бизнес процессы • Не надо бояться перестраивать архитектуру проекта
- 114. Выводы • Разные workflow большой системы не должны влиять друг на друга • Хорошая архитектура растет вместе с вами
- 115. Спасибо • Skype: gen1us2k • Habr: @gen1us2k
Editor's Notes
- #9: Рассказать про workflow термин
- #14: Потому что мы планировали заходить на рынок мобильных девайсов Выход – сделать свой софт
- #17: Последний пункт переделать. Нужно рассказать о том, что не возможно тут мастабироваться горизонтально
- #25: Рассказать историю о том, как помогали опсосам
- #36: Сделать подробнее
- #39: Перенесли один СМС номер
- #40: Перенесли все номера
- #41: Перенесли телефонию
- #45: Скорость переноса водителей – 2 водителя в минуту в часы пик.
- #49: Все заказы идут через новый софт
- #54: Добавить Redis
- #58: Время подачи машины было 8 стало 5
- #67: Нужно отразить схемой
- #75: Добавить точки
- #76: HaProxy у нас также отказоустойчивый через keepalived. Держим около 40% ресурсов свободными
- #94: 1хх – мы не можем корректно работать со статусами прогресса
- #102: МЫ могли не париться по двум причинам: Между операторами звонки бесплатные и безлимитные.
- #108: Добавить заказы
- #116: Добавить контакты