Масштабируемость: чтение чисел и конфигов
Читай реальную математику ёмкости, конфиг и код, затем делай арифметику: потолок по закону Литтла, бюджет очередей, хелпер оценки и проверка задержки, что отвергает дизайн.
Баги масштабирования живут в числах, а не в прозе: размер пула, цель утилизации, шаг округления, вызов на запрос в далёкий регион. Читай каждый сниппет, делай арифметику в голове и выбирай ответ, под которым подпишется senior-инженер.
Отработай цикл, что прогоняешь на ревью дизайна или ёмкости: найди числа в коде, примени закон Литтла, или кривую очередей, или иерархию задержек, и выбери изменение, что арифметика реально поддерживает.
Сниппет 1 — хелпер размера пула
def max_throughput_rps(pool_size: int, avg_latency_ms: float) -> float:
# Закон Литтла: λ = L / W, где W в секундах
return pool_size / (avg_latency_ms / 1000)
print(max_throughput_rps(pool_size=200, avg_latency_ms=40)) # что напечатает?Что вернёт max_throughput_rps(200, 40) и что это значит?
Сниппет 2 — цель утилизации
# конфиг автоскейлера
target_cpu_utilization: 0.95 # «использовать железо полностью»
# время обслуживания без нагрузки ~20 мс; SLO p99 <= 200 мсКоманда поставила цель автоскейлера 95% CPU ради экономии. По модели очередей, каков риск и фикс?
Сниппет 3 — хелпер оценки
def daily_to_qps(daily_requests: float, peak_multiplier: float = 3) -> dict:
avg = daily_requests / 86_400
return {"avg_qps": round(avg), "peak_qps": round(avg * peak_multiplier)}
# 1,5 миллиарда запросов/сутки
print(daily_to_qps(1_500_000_000))Примерно что вернёт daily_to_qps(1_500_000_000) и как это верно прочитать?
Сниппет 4 — вызов на запрос
# сервис в us-east-1 (Вирджиния); этот стор в eu-central-1 (Франкфурт)
def handle_request(req):
user = remote_store.get(req.user_id) # Вирджиния -> Франкфурт -> Вирджиния
prefs = remote_store.get(req.prefs_id) # Вирджиния -> Франкфурт -> Вирджиния
return render(user, prefs) # два синхронных межрегиональных вызоваПо числам задержек, каков пол задержки этого хендлера и каков верный фикс?
- 01Дан размер пула и средняя задержка — как посчитать потолок пропускной способности и в чём ловушка единиц?
- 02Почему цель автоскейлера 95% CPU опасна и какая цель держит SLO?
- 03Каков пол задержки двух синхронных межрегиональных вызовов подряд и фикс?
Любое решение масштабирования в этом разделе сводится к арифметике, что читаешь прямо с конфига. Закон Литтла (λ = L/W, где W в секундах) превращает размер пула и задержку в потолок пропускной способности — и ловушка единиц в том, чтобы забыть перевести миллисекунды в секунды. Кривая очередей (W = 1/(μ−λ)) говорит, что цель утилизации 95% пробивает узкий SLO p99, ведь хвост там ~в 20× без нагрузки, поэтому ставишь ~60–70%. Код оценки на салфетке (суточные ÷ 86 400, затем × множитель пика, прочитано до одной значащей цифры) даёт нагрузку, под которую размеряешься — пик, никогда среднее. А числа задержек (~150 мс на межрегиональный round-trip, ~100 случайных seek/с на HDD) дают отвергнуть межрегиональный вызов на запрос или чтение «диск-на-запрос» в одном предложении. Senior-привычка — найти числа, сделать математику и выбрать фикс, что арифметика поддерживает, а не тот, что её замазывает.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.