Блог

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

В ходе этого видео объемом 1 ГБ разбивается на несколько ГБ промежуточных данных. Этот сервис написан так, что каждая часть конвейера может обрабатываться другой программой (через RabbitMQ). Конечно, процесс не обязательно должен выполняться таким образом, что подводит меня к моему вопросу.

Я рассматриваю требования к хранилищу для того, чтобы приложение стало «живым». С облачными провайдерами вы платите за ГБ хранилища и за ГБ передачи. Пока все хорошо.

Когда я переношу этот большой видеоблок объемом 1 ГБ из одного экземпляра облачной виртуальной машины в другой или с виртуальной машины в общую службу хранения, учитывается ли это в моей пропускной способности? (Я понимаю, что этот ответ будет меняться в зависимости от условий обслуживания хоста.)

Было бы разумнее, если бы 1 виртуальная машина выполняла весь процесс, а затем запускала несколько его экземпляров? В отличие от 1 виртуальной машины, выполняющей только одну задачу в конвейере? Я задаю этот вопрос с точки зрения оптимизации затрат (самая низкая стоимость хранения, самая низкая стоимость развертывания виртуальных машин. Поскольку кодирование будет происходить в пакетном режиме, я меньше беспокоюсь о быстрой отправке запросов).

Этот сценарий немного уникален тем, что у меня есть огромные объемы двоичных данных, которые невозможно эффективно хранить, скажем, в базе данных. Возникает аналогичный вопрос: для тех, у кого есть опыт, когда ваша виртуальная машина DB отправляет свои результаты обратно в ваше веб-приложение, взимается ли с вас плата за эту промежуточную передачу?

Я вообще задаю правильные вопросы? Есть ли руководство, которое я должен прочитать, кроме как позвонить хостинг-провайдерам и спросить их о ценах самостоятельно?

Я бы сказал, уникальность вашего сценария делает его довольно интересным!

О передаче данных между виртуальными машинами в облаке, это зависит от поставщика и местоположений. Amazon, например, в EC2 не взимает плату за передачу данных между веб-службами в одном и том же местоположении. Таким образом, вы можете минимизировать затраты на передачу вплоть до начальной загрузки вашего «большого количества двоичных данных».

Теперь, можно ли эффективно распараллелить вашу задачу? Если да, рассмотрите возможность одновременного запуска большого количества виртуальных машин, чтобы ускорить выполнение работы. Это, безусловно, экономически выгодно, если время = деньги, но я неохотно отношусь к вашему случаю, потому что вы упоминаете, что вас меньше беспокоит быстрое внесение изменений. У вас все еще может быть основная виртуальная машина, обрабатывающая запросы и координирующая пакеты, и запускающая-выключающая другие виртуальные машины, которые будут обрабатывать часть рабочей нагрузки. Вы платите до тех пор, пока ваша виртуальная машина работает, как утилита.

Хорошая вещь в вашем сценарии заключается в том, что такого рода пакетные задачи идеально подходят для облачных вычислений, а их модель ценообразования довольно проста. Такие задачи требуют больших ресурсов (CPU / RAM), поэтому их «жадность» может быть удовлетворена практически неограниченными ресурсами, которые может предложить облако.