3.5 Масштабируемость, производительность, устойчивость

Обзор и мотивация

Масштабируемость, производительность и устойчивость три различных качества, и люди часто смешивают их. Производительность это то, как быстро система отвечает и сколько работы делает на единицу ресурса. Масштабируемость это то, как хорошо она сохраняет производительность по мере роста нагрузки. Устойчивость это то, как хорошо она продолжает работать или плавно деградирует, когда что-то отказывает. Система может быть быстрой, но немасштабируемой (отлична при малой нагрузке, рушится при высокой), масштабируемой, но хрупкой (справляется с объёмом, но падает при отказе одного компонента) или устойчивой, но медленной. Большой организации нужны все три, заложенные в проект с самого начала, потому что дооснащение любого из них после запуска дорого и разрушительно.

Для корпоративных и государственных систем последствия ошибки здесь публичны и серьёзны. Подумайте о портале пособий, прогибающемся в первый день новой схемы, налоговой системе, дающей тайм-аут в срок подачи, или платёжной платформе, падающей в пик покупок. Это те сбои, что попадают в заголовки, влекут расследования и подрывают общественное доверие. Эти системы также сталкиваются с сильно пиковой, часто юридически приуроченной нагрузкой (сроки подачи, окна регистрации, дни выплат) и жёсткими обязательствами по доступности и восстановлению. Нужно планировать мощность под предсказуемые всплески, плавно деградировать под непредсказуемые и восстанавливаться в определённых пределах времени и потери данных после бедствия. Это инженерия с измерением публичной подотчётности.

Эта глава охватывает горизонтальное и вертикальное масштабирование, отсутствие состояния и шардирование как факторы масштаба, балансировку нагрузки, автомасштабирование и планирование мощностей, инженерию производительности с явными бюджетами, паттерны устойчивости и хаос-инженерию и многорегиональное аварийное восстановление в рамке RTO, RPO и непрерывности бизнеса. Объединяющий посыл: эти качества продукт намеренного проектирования и непрерывного тестирования, а не надежды.

См. также: главу 3.3 (распределённые системы), главу 9.1 (инженерия надёжности сайтов) и главу 9.2 (наблюдаемость и мониторинг).

Ключевые принципы

Проектируйте под горизонтальное, а не вертикальное масштабирование. У вертикального масштабирования есть потолок и единая точка отказа; горизонтальное это способ достичь большого устойчивого масштаба.
Отсутствие состояния это фактор горизонтального масштаба. Если любой запрос может попасть на любой экземпляр, вы можете свободно добавлять и убирать мощность.
Нельзя улучшить то, чего не измеряешь. Работа над производительностью ведётся профилированием и нагрузочным тестированием относительно явных бюджетов, а не гаданием.
Всё отказывает; проектируйте под это. Предполагайте, что компоненты откажут, и стройте так, чтобы система пережила их отказ.
Плавная деградация побеждает жёсткий отказ. Частично работающая система, сбрасывающая несущественные функции, лучше полного сбоя.
Мощность планируется, всплески поглощаются. Прогнозируйте предсказуемую нагрузку; используйте автомасштабирование и запас для остального.
Цели восстановления это бизнес-решения. RTO и RPO выбирает бизнес относительно стоимости, затем под них проектируют.
Тестируйте устойчивость намеренно. Вы не знаете, что система устойчива, пока не заставили её отказать намеренно.

Компромиссы: плюсы и минусы

Выбор	Плюсы	Минусы
Вертикальное масштабирование	Просто, нет изменений кода, малые начальные усилия	Жёсткий потолок, дорого на верху, единая точка отказа
Горизонтальное масштабирование	Почти неограниченный масштаб, улучшает доступность	Требует отсутствия состояния, балансировки нагрузки, больше эксплуатации
Автомасштабирование	Подгоняет стоимость под спрос, справляется с переменной нагрузкой	Реагирует с запаздыванием; холодные старты; может дребезжать при неверной настройке
Активно-активная многорегиональность	Почти нулевые RTO/RPO, переживает потерю региона	Наибольшая стоимость и сложность, трудная согласованность данных
Аварийное восстановление через резервное копирование	Дешевле и проще всего	Долгое RTO, большее окно потери данных

Основной компромисс это стоимость против гарантии. Каждое приращение запаса масштабируемости, производительности и способности восстановления стоит денег и сложности, а отдача нелинейна. Переход от доступности 99,9% к 99,99% или от часового RTO к секундам может умножить стоимость. Дисциплина в том, чтобы соразмерять каждое вложение с реальной критичностью системы и терпимостью бизнеса к простою и потере данных, а не рефлекторно проектировать всё до высшего яруса. Платёжная система для граждан заслуживает активно-активной избыточности; внутренний инструмент отчётности нет.

Вопросы для обсуждения с командой

Когда случился ваш последний серьёзный инцидент, что из трёх (производительность, масштабируемость, устойчивость) на самом деле отказало и исправили ли вы правильное? Глава намеренно разделяет их: система может быть быстрой, но рушиться под нагрузкой, масштабироваться, но падать при гибели одного компонента, или переживать отказы, оставаясь медленной. Команды часто ставят неверный диагноз, добавляя мощность к проблеме устойчивости или укрепляя систему, которой просто не хватало ресурсов на всплеск. Пройдите по двум последним серьёзным инцидентам и назовите, какое качество сломалось и что ответ реально улучшил. Различие меняет исправление: отсутствие состояния и шардирование для масштаба, избыточность и предохранители для устойчивости, профилирование и бюджеты для производительности. Верная категория это разница между лечением и лечением симптома.
Валят ли регрессии производительности ваш конвейер или доходят до пользователей, прежде чем кто-либо заметит? Бюджет производительности (задержка p95, время до интерактивности страницы, стоимость транзакции) защищает пользователей, только если обеспечивается автоматически, так что изменение, превышающее его, валит сборку, а не выходит. В большой команде со многими участниками задержка прокрадывается через тысячу мелких коммитов, и без шлюза хвост медленно гниёт, пока запуск его не обнажит. Принесите ваши текущие бюджеты и проверьте, подключены ли они к CI и мониторингу и нацелены ли на p95 и p99, а не средние, потому что хвост это то, что пользователи ощущают в масштабе. Там, где бюджета нет, его установка первый шаг. Обеспечение превращает доброе намерение в свойство, переживающее рост команды.
Что под нагрузкой сбрасывается первым и спроектировали ли вы этот порядок или обнаружите его во время сбоя? Плавная деградация и сброс нагрузки означают, что система отказывается от несущественной работы, чтобы защитить ядро, но только если вы заранее решили, что существенно. Для сервиса для граждан это ранжирование часто решение политики: подача налоговой декларации должна пережить, даже если панели статуса и исторические поиски погаснут. Если никто не выбрал, система сбрасывает то, что откажет первым, а это может быть именно то, что пользователям нужно больше всего. Перечислите ваши функции в порядке приоритета и убедитесь, что архитектура может отбросить низкоприоритетные (кэшированные ответы, отключённые рекомендации, поставленную в очередь несрочную работу), не утащив с собой критический путь. Затем проверьте под реальной нагрузкой, потому что непроверенная деградация лишь надежда.
Каковы RTO и RPO вашей самой критичной системы, кто на самом деле выбрал эти числа и когда вы в последний раз доказали, что можете их выполнить? Целевое время восстановления (как долго вы можете быть недоступны) и целевая точка восстановления (сколько данных вы можете позволить себе потерять) это бизнес-решения с прямыми последствиями для стоимости, однако в большой команде их часто придумывает тот, кто написал ранбук, а не те, кто отвечает за сервис. Противоположное тяготение это стоимость против гарантии: сокращение RTO от часа до секунд или RPO от минут до нуля может умножить счёт за инфраструктуру, поэтому правильное число то, за которое бизнес действительно заплатит, а не самое впечатляющее. Принесите документированные цели, дату последнего настоящего теста переключения и измеренные время и потерю данных, которые этот тест дал, потому что непроверенная цель пожелание. В корпоративной и государственной среде эти числа могут задаваться законом, контрактом или SLA, поэтому назовите, кто их утверждает и удовлетворила ли последняя репетиция обязательство или тихо его не выполнила.
Для вашего крупнейшего предсказуемого всплеска вы полагаетесь на автомасштабирование, реагирующее в моменте, или спрогнозировали нагрузку, заранее выделили мощность и нагрузочно протестировали до этой цели? Автомасштабирование реагирует с запаздыванием, а холодные старты добавляют задержку именно когда вы меньше всего можете её позволить, поэтому известное ступенчатое изменение (срок подачи, окно регистрации, распродажа) в точности тот случай, где реактивное масштабирование проваливается, а намеренное планирование мощностей побеждает. Напряжение в стоимости: прогрев мощности под пик означает оплату запаса, простаивающего большую часть года, и соблазн надеяться, что автомасштабирование покроет бесплатно. Принесите прошлогодние пиковые числа, этот год с прогнозом роста и результаты нагрузочного теста, прогнанного до кратного этому прогнозу, а не до сегодняшнего среднего трафика. Для государственного или корпоративного сервиса, сталкивающегося с юридически приуроченным всплеском, добавьте последствие ошибки, поскольку портал пособий или налоговая система, прогнувшаяся в первый день, становится публичным расследованием, а не просто медленным днём.
Отказывали ли вы когда-либо компонент в эксплуатации намеренно и соответствует ли ярус избыточности каждой системы её критичности и стоимости? Устойчивость, которую никогда не проверяли, гипотеза, а ярусы, которые можно купить, варьируются от дешёвого резервного копирования и восстановления через тёплый резерв до дорогой активно-активной многорегиональности, поэтому дисциплина в том, чтобы тратить гарантию там, где она оправдана, а не позолачивать всё или не защищать ничего. Противоположные соображения это радиус поражения и бюджет: эксперименты хаоса должны иметь ограждения и выключатель прерывания, а активно-активность для внутреннего инструмента отчётности расточительство, тогда как одно резервное копирование для платёжной платформы халатность. Принесите опись ваших единых точек отказа, яруса избыточности каждой критичной системы и свидетельство последнего контролируемого внедрения отказа и что оно обнаружило. В корпоративных и государственных портфелях сопоставьте каждый ярус с документированной оценкой критичности, чтобы аудитор видел, что деньги следуют за риском, и чтобы никому не приходилось впервые защищать расход во время сбоя.

Взгляд по секторам

Стартап. Вы не можете предсказать, принесёт ли запуск пятьдесят регистраций или пятьдесят тысяч, поэтому покупайте масштаб, а не стройте его: запускайте сервисы без состояния за управляемым балансировщиком нагрузки и позвольте платформе автомасштабироваться по частоте запросов. Задайте один скромный бюджет производительности и выберите управляемые хранилища данных, чтобы всплеск не вынудил к переустройству в два часа ночи. Пропустите многорегиональное аварийное восстановление и программы хаоса пока; держите протестированные резервные копии и тратьте скудное инженерное внимание на продукт, а не на избыточность, которую ваш трафик пока не оправдывает.

Малый бизнес. Без специалиста по надёжности и при ограниченном бюджете выбор «купить или построить» сильно склоняется к покупке: управляемая платформа или бессерверный стек делает масштабирование и переключение при отказе заботой провайдера, а одного хорошо ведомого региона обычно достаточно. Формулируйте устойчивость как небольшое число конкретных обещаний, которые вы можете выполнить, например ночная резервная копия, из которой вы действительно хоть раз восстанавливались, и реалистичное окно восстановления, о котором вы сообщили клиентам. Не платите за активно-активность или непрерывное нагрузочное тестирование, для которых у вас нет ни трафика, ни персонала.

Крупная организация. Проблема в согласованности между многими командами: стандартизируйте бюджеты производительности, обеспечиваемые в CI, общую библиотеку паттернов устойчивости (тайм-ауты, предохранители, переборки) и документированный ярус избыточности для каждой системы, привязанный к её критичности. Резервируйте активно-активную многорегиональность для сервисов первого яруса, ведите программу хаос-инженерии с ограждениями и игровыми днями в эксплуатации и воспринимайте планирование мощностей под известные всплески как плановую дисциплину, а не запоздалую мысль. Управляйте RTO и RPO централизованно, чтобы у каждой критичной системы были владеемые, протестированные цели, которые аудитор может проверить.

Государственный сектор. Нагрузка часто юридически приурочена, а обязательства по доступности установлены законом, поэтому планирование мощностей не может полагаться на автомасштабирование, реагирующее в моменте: прогнозируйте всплеск срока, заранее выделяйте мощность и нагрузочно тестируйте значительно выше прогноза. Закупки должны задавать RTO, RPO и график отрепетированных переключений как контрактные требования, а не обещания поставщика, и избегать привязки к одному региону для критичных сервисов. Решите заранее, какой путь юридически существенен (подача декларации, заявление на пособие), чтобы деградация сбрасывала сначала панели статуса и поиски, и будьте прозрачны перед обществом о сбоях и восстановлении, а не надейтесь, что никто не заметит.

Примеры

Стартап. Небольшой стартап, запускающийся на Product Hunt, не может предсказать, получит ли он пятьдесят регистраций или пятьдесят тысяч, поэтому держит сервисы без состояния за управляемым балансировщиком нагрузки и позволяет платформе автомасштабироваться по частоте запросов. Он задаёт один скромный бюджет производительности (страницы отвечают менее чем за 300 мс на 95-м процентиле) и выбирает управляемую базу данных, чтобы всплеск трафика не вынудил к переустройству в два часа ночи. Когда всплеск в день запуска всё же приходит, сайт слегка замедляется, а не падает, и команда проводит день в разговорах с новыми пользователями вместо борьбы со сбоем.

Крупная организация. Компания потокового медиа запускает сервисы без состояния по нескольким регионам за глобальной балансировкой нагрузки, автомасштабируясь по частоте запросов вслед за ежедневной волной прайм-тайма. Бюджеты производительности служат шлюзом каждого выпуска по задержке запуска p99. При отказе региона трафик автоматически переключается на здоровые регионы, а несущественные функции (персонализированные обложки, обновление рекомендаций) деградируют первыми, чтобы защитить воспроизведение. Компания ведёт непрерывные эксперименты хаоса в эксплуатации, регулярно завершая экземпляры и внедряя задержку, так что реальные отказы неотличимы от учений и не вызывают видимого клиентам сбоя.

Государственный сектор. Налоговое управление знает, что его система подачи сталкивается с массовым юридически фиксированным всплеском каждый год. Вместо того чтобы полагаться на автомасштабирование, реагирующее в моменте, оно прогнозирует пиковую нагрузку по прошлым годам, заранее за недели выделяет мощность и нагрузочно тестирует до 150% прогноза. Архитектура без состояния за балансировщиками нагрузки с тёплым резервным вторым регионом. RTO и RPO заданы политикой (не более 15 минут простоя и почти нулевая потеря данных для поданных деклараций), а переключение репетируется ежеквартально. При экстремальной нагрузке несущественные функции (панели статуса, исторические поиски) сбрасываются первыми, чтобы подача декларации, юридически существенный путь, оставалась доступной.

Бизнес-обоснование: мотивы, ROI и TCO

Масштабируемость, производительность и устойчивость классические случаи, где стоимость отказа многократно превышает стоимость профилактики. Но профилактика видна в бюджете, а отказ лишь потенциален, поэтому их хронически недофинансируют до первой катастрофы. Стоимость внедрения реальна: избыточная инфраструктура, многорегиональная мощность, инструменты нагрузочного тестирования и хаоса и инженерное время на построение отсутствия состояния и паттернов устойчивости. Стоимость отказа от вложений это громкий сбой во время пикового спроса: потерянная выручка по минутам для торговли, пропущенные обязательства по закону и публичное расследование для государства, штрафы по соглашению об уровне обслуживания (SLA) и длительный репутационный ущерб.

Формулируйте обоснование руководству числами, которые бизнес уже понимает. Оцените стоимость часа простоя во время пика (потерянные транзакции, штрафы, исправление, репутация), затем сопоставьте с годовой стоимостью избыточности и тестирования, которые его предотвращают. Для критичных систем профилактика почти всегда доля одного крупного инцидента. Привяжите RTO и RPO к явным деньгам: сколько выручки или транзакций в час простоя и какая потеря данных юридически или коммерчески допустима. Представляйте производительность как рычаг выручки и удовлетворённости, поскольку более быстрые системы лучше конвертируют и стоят меньше на транзакцию, а устойчивость как страховку, чья премия мала относительно покрываемого убытка. Самый сильный аргумент в том, что эти качества дёшево закладывать в проект и разорительно дооснащать после сбоя, вынуждающего заняться этим.

Антипаттерны и ловушки

Липкие сессии и состояние в экземпляре. Хранение состояния сессии на сервере, препятствующее свободному горизонтальному масштабированию и безопасной замене экземпляров.
Автомасштабирование как планирование мощностей. Предположение, что автомасштабирование поглотит известный ступенчатый всплеск, на который оно слишком медленно реагирует.
Работа на пределе без запаса. Эксплуатация на почти 100% загрузке, не оставляющая ничего для поглощения всплесков или отказов.
Оптимизация без профилирования. Настройка кода, не являющегося узким местом, пока настоящее остаётся нетронутым.
Игнорирование хвоста. Сообщение средней задержки, пока пользователи p99 страдают; средние скрывают боль в масштабе.
Непроверенное аварийное восстановление. План аварийного восстановления и резервные копии, никогда не отрабатывавшиеся и проваливающиеся, когда нужны.
Единые точки отказа. Один балансировщик нагрузки, один первичный узел базы данных, один регион: неизбыточный компонент, роняющий всё.
Хаос-инженерия без ограждений. Внедрение отказов без контроля радиуса поражения и выключателя прерывания, вызывающее тот самый сбой, который вы хотели предотвратить.

Модель зрелости

Уровень 1: Начальный. Стихийно и реактивно. Один экземпляр или вертикальное масштабирование, состояние хранится на сервере. Нет нагрузочного тестирования, бюджетов производительности и аварийного восстановления кроме случайных резервных копий, из которых никто не восстанавливался. Любой отказ компонента вызывает полный сбой, а проблемы масштаба обнаруживаются в эксплуатации.
Уровень 2: Развитие. Появляются базовые практики, но они различаются по командам. Некоторые сервисы горизонтально масштабированы и без состояния за балансировщиком нагрузки, с базовым автомасштабированием на нескольких. Нагрузочное тестирование проводится перед крупными запусками, но не рутинно, резервные копии существуют, а аварийное восстановление документировано, но редко отрабатывается. То, что одна команда делает хорошо, другая не начала.
Уровень 3: Стандартизация. Практики задокументированы и соблюдаются по организации. Мощность планируется под известные всплески с запасом, бюджеты производительности обеспечиваются в CI, так что регрессии валят сборку, а паттерны устойчивости (тайм-ауты, ограниченные повторы, предохранители, переборки) плюс плавная деградация умолчание. RTO и RPO определены по системе, ярусы избыточности назначены по критичности, а переключение аварийного восстановления тестируется по регулярному графику во всех командах.
Уровень 4: Управление. Качества измеряются и контролируются относительно базовых значений. Команды отслеживают задержку p95 и p99, бюджеты ошибок и загрузку и запас относительно прогноза и оповещают о нарушениях, а не обнаруживают их при запуске. Протестированные времена переключения сравниваются с целевыми RTO и RPO, пороги деградации и сброса нагрузки проверяются метриками, а решения «идти или не идти» по выпускам и мощностям ведутся данными. Где числа дрейфуют от базового уровня, разрыв виден и имеет владельца, а не спрятан за средними.
Уровень 5: Оркестрация. Масштабируемость, производительность и устойчивость непрерывно улучшаются и интегрированы по организации. Активно-активная многорегиональность используется везде, где критичность это оправдывает, хаос-инженерия идёт непрерывно, включая игровые дни в эксплуатации, а прогнозирование мощностей питает планирование и закупки напрямую. Устойчивость проверяется непрерывно, цели восстановления последовательно достигаются и доказываются, а архитектура адаптируется по мере смещения шаблонов нагрузки и картины рисков, связанная с планированием непрерывности бизнеса и рисков.

Идеи для обсуждения

Какие из ваших сервисов всё ещё держат состояние на экземпляре и что мешает сделать их без состояния?
Каковы RTO и RPO вашей самой критичной системы, кто их задал и когда вы в последний раз доказали, что можете их выполнить?
Защищает ли вас автомасштабирование от вашего крупнейшего известного всплеска или вы рассчитываете, что оно сделает то, чего не может?
Где ваша оставшаяся единая точка отказа и каков план её устранения?
Измеряете ли вы и закладываете ли бюджет на задержку p99 или прячетесь за средними?
Отказывали ли вы когда-либо компонент в эксплуатации намеренно? Если нет, откуда вы знаете, что ваша устойчивость работает?

Главные выводы

Различайте производительность, масштабируемость и устойчивость; большой системе нужны все три, заложенные в проект с самого начала.
Горизонтальное масштабирование и сервисы без состояния фундамент масштаба, доступности и безопасного развёртывания.
Сочетайте автомасштабирование с настоящим планированием мощностей и запасом для предсказуемых критичных для бизнеса всплесков.
Ведите производительность профилированием и нагрузочным тестированием относительно явных бюджетов, сосредотачиваясь на критическом пути и хвосте.
Стройте устойчивость тайм-аутами, предохранителями, переборками, плавной деградацией и избыточностью, затем проверяйте её хаос-инженерией.
Задавайте RTO и RPO как бизнес-решения, проектируйте аварийное восстановление под критичность каждой системы и регулярно тестируйте переключение.

Источники и дополнительное чтение

Martin Kleppmann, Designing Data-Intensive Applications
Michael Nygard, Release It!: Design and Deploy Production-Ready Software
Betsy Beyer et al. (Google), Site Reliability Engineering and The Site Reliability Workbook
Casey Rosenthal and Nora Jones, Chaos Engineering
Brendan Gregg, Systems Performance: Enterprise and the Cloud
John Allspaw, The Art of Capacity Planning
Ilya Grigorik, High Performance Browser Networking
Nassim Nicholas Taleb, Antifragile

3.5 Масштабируемость, производительность, устойчивость

Обзор и мотивация

Ключевые принципы

Рекомендации

Предпочитайте горизонтальное масштабирование и проектируйте сервисы без состояния

Балансируйте нагрузку, автомасштабируйте и планируйте мощность

Проектируйте производительность относительно явных бюджетов

Встраивайте паттерны устойчивости и проверяйте хаос-инженерией

Планируйте многорегиональность, аварийное восстановление и непрерывность бизнеса