Масштабируемость

Что такое масштабируемость

Масштабируемость — способность системы справляться с возросшей нагрузкой. Это не галочка «есть или нет», а разговор о том, что мы будем делать, когда система перестанет справляться.

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

Краткая идея автора

Клеппман не даёт рецепта «сделай так — и будет масштабируемо». Он даёт порядок рассуждения, и весь раздел построен по нему.

1. 01 Система перестаёт справляться

   Пользователей стало больше, данных стало больше, запросов стало больше. Система, которая вчера работала нормально, начинает тормозить. Рост — это не только рост трафика: расти могут объём данных и сложность связей между ними.

2. 02 Описать нагрузку

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

3. 03 Описать производительность

   Производительность — это насколько хорошо система справляется с этой работой. В пакетной обработке смотрят на пропускную способность, в онлайн-системах — на время отклика, причём не среднее, а по процентилям.

4. 04 Выбрать стратегию и архитектуру

   И только теперь выбираем: расти вверх (машина мощнее) или вширь (машин больше), что делать с состоянием, где кэшировать и что можно потерять. Архитектура вырастает из нагрузки, а не наоборот.

Шаг первый: описать нагрузку

Сначала описываем нагрузку — и только потом смотрим, как система при ней себя ведёт. Выбрать не тот параметр — значит промахнуться мимо реальной проблемы.

Пример из книги: Twitter

Числа Twitter из книги. Кажется, что главная нагрузка здесь — публикация твитов. На самом деле нет.

12 000 записей в секунду современная система переварит. Проблема в другом: один твит нужно доставить всем подписчикам автора — операция размножается на выходе. Это разветвление и называют fan-out.

Два способа собрать ленту

Одну и ту же ленту можно построить двумя способами, и вся разница — в том, когда выполняется работа: в момент чтения или в момент записи.

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

Потому что у Twitter записей несоизмеримо меньше, чем чтений — и это свойство нагрузки выгодно использовать.

Вот зачем нужен был шаг «описать нагрузку»: решение принимает не архитектурный вкус, а соотношение чисел — 4 600 записей против 300 000 чтений.

Пока не появляется знаменитость

Среднее — 75 подписчиков. У аккаунтов из верхнего ряда их сотни миллионов, и один твит такого автора превращается в десятки миллионов записей, которые Twitter хотел доставлять примерно за пять секунд.

Среднее число подписчиков прячет крайние случаи. Архитектуру определяет распределение параметра нагрузки, а не его среднее — поэтому в итоге в Twitter живут оба подхода сразу.

Шаг второй: описать производительность

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

Из чего складывается время отклика

Response time — всё это вместе, то есть ровно то, что видит клиент.

Поэтому время отклика может быть огромным, даже когда обработка мгновенная — запрос просто стоял в очереди. Мерить надо у клиента, а не внутри сервера.

Одно среднее число ничего не описывает

99 запросов по 10 мс и один на 10 секунд дают «в среднем 110 мс» — число, которого не видел ни один пользователь. Поэтому время отклика описывают распределением и процентилями.

Хвост — не мелочь: при 10 млн запросов 1 % — это 100 000 медленных ответов, и достаются они чаще самым активным клиентам, у которых больше всего данных. В Amazon считали, что лишние 100 мс времени отклика — это около −1 % продаж.

Откуда берётся хвост

Медленный запрос редко медленный сам по себе — чаще он просто стоял в очереди за чужим.

Отсюда правило: время отклика измеряют на стороне клиента. Внутреннее время работы сервера ничего не знает про очередь, которая выстроилась перед ним.

В распределённых системах хвост усиливается

Одна страница магазина собирается из ответов нескольких сервисов — пользователи, товары, рекомендации, реклама, оплата, — и пользователь ждёт самый медленный из них. Пусть каждый отвечает медленно лишь в 1 % случаев.

Шаг третий: чем масштабировать

Нагрузка описана, производительность описана — теперь можно выбирать: расти вверх или вширь. На практике — разумное сочетание того и другого.

Разница вся в состоянии. Stateless-сервис размножается почти даром — запрос можно отдать любому серверу. Но если сервер помнит корзину пользователя, соседний о ней не знает, и появляются репликация, согласованность, обработка отказов. Поэтому базы данных так долго старались держать на одной машине; инструменты стали лучше, но распределённость сама по себе не цель.

Главный вывод раздела

Универсальной масштабируемой архитектуры не существует. Она вырастает из конкретной нагрузки: чего больше — чтений или записей, насколько велики данные, как быстро нужно отвечать, какие бывают пики. Две системы с одинаковой пропускной способностью могут не иметь между собой ничего общего.

Пропускная способность одинаковая — около 100 МБ/с у обеих. Архитектуры будут совершенно разными, потому что нагрузка у них разная по характеру, а не по объёму.

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

вывод по разделу 1.3 книги «Высоконагруженные приложения» Мартина Клеппмана