Что означает IOPS (в Amazon EBS) на практике?

У меня есть некоторые изображения, необходимые для приложения. Существует много изображений (50 000+), но общий размер небольшой (40 Мб). Первоначально я думал, что просто буду использовать S3, но это очень медленно загружать. В качестве временного решения я хотел приложить EBS, содержащую изображения, и это было бы хорошо. Однако, немного прочитав об общем назначении EBS (gp2), я заметил следующее описание:

GP2 - это тип тома EBS по умолчанию для экземпляров Amazon EC2. Эти объемы поддерживаются твердотельными накопителями (SSD) и подходят для широкий спектр транзакционных нагрузок, включая dev/test среды, интерактивные приложения с малой задержкой и загрузочные тома. GP2 предназначен для одношаговых миллисекундных задержек, доставить согласованная базовая производительность 3 IOPS/GB до максимума 10000 IOPS и обеспечивают пропускную способность до 160 МБ/с на каждый том.

Это 3 количества IOPS/GB, которые беспокоят меня. Что это означает в практическом плане? Предположим, что вам нужен сайт электронной коммерции для небольшого количества пользователей (например, < 10 000 запросов в минуту), и эти изображения необходимо получить. Amazon описывает, как измеряются IOPS:

Когда небольшие операции ввода-вывода физически смежны, Amazon EBS пытается объединить их в один ввод-вывод до максимального размера. Для Например, для томов SSD одна операция ввода/вывода 1 024 KiB будет считаться как 4 операции, в то время как 256 операций ввода-вывода при 4 KiB будут считаться как 256 операций.

Означает ли это, что если я хочу получить 50 изображений по 10 кбайт каждый в секунду, мне потребуется 50 IOPS и легко превысить базовую линию из 3 IOPS?

UPDATE

Благодаря предложению Mark B, я смог использовать S3 для загрузки моих файлов. Тем не менее, мне все еще интересно узнать о количестве IOPS, необходимых для выполнения общих задач, таких как запуск базы данных или обслуживание других файлов для веб-приложения. Я был бы рад услышать некоторые ссылочные значения относительно минимальных значений IOPS на основе вашего опыта.

Ответ 1

Вам не хватает части "/GB" этого оператора. Исходный уровень составляет 3 IOPS за GB. Если ваш объем EBS равен 100 ГБ, то у вас будет базовый уровень в 300 IOPS. Для объема GP2 EBS вам нужно увеличить размер тома на 3, чтобы получить IOPS.

Обратите внимание, что любой том GP2 под 1TB также может разрываться до 3000 IOPS, поэтому любое ограниченное увеличение IO должно все же работать очень хорошо.

Кроме того, я добавлю, что S3 звучит как лучше подходит для вашего случая использования. Если вы видите медленную скорость загрузки на S3, это проблема, которая может быть решена. Вы можете использовать CloudFront, чтобы предоставить соседнее местоположение края, которое вы можете загрузить.

По моему опыту загрузка на S3 никогда не будет медленнее, чем загрузка в экземпляр EC2, к которому будет подключен ваш том EBS.

Update:

Чтобы ответить на ваш дополнительный вопрос, минимальный необходимый IOPS будет зависеть от многих переменных, таких как объем оперативной памяти, тип приложения, которое вы используете, насколько приложение кэширует значения в памяти, средний размер операций ввода-вывода и т.д. Очень сложно определить точное число и указать, что вам нужно именно X IOPS для приложения.

Вам также необходимо помнить, что любой том размером менее 1 ТБ может разыграть до 3000 IOPS в течение нескольких секунд. Поэтому, даже если вашему приложению нужны высокие IOPS, когда он используется, если он не видит многого использования, функция всплеска IOPS может быть все, что ему когда-либо понадобится.

В общем, я обычно начинаю с чего-то вроде объема 100 ГБ с 300 IOPS и проверял производительность моего приложения против этого. Веб-сервер, который работает полностью в ОЗУ, может не понадобиться больше. Для чего-то вроде базы данных вы, вероятно, начнете с объема дискового пространства, которое, по вашему мнению, вам понадобится, а затем начните тестирование производительности. CloudWatch покажет количество IOPS, которое использует ваше приложение, и если вы видите, что оно максимизируется в пределах вашего тома, вы должны знать, что вам нужно увеличить доступный IOPS. Промойте и повторите, пока вы не превысите максимальный доступ к IOPS во время тестов производительности.

Ответ 2

@Mark B ответ, вероятно, правильный, поскольку он указывает, что ваши IOPs основаны на размере вашего объема EBS. Для чего вы хотите, S3 - лучший вариант.

Но в зависимости от вашего варианта использования и требований может потребоваться EBS. Это особенно актуально, если вы хотите запустить базу данных. В этом случае у вас есть несколько вариантов.

Вы можете получить Provisioned IOPS - если вы знаете, что вам нужно 5000 IOPS, но вам нужно только 100 ГБ хранения (которое с gp2 обычно предоставляет вам около 300 IOPS), вы можете использовать тома io1. Для этого есть дополнительные затраты, и вы захотите убедиться, что они привязаны к оптимизированному экземпляру EBS, но при необходимости вы можете получить до 20k IOPS.

Если вы делаете много последовательных чтений (чтение в большом наборе данных?), тогда появляется новый тип EBS, st1. Это хорошо для 500 Мбайт/с и меньше 1/2 стоимости gp2.

Наконец, есть еще один сценарий, который вы могли бы рассмотреть (скажем, вы немного сумасшедший и хотите попробовать странные вещи). Если вы можете где-то захватить архив, и все, о чем вы заботитесь, обслуживает их из действительно быстрой файловой системы, вы можете разместить их на экземпляре с хранилищем экземпляров. Это локально подключенный SSD, поэтому он очень быстрый. Единственный недостаток заключается в том, что когда ваш экземпляр останавливается, данные пропадают.

Чтобы обратиться к вашему обновлению, "сколько IOPS вам нужно для базы данных", ответ "это зависит". Каждый механизм базы данных имеет разные требования, и каждое использование базы данных имеет разные шаблоны использования. Посмотрите этот, если хотите получить дополнительную информацию. Но в основном, тест и монитор. Если вы беспокоитесь, по поводу обеспечения при запуске и при необходимости уменьшите масштаб. Или угадайте, и увеличивайте, если у вас возникнут проблемы - важнее ли минимизировать затраты или обеспечить хорошую производительность для ваших конечных пользователей?