CC BY
9
Архитектура распределенных вычислений, базирующаяся на обработке потока взаимосвязанных задач
А.Е. Капитанов, С.А. Лупин, Московский государственный институт электронной техники, e-mail: albert-k@live.ru, lupin@miee.ru
Введение
В современном мире вычислительных средств существует тенденция распространения средств параллельных и распределенных вычислений в область прикладных задач. В связи с этим фактом появляется необходимость разработки:
• средств быстрой разработки приложений (т.н. RAD-средства) для
области параллельных и распределенных вычислений;
• средств организации параллельных и распределенных вычислений.
В качестве одного из возможных решений рассматривается реализация архитектуры, основанной на модели вычислений, управляемых потоком данных. Сформулируем принципы данной архитектуры:
177. Представление всего прикладного кода как набора программ, каждая из которых характеризуется набором входных параметров и набором результатов.
178. Представление всего вычислительного задания как ориентированного графа, узлами которого являются задачи, ветвями - зависимости входных параметров одной задачи от выходных результатов другой.
179.Исполнение задачи на одном рабочем узле при отсутствии взаимодействия между рабочими узлами. Один рабочий узел в любой момент времени может исполнять не более одной задачи.
180. Передача задачи на рабочий узел по инициативе рабочего узла, по факту его готовности.
Данный подход организовывает распределенные вычисления, исходя из зависимостей по данным между различными частями-задачами всего приложения. Подход подразумевает разделение вычислительного задания на достаточно крупные блоки с четко определенными списками входных и выходных данных. Таким образом, данный подход применим к задачам, относящимся к классу задач с крупнозернистым параллелизмом (coarse-grained parallelism) и с параллелизмом задач (task parallelism).
Вычислительное задание, отправляемое на центральный узел, имеет вид направленного ациклического графа, вершины которого соответст-
вуют отдельным блокам-задачам, а ветви - зависимостям по данным между задачами.
Центральный узел выстраивает очередь задач для исполнения. Для того, чтобы задача была добавлена в очередь, все задачи, от результатов которых она зависит, должны быть вычислены. Если задача не имеет зависимостей, она попадает в очередь немедленно.
Описание прототипа системы
В целях экспериментальной проверки предлагаемой архитектуры был создан прототип программного обеспечения вычислительной системы.
Архитектура прототипа
Пользователь Центральный узел Рабочие узлы
Архитектура прототипа представлена тремя уровнями:
1. Уровень пользователя - ответственен за формирование задания, его отправку и запуск на исполнение. Включает в себя два модуля:
1). Клиентский модуль для организации связи между клиентской программой и центральным узлом,
2). Модуль 1ЛР1, являющийся надстройкой над клиентским модулем и предназначенный для упрощения процесса создания задания.
2. Уровень центрального узла, состоящий из двух независимых подсистем:
1). Планировщик задач - в его обязанности входят:
- распределение задач по рабочим узлам,
- управление зависимостями между задачами (обновление зависимостей между задачами и построение очереди задач, готовых к исполнению).
2). Служба обмена данными, предназначенная для организации обмена данными между рабочими узлами и пользователем. Также данная служба используется для передачи на рабочие узлы исполняемого кода.
3. Уровень рабочих узлов представлен некоторым количеством запущенных на вычислительных узлах процессов-исполнителей, осуществляющих запрос и непосредственное исполнение задач.
Технологическое решение
В качестве технологической базы для создания прототипа и отработки архитектурных решений была выбрана платформа .NET версии 3.5 и язык программирования C#. Для организации каналов связи между уровнями системы использовалась библиотека Windows Communication Foundation, являющаяся стандартным решением из .NET Framework 3.5, предназначенным для организации RPC-коммуникации в распределенных приложениях. Преимуществом данной библиотеки является разделение протокола связи от контракта RPC-службы, что позволяет при необходимости легко перейти к бинарному протоколу связи, не изменяя программный код. Для целей отладки использовался текстовый протокол HTTP.
Тестовая задача
Для отладки и профилирования прототипа системы, оценки производительности и определения узких была выбрана тестовая задача -построение сортированного ограниченного списка частот слов для набора текстовых файлов. Реализация данной задачи с использованием вычислительной схемы «Map-Reduce» достаточно эффективно задается как набор взаимосвязанных задач.
Обрабатываемые файлы
Задачи этапа "Map"
Промежуточные результаты
Задача этапа "Reduce"
Конечный результат
1 г
Map(1)
1 г
> г
Map(2)
1 г
>
Map(3)
1 >
\ <
Map(4)
> г
1 Г ' < 1 Г 1 г
Reduce
Следует отметить, что, помимо схемы «Map-Reduce», подход с использованием графа взаимосвязанных задач в качестве вычислительного задания позволяет также реализовывать и другие вычислительные схемы, представимые в виде графа.
Типизированный обмен данными
Существенной деталью организации распределенных вычислений в данной системе является обмен данными, как между системой и пользователем, так и между вычислительными процессами. Как видно из схемы тестовой задачи, можно выделить два вида обмена данными:
1. Обмен данными в произвольном (нетипизированном) виде - текстовые файлы, файлы изображений и т.п. В тестовой задаче в эту категорию попадают обрабатываемые текстовые файлы.
2. Обмен типизированными данными - списками, словарями, массивами и другими структурами данных. В тестовой задаче в эту категорию попадают файлы промежуточных и окончательных результатов, содержащие в себе упорядоченные списки пар «слово-частота».
Обмен данными в нетипизированной форме непосредственно реализуется службой обмена данными, в то время как обмен данными в типизированной форме требует преобразования данных в потоковое представление (сериализации) и последующего обратного преобразования (десериализации). Поскольку, как видно из тестовой задачи, обмен типизированными данными является типичным сценарием при разработке распределенного ПО, было решено ввести в систему слой типизированного обмена данными - Data Exchange Layer, действующий поверх службы обмена данными:
Data Exchange Layer
Библиотека классов .NET Framework Сервис обмена данными
Данный слой является надстройкой над службой обмена данными, исполняется на рабочих узлах, и предназначен для упрощения процесса сериализации и десериализации данных, передаваемых от процесса к процессу:
Передающая сторона Центральный узел Передающая сторона
0
Таск №1
Сериализация
Сервис обмена данными
Десериализация
Таск №2
w Данные в логическом -Ь. Данные в бинарном
представлении представлении
Поскольку система построена на базе платформы .NET, было решено использовать следующий набор стандартных средств сериализа-ции/десериализации, предоставляемый платформой .NET версии 3.5 и старше:
11. Базовые сериализаторы из базовой библиотеки классов BCL (требуют пометки класса-контейнера данных атрибутом System.SerializableAttribute и наличия конструктора без параметров либо реализации классом интерфейса System.ISerializable):
1) . BinaryFormatter - осуществляет сериализацию во внутреннее
бинарное представление,
2) . XmlSerializer - осуществляет сериализацию в формат XML,
12. Расширенные сериализаторы из библиотеки коммуникации WCF (требуют разметки класса-контейнера данных атрибутами System.Runtime.Serializa-tion.DataContractAttribute и System.Runtime.Serialization.DataMemberAttribute):
1) . DataContractSerializer - осуществляет сериализацию в формат
XML,
2) . DataContractJsonSerializer - осуществляет сериализацию в
формат JSON.
Для обеспечения большей гибкости полученного решения, пользователю предоставляется возможность выбирать сериализатор в каждом конкретном случае, передавая дополнительный параметр в инструментарий и задавая тем самым режим обмена. В случае отсутствия этого параметра будет выбран сериализатор «по умолчанию». Таким образом, возникает проблема выбора одного из вышеуказанных сериализаторов в качестве основного.
Сравнение производительности сериализаторов
Основной характеристикой любого из режимов обмена является производительность обмена. Она складывается из производительности
сервиса обмена данными, производительности инструментария DEL и производительности сериализации и десериализации.
Для анализа производительности различных режимов сериализации были проведены два эксперимента:
• Передача и последующий прием линейной структуры данных - списка элементов, содержащих символьные строки;
• Передача и последующий прием иерархической структуры данных -бинарного дерева, в листьях которого содержатся символьные строки.
Эксперимент №1. Производительность сериализации для линейных структур данных
Объем данных (число записей): 1000 5000 10000 15000 20000 25000
BinaryFormatter Запись 112 мс 273 мс 473 мс 716 мс 984 мс 1115 мс
Чтение 84 мс 322 мс 758 мс 1099 мс 1568 мс 1873 мс
Всего 196 мс 595 мс 1231 мс 1815 мс 2552 мс 2988 мс
DataContractJson Serializer Запись 114 мс 275 мс 391 мс 593 мс 717 мс 885 мс
Чтение 65 мс 250 мс 514 мс 549 мс 785 мс 1107 мс
Всего 179 мс 525 мс 905 мс 1142 мс 1502 мс 1992 мс
DataContractSeria lizer Запись 96 мс 205 мс 503 мс 528 мс 738 мс 941 мс
Чтение 64 мс 187 мс 339 мс 629 мс 696 мс 878 мс
Всего 160 мс 392 мс 842 мс 1157 мс 1434 мс 1819 мс
XmlSerializer Запись 265 мс 484 мс 912 мс 1186 мс 1582 мс 1970 мс
Чтение 69 мс 181 мс 394 мс 559 мс 703 мс 873 мс
Всего 334 665 1306 1745 2285 2843
Эксперимент №2. Производительность сериализации для иерархических структур данных
Объем данных (число записей): 1000 5000 10000 15000 20000 25000
BinaryFormatter Запись 64 185 295 741 1012 1378
Чтение 65 437 949 2850 3851 5062
Всего 129 622 1244 3591 4863 6440
DataContractJsonS erializer Запись 68 156 283 851 1128 1103
Чтение 47 212 369 1181 1498 2102
Всего 115 368 652 2032 2626 3205
DataContract Serializer Запись 84 157 261 750 981 1207
Чтение 40 165 335 934 1314 1827
Всего 124 322 596 1684 2295 3034
XmlSerializer Запись 140 387 671 1747 2565 2696
Чтение 41 186 344 978 1433 1868
Всего 181 573 1015 2725 3998 4564
100 500 1 ООО 1 500 2 000 2 500
Объем данных
Анализ экспериментальных данных и выбор сериализатора «по умолчанию»
В соответствии с результатами замеров производительности в качестве основного был выбран сериализатор DataContractSerializer, обеспечивающий наивысшую производительность сериализации во всех проведенных экспериментах, независимо от структуры и объема данных. Однако использование данного сериализатора требует разметки классов-контейнеров данных атрибутами
System.Runtime.Serialization.DataContractAttribute и
System.Runtime.Se-rialization.DataMemberAttribute, что не всегда возможно, в частности, в случае, когда нежелательно изменять классы-контейнеры данных.
Использование стандартных сериализаторов базовой библиотеки классов BCL, как показал эксперимент, в общем случае не рекомендуется, в связи с недостаточной производительностью.
Также имеет смысл для обеспечения большей гибкости инструментария обмена данными ввести в него поддержку пользовательских се-риализаторов, способных обеспечить максимальную производительность для конкретных классов данных.
Оценка производительности системы
и поиск узких мест в архитектуре
В целях анализа производительности прототипа ключевые участки кода системы и кода тестовой задачи были инструментированы для оценки затрат времени на ключевые операции. Тестирование производилось на одном вычислительном узле с двуядерным процессором, в качестве набора входных данных использовались 4 одинаковых текстовых файла размером 10 Мб каждый. Таким образом, тестовая задача содержала 4 задачи на этапе «Map» и одну задачу на этапе «Reduce». Для сравнения эффективности тестирование проводилось в два этапа:
1 этап: тестирование на узле, на котором запущены процесс центрального узла и один процесс рабочего узла.
2 этап: тестирование на узле, на котором запущены процесс центрального узла и два процесса рабочего узла, таким образом, вычислительное задание исполнялось двумя процессами.
Для исключения случайных погрешностей тестирование было проведено 3 раза, после чего результаты были усреднены.
Усредненные результаты замеров затрат времени на ключевые операции
Операция Абсолютные затраты времени Относительные затраты времени
Запрос задачи из планировщика 10 мс 0,1%
Загрузка кода и запуск задачи 750 мс 9,4%
Чтение задачей входного файла 1200 мс 15,0%
Обработка данных 5200 мс 64,8%
Запись выходного файла 850 мс 10,6%
Выгрузка задачи и освобождение ресурсов 10 мс 0,1%
Выгрузка задачи и освобождение ресурсов Запись выходного файла Обработка данных Чтение задачей входного файла Загрузка кода и запуск задачи Запрос задачи из планировщика
0,0% 10,0% 20,0% 30,0% 40,0% 50,0% 60,0% 70,0%
Производительность планировщика задач
Как показало тестирование, реализация планировщика имеет достаточно высокую производительность. При наличии задач в очереди выполнения планировщика затраты времени на получение следующей задачи рабочим процессом не превышают 10 мс, что является незначительной величиной по сравнению со временем работы исполняемой задачи.
Производительность уровня исполнения
По результатам оценок, затраты времени на служебные нужды среды исполнения не превышают 10% от общих затрат времени на исполнение задачи. Следует отметить, что эта величина слабо зависит от вычислительной сложности задачи, следовательно, относительные затраты времени на работу среды исполнения будут уменьшаться с увеличением времени работы собственно исполняемой задачи. Т.о. при разбиении вычислительного задания на достаточно крупные подзадачи эффективность системы будет достаточно высокой.
Затраты времени в этой категории складываются из затрат времени на несколько операций:
-4
Операция Усредненные относительные затраты времени
Создание «песочницы» для исполнения задачи 6%
Загрузка кода задачи посредством службы обмена данными 92%
Инициализация загруженной задачи 1%
Выгрузка задачи и высвобождение используемых ресурсов 1%
Как следует из замеров производительности, узким местом в данном случае является операция загрузки кода задачи.
Производительность службы обмена данными
Помимо результатов, указанных в предыдущем пункте, также проводились замеры затрат времени на чтение и запись задачами файлов данных.
Операция Усредненные относительные затраты времени
Чтение входного файла 16%
Обработка данных 72%
Запись файла с результатами 12%
Как следует из замеров производительности, 28% от всего времени работы задачи тратится на ввод/вывод, что также является узким местом в системе.
Выводы
Применимость предлагаемого подхода к созданию распределенных приложений
Тестирование показало, что предлагаемый подход к созданию распределенных приложений в целом жизнеспособен. Он обладает рядом преимуществ по сравнению с традиционными системами на основе обмена сообщениями:
1. Вычислительный код отделен от коммуникационного кода, притом коммуникационный код является частью системы, что сокращает объем кода, необходимого для решения задачи.
2. Вычислительный код для каждой из задач представляет собой отдельный класс, что обеспечивает широкие возможности юнит-тестирования отдельных частей приложения.
В качестве недостатка можно отметить следующее: данный подход эффективен для ограниченного класса задач. Критерием применимости является возможность эффективного разбиения вычислительного зада- 593 -
ния на отдельные блоки достаточно большого размера. В качестве примера таких задач можно привести:
• поисковые задачи;
• задачи извлечения данных;
• задачи машинного обучения.
Технические вопросы реализации прототипа системы В процессе тестирования планировщик задач показал достаточно высокую производительность, в связи с чем можно заключить, что дальнейшая оптимизация планировщика задач не является актуальной.
Служба обмена данными, несмотря на проделанную работу по оптимизации, на данный момент является узким местом, ограничивающим производительность системы, вследствие чего дальнейшие работы по оптимизации данной службы являются приоритетными.
Другим слабо проработанным вопросом является проблема удобного создания вычислительных заданий как направленных ациклических графов. На данный момент для этого реализовано два способа:
1. Использование протокола передачи описаний задач JobManager от пользователя к центральному узлу. Данный способ не является удобным для пользователя в связи с низкоуровневостью этого протокола.
2. Использование модуля JAPI, являющегося надстройкой над протоколом JobManager и предназначенного для упрощения процесса генерации вычислительных заданий. Развитие библиотеки является одной из приоритетных задач для дальнейшей разработки.
В то время как протокол JobManager на данный момент является достаточно устоявшимся, средства модуля JAPI являются весьма ограниченными. Можно наметить несколько путей дальнейшего расширения:
1. Разработка и поддержка внутреннего DSL-языка для удобного и гибкого задания вычислительных графов.
2. Разработка средств генерации вычислительных графов во время исполнения, базирующихся на таких средствах среды .NET, как внутриязыковые LINQ-запросы и деревья выражений.
3. Разработка набора библиотечных средств для быстрой реализации простых вычислительных схем, таких, как Map-Reduce.
Наличие в системе простых и удобных средств задания вычислительных графов позволит в полной мере раскрыть преимущества, предоставляемые предлагаемым подходом. Литература
1. В.В. Воеводин, Вл.В. Воеводин «Параллельные вычисления»
2. Джеффри Рихтер «CLR via C#»
3. С. А. Лупин, М. А. Посыпкин «Технологии параллельного
»
