[Balun.Courses] Паттерны отказоустойчивости в микросервисах на Go [Даниил Булыкин]

[Robot]

Ссылка на картинку

Глядя на архитектуру, возникают вопросы:

1. Упал один микросервис, а за ним вся система. Как разорвать цепочку
2. БД легла от всплеска запросов. Как правильно использовать кэш, чтобы оптимизировать хранение данных
3. В момент дежурства упала система. Как найти быстро найти причину, и какие действия предпринять для ее устранения без помощи старших коллег
4. Как правильно кэшировать данные, чтобы не получить тонны устаревшей информации при инвалидации кеша или падении Redis
5. Как написать повторную обработку сообщений, которая гарантированно не сломает систему
6. Как правильно использовать retry, чтобы он за минуты при нагрузке не положил прод

Чтобы решить задачу: Вместе c Senior из Ozon Tech поочередно рассмотришь все проблемы в коде, к каждой разберешь теорию и сразу напишешь best practice решение, как в BigTech

6 недель систематизированно изучаем применение паттернов отказоустойчивости. Попадешь в смоделированную ecom-компанию: микросервисная архитектура с десятками типичных проблем в коде. Поочередно разберешь каждую, получишь необходимую теорию и уже со второго занятия начнешь писать код

В результате освоишь hard’ы, без которых сложно вырасти до Senior’а:

1. Научишься изолировать упавший сервис с помощью Circuit Breaker, а также писать Graceful Degradation и Fallback, чтобы один баг не ронял всю систему
2. Сможешь контролировать перегруз БД через Rate Limiter, «склейку» дублирующихся запросов через Single Flight и балансировку Nginx
3. Научишь систему заранее оповещать о предстоящих инцидентах, а если он уже случился — сможешь быстро их находить и решать
4. Реализуешь многоуровневое кеширование с LRU/LFU-вытеснением и настроишь Redis так, чтобы данные в кеше были всегда актуальны
5. Научишься внедрять идемпотентность и писать повторную обработку сообщений с outbox-паттерном и ручным управлением offset’ами в Kafka
6. Сможешь писать Retry, который не создает «шторм» запросов, и делает систему стабильной под нагрузкой

Курс подойдет для junior/middle Golang-разработчиков, которые хотят вырасти в грейде.
Программа состоит на 80% из практики, поэтому нужно знать язык и иметь базовые навыки работы с Kafka и Redis.

Программа:

• Неделя 1. Ключевые проблемы и принципы отказоустойчивости
• Неделя 2. Обработка ошибок и временные сбои
• Неделя 3. Контроль нагрузки и балансировка
• Неделя 4. Асинхронная коммуникация и очереди
• Неделя 5. Эффекты слоя кеширования при построении высокодоступных систем
• Неделя 6. Обнаружение отказа и методы реагирования

Программа подробнее:

Неделя 1. Ключевые проблемы и принципы отказоустойчивости

Особенности распределенных информационных систем:

• Отказоустойчивость & Надежность
• Каскадные сбои
• CAP-теорема (Consistency, Availability, Partition Tolerance)
• Классификация проблем и типы частичных отказов

Метрики надежности с примерами:

• SLA (Service Level Agreement)
• SLO (Service Level Objective)
• SLI (Service Level Indicator)
• Что такое «99,9%» доступности и для чего это нужно?

Влияние отказов на целостность данных:

• Понятие целостности и угрозы ее потери
• Идемпотентность
• Split-brain & Failover
• Кворумная запись/чтение
• Разберем:
• что такое WAL и зачем он нужен Postgres
• почему важен replica factor > 1 в Kafka
• Как ЮKassa обрабатывает дубликаты платежей

BigTech-инциденты и как их можно было избежать:

• GitHub — как все упало на сутки
• AWS us-east-1 — как пострадали сотни онлайн-сервисов по всему миру
• Facebook, Instagram, WhatsApp — как отказ системы обрушил цену акции и привел к потере $6 млрд
• GitLab — как легла БД и удалился пользовательский код
• Случаи из личной практики в production

Результат недели:

• понимаешь суть и последствия отказоустойчивости, как свойства системы
• можешь выделить 2 из 3 свойств CAP-теоремы для выбранной системы
• магические девятки в метриках надежности теперь прозрачны и понятны

Неделя 2. Обработка ошибок и временные сбои

Функционал работает идеально, и вроде бы всё хорошо. Но что происходит, когда база данных на секунду «ложится»? Или сторонний API начинает отвечать с задержкой в 30 секунд? А если сеть между микросервисами ненадолго пропадает?
В реальном мире такие инциденты неизбежны. И правильная реакция на них — барьер между грейдом middle и senior

Повторная попытка:

• умный retry
• грамотный выбор backoff + jitter
• idempotent requests
• hedging запросов

Контроль выполнения:

• timeout, когда дольше уже нельзя
• установка deadline
• cancel propagation при прерывании пути запроса

Защита системы от каскадных сбоев:

• circuit breaker для спасения от отказов частей системы
• graceful degradation, когда отказ все же произошел
• fallback по возможности

На практике:

• внедрим circuit breaker между сервисами
• обеспечим graceful degradation
• применим fallback
• выставим timeout'ы на синхронные вызовы
• реализуем idempotent retry

Домашняя работа:

• Ты на дежурстве, алерты стучатся в дверь, а пользователи недовольны работой системы. Задача — самостоятельно найти инцидент, выбрать нужный паттерн и реализовать его

Результат:

• умеешь справляться с ошибками и временными сбоями
• глубоко понимаешь суть каждого паттерна и сценария его применения
• умеешь применять это на практике в реальном проекте

Неделя 3. Контроль нагрузки и балансировка

Что делать, если внезапный всплеск трафика, медленный запрос к базе или сбой в соседнем микросервисе роняет прод? В этом модуле учимся делать сервисы стабильными при любой нагрузке

Изоляция ресурсов:

• планирование ресурсов
• подход bulkhead
• процессная изоляция
• физическая изоляция

Контроль нагрузки:

• глубокое погружение в rate limiting
• single flight как фильтр
• backpressure / load shedding

Распределение нагрузки:

• клиентская / серверная
• алгоритмы балансировки
• стратегии деплоя и откат
• upstream
• active / passive health checks
• nginx

На практике:

• настроим балансировку на nginx
• посмотрим на различные алгоритмы балансировки в действии
• применим rate limiter и изучим его вдоль и поперек
• разберем подкапотную магию single flight и применим его как щит

Домашнее задание:

• QA во время стресс-тестов выявил деградацию системы. Найди инцидент, выбери нужный паттерн и реализуй его

Результат:

• умеешь защищать свои и чужие сервисы в условиях непредусмотренных нагрузок
• понимаешь, как все работает изнутри, и умеешь выделять общие паттерны применения подходов в реальных системах
• разбираешься в подходах к распределению нагрузки

Неделя 4. Асинхронная коммуникация и очереди

Ты уверен(-а), что твои сообщения доходят? Что заказ не создастся дважды, а платеж не обработается несколько раз?
В этом модуле учимся строить асинхронный отказоустойчивый конвеер — гарантированно доставлять сообщения, легко отрабатывать сбои и бесшовно масштабироваться под нагрузку


Очереди и брокеры сообщений:

• особенности работы с технологиями (Rabbit, Kafka)
• буфферизация и выравнивание нагрузки
• гарантии доставки сообщений
• масштабирование при нагрузке
• распределенные транзакции
• SAGA vs 2PC

Грамотная запись:

• подтверждение от брокера
• умные retry
• идемпотентность
• outbox как лекарство от бед

Грамотное чтение:

• offsets и восстановление
• manual vs auto commit
• как обработать дубликаты, будто их нет
• inbox для чайников
• dead letter queue

На практике:

• как сообщения теряют события без нашего ведома, и как это исправить
• применим outbox pattern
• настроим механизм идемпотентности
• научимся писать DLQ (Dead Letter Queue)
• разберем подходы к реагированию на нештатные ситуации

Результат:

• понимаешь, на что обращать внимание при проектировании асинхронного взаимодействия
• не теряешь сообщения и умеешь справляться с дубликатами
• умеешь писать паттернами inbox/outbox
• умеешь применять DLQ и работать с ним
• знаешь критически важные метрики и умеешь за нами наблюдать

Неделя 5. Эффекты слоя кеширования при построении высокодоступных систем

Добавили кэш, чтобы ускорить систему, а получили лавину запросов к базе в момент его протухания? Пользователи видят устаревшие данные и жалуются? В этом модуле изучаем best practices по использованию кеша

Stale Data (протухшие данные):

• время жизни объектов (ttl)
• активная инвалидация
• событийная инвалидация

Data consistency (согласованность данных):

• write-thorugh
• управление ttl
• блокировки и версионирование
• Compare and swap (check and set)
• репликация в зоопарке инструментов кеширования

Thundering Herd (грозовая стая):

• signle flight
• фоновая актуализация
• soft ttl и мертвые данные

Cache avalanche (лавина кеша):

• random ttl & jitter
• многоуровневое кеширование
• проактивное обновление
• лимитирование ресурсов на источник данных

Стратегии вытеснения:

• LRU / LFU / MRU / FIFO / Random

На практике:

• реализуем кеширование с грамотной стратегией вытеснения
• разберем все проблемы с внедрением кеш-слоя и изучим подходы к их решению
• посмотрим на конфигурацию redis и выберем самые оптимальные параметры
• разберем best practices по эксплуатации кеша
• изучим перечень метрик для мониторинга

Результат:

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

Неделя 6. Обнаружение отказа и методы реагирования

Тушишь один инцидент, а на смену приходит следующий. Пользователи видят ошибки раньше, чем срабатывают алерты. Классика

В этом модуле научим систему предупреждать об отказах до удара по пользователю. Узнаешь, как быстро найти и локализовать сбой в синхронных вызовах или в лаге асинхронных очередей, и что делать, когда автоматика уже не справляется

Инциденты для всех:

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

Особенности синхронного взаимодействия:

• следим за response time & response codes
• контролируем утилизацию ресурсов
• не забываем про наблюдаемость соседей и внешних инструментов
• важность подробного логгирования
• алерты и их влияние на скорость устранения инцидентов

Асинхронное взаимодействие:

• метрики обработки топиков (скорость, время, имеющийся лаг на партициях)
• наблюдаемость состояния consumer-групп
• методы борьбы с лагом в неожиданные моменты
• алерты, как средство оперативного реагирования на проблемы с топиками
• ручные манипуляции с оффсетами и консьюмер группами.

Результат:

• умеешь находить инциденты и отказы и бороться с ними, как это делают в BigTech
• знаешь, на что обращать внимание в первую очередь при возникновении нештатной ситуации
• знаешь, как локализовать отказ при синхронном и асинхронном взаимодействии
• умеешь устранять последствия, инцидент все же произошел

Преподает Даниил Булыкин - senior в ozon tech.

Читать далее...

Показать больше