Новое свойство проекта 3DES

Команда 3DES поставила перед собой задачу оптимизации процесса обработки большого числа моделей при минимальных ресурсных затратах. С этой целью мы спроектировали распределенную биржу вычислительных мощностей, нацеленную на выполнение задачи слайсинга. В процессе проектирования системы родилось предположение, что биржа может быть масштабирована и на другие задачи помимо работы с 3д-моделями. Это предположение подтвердилось, когда мы разработали и протестировали mvp-версию продукта.

Подробнее о разработке MVP:

Первая версия продукта представляет из себя централизованный сервис для обработки 3д-моделей и подготовки их к печати на 3д принтере. Познакомиться с его работой вы можете здесь: https://mvp.3des.network

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

1. Максимальная утилизация производственных мощностей при минимальных потерях на накладные расходы
2. Быстрая и простая доставка программного кода до исполнителя
3. Универсальность решения — мы должны иметь возможность запускать воркер на разных операционных системах и разном железе
4. Простой интерфейс управления

Для достижения результата отвечающего всем этим требованиям мы провели исследование и выделили 3 основных способа решения задачи:

1. Разработка и распространение установочных скриптов
2. Запаковка образов виртуальных машин
3. Контейнеризация

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

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

Таким образом мы остановились на контейнеризации. Уникальность этого подхода заключается в том, что виртуализация происходит на уровне процессов и сервисов, а не на уровне всей операционной системы. Это позволяет создавать полностью изолированную среду для выполнения программного продукта, но само выполнение происходит в рамках ядра самого хоста исполнителя. Такой подходит сводит к минимуму потери производительности виртуализации.

На данный момент существует несколько решений в этой области, но самым популярным и стабильным является Docker. Он и был выбран нашей командой в качестве инструмента контейнеризации.

Docker

Подробно о Docker можно почитать в интернете: https://ru.wikipedia.org/wiki/Docker

или на оффициальном сайте: https://docs.docker.com/engine/docker-overview/.

Мы остановимся на том, почему он подошел именно нам.

Производительность.

Существует несколько исследований производительности работы docker. Вот примеры:

1. http://domino.research.ibm.com/library/cyberdig.nsf/papers/0929052195DD819C85257D2300681E7B/$File/rc25482.pdf
2. https://www.percona.com/blog/2016/02/11/measuring-docker-io-overhead/
3. https://www.percona.com/blog/2016/02/05/measuring-docker-cpu-network-overhead/

Они показывают, что:

1. потери в записи/чтении данных отсутствуют
2. потери CPU незначительны
3. потери сетевого интерфейса также незначительны при некоторых, зависящих от задачи конфигурациях

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

Образы и регистры.

Технологии, на которых построен Docker, позволяют создавать образы, разделенные на «слои». Каждый слой являет собой некий слепок состояния системы после каждого изменения. Такие сервисы как Docker Hub дают возможность легко и быстро распространять наши образы публично или в закрытой группе. Сами образы весят немного по сравнению с образами виртуальных машин. А при обновлении программного продукта, исполнителям необходимо скачивать только измененные слои, а не весь образ целиком. На данным момент это самый быстрый и простой способ доставки программного продукта до его пользователя, или, в нашем случае, исполнителя.

Кроссплатформенность.

Изначально Docker работал только под Linux, что считалось проблемой. Но последние несколько лет активного развития, он получил широкое распространение среди Windows и macOS пользователей. Сейчас все эти платформы активно поддерживаются разработчиками Docker.

Интерфейс.

Технология Docker очень популярна и имеет большую поддержку сообщества. Существует множество документов, статей и инструментов для работы ней. Для управления системой можно использовать консоль, web-интерфейсы и десктоп приложения. Очень широкий выбор позволяет говорить о том, что мы покрываем почти любые требования исполнителей.

Перспективы масштабирования.

На данный момент модуль worker построен на основе связки технологий:

1. Docker
2. Celery
3. Slic3r

И реализации клиента API центрального модуля.

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

Учитывая возможности платформы, на основе данного контейнера можно разработать несколько других, нацеленных на отличные от слайсинга задачи. Это может быть обработка видео, передача интернет трафика между узлами закрытой сети, формирование запросов к серверу, выполнение другого абстрактного программного кода. В случае разработки системы распределенного динамического DNS-менеджмента возможно создание распределенных серверов, которые могут хоститься на машинах исполнителей 3DES вместо классических решений типа Amazon AWS или Digital Ocean. Такие решения позволяют уменьшить затраты или защититься от проблем централизации, например блокировка IP серверов регулирующими органами.

Исходя из проведенного исследования, представленного выше, мы пришли к мнению, что проект 3DES необходимо масштабирования. В ближайшее время мы займемся поиском партнеров для масштабирования 3des из сервиса обработки 3D моделей в универсальную систему децентрализованной обработки информации различных форматов. Иными словами, речь идет о полноценном децентрализованном дата-центре.

В настоящее время мы ведем переговоры с международными группами разработчиков с целью расширения команды для реализации проекта. Мы будем Вас информировать о происходящих процессах. Следите за нашими сообщениями.

С уважением, команда 3DES.