Платные IOPS: как облако продаёт вам один диск дважды

MAATRIX

Вы арендовали диск на 500 ГБ, посмотрели на цену за гигабайт и решили, что посчитали стоимость хранения. А через месяц в углу счёта обнаружилась отдельная строка — IOPS сверх базового уровня, потому что база данных или очередь сообщений упёрлись в лимит и провайдер молча включил платный овербуст. По факту вы заплатили за один и тот же диск дважды: один раз за место, которое он занимает, и второй раз за то, с какой скоростью к этому месту можно обращаться. Разберёмся, почему облако так считает, откуда там вообще берётся отдельный счётчик IOPS и что в этой схеме принципиально отличается от аренды сервера с физическим NVMe.

Что такое IOPS и почему это отдельная характеристика, а не производная от объёма

IOPS (input/output operations per second) — количество операций чтения и записи, которое система хранения успевает обработать за секунду. Это не то же самое, что пропускная способность в мегабайтах в секунду: операция ввода-вывода может быть маленьким блоком в 4 КБ (случайное чтение записи из индекса базы данных) или крупным блоком в несколько мегабайт (последовательное чтение видеофайла). При одинаковой пропускной способности диск с мелкими случайными операциями требует на порядки больше IOPS, чем диск с крупными последовательными.

Физически объём хранения и скорость доступа к нему — независимые параметры. Объём — это количество ячеек флеш-памяти (или выделенных блоков в распределённой системе). Производительность — это то, сколько параллельных операций контроллер и интерфейс успевают обслужить: глубина очереди команд, пропускная способность шины или сети, латентность носителя. Купить много ёмкости не значит автоматически купить много скорости, и наоборот. Именно из этой физической независимости и вырастает коммерческая возможность тарифицировать их раздельно.

На локальном NVMe-накопителе IOPS — фиксированное свойство модели чипа и контроллера, указанное производителем в спецификации: купить у него чуть больше IOPS для того же физического диска нельзя, только другой диск. Подробнее о том, что реально стоит за паспортной цифрой производительности и почему она недостижима на практике, — в статье «Что такое IOPS на самом деле и почему цифра недостижима». В облаке всё иначе: диск, который вы видите как блочное устройство /dev/vdb, физически не привязан к одному куску железа под вашей виртуальной машиной.

Почему облачный диск — это не кусок железа, а квота на удалённой системе

Ключевое архитектурное отличие большинства облачных дисков (persistent disk, EBS-подобных сервисов, managed block storage) от локального SSD — это не физический носитель, подключённый напрямую к виртуалке, а том на распределённой системе хранения, доступ к которому идёт по сети: через аналог iSCSI, NVMe-over-Fabrics или проприетарный протокол провайдера. Виртуальная машина обращается к диску не через локальную шину PCIe, а через сетевой стек: запрос на запись уходит с гипервизора на storage-кластер, реплицируется там на несколько узлов ради отказоустойчивости, подтверждается — и только после этого операция считается завершённой.

Это даёт провайдеру удобства: диск можно "отвязать" от одной виртуалки и "привязать" к другой без физического переноса данных, делать снапшоты силами системы хранения, менять размер тома на лету, размещать реплики в разных стойках. Но у архитектуры есть прямое следствие — производительность диска теперь зависит не только от вашего тома, а от всей общей инфраструктуры: сетевого канала гипервизора, загрузки storage-узлов, числа соседей, которые в этот момент тоже пишут на тот же кластер. Поэтому провайдеру нужен механизм QoS (quality of service) — программное ограничение, сколько операций в секунду конкретному тому разрешено взять из общего пула. Без него один "шумный сосед" мог бы забрать всю пропускную способность кластера и посадить производительность у остальных клиентов узла.

Вот и весь технический фундамент платных IOPS: раз производительность — это управляемый программно лимит на разделяемом ресурсе, а не физическое свойство вашего куска флеш-памяти, этим лимитом можно торговать отдельно от объёма. Провайдер продаёт вам квоту на использование общей инфраструктуры, а не сам физический диск.

Как устроено разделение "объём отдельно, скорость отдельно" в прайсинге

Типичная модель облачного блочного хранилища работает по одной из двух логик (или их комбинации):

Базовый уровень IOPS, привязанный к объёму диска. Вам дают какое-то количество операций в секунду на каждый гигабайт ёмкости — условно, N IOPS на ГБ, с нижним и верхним потолком. Хотите больше операций — либо увеличивайте объём диска (даже если реальные данные туда не помещаются и половина места простаивает), либо переходите на более дорогой класс хранилища.

Провижининг IOPS как отдельный ресурс. Вы покупаете объём диска и отдельно — гарантированное число IOPS, независимо от объёма. Это похоже на аренду отдельно "квадратных метров склада" и отдельно "пропускной способности погрузчиков, которые могут туда заезжать одновременно".

В обоих случаях итоговый счёт складывается минимум из двух чисел, а не из одного — и это принципиально иная модель, чем "просто диск на 500 ГБ за фиксированную цену". Таблица ниже показывает логику (без привязки к конкретному провайдеру и без реальных цифр — только структура тарифа):

На практике это может превратиться и в три платных измерения одного и того же диска: гигабайты, операции в секунду и мегабайты в секунду — отдельно, на некоторых тарифных планах у некоторых провайдеров. Точные тарифы у каждого свои и меняются, но принцип общий: у диска в облаке может быть больше одной оси тарификации, и это не техническая случайность, а осознанная модель монетизации.

Почему провайдеру выгодно продавать это раздельно, а не одной ценой

С точки зрения экономики поставщика инфраструктуры разделение объёма и производительности — рациональный шаг по нескольким причинам.

Во-первых, у объёма и производительности разная себестоимость и разная эластичность спроса. Хранить неактивные, "холодные" гигабайты дёшево — это занятая флеш-память, почти не нагружающая контроллер. А обслуживать высокую интенсивность операций дорого: это загрузка сети, процессора storage-узлов, контроллеров NVMe на бэкенде, репликации между узлами. Продавать всё это одной ценой за гигабайт означало бы либо завышать её для всех, либо терять маржу на клиентах с интенсивной нагрузкой. Раздельная тарификация берёт деньги именно с того, кто потребляет дорогой ресурс, не размазывая его стоимость по всем поровну.

Во-вторых, это классическая ценовая дискриминация по сегментам спроса: продавать base tier дёшево, а всё, что нужно требовательным нагрузкам — базам данных, очередям, поисковым индексам, — выносить в premium-надстройку. Клиент с сайтом-визиткой почти никогда не упрётся в лимит IOPS и заплатит только за объём. Клиент с транзакционной базой упрётся почти гарантированно — и это тот самый момент апсейла на provisioned IOPS.

В-третьих, это инструмент управления нагрузкой на общую инфраструктуру. Жёсткие лимиты IOPS на базовом тарифе одновременно защищают от "шумных соседей": без них у провайдера не было бы экономического сдерживающего фактора против клиентов, заваливающих storage-кластер операциями бесплатно. Цена на IOPS одновременно монетизирует ресурс и рационирует его.

Где базового уровня IOPS реально не хватает

Базовый уровень IOPS, идущий "бесплатно" с объёмом диска, на практике часто рассчитан на равномерную, не слишком интенсивную нагрузку — что-то вроде файлового хранилища или редко читаемого архива. Реальные рабочие нагрузки этому профилю не соответствуют:

• Реляционные базы данных (PostgreSQL, MySQL) генерируют много мелких случайных операций записи из-за WAL/binlog, checkpoint'ов, обновления индексов B-tree — именно тот паттерн, где IOPS упирается в потолок первым, задолго до исчерпания объёма или пропускной способности в МБ/с.
• Очереди сообщений (Kafka, RabbitMQ) при высокой интенсивности публикации создают поток записи с частыми fsync — тоже упирается в лимит операций на сетевом диске.
• CI/CD окружения с частым созданием/удалением слоёв образов дают всплески мелких операций метаданных файловой системы.
• Поисковые индексы и векторные базы при построении индекса создают интенсивную случайную запись, которая на базовом тарифе может растянуть операцию с минут до часов.

Когда нагрузка упирается в лимит, происходит одно из двух: провайдер троттлит операции (латентность резко растёт, приложение "подвисает" без явной ошибки), либо автоматически включается платный овербуст — и вы узнаёте об этом постфактум по счёту, хотя не принимали осознанного решения платить больше. Чтобы заранее понять, во что реально упирается диск, полезно снять честный профиль нагрузки инструментом fio — как это делать, разобрано в статье «fio для честного замера диска», а разница между последовательным и случайным паттерном доступа, которая определяет требуемый IOPS, — в статье «Последовательная и случайная запись на SSD».

Как считать реальную стоимость диска в облаке — и с чем сравнивать физический NVMe

Чтобы честно посчитать, во сколько вам обходится хранение в облаке, объём в счёте недостаточен — нужно закладывать вторую переменную:

Реальная_стоимость_диска = Цена_за_ГБ * Объём
                          + Цена_за_IOPS_сверх_базового * (Пиковая_нагрузка_IOPS - Базовый_IOPS)
                          + (опционально) Цена_за_throughput_сверх_базового

Проблема этой формулы не в арифметике, а в том, что "пиковую нагрузку IOPS" заранее правильно оценить сложно. Она зависит от профиля запросов приложения, который меняется во времени: сегодня операций в секунду достаточно, через полгода рост базы клиентов и более тяжёлые отчётные запросы поднимают требование в разы. В облаке это плавающая, трудно прогнозируемая статья расхода, растущая вместе с успехом продукта — именно тогда, когда бюджет и так под давлением роста.

Теперь сравним с сервером, где диск — физический NVMe, подключённый напрямую по PCIe к тому же шасси, где стоит процессор. У такого диска нет второго счётчика по одной причине: производительность здесь не является управляемым программно ресурсом, разделяемым между чужими нагрузками. Вы не делите контроллер и очередь команд NVMe с чужими виртуальными машинами на соседнем storage-узле — весь IOPS, который способен выдать чип, физически ваш, потому что диск целиком в вашем распоряжении. Производителю нечего продавать сверху: паспортная производительность накопителя фиксирована в момент покупки железа провайдером, а не в момент вашей аренды.

Это не значит, что у физического диска нет ограничений — есть предел самого чипа, деградация по мере заполнения (write amplification и wear leveling у SSD), возможная конкуренция за диск между процессами на одной машине, если это разделяемый VPS с локальным хранилищем. Но здесь нет искусственного коммерческого разделения "мало базового IOPS — доплати за то же железо, но быстрее". Диск либо арендован с определённой физической производительностью, либо нет — и она не меняется от того, сколько вы готовы доплатить в этом месяце.

Практический вывод для расчёта TCO: сравнивая облако и аренду сервера с локальным NVMe, нужно закладывать в облачную колонку не только цену за гигабайт, но и реалистичную оценку provisioned/burst IOPS под пиковую, а не среднюю нагрузку — иначе сравнение окажется нечестным в пользу облака на старте и обманчивым через полгода роста. Более полная методика такого сравнения на горизонте нескольких лет — в статье «Выделенный против облака: TCO на три года».

Что делать, если вы уже платите за IOPS сверх базового уровня

Прежде чем платить за повышенный тариф производительности, стоит проверить три вещи. Во-первых, действительно ли упор в IOPS, а не в неоптимальные запросы приложения: лишние индексы, отсутствие батчинга записи, слишком частые fsync там, где допустима асинхронная запись, искусственно завышают число операций к диску. Во-вторых, не смешаны ли в одном томе разнородные нагрузки — например, логи и данные СУБД: разнесение на отдельные тома часто снимает конкуренцию за IOPS без доплаты. В-третьих, полезно посмотреть на реальную утилизацию диска через iostat -x 1 (колонки %util, await, avgqu-sz) и сопоставить с тем, что показывает fio на синтетическом тесте — если реальная нагрузка на порядок ниже "паспортного" лимита, повышенный тариф решает не ту проблему.

iostat -x 1
# смотрим на %util (близко к 100% — диск действительно узкое место)
# и await (растущая латентность — признак упора в IOPS, а не в throughput)

Если после этой диагностики выясняется, что нагрузка объективно требует стабильно высокого числа операций в секунду — реляционная база под нагрузкой, очередь с высоким rps, — тогда разумный шаг это не доплата за очередной уровень облачного provisioned IOPS, а пересчёт экономики в сторону физического NVMe, где нужная производительность уже включена в стоимость диска и не превращается в отдельную растущую статью счёта.

Частые вопросы