Лимитируй это

Однажды я провел день на колоссальном девятичасовом созвоне в попытке понять «а почему продакшн не работает?» и выводы, которые я вынес из этого дебага, я хочу принести вам в этом докладе.

Что же у нас за система? Мы делаем чат, это современная event-driven архитектура, все наши бэкенды — это rest-like части на fastapi и основная часть системы базируется на kafka продюсерах/консьюмерах. Весь наш код асинхронный, а баз две штуки — postgres и keydb.

Моя история будет о том:
— как уронить keydb;
— как kafka может уничтожить ваше асинхронное приложение;
— как неправильно планировать ресурсы в кубер кластере;
— как можно покалечиться всей системой, если у тебя кривая библиотека для работы с БД;
— какие мониторинги делать обязательно;
— что такое плохой healtcheck;
— почему документация может быть очень коварной.

Доклад стыдный, но, надеюсь, полезный!

Transcript

1. / Денис Аникин https://xfenix.ru Лимитируй это
2. Денис Аникин 2 Что я делаю — работаю в Райфе — teamlead в 3 командах — community lead в Python Community — fullstack: typescript, python, devops — шучу шутки со средней оценкой 4 балла https://xfenix.ru
3. Денис Аникин 3 Что я делаю — работаю в Райфе — teamlead в 3 командах — community lead в Python Community — fullstack: typescript, python, devops — шучу шутки со средней оценкой 4 балла ИЗ 100 https://xfenix.ru
5. Пару слов о нашей системе
6. Что у нас за система? 6 — Распределенная — Чат — Две основных базы данных: KeyDB (redis) & PostgreSQL — Наш MQ это Kafka — Пишем на FastAPI, Starlette — НЕ ХАЙЛОАД (!!!11) — Ну конечно же любимые и ненавистные всем микросервисы (настоящие)
7. Пару слов о «НЕ ХАЙЛОАД» 7 — Порядок: сотни RPS от пользователей — Система постоянной доступности (непрерывный режим работы) — «Последняя» линия, к нам приходят когда уже что-то сломалось
8. И вот однажды мы упали 8
10. Моя история — о том как это вышло 10
12. Ещё пару слов обо мне 12 — У меня не очень много опыта с распределенными и особенно event driven системами — Я не идеально разбираюсь в мониторинге
13. 4 золотых сигнала Latency, traffic, saturation, errors
14. Ещё пару слов обо мне 14 — У меня не очень много опыта с распределенными и особенно event driven системами — Я не идеально разбираюсь в мониторинге — Kubernetes на момент разработки системы был для меня новой технологией
15. Все совпадения с реальными людьми — выдуманы 15
16. Если вы беспокоетесь, что чего-то не знаете, посмотрите на меня и вам станет легче 16
17. Какой бывает event driven
18. По полям, по полям архитектор едет к нам! Так как в докладе будет много хороших решений и классных практик…
19. Итак, июнь 2022, пятница 19
21. 14 часов mob-debug в zoom
22. Наша система не упала, а просто перестала работать 22
24. Если вы работаете с монолитом, то знакомо:
25. Микросервисы (вы ждали этой картинки):
26. Но на самом деле:
27. НАКОНЕЦ о наших делах 27
28. KeyDB (redis) мёртв 28
30. Хвала failover! (заметили не сразу) 30
32. Стоп. А что происходит? 32
33. Мы бъемся головой в лимит соединений! 33
34. Открытие: когда KeyDB упирается в соединения, ну… он падает! 34
35. Давайте вынесем на ретро 35
36. Ошибка номер 1 — мы не мониторим соединения с KeyDB 36
37. KeyDB 37 И мониторинг — Обычно все мониторят память — Количество операций — CPU
38. Сколько соединений по-умолчанию у KeyDB? 38 Давайте проголосуем — 1 000 — 10 000 — 30 000 — не ограничено ✅
39. Но зачем столько соединений-то? 39 Ну правда! — Корутины! — Распределенная система — Куча реплик — Несколько зон доступности — И секретный ингредиент!
40. Ошибка номер 2 — мы не мониторим topic lag 40
42. Что такое topic lag и как он выглядит
43. Это был (почти) «добрый» topic lag 43
44. 44 Злой выглядел бы вот как-то так:
45. Страшная ситуация: «перезагрузка не помогает» 45
47. Ошибка номер 3 — плохо настроенный pooling & шутки от aioredis 47
48. 48 4 вида сетапов redis/keydb
49. Немного о пулинге 49 Пулинг — прекрасно, но если вы его конфигурируете правильно — В документации Sentinel клиента ни слова о пулинге — Но самый сок нас ожидает под капотом…
50. 50 Цитата из redis-py (aioredis туда вмержен) def __init__( … max_connections: Optional[int] = None, … ): max_connections = max_connections or 2 ** 31 # ß Добрый вечер! С sentinel сработает вот так
51. 51 Вот вам и Redis Cluster class redis.asyncio.cluster.RedisCluster(host=None, port=6379, startup_nodes=None, require_full_coverage=True, read_from_replicas=False, reinitialize_steps=5, cluster_error_retry_attempts=3, connection_error_retry_attempts=3, max_connections=2147483648, # ß Привет! Как дела? Спишь? Наберу? db=0, path=None, credential_provider=None, username=None, password=None, client_name=None, encoding='utf-8', encoding_errors='strict', decode_responses=False, health_check_interval=0, socket_connect_timeout=None, socket_keepalive=False, socket_keepalive_options=None, socket_timeout=None, retry=None, retry_on_error=None, ssl=False, ssl_ca_certs=None, ssl_ca_data=None, ssl_cert_reqs='required', ssl_certfile=None, ssl_check_hostname=False, ssl_keyfile=None, address_remap=None)
52. Для high availability (HA), cluster в документации примеры указаны без max_connections! А умолчание вы видели… 52
53. Я пытаюсь сделать устойчивый кластер redis Документация к redis-py 2 ** 31
54. Ошибка номер 4 — мы очень полюбили concurrency с помощью create_task 54
55. Тут всё довольно скромно 55 — Наш consumer потребляет сообщение — Создает обработчик с помощью create_task — Идёт дальше
56. 56 Если вспомнить topic lag…
57. Пулинг Очень много корутин Один знаменитый программист сказал: it’s get crashing, when I pull (pull из pool’а соединений имеется ввиду)
59. Ошибка номер 5 — requests & limits 59
61. Давайте глянем как оно там без них 61 — По началу неплохо — Но когда что-то пойдет не так… — Пожалуйста, проставляйте реквесты и лимиты!!1111
63. Ошибка номер 6 — мы очень очень любили resilience, а особенно реконнекты 63
64. Прежде чем говорить, предыдущие пункты 64 — Что-то замедляет обработку топика (возможно, краш) — Мы не видим топик лаг, ребутаемся — Корутины плодятся без всяких на то ограничений — Коннекшены «хватаются» из пула огромными пачками — Мы и об этом не знаем — KeyDB умирает, уничтоженный в щепки — В кластере плохеет нодам, ложатся соседние сервисы (не все!)
65. Цитируя известного художника: «вечеринка движется к каннибализму» 65
67. И добиваем лоу-киком 67 Чтобы KeyDB не имел шанса подняться и всем было веселее, мы сверху полируем реконнектами… …в каждой корутине
68. Ты обронил, держи продакшн!
69. Мои архитектурные навыки Моё умение программировать
70. Крепкого здоровья погибшим, остальным либа backoff 70
71. Ошибка номер 7 — 71
72. Я — терминатор от мира архитектуры
73. Ошибка номер 7 — великолепные healtcheck’и 73
74. Как не стоить делать хелсчеки консьюмеров 74 — Берем асинхронный консьюмер — Рядом в треде запускаем асинхронный фреймворк с одной ручкой — Вешаем пробу на эту ручку
75. 75 Что же может пойти не так?
76. 76 Что же может пойти не так? Мой продакшн
77. 77 Что же может пойти не так? Я, пытающийся понять почему topiclag 10055000, консьюмеры мертвее моей архитектурной карьеры, а хелсчеки говорят Мой продакшн
78. Ошибка номер 8 — dead letter queue 78
80. Есть такая классическая проблема в EDA 80 Довольно классическая — К нам приходит сообщение в консьюмер — Мы обрабатываем это сообщение, но у нас не выходит — Что же делать?
81. 81 Делаем DLQ (dead letter queue) УПС Попыток 10 на сообщение
82. Как вы догадались: мы поддавали жару ещё и здесь 82
83. Подведем итог: у нашей системы не было и шанса! 83
84. Это явно я Ф — надежность
85. Как же мы всё это вылечили?
87. / Денис Аникин https://xfenix.ru https://github.com/xfenix/ Спасибо!
89. Проставили requests & limits 89
90. А как это делать когда ничего непонятно? 90 Есть пару простых идей — Проставьте минимальное значение для requests, ниже которого сервис не будет работать совсем — Проставьте limits в 2-3 раза выше (в зависимости от ваших возможностей) — Дальше двигайтесь итерационно, либо с помощью нагрузочного тестирования, либо докидывая limits в процессе жизни (что более нервно) — Не забывайте мониторить throttling!
92. Что будет, если неправильно сконфигурить 92 Ну кроме очевидного «пока, мой любимый кластер, мне так нравилось спать в 3 ночи» — Наш добрый дружок ООМ — CPU-«голодание» — «Выселение» подов — Трата лишних ресурсов
93. Сделали мониторинг topic lag и количества консьюмеров 93
95. Что можно было бы мониторить ещё 95 Но что мы пока не мониторим — Количество sent запросов — Количество received запросов — Время/продолжительность отправки — Время/продолжительность потребления — RPS
96. Сделали мониторинг количества соединений KeyDB 96
97. Проставили max_connections для пулинга! (у Sentinel тоже можно) 97
98. Самое интересное было с concurrency! 98
99. КО Порождаем 100_000 корутин Берем здесь соединение из пулинга УПС В чём сложность
100. Когда мы поняли, что дело в нём 100 А понять было ОЧЕНЬ непросто на самом деле (ведь корутины мы не мониторим) — Долго обсуждал — И в конце я вспомнил, что в asyncio есть Semaphore!
101. … Какой-то шаренный ресурс (типа коннекта к базе/базы) Корутины Семафор со значением 3 Корутины
102. Пару мыслей по корутинам 102 — Concurrency — штука коварная, имеет смысл ограничивать количество create_task — Semaphore и другие примитивы синхронизации вам бро! — Возможно, вам может быть полезен aiomonitor!
103. Enterprise архитектор Solution архитектор Я, делающий вот это всё
104. Моя любимая панацея! 104 — Можно просто раз в сутки ребутать все контейнеры — Сделать очень просто: берёте gitlab scheduled ci и делаете с помощью kubectl rollout и/или helm — Не убегайте из зала с воплями ужаса, это правда экономит кучу нервных клеток — Не будем забывать о chaos engineering
105. Сделал ребуты и делаю вид, что это chaos engineering
106. Эксперты, слушающие доклад
107. Пару слов о том, что не полечили 107 — retry. Тут стоило бы затащить circuit breaker! — healtcheck. В интернете ноль адекватных советов на эту тему, кстати — Не продумали стратегию backpressure когда retry не справляется (eviction/drop? delay? buffer?) — Пока не троттлили DLQ
108. Самое главное, что я хочу сказать: «лимитируй это»… 108
109. …пожалуйста! 109
110. …не будь как я 110
111. Как тебя архитектурить? Не надо меня архитектурить Откуда ты это сказал?
113. Веселый был бы доклад на хайлоад…
114. Веселый был бы доклад на хайлоад… если бы хайлоад писали на питоне
115. Некоторые ссылки 115 Redis py коммиты (но это не все) — https://github.com/redis/redis- py/blob/2732a8553e58d9e77f16566b9132fc7205614a53/redis/asyncio/connection.py#L976 — https://github.com/redis/redis- py/blob/2732a8553e58d9e77f16566b9132fc7205614a53/redis/asyncio/cluster.py#L232 — https://github.com/redis/redis- py/blob/2732a8553e58d9e77f16566b9132fc7205614a53/redis/connection.py#L952
116. Денис Аникин https://xfenix.ru https://github.com/xfenix/ Спасибо!