РИТ++ 2017, HighLoad Junior Зал Конгресс-холл, 5 июня, 10:00 Тезисы: http://junior.highload.ru/2017/abstracts/2577.html Микросервисы - это круто, модно и интересно. Переход на их использование принесет команде заметные преимущества. Но сервис-ориентированная архитектура (SOA) не лишена недостатков. Один их них - это то, что, заменяя простой вызов функции на RPC, мы в неявном виде вводим в уравнение, отвечающее за стабильность системы, целую плеяду новых неизвестных. Например, простейший HTTP-запрос за время своей жизни проходит через множество всевозможных буферов, очередей и алгоритмов на своем пути от клиента к серверу и обратно. Совокупное поведение этих составляющих трудно предсказать, понять и правильно интерпретировать. И особенно трудно это сделать в нестандартных ситуациях. В своем докладе я хочу поделиться опытом решения проблем, с которыми я столкнулся за время работы в Booking.com. Я расскажу, как небольшой тюнинг сервера и клиента существенно влиял на конечную стабильность системы.

1. SOA:
послать запрос на сервер?
что может быть проще?!
Иван Круглов - Booking.com

3. плюсы
минусы
снижение гибкости
сложность внесения
атомарных изменений
сложная отладка
сложная инфраструктура
RPC
слабая связанность
независимый деплой
независимая разработка
быстрее onboarding
быстрее разработка
Микросервисная архитектура: проблемы и решения
Сергей Орлов
Преимущества и недостатки
микросервисной архитектуры в HeadHunter
Антон Иванов

4. Booking.com

5. application
transport transport
provider
client library server
service consumer service provider

6. История одной проблемы

7. Архитектура поиска в Booking.com
https://goo.gl/gW7Jd6
https://goo.gl/BQFlJG
AVinv материализация AVAV
MR
веб-сервер
MR
MR

8. master
worker worker worker worker
coordinate/reduce
map
поисковый запрос

9. client 2
worker 1 worker 2 worker 3 worker 4 worker 5
client 1

10. • в определенный момент
запускалась цепная реакция
• все машины покидали кластер
в течение 5-10 секунд
• кластер впадал в deadlock
• приходилось рестартовать все
машины
• не могли переключить трафик
на другой кластер, боясь
положить его

11. Демо

12. Setup
Server:
• nginx
• 24 workers
• backlog = 2048
• uwsgi
• 96 workers
• listen = 2048
• mixed CPU/IO bound
workload
Client:
• HTTP
• timeout 500 ms
• many small (< 1KB) / medium
(< 100 KB) requests

13. Сценарий
0
1000
2000
3000
4000
5000
6000
7000
8000
1 5 9 13 17 21 25 29 33 37 41 45
количество запросов
секунда
1 2 3

14. гистограмма результатов
запросов за последние 10 секунд
* – успешный запрос(ы)
E – ошибочный запрос(ы)
временные интервалы от 0 до ~1 сек
логарифмическая шкала
текущий/требуемый RPS
https://github.com/ikruglov/slapper

16. scenario-queues-2048-cut.gif

17. 0
1000
2000
3000
4000
5000
6000
7000
8000
0
100
200
300
400
500
600
700
время ответа, мсколичество ответов
p99
успешные запросы
ошибочные запросы

18. Что происходит?
www
www
www
www
w
w
w
w
uwsgi
www
www
www
nginx
tnginx_worker
tuwsgi_worker
ttotal = tnginx_worker + tuwsgi_worker

19. scenario-queues-2048-part-1.gif
96 uwsgi workers

20. scenario-queues-2048-part-2.gif

21. Что происходит?
www
www
www
www
w
w
w
w
uwsgi
www
www
www
nginx
tnginx_worker
tuwsgi_worker
TCP socket unix socket
ttcp_socket
tunix_socket
ttotal = ttcp_socket + tnginx_worker + tunix_socket + tuwsgi_worker

22. Что происходит?
www
www
www
www
w
w
w
w
uwsgi
www
www
www
nginx
TCP socket unix socket
ttotal = ttcp_socket + tnginx_worker + tunix_socket + tuwsgi_worker
timeout
tnginx_worker
tuwsgi_worker
ttcp_socket
tunix_socket
100% CPU на сервере

23. scenario-queues-2048-part-3.gif

24. Что происходит?
www
www
www
www
w
w
w
w
uwsgi
www
www
www
nginx
TCP socket unix socket
502 Bad Gateway
ttotal = ttcp_socket + tnginx_worker + tunix_socket + tuwsgi_worker
timeout

25. client 2
worker 1 worker 2 worker 3 worker 4 worker 5
timeout
slowslow
timeout

26. Что происходит?
www
www
www
www
w
w
w
w
uwsgi
www
www
www
nginx
TCP socket unix socket
попробуем
сделать
меньше?!
listen=96

28. scenario-queues-96-3-cut.gif

29. 0
1000
2000
3000
4000
5000
6000
7000
8000
0
10
20
30
40
50
60
70
80
90
100
время ответа, мсколичество ответов
p99
успешные запросы
ошибочные запросы
стабилизация стабилизация
сохранение
QoS
сохранение
QoS
0
10
20
30
40
50
60
70
80
90
100
p99 backlog=192
p99 backlog=96
p99 backlog=20
мс

30. Решение проблемы
• Краткосрочное:
• снижение длины очереди
• «разрыв» цикла
• дешевый повтор
• Долгосрочное:
• переход на двухступенчатую архитектуру

31. Конец истории

32. transport transport
service consumer service provider
client library
timeouts
server
queue

33. Что делать с быстрыми ошибками?
• при насыщении
• ничего!!
• мягкое деградирование (graceful degradation)
• при кратковременном переполнении очереди
• повтор (retry)

34. transport transport
timeouts queue
retry
service consumer service provider
client library server

35. retry
• бюджет
• идемпотентная операция
• до записи в сокет – OK, после - ?
• GET – OK, POST – not OK
• в реальности - ?
• быстрый повтор неэффективен
• нужен back-off

36. transport transport
timeouts queue
retry
back-off
service consumer service provider
client library server

37. back-off
• вставить паузу между
попытками
• увеличивает шансы на успех
• алгоритмы:
• фиксированный
• экспоненциальный
• важна рандомизация – jitter
interval = 100 ms
randomization factor = 0.5
multiplier = 2
delta = interval * randomization factor
result = interval ± (delta * rand())
interval = interval * multiplier
53 ms
129 ms
555 ms
719 ms
431 ms
644 ms
934 ms
1605 ms
1732 ms
2126 ms
https://github.com/cenkalti/backoff/

38. transport transport
timeouts queue
retry
back-off
timeouts
service consumer service provider
client library server

39. Согласованность таймаутов
• отмена запроса (request cancellation)
• X-Booking-Timeout-Ms
• таймаут сервера = таймаут клиента + дельта

40. transport transport
timeouts queue
retry
back-off
timeouts
chaos monkey
service consumer service provider
client library server
chaos monkey

41. Виды Chaos Monkey
• проверить HTTP клиент
• 50x-ый ответ
• работает в production
• мягкое деградирование
приложения
• 400-ый ответ
• работает только внутри компании
• есть список критических запросов
• готовность к задержкам в
репликации
• 200-ый ответ c логической ошибкой
• работает в production

42. transport transport
load balancingdiscovery
chaos monkeytimeouts
circuit breakerretry
…back-off
queue timeouts
chaos monkeyprioritization
throttling
service consumer service provider
client library server
…

43. Заключение
• Предсказуемая отправка HTTP запроса – это сложно!
• тестируйте и проверяйте!
• Посмотрите:
• frameworks - grpc, finagle, …
• proxy - linkerd, envoy, …
• Поэкспериментируйте с очередями:
• длина очереди влияет на время ответа
• контроль над клиентом
• nginx + unix socket

44. Спасибо!
Иван Круглов
ivan.kruglov@booking.com

45. Ссылки
• https://github.com/ikruglov/slapper
• SRE book
• resiliency patterns
• https://developers.redhat.com/blog/2017/05/16/it-takes-more-than-a-circuit-breaker-to-create-a-resilient-application/
• https://www.youtube.com/watch?v=dlixGkelP9U
• https://www.youtube.com/watch?v=modXC5IWTJI
• circuit breaker
• SRE book Chapter 21 - Handling Overload
• https://docs.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker
• backoff
• https://www.awsarchitectureblog.com/2015/03/backoff.html
• tcp_abort_on_overflow
• http://veithen.github.io/2014/01/01/how-tcp-backlog-works-in-linux.html
• https://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/tcpvariables.html
• https://github.com/ton31337/tools/wiki/Is-net.ipv4.tcp_abort_on_overflow-good-or-not%3F