В этом блоке мы разберем теорию и посмотрим примеры расчетов. А уже в следующем блоке ты сможешь попрактиковаться в расчетах
Это очень важный раздел, так как многие неправильно относятся к расчетам, а потом страдают — либо система может рухнуть от нагрузки, либо к тебе придут с вопросами почему у вас простой и ты недоиспользуешь ресурсы.
А тебе же не хочется сидеть по ночам, разгребая инциденты, или объясняться с админами?
Давай на примерах разбираться, откуда могут появиться проблемы:
- Если неправильно рассчитать нагрузку на систему, количество запросов будет превышать допустимое. А система будет долго отвечать или начнет рестартовать.
- Не менее важно оценивать нагрузку на внешние интеграции. Нередко в каком-то запросе к нашей системе есть последующие запросы к внешним системам. И если количество запросов на нашу систему увеличилось, это может произвести эффект домино и на них.
- В каждой компании есть квоты. В Big Tech это инструмент балансировки ресурсов между отделами, который обеспечивает эффективное использование инфраструктуры. Например, отдел А получит 500 RAM и 700 CPU на все команды внутри отдела, отдел Б — тоже определенное количество. Если планируется большой проект, стоит заранее заложить под это квоты, иначе придется экстренно искать ресурсы.
- Если мы говорим про стартапы, то ситуация еще критичнее: к примеру, Managed K8S стоит от 20 тысяч рублей в месяц. Теперь представь, что ты заложил слишком много Disk Space или RAM для своего приложения вместо того, чтобы оптимизировать бюджет — такое халатное отношение к деньгам может даже привести компанию к банкротству.
- Важно понимать, какой будет retention policy, то есть политика хранения данных. От этого будет зависеть способ хранения и возможные оптимизации.
Retention policy — набор правил и руководящих принципов, которые определяют, как долго должны храниться различные типы данных, как они будут архивироваться и когда их следует удалять. Такая политика охватывает весь жизненный цикл данных, начиная с момента их создания или получения и заканчивая окончательным удалением.
Сейчас я приведу несколько примеров расчетов, чтобы у тебя сложилось понимание, как я их делаю и на что обращать внимание. Контекст такой — делаем соцсеть.
Пример 1. Общий расчет запросов к системе
MAU — monthly active users
DAU — daily active users
Важными показателями являются нагрузка на чтение и на запись. Их считают отдельно, чтобы решить, закладывать ли возможности на чтение и на запись тоже по отдельности, или этого не нужно.
Дано:
- Monthly Active Users (MAU): 100 million
- Daily Active Users (DAU): 35 million
- Каждый пользователь взаимодействует с системой 50 раз в день
- Коэффициент чтение : запись — 43 : 7
Задача: узнать количество запросов на чтение и запись.
Расчеты
Количество запросов в день:
Requests per day = 35 000 000 * 50 = 1 800 000 000
У нас есть коэффициент чтение: запись. Отлично, можно вывести пропорцию:
- 50 = 100 %
- 43 = x %
- (100 * 43) / 50 = 86 % (чтение)
- 100% - 86% = 14 % (запись)
86 400 — константа, которую должен знать каждый (60 * 60 * 24)
60 — количество секунд в минуте
60 — количество минут в часе
24 — количество часов в сутках
Перемножаем и получаем количество секунд в сутках.
- Requests Per Second = 1 800 000 000 / 86 400 = 21 000
- RPS (read) 21 000 * 0.86 = 18 000
- RPS (write) 21 000 * 0.14 = 3 000
Пример 2. Идем дальше и готовимся к праздникам
Ну что ж, снова доставай калькулятор, потому что сейчас расскажу, как считать сезонную нагрузку!
И тут сразу пару терминов тебе:
Peak Multiplier (коэффициент пикового значения RPS) — показатель, который используется для измерения увеличения нагрузки, активности или потребления в определенный пиковый момент по сравнению со средней или базовой нагрузкой.
Off-Peak Multiplier (коэффициент непикового значения) — это показатель для оценки нагрузки или активности системы в непиковые периоды относительно её среднего или базового значения. Он противоположен Peak Multiplier и помогает анализировать поведение системы, когда нагрузка минимальна. Дано:
- Peak Multiplier (PM) — 2.5
- Off-Peak Multiplier (OM) — 0.5
- RPS (как мы уже посчитали) — 21 000
Задача: узнать количество запросов в дни пиковой и минимальной активности.
Расчеты:
- Peak RPS = Average RPS × PM = 21_000 * 2.5 = 53 000
- Off-Peak RPS = Average RPS × OM = 21 000 * 0.5 = 11 000
Пример 3. Расчет памяти в системе
Дано:
- посты — 25% от общего числа записей в системе;
- RPS (записей) = 3 000 (считали в первом примере)
Задача: узнать, сколько памяти нужно для хранения постов.
Расчеты:
- 3000 * 0.25 = 750 posts per second
Представим, что каждое фото занимает 5 MB, и в посте, помимо фото, может быть еще какая-то информация. Условимся на 6 MB на пост.
Столько памяти тратится за секунду:
- 750 * 6 = 4 500 MB/second
А столько нужно на день и год:
- 4 500 * 86 400 = 390 000 000 MB = 390 000 GB = 390 TB per day
- 390 * 365 = 143 000 TB = 143 PB per year