«Высоконагруженные приложения» Мартина Клеппманна — книга для меня особенная. Именно она поменяла мой взгляд на системы и их проектирование. Книга представляет собой довольно глубокое погружение в то, как устроены системы которые работают под реальной нагрузкой. Клеппманн объясняет не только что делать, но и почему одни решения работают а другие разваливаются при масштабировании.
Книгу называют «Кабанчиком» за, уже легендарную, обложку с животным.
Эта статья не пересказ. Это попытка посмотреть на три ключевых принципа из книги через другую оптику: опыт системного анализа и проектирования реальных систем в бигтехах, стартапах и 111 километров по суздальским полям в июльскую жару.
Синтез бега и системного анализа
Меня зовут Михаил, я ведущий системный аналитик в ВБ Тех. За плечами банковские сервисы, крупные фичи, стартапы, сейчас крупнейший маркетплейс СНГ.
Параллельно я ультрамарафонец: 111 километров по суздальским полям в июльскую жару, ультра за полярным кругом, победа на международном 50-километровом забеге.
Это не случайное совпадение интересов. Чем дольше я занимаюсь обоими, тем яснее вижу: проектирование отказоустойчивой системы и подготовка к ультрамарафону — это один и тот же процесс. Оба про поведение под нагрузкой, деградацию компонентов и восстановление после сбоя.
Пишу про системный анализ, бег и чайные церемонии в Telegram
Тело как высоконагруженная система
Чтобы финишировать в таких условиях, нужно перестать воспринимать себя как человека который просто бежит — и начать относиться к телу как к системе под высокой нагрузкой. У этой системы есть пропускная способность, пороги деградации, критические компоненты и точки отказа. Её нужно мониторить в реальном времени, управлять нагрузкой и знать заранее при каких условиях она начнёт отключать второстепенные процессы.
На 71-м километре это происходит само: организм делает то, что любая грамотно спроектированная система делает под критической нагрузкой — отключает второстепенные процессы и перераспределяет ресурсы в пользу выживания организма. Ты перестаёшь замечать пейзаж, боль в ногах уходит на второй план, мозг работает только с одним вопросом: как добраться до финиша.
В архитектуре это называется graceful degradation — контролируемое снижение функциональности при перегрузке вместо полного отказа. Netflix отключает рекомендации когда система под нагрузкой, но стриминг продолжает работать. Amazon скрывает персонализацию, но товары в корзине остаются доступны.
Любое высоконагруженное приложение строится вокруг трёх принципов.
Надежность
Разговаривая о надежности стоит сразу разделить два понятия которые часто путают.
Сбой (fault) — отклонение одного компонента от нормальных характеристик. База данных отвечает медленнее обычного. Интеграция вернула неожиданную структуру ответа. На суздальской трассе я стабильно спотыкался о корни и камни два‑три раза за забег — на результат это не влияло.
Отказ (failure) — система в целом перестаёт выполнять свои функции. Это то чего мы стараемся не допустить.
Задача системного аналитика или архитектора: проектировать систему так чтобы сбои компонентов не приводили к отказу всей системы. Для этого есть несколько проверенных практик.
Circuit Breaker. Если downstream‑сервис начинает отвечать с ошибками или таймаутами, circuit breaker размыкает цепь и перестаёт слать запросы туда — давая системе время восстановиться. Без этого паттерна один упавший сервис тянет за собой всю цепочку.
Retry с экспоненциальным backoff. Повторный запрос при ошибке — базовая практика. Но без ограничений retry превращается в DDoS на и без того перегруженный сервис. Экспоненциальный backoff с jitter решает это: каждая следующая попытка ждёт дольше, паузы рандомизированы чтобы клиенты не синхронизировались.
Chaos Engineering. Netflix придумали Chaos Monkey — инструмент который случайным образом отключает сервисы в продакшене. Звучит безумно, но логика железная: лучше найти слабые места в контролируемых условиях чем узнать о них от пользователей в пиковый час. Это как тренироваться в жару в плотной одежде — организм адаптируется к стрессу заранее.
Мониторинг и алертинг. Система должна уметь говорить о своём состоянии до того как проблема стала критической. Здесь важно не путать метрики: среднее время отклика — плохой индикатор. Один запрос за 10 секунд среди тысячи быстрых улучшает среднее, но реальный пользователь ждёт 10 секунд.
Важная метрика при проектировании запросов и времени ответа сервиса — процентили. p95 говорит что 95% запросов обрабатываются быстрее порогового значения. p99 показывает опыт самых нагруженных пользователей — как правило самых ценных.
Масштабируемость: чай для одного и для сотни
Выполняя роль мастера чайных церемоний я иногда сталкивался с проблемой: когда гостей мало, ты завариваешь чай сам медленно и с удовольствием, все меняется, когда на церемонию приходит больше человек, чем планировалось.
Как у чайного мастера перед тобой два пути.
Вертикальное масштабирование — ты становишься быстрее. Покупаешь чайник побольше, оттачиваешь движения, разливаешь на десятерых одновременно. В терминах IT инфраструктуры это upgrade сервера: больше CPU, больше RAM, быстрее диск. Просто в реализации, но имеет жёсткий потолок — железо не бесконечно. Один сервер это single point of failure и разбитый чайник.
Горизонтальное масштабирование — ты нанимаешь ещё трёх чайных мастеров. Каждый обслуживает свой круг гостей, нагрузка распределяется, если один заболел — остальные продолжают работать. В архитектуре это добавление новых узлов за балансировщиком нагрузки.
Горизонтальное масштабирование требует stateless‑сервисов: каждый инстанс должен уметь обработать любой запрос не зная о предыдущих. Сессии и состояние выносятся во внешнее хранилище — Redis, базу данных. Netflix, Google и Amazon давно выбрали этот путь и строят системы из сотен независимых сервисов.
Кейс из практики. В банковском сервисе мы столкнулись с классической проблемой: мастер‑система хранила справочные данные и была чувствительна к количеству запросов в секунду. При росте нагрузки она начинала деградировать, что тянуло за собой весь процесс обработки.
Решение — Redis как кэш между нашим сервисом и мастер‑системой. Справочники обновлялись по расписанию и при изменениях, все оперативные запросы шли в кэш. Нагрузка на мастер‑систему упала в 5 раз. Время ответа на чтение справочников сократилось с десятков миллисекунд до единиц.
Главное что нужно продумать при введении кэша: стратегия инвалидации. Когда и как данные в кэше обновляются — это архитектурное решение которое нужно принять до внедрения, а не после.
Поддержка и эксплуатация
IT система, как конечный продукт, почти всегда отличается от плана. Новые требования или доработки — нормальная практика в жизненном цикле разработки продукта. Три практики которые делают эту жизнь управляемой и предсказуемой.
Observability. Три столпа: логи, метрики, распределённый трейсинг. Логи говорят что произошло. Метрики показывают как система себя чувствует прямо сейчас. Трейсинг позволяет пройти путь конкретного запроса через все сервисы и найти где он застрял.
Во время ошибок от сервисов я и тестировщик буквально спасались заветным trace_id, который помогал отследить источник ошибки.
Дневник тренировок и сна работает так‑же: каждая пробежка записана — пульс, темп, самочувствие, рельеф. Через месяц видишь паттерны которые не заметил бы на ощупь.
Документация API. Хлеб системного аналитика. Хорошо спроектированный и задокументированный API решает задачи которые не были заложены при создании MVP — потребители сервиса находят возможности самостоятельно. Плохо задокументированный создаёт зависимость от конкретных людей которые «знают как оно работает»
Согласованность требований. Функциональные требования описывают что система делает. Нефункциональные — как: время отклика, доступность, пропускная способность. Ошибка которую я видел в нескольких проектах: NFR прописываются формально или не прописываются вовсе. При. эксплуатации происходит следующее: что система функционально работает правильно но у пользователя экран фичи прогружается больше 10 секунд или частично.
Синтез двух идей
Ультрамарафон учит одному: система не ломается внезапно. Она деградирует постепенно, отправляя сигналы задолго до отказа. Задача — научиться их читать.
В IT то же самое. Хорошая архитектура не та которая никогда не падает. Это та которая падает предсказуемо, восстанавливается быстро и оставляет достаточно сигналов чтобы понять что пошло не так.
Надёжность, масштабируемость, поддержка — три принципа которые работают одинаково и на суздальской трассе в июльскую жару, и в продакшене в пятницу вечером.
