Масштабируемость: обзор с выбором ответа
Синтез всего раздела масштабируемости в формате с выбором ответа: закон Литтла и кривая очередей, вертикаль против горизонтали и USL, арифметика оценки на салфетке и числа задержек для отсева дизайна.
Шесть вопросов через весь раздел. Каждый — решение, которое ты принимаешь, когда размеряешь сервис, ревьюишь дизайн-док или оцениваешь систему на доске: не определение для пересказа, а арифметика закона Литтла, USL и чисел задержек под реальной нагрузкой.
Убедись, что умеешь применять закон Литтла для потолка пропускной способности, читать кривую очередей, размещать нагрузку на оси вертикаль/горизонталь с учётом USL, прогнать оценку на салфетке до одной значащей цифры и отвергнуть дизайн по одним лишь числам задержек.
Сервис ограничен 150 одновременными запросами в полёте лимитом пула соединений, каждый запрос в среднем 30 мс от начала до конца. По закону Литтла, какова его максимальная устойчивая пропускная способность?
При 90% утилизации твой p99 ~в 10× больше времени обслуживания без нагрузки, и команда хочет дожать до 98%, чтобы «использовать железо полностью». Что предсказывает кривая очередей?
Stateless API-слой масштабируется вширь линейно до ~30 узлов, затем общая пропускная способность выходит на плато и наконец слегка падает после ~45 узлов. По Universal Scalability Law, что происходит?
Оценивая до одной значащей цифры: 50М активных в день, каждый делает 20 запросов/день. Каков средний QPS и под какой пик провижинить?
Дизайн-док предлагает отдавать 50 000 чтений/с случайными seek записей со шпиндельного HDD. По числам задержек, каков вердикт, и каков связывающий предел?
Твоя одна пишущая primary-БД на 70% CPU на втором по размеру инстансе, а трафик растёт 8%/мес. Какой план отражает урок вертикального масштабирования?
- 01Почему держать утилизацию на 60–70%, а не дожимать до 98%?
- 02Как отвергнуть дизайн «50К чтений/с со шпиндельного диска» в одном предложении?
Сквозная мысль: масштабирование — арифметика, что делаешь до сборки. Закон Литтла (λ = L/W) даёт потолок пропускной способности из конкурентности и задержки; кривая очередей (W = 1/(μ−λ)) уводит хвост в вертикаль у предела, поэтому держишь 30–40% запаса, а не дожимаешь до 98%. Вертикальное масштабирование просто, но капнуто, суперлинейно по цене и это SPOF — поэтому апгрейдишь как затычку, начиная scale-out до потолка; горизонтальное эластично, но платит налог координации USL (α выводит на плато, β делает кривую ретроградной). Оценки на салфетке (запросов/сутки ÷ ~10^5, под пик 3×, округлено до одной значащей цифры) говорят, какой ресурс сломается первым, а числа задержек (~100 случайных seek/с на HDD, ~150 мс межрегион) дают отвергнуть плохой дизайн в одном предложении — без всякого бенчмарка.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.