Масштабируемость: план ёмкости с нуля
Практический проект: возьми бриф продукта, сделай полный план ёмкости на салфетке (QPS, объём, трафик, память), затем подтверди предсказания закона Литтла и очередей крошечным нагрузочным тестом.
Прочитать, что оценивать надо до проектирования — не то же, что выдать план ёмкости, под которым подпишется staff-инженер. Возьми реалистичный по форме бриф продукта, оцени его от начала до конца на бумаге, а затем докажи два самых рискованных предсказания — потолок пропускной способности и колено очередей — нагрузочным тестом, что напишешь сам.
Этот проект делает весь раздел операционным: ты по-настоящему применишь дисциплину оценки, обоснуешь каждый порог дизайна числом, а затем измеришь, чтобы подтвердить два предсказания, что вероятнее всего тебя укусят — потолок пропускной способности по закону Литтла и колено задержки по кривой очередей.
Сделай полный план ёмкости на салфетке для выбранного продукта (например приложение обмена фото, сокращатель ссылок или чат), затем собери небольшой нагрузочный тест, что эмпирически подтверждает твой потолок пропускной способности по закону Литтла и колено задержки по кривой очередей — замыкая петлю между оценкой и измерением.
- Одностраничный план ёмкости с QPS (средн + пик), объёмом/хранением, трафиком и памятью, каждая цифра округлена до одной значащей цифры и каждое допущение названо — читается за две минуты.
- Список архитектурных решений, где каждое решение цитирует конкретное число, что им движет, включая, какой ресурс ломается первым и какой класс данных доминирует в объёме.
- Рабочий нагрузочный тест, чья измеренная макс. пропускная способность совпадает с предсказанием закона Литтла λ = L/W (в пределах заявленного допуска), с размером пула и задержкой, что её дали.
- График (или таблица) задержка-против-утилизации, что наглядно показывает колено очередей — p99 ровный до ~70%, затем круто растёт — плюс однострочная рекомендация цели автоскейлера и обоснование.
- Короткий разбор: один абзац о том, что вскрыла одна лишь оценка до любых измерений, и один — где измерение разошлось с салфеткой и почему.
- Добавь сценарий пик-и-ретраи: внеси короткий затык, включи клиентские ретраи и покажи, как ретраи при насыщении толкают предложенную нагрузку вверх и ускоряют коллапс очередей — петля обратной связи просадка-в-сбой.
- Сравни вертикаль и горизонталь: прогони ту же нагрузку против одного большого пула против нескольких малых пулов за round-robin балансировщиком и обсуди, где налог координации USL начал бы кусаться при большем числе узлов.
- Добавь осознание coordinated omission: прогони тест раз closed-loop (следующий запрос после возврата прошлого) и раз open-loop (фиксированный темп прибытия) и покажи, как closed-loop p99 занижает реальный хвост во время затыка.
- Пересчитай план при допущении роста 10× и определи первый порог, что пересекаешь (шард кэша, шард БД, мульти-регион), показав, как оценка меняет дизайн по мере масштабирования входов.
- 01Какие четыре величины оценивает план ёмкости и как превратить каждую в решение дизайна?
- 02Как подтвердить закон Литтла и колено очередей в нагрузочном тесте?
- 03Почему сначала оценка, а потом измерение, а не просто измерение?
Этот проект превращает раздел масштабируемости в воспроизводимый рабочий процесс: возьми бриф продукта, оцени четыре величины (QPS с множителем пика, объём за окно хранения, трафик, память горячего набора) до одной значащей цифры и переведи каждую в архитектурное решение, обоснованное конкретным числом — какой ресурс ломается первым, какой класс данных доминирует, где лежат пороги (одна машина, один кэш-узел, один primary БД). Затем замкни петлю измерением: собери небольшой сервис с известным размером пула и управляемой задержкой, подтверди, что измеренная пропускная способность совпадает с потолком закона Литтла λ = L/W, и построй p99 против утилизации, чтобы увидеть колено очередей, что предсказывает кривая M/M/1, выбрав по нему цель автоскейлера. Сначала оценка, потом тест — в этом вся дисциплина: салфетка говорит форму и самые рискованные предсказания; нагрузочный тест их подтверждает. Инженер, что собрал это однажды, размеряет системы осознанно, а не открывает потолок во время инцидента в 3 часа ночи.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.