РИТ++ 2017, HighLoad Junior Зал Сингапур, 6 июня, 14:00 Тезисы: http://junior.highload.ru/2017/abstracts/2499.html Компания TIMCONNECT процессит банковские смс-сообщения, по возможности отправляя их как push. Расскажем, как мы за 2 месяца небольшой командой масштабировались в 15 раз, минимально переписывая код, применяя паттерны из хайлоада методом проб и ошибок. На примерах проиллюстрируем, что хайлоад может быть достижим просто и быстро. Если повезет. Доклад о собранных граблях и сделанных выводах, применимых к большинству проектов.

1. Рост с нуля до 15000 сообщений в
секунду. Мучительный и
поучительный
Юрий Колесов
http://security-gu.ru
security-guru@mail.ru
+7 (926) 55-99-824
https://www.facebook.com/yuri.v.kolesov

2. TIM-CONNECT
Процессит банковские SMS-уведомления, по
возможности отправляя их как PUSH
Принимаем по SMPP (Short message Peer-to-Peer),
отправляем по SMPP и PUSH (APNS, GCM, MPNS)
SMPP — C daemon. PUSH, API — python.

3. TIM-CONNECT
Процессит банковские SMS-уведомления, по
возможности отправляя их как PUSH
Принимаем по SMPP (Short message Peer-to-Peer),
отправляем по SMPP и PUSH (APNS, GCM, MPNS)
SMPP — C daemon. PUSH, API — python.
Задача: показать процессинг 15000 sms/sec
Срок: 2 месяца

4. TIM-CONNECT
Процессит банковские SMS-уведомления, по
возможности отправляя их как PUSH
Принимаем по SMPP (Short message Peer-to-Peer),
отправляем по SMPP и PUSH (APNS, GCM, MPNS)
SMPP — C daemon. PUSH, API — python.
Задача: показать процессинг 15000 sms/sec
Срок: 2 месяца

6. Что уже было

7. Что уже было
● Оптимизировали SMPP демоны
(многопоточные, внутренние очереди, блочная
работа с БД)

8. Что уже было
● Оптимизировали SMPP демоны
(многопоточные, внутренние очереди, блочная
работа с БД)
● Разделили БД на две: очередь и архив

9. Что уже было
● Оптимизировали SMPP-демоны
(многопоточные, внутренние очереди, блочная
работа с БД)
● Разделили БД на две: очередь и архив
● Монолит разделили на:
– mobile API
– ЛК
– PUSH

10. 640k ought to be enough for
anybody
(C) Bill Gates 1981

11. Требования
● Минимальные сроки (уложиться до deadline)

12. Требования
● Минимальные сроки (уложиться до deadline)
● Ограниченные ресурсы

13. Требования
● Минимальные сроки (уложиться до deadline)
● Ограниченные ресурсы
● Количественно определенные цели

14. Оценить
● Достижимость

15. Оценить
● Достижимость
● Трудоемкость

16. Оценить
● Достижимость
● Трудоемкость
● Скейлинг

17. Тестирование
● Все сценарии
● Релевантный набор данных

18. Тестирование
● Все сценарии
● Релевантный набор данных
– Быстро начать!
– Тестируем на том, что есть

19. Тестирование
● Все сценарии
● Релевантный набор данных
– Быстро начать!
– Тестируем на том, что есть
● Генераторы и приемники нагрузки

21. php-fpm vs.
uwsgi+python
На python rps в
два раза больше

22. Результаты тестирования
Single instance:
● 3500 sms/sec по SMPP

23. Результаты тестирования
Single instance:
● 3500 sms/sec по SMPP
● 1000 sms/sec по PUSH

25. Результаты тестирования
Single instance:
● 3500 sms/sec по SMPP
● 1000 sms/sec по PUSH

27. Тестируем компоненты

28. Тестируем компоненты
● SMPP (5000/sec)

29. Тестируем компоненты
● SMPP (5000/sec)
● БД

30. Тестируем компоненты
● SMPP (5000/sec)
● БД
– Очередь (3500/sec)

31. Тестируем компоненты
● SMPP (5000/sec)
● БД
– Очередь (3500/sec)
– Архив (14000/sec)

32. Тестируем компоненты
● SMPP (5000/sec)
● БД
– Очередь (3500/sec)
– Архив (14000/sec)
● Mobile API (4000/sec)

33. Тестируем компоненты
● SMPP (5000/sec)
● БД
– Очередь (3500/sec)
– Архив (14000/sec)
● Mobile API (4000/sec)
● PUSH (1000/sec)

35. Идеи

36. Идеи
● Tuning (достигли 15000/sec в архиве и 4000 в
очереди)

37. Идеи
● Tuning (достигли 15000/sec в архиве и 4000 в
очереди)
● ENGINE=memory

38. Идеи
● Tuning (достигли 15000/sec в архиве и 4000 в
очереди)
● ENGINE=memory
● Master-Master

39. Идеи
● Tuning (достигли 15000/sec в архиве и 4000 в
очереди)
● ENGINE=memory
● Master-Master
● TokuDB

40. Идеи
● Tuning (достигли 15000/sec в архиве и 4000 в
очереди)
● ENGINE=memory
● Master-Master
● TokuDB
● Перенос в redis

41. Идеи
● Tuning (достигли 15000/sec в архиве и 4000 в
очереди)
● ENGINE=memory
● Master-Master
● TokuDB
● Перенос в redis
Шардинг?!

42. Шардинг очереди
● Ключ
– Равномерность распределения данных и
обращений к шардам

43. Шардинг очереди
● Ключ
– Равномерность распределения данных и
обращений к шардам
– Участвует во всех нужных выборках

44. Идеи
● Разделить APNS, MPNS, GCM

45. Идеи
● Разделить APNS, MPNS, GCM
● Шардим по номеру телефона

46. Идеи
● Разделить APNS, MPNS, GCM
● Шардим по номеру телефона
Грабли
● Номер телефона не присутствует в вызовах API

47. Идеи
● Разделить APNS, MPNS, GCM
● Шардим по номеру телефона
Грабли
● Номер телефона не присутствует в вызовах API
● Выборки ЛК требуют обращения ко всем
шардам

48. Идеи
● Разделить APNS, MPNS, GCM
● Шардим по номеру телефона
Грабли
● Номер телефона не присутствует в вызовах API
● Выборки ЛК требуют обращения ко всем
шардам
Бонус
● По API проблема решена

49. PUSH
Технический долг догоняет (

50. PUSH
Технический долг догоняет (
Идеи
● Добавить воркеров

51. PUSH
Технический долг догоняет (
Идеи
● Добавить воркеров
● Разделение APNS/GCM/MPNS

52. PUSH
Технический долг догоняет (
Идеи
● Добавить воркеров
● Разделение APNS/GCM/MPNS
● Python 3.5 async/await

53. Итоговый конфиг
● Архивная БД + ЛК
● Процессинг (x4, 4000/sec каждый)
– Очередь
– SMPP
– API
– PUSH
16000+/сек по результатам тестирования

55. 4000x4 не всегда 16000

56. Выводы
● Планируйте архитектуру, потом оптимизируйте
код

57. Выводы
● Планируйте архитектуру, потом оптимизируйте
код
● Контролируйте технический долг

58. Выводы
● Планируйте архитектуру, потом оптимизируйте
код
● Контролируйте технический долг
● Тестируйте, чтобы знать свои пределы

59. Выводы
● Планируйте архитектуру, потом оптимизируйте
код
● Контролируйте технический долг
● Тестируйте, чтобы знать свои пределы
● Масштабирование всегда ступенчатое

60. Выводы
● Планируйте архитектуру, потом оптимизируйте
код
● Контролируйте технический долг
● Тестируйте, чтобы знать свои пределы
● Масштабирование всегда ступенчатое
● Простые варианты вперед

61. Выводы
● Планируйте архитектуру, потом оптимизируйте
код
● Контролируйте технический долг
● Тестируйте, чтобы знать свои пределы
● Масштабирование всегда ступенчатое
● Простые варианты вперед
● Хайлоад — быстро и несложно. Но не всегда)

62. Вопросы?
Юрий Колесов
http://security-gu.ru
security-guru@mail.ru
+7 (926) 55-99-824
https://facebook.com/yuri.v.kolesov