Доклад с конференции 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

1. Как строить
архитектуру для
отказоустойчивой
службы такси
Минкин Андрей
NambaTaxi

2. Частник

3. Диспетчерская служба

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

9. Как все начиналось?

10. Workflow на софте поставщика
Клиент Оператор Заказ
Водитель
Принял
заказ
Приехал на
место
Забрал
клиента
Привез
клиента
Менеджер
видит отчет

11. Фичи софта поставщика
• Call-центр
• SMS оповещения
• Автоматизация workflow
• Много китайских
навигаторов (Shturmann,
A500)

12. Оповещения по SMS
• Водитель принял заказ на
исполнение
• Водитель приехал на
место

13. Почему отказались
• Нестабильная работа
• Долгий даунтайм
• Перестал удовлетворять
нашим требованиям роста
и бизнеса

14. Требования к системе
• Минимум изменений в
workflow водителей и
операторов
• Гибкость разработки и
добавления новых фич

15. • Водители должны
остаться на навигаторах
на WinCE
• Заложить поддержку
Android для водителей

16. • Реалтайм в операторской
• Работающая телефония
• Возможность сразу
перейти на свое решение

17. Ограничения
• Цена на мобильный
интернет
• Серверные ресурсы
• Маленькая команда
• Результат в кратчайшие
сроки

18. Проектирование Web
Ядро
Операторы Водители
Менеджеры Платежи

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
Менеджеры Операторы Водители Платежи

23. Водители
Навигатор Twisted Django+Redis
TwistedНавигатор

24. SMS оповещения
Twisted Django
Ruby SMSSMSC

25. SMS заказы
Клиент SMS SMSC
Ruby SMSDjango

26. Операторская
Операторы
Заказы Телефония

27. Операторская. Заказы

28. Менеджеры
Django
Excel Browser
Percona

29. Percona 5.5 HA
• Master-slave replication
• Virtual IP for Master

30. Первая проверка
• Проверили продукт в
реальных условиях
• Стабилизировали
WebRTC

31. Перевод бизнеса на свое
решение

32. Задача по переносу
• Перенести 2 000
водителей
• Перенести все короткие
смс номера
• Перенести телефонию
• Перенести 20 операторов

33. • 7 дней
• Техническая команда
• Начальник транспортного
отдела
• Начальник call центра

34. Как выглядела
операторская
Nginx
Ядро Node.js

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 синхронный

43. Решение
TCP
proxy
Twisted1 Twisted2

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 не справляется

47. Решение
Nginx
Node.js
node1 node2
Ядро

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. Выход

52. Общее решение
Nginx
Node.js
node1 node2
Ядро
Django1 Django2

53. Первая балансировка

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
• Нагрузочные тесты не из
реального мира

59. Начался рост заказов
0
1000
2000
3000
4000
5000
6000
7000
8000
9000

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 точка входа для
операторов, клиентов

67. 0
10
20
30
40
50
60
70
80
90
100
Chart Title
s1 s2

68. Схема водителей на
этот момент
Haproxy
Twisted1
Django1
Twisted2
Django2

69. Nginx
Ядро Node.js Apps

70. Nginx
• 2 nginx с keepalived
• DNS round robin

71. HA для Nginx

72. Разделяем workflow
Nginx
workflow
Django1
Master DB
Django2
reports
Django3
Slave Db
Django4

73. Правильный Twisted
• Async HTTP
• Async Redis
• Random upstream

74. План
Twisted
nginx nginx

75. Итог

76. Что еще не HA
• СМС демоны
• Redis

77. СМС демоны
Django SMSDaemon
SMSC

78. Минусы
• Много коннектов по TCP
• Нет масштабируемости

79. Выход
• Redis pub/sub

80. СМС демоны
Django Redis
SMS
Daemon
SMSC

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

85. Как сделали webrtc
стабильным

86. Первая реализация
sipML5
webrtc2sip
Провайдер

87. Минусы
• Не можем подключать
больше номеров
• Не можем балансировать
исходящую связь
• 1 номер = 1 webrtc2sip

88. Asterisk 11.5
sipml5 asterisk
GSM
шлюз/провайдеры

89. Плюсы
• Можем подключать новые
номера
• Можем балансировать
нагрузку
• Получили полноценную
АТС

90. Проблемы
• Срывается звонок
• Нет гудков
• Нет правильной работы со
статусами прогресса SIP
• Долгое время бриджа аудио
• Входящий звонок мог
крашнуть asterisk

91. Asterisk 11.6
sipml asterisk
GSM
шлюз/провайдеры

92. Плюсы
• Звонок не срывается
• Asterisk не падает
• Audio бриджуется отлично

93. Минусы
• Нет гудков и служебных
ответов
• Нет правильной работы со
статусами прогресса
• Одностороннее аудио

94. Sipml+webrtc2sip
sipml webrtc2sip
asterisk
GSM
шлюз/провайдеры

95. Плюсы
• Статусы работают
• Есть гудки
• Нет проблем с
односторонним аудио
• Все работает

96. Минусы
• Рандомно крашится

97. Почему не починили
• Нет документации
• Плохое качество кода

98. FreeSWITCH
sipml5 FreeSWITCH
GSM
шлюз/провайдеры

99. Плюсы
• Стабильно работает
• Поддерживает webrtc
полностью
• Все работает, но…

100. Минусы
• Нет гудков и служебных
ответов от операторов

101. Решение
• FreeSWITCH берет трубку
при исходящем звонке

102. Проблемы
• Звонок не больше 2х
минут из-за SipML5

103. Выход
• Sipml5 -> JSSIP

104. Итог
jssip FreeSWITCH
GSM
шлюз/провайдеры

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