Подробное руководство
Симулятор масштабирования базы данных и IOPS: когда стоимость управляемой базы обгоняет выручку на пользователя
Аналитический обзор отрасли
Управляемая база данных — та часть стека, о которой люди больше всего хотят забыть, и которая забывает о них, когда приходит счёт. Всё начинается с небольшого экземпляра и небольшого диска. Затем пользователи растут, функции добавляют запросы, таблицы наполняются историей, и тариф, который был дешёвым, становится самой крупной строкой в счёте. В отличие от веб-серверов, базы данных не масштабируются добавлением дешёвых одинаковых машин. Они масштабируются переходом на более крупные экземпляры, добавлением выделенной пропускной способности и копированием всего на реплики, и каждый из этих шагов умножает расходы.
Суть задачи в том, что расходы растут ступенями, а выручка — плавно. Размеры экземпляров удваиваются: от двух к четырём, к восьми, к шестнадцати vCPU, и цена каждый раз примерно удваивается. Хранилище и IOPS тарифицируются отдельно, а реплики умножают всё. Выручка на пользователя не удваивается, когда удваивается ваш экземпляр. Бизнес, комфортно прибыльный при 30 000 пользователей, может обнаружить, что следующий размер обнуляет выигрыш от следующих 10 000 пользователей.
Модель домино прослеживает цепочку. Пользователи и IOPS на тысячу пользователей задают пиковый спрос на уровень хранения. Требования к вычислениям определяют размер экземпляра, который вместе с репликами, хранилищем и выделенной пропускной способностью задаёт счёт. Счёт становится долей выручки, которая в итоге решает вопрос прибыли. Плохо проиндексированный запрос может изменить первый блок втрое без всякого изменения числа пользователей, поэтому оптимизация запросов нередко самый дешёвый способ снизить все последующие блоки.
Айсберг отделяет экземпляр, который видят все, от дополнений, из-за которых счёт получается больше ожидаемого. Видимыми остаются основной экземпляр и хранилище. Под водой лежат реплики, повторяющие вычисления и хранилище, выделенные IOPS сверх базового уровня, который включает диск, резервные копии, хранимые неделями, и трафик, реплицирующий данные между зонами. Каждая статья тарифицируется под своим заголовком, поэтому их легко недооценить при планировании. С помощью симулятора проверьте, как ваша архитектура ведёт себя при росте числа пользователей и где база данных становится неподъёмной.
Формулы и методология
Модель описывает один месяц. Пиковый спрос на IOPS — это пользователи на тысячу, умноженные на IOPS на тысячу и на пиковый коэффициент 2,5. Необходимые вычисления — 0,0005 vCPU на пользователя, округлённые вверх до размера экземпляра в виде степени двойки с минимумом в два. Каждая реплика повторяет основной экземпляр, хранилище и выделенные IOPS. Выделенные IOPS тарифицируются сверх базового уровня в 3000. Хранилище, резервные копии и межзонная репликация добавляются к итогу, а прочие расходы составляют 40 % выручки.
- Пиковые IOPS
- I = пользователи ÷ 1000 × IOPS на 1000 × 2,5
- Операции в секунду, которые уровень хранения должен выдерживать на пике.
- Размер экземпляра
- V = 2^округл.вверх(log₂(max(2, пользователи × 0,0005)))
- vCPU на основном узле; размеры бывают только степенями двойки.
- Счёт за базу данных
- D = (1 + реплики) × (V × цена + стоимость IOPS + хранилище) + резервные копии + межзонный трафик
- Вычисления, пропускная способность и хранилище, повторяемые на каждом узле, плюс резервные копии и репликация.
- Выделенные IOPS
- max(0, I − 3000) × 0,10 $ на узел
- Пропускная способность сверх того, что включает диск; тарифицируется на каждом узле.
- Чистая прибыль
- Чистая прибыль = выручка × (1 − 40 %) − D
- Месячный результат. Точка разрыва — там, где он обращается в ноль.
Каскадная эластичность
Реплики и IOPS на пользователя — самые эластичные параметры, потому что каждый умножается на каждом узле. Выручка на пользователя масштабирует всю маржу. Пользователи влияют на результат и через выручку, и через переход на более крупный экземпляр, так что рост — не бесплатная победа.
Три реальных примера
Старт на собственных средствах
Небольшой продукт на минимальной базе данных
У молодого продукта три тысячи пользователей, одна реплика и мало данных на пользователя. Выручка на пользователя высока, а экземпляр минимального размера. Загрузите пример и посмотрите, что на ранней стадии база данных незначительна и как высокая выручка на пользователя даёт пространство для роста.
Растущий средний бизнес
Большая база пользователей с эффективными запросами
Продукт с тремястами тысячами пользователей держит IOPS на пользователя низкими с помощью индексов и кэширования и работает с двумя репликами. Счёт велик в абсолютных цифрах, но составляет скромную долю выручки. Загрузите пример и посмотрите, как масштаб работает при настроенных запросах.
Кризис типа «чёрный лебедь»
Тяжёлые запросы и слишком много реплик
Продукт с большой базой пользователей и низкой выручкой на пользователя запускает непроиндексированные запросы, пять реплик и много хранимых данных на пользователя. Выделенные IOPS и реплики умножают каждую статью расходов. Загрузите пример и посмотрите, как счёт за базу данных превышает выручку и какой рычаг возвращает месяц в плюс.
Матрица отраслевых ориентиров
| Показатель | Опасная зона | Среднее по отрасли | Лучшие 10 % |
|---|---|---|---|
| Стоимость базы данных как доля выручки | Выше 35 % | 8–15 % | Ниже 6 % |
| Стоимость базы данных на активного пользователя в месяц | Выше 0,25 $ | 0,05–0,12 $ | Ниже 0,04 $ |
| Реплики для типичного SaaS | Больше 3 без явной потребности в чтении | 1–2 | 1 резервный узел плюс целевые реплики для чтения |
| Доля выделенных IOPS, реально используемая на пике | Ниже 30 % | 50–70 % | 70–85 % |
| Срок хранения резервных копий | Месяцы полных снимков | 7–14 дней | Многоуровневое хранение с архивом |
Переменные и рычаги
Активные пользователи
Пользователи, создающие нагрузку на базу данных в типичный месяц.
Рычаг: Не считайте, что больше пользователей всегда означает лучшую маржу; проверяйте, что выручка на пользователя по-прежнему покрывает следующий размер экземпляра.
Выручка на пользователя в месяц
Средняя месячная выручка, которую вы получаете от одного активного пользователя.
Рычаг: Повышайте выручку на пользователя через ценовые уровни: стоимость базы данных на пользователя растёт вместе с использованием и хранилищем.
Пиковых IOPS на 1000 пользователей
Среднее число операций чтения и записи в секунду, создаваемых каждой тысячей пользователей. Сильнее всего на это влияют структура запросов и индексы.
Рычаг: Добавьте недостающие индексы, кэшируйте горячее чтение и группируйте записи; снижение IOPS часто позволяет избежать и больших дисков, и больших экземпляров.
Цена vCPU в месяц
Сколько ваша управляемая база данных берёт за vCPU в месяц для используемого класса экземпляров.
Рычаг: Сравните семейства экземпляров и зарезервируйте мощности, когда нагрузка станет предсказуемой.
Реплики для чтения и резервные узлы
Дополнительные копии базы данных для чтения или отказоустойчивости. Каждая повторяет расходы на вычисления, хранилище и IOPS.
Рычаг: Подвергайте сомнению каждую реплику: держите один резервный узел для отказоустойчивости и добавляйте реплики для чтения, только когда чтение действительно в них нуждается.
Данных хранится на пользователя (ГБ)
Среднее число гигабайт хранилища базы данных, которое добавляет каждый пользователь, включая индексы.
Рычаг: Архивируйте старые записи в более дешёвое хранилище, задайте лимиты хранения и сжимайте крупные столбцы.
Как пользоваться этим симулятором
- 1Начните с реалистичного пресета или введите пользователей, выручку на пользователя и параметры текущего экземпляра.
- 2Изучите пять блоков домино и посмотрите, что раньше станет красным: спрос на IOPS или размер экземпляра.
- 3Нажмите «Найти мою точку разрыва», чтобы увидеть нагрузку или число реплик, которые обнуляют прибыль.
- 4Сравните текущую конфигурацию с планом оптимизации на 24-месячном графике.
- 5Каждый квартал проверяйте медленные запросы и неиспользуемые реплики, прежде чем наступит следующая ступень экземпляра.
Каких ошибок избегать
- Считать, что стоимость базы данных растёт пропорционально числу пользователей, хотя она растёт ступенями и умножается репликами.
- Выделять IOPS намного выше того, что использует нагрузка, потому что настройку скопировали с более крупной системы.
- Держать реплики для чтения, которыми не пользуется ни один запрос, и платить за вычисления и хранилище вдвое или втрое.
- Наращивать экземпляр, не посмотрев на медленные запросы и недостающие индексы, которые создали нагрузку.
Часто задаваемые вопросы
Что такое IOPS и почему за них берут плату?
IOPS означает операции ввода-вывода в секунду: сколько операций чтения и записи выполняет уровень хранения. Некоторые уровни хранилища включают базовый объём и тарифицируют выделенную пропускную способность сверх него. Проверьте текущие правила вашего провайдера.
Когда стоит добавлять реплику для чтения?
Когда чтение явно преобладает и основной узел является узким местом либо когда нужны географическая близость или отказоустойчивость. Добавление реплик по привычке умножает весь счёт.
Почему стоимость скачет при определённом числе пользователей?
Экземпляры бывают фиксированных размеров, поэтому пересечение порога переводит вас на следующий размер с примерно вдвое большей ценой. Модель использует размеры в виде степеней двойки, чтобы показать эти скачки.
Что лучше: более крупный экземпляр или больше реплик?
Для записи обычный ответ — более крупный основной узел. Для чтения помогают реплики или кэширование. Правильное сочетание зависит от нагрузки, поэтому измеряйте, прежде чем масштабироваться.
Как найти число пользователей, при котором база данных становится неподъёмной?
Нажмите «Найти мою точку разрыва». Инструмент сдвигает каждый параметр к худшему краю и сообщает значение, при котором месячная прибыль обращается в ноль.
Насколько это точно?
Это учебная модель с иллюстративными ценами, а не инженерное предложение и не консультация. Замените константы текущими ценами вашего провайдера и измеренной нагрузкой.
Это учебная модель планирования с заявленными допущениями. Она не является финансовой, налоговой или юридической консультацией. Подставьте собственные данные и проверяйте важные решения у квалифицированного специалиста.