Про RPS и стоимость ресурсов.

В тренингах по проектированию интеграций и по составлению требований есть часть про расчет нагрузки и масштабирования. Очень часто это вызывает у участников затруднения, потому что нет наглядной картины, примера масштабов, о чём мы вообще говорим?

Я нашел у Gitlab хорошую табличку с разными вариантами нагрузки и разной стоимостью. (Gitlab — это сервер для системы управления версиями git, типа Github — но ваш персональный).

Итак, во-первых — какая нагрузка? RPS — requests per second, число запросов в секунду. У Gitlab она измерена эмпирически, на этапе требований можно предположить её из понимания частоты выполнения процессов. Минимальная конфигурация — 20 RPS, до 1000 пользователей. Считаются и автоматические вызовы, и пользовательские: 20 вызовов API/сек, 2 RPS через web, 2 git push, 2 git pull. Как можно посчитать — ну сколько программисты делают пуллов и пушей? Штук 20 макс.? Значит, 20000/8 (рабочих часов)/60 — где-то 40 в минуту получаем, с запасом, в пике (например, в конце рабочего дня, когда все побежали пушить изменения за день) — как раз можно рассчитывать на 120 в минут, или 2 RPS.

Впрочем, нас здесь интересует ограничение сверху, т.к. это минимальная конфигурация, которая может жить на одной виртуальной машине. Это, правда, довольно здоровенная машина: 8 vCPU, 16 GB memory, но всё-таки одна. То есть это — верхний предел вертикального масштабирования. Туда помещается все элементы архитектуры Gitlab — приложение на Ruby on Rails, Sidekiq — сервис для фоновых задач, Redis для кэширования, PostgreSQL, Gitaly — RPC сервис для выполнения команд git, и, собственно, локальное хранилище текстов программ.

Следующие конфигурации уже используют размещение всех компонент на отдельных машинах, этим объясняется резкий скачок стоимости. Ну и дальше наращивается просто количество единиц одинаковых компонент:
— при росте до 40RPS и 2000 пользователей — два экземпляра веб-приложения + балансировщик;
— при 60RPS и 3000 пользователях — три веб-приложения, два Sidekiq, три Redis, три Gitaly, кластер из трёх PostgreSQL. Соответственно, всё это требует обвзяки из внешних и внутренних балансировщиков, мониторинга и service discovery. На этом этапе также можно обеспечить High Availability, то есть вы можете заявлять доступность выше 99%. Можно оценить, во сколько это выражается в деньгах.

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

Поэтому, на практике, мы, как аналитики, должны сделать две вещи:

1. Выяснить — есть ли у нас потребность в горизонтальном масштабировании? Ищем пользователей больше 1000 или число запросов больше нескольких в секунду (не обязательно от пользователей, это могут быть и какие-то автоматические транзакции). Если таких чисел не видно — вам хватит одной машины.

2. Узнать — как бизнес (и система вслед за ним) собирается расти. При этом страшнее не планы бизнеса "привлечь 100500 новых клиентов", они обычно не сбываются; страшнее слова "мы хотим распространить этот сервис" — на всех клиентов, на все регионы, на другие операции и т.п., то есть туда, где эти пользователи или эти операции в таком объеме уже сейчас есть. Вот это можно включить в требования, чтобы архитекторы смогли заложить в архитектуру.