Разработка менеджера ресурсов и сервиса авторизации для многопользовательской платформы распределенных вычислений

Размещено на http://www.allbest.ru/

Федеральное государственное автономное образовательное учреждение высшего образования

«Национальный исследовательский университет «Высшая школа экономики»

Факультет компьютерных наук

Основная образовательная программа «Прикладная математика и информатика»

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА Программный проект на тему Разработка менеджера ресурсов и сервиса авторизации для многопользовательской платформы распределенных вычислений

Выполнил студент группы БПМИ166, 4 курса,

Фавстов Олег Сергеевич

Руководитель ВКР: Доцент, кандидат технических наук,

Сухорослов Олег Викторович

Москва, 2020



Содержание

1. Аннотация

2. Введение

3. Обзор литературы

3.1 Everest

3.2 BOINC

3.3 Выводы

4. Архитектура платформы Sky

4.1 Менеджер заданий и планировщик

4.2 Менеджер данных

4.3 Агент

4.4 Менеджер ресурсов

4.5 Менеджер пользователей

4.6 Обратный прокси сервер

5. Описание решений

5.1 Обратный прокси-сервер

5.2 Менеджер пользователей

5.3 Менеджер ресурсов

6. Тестирование системы

Заключение

Библиографический список



1. Аннотация

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

Annotation

Popularity of distributed computing grows every year. However modern systems that can operate with distributed computing are too complex for ordinary users. This paper describes multi-tenant distributed computing platform, which goal is to simplify interactions between users and their computing resources. It automates most parts of routine related to running computing and maintaining resources up to date. Platform follows Platform as a Service (PaaS) cloud delivery model. The three parts of the platform that were implemented as part of this work are described in more detail: reverse proxy server, resource manager and user manager.

Ключевые слова: распределенные вычисления, микросервисная архитектура, REST API, платформа как сервис



2. Введение

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

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

Многопользовательская платформа распределенных вычислений, о которой пойдет речь в данной работе, упрощает взаимодействие пользователя со своими вычислительными ресурсами, взяв на себя большую часть задач, связанных с отправкой задач на машины, сбором данных и логов, слежением за выполняемыми задачами и т.д. К платформе можно подключать различные виды ресурсов: персональные компьютеры, Unix-сервера, созданные в облачных системах виртуальные машины, а также аккаунты в Amazon AWS, которые будут использоваться для автоматического создания виртуальных машин по мере необходимости.

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

Целью работы является реализация менеджера ресурсов и менеджера пользователей, а также реализация обратного прокси-сервера.

Для достижения целей были поставлены следующие задачи:

• Реализовать HTTP и gRPC интерфейсы менеджера ресурсов

• Реализовать HTTP и gRPC интерфейсы менеджера пользователей

• Реализовать обратный прокси-сервер, поддерживающий авторизацию пользователей по токенам

• Реализовать команды интерфейса командной строки, соответствующие реализованным HTTP обработчикам.

HTTP интерфейсы необходимы для обработки пользовательских запросов, а gRPC [1] используется для общения между частями платформы.

В результате работы поставленные задачи были выполнены.

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



3. Обзор литературы

интерфейс вычисление ресурс менеджер

В данном разделе рассматриваются схожие по области применения программные решения, выявляются их достоинства и недостатки.

3.1 Everest

Everest - облачная платформа, предназначенная для публикации, выполнения и композиции вычислительных приложений в распределенной среде [2]. Основная задача, которая решается платформой Everest - дать исследователям, публикующим свои статьи, простой способ делиться результатами своей деятельности с общественностью. После публикации приложения в платформе у пользователей появляется возможность воспользоваться приложением в веб-интерфейсе платформы или через REST API. Другой важной чертой платформы является возможность запускать пользователем такие приложения на произвольных комбинациях ресурсов, которые были подключены к платформе.

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

Ресурсы подключаются к платформе Everest с помощью программы-агента, который подключается к системе по протоколу WebSocket [3], который позволяет обмениваться сообщениями в обе стороны. Отмечается, что такой подход, в сравнении с обычным SSH доступом к ресурсу, позволяет подключать к платформе ресурсы, скрытые за файерволом или NAT. Это очень важная идея, которая также используется в платформе Sky, но уже с использованием более современного протокола двунаправленной потоковой передачи на основе gRPC.

Ключевым элементом платформы Everest является вычислительный мост [4], который выполняет большую часть задач системы. К примеру, при поступлении задачи на выполнение именно вычислительный мост выполняет перевод из входящего запроса в вычислительную задачу, а также скачивает входные данные для задачи. После выполнения задачи именно вычислительный мост переводит выходные данные в конечный результат, а также сохраняет результаты в хранилище. Здесь явно можно увидеть, что вычислительный мост является узким местом системы, так как в какой-то момент при больших нагрузках он может перестать успевать отвечать на запросы или при большом количестве обрабатываемых файлов одновременно может кончиться запас сети.

3.2 BOINC

Berkeley Open Infrastructure for Network Computing (BOINC) [5] - открытая программная платформа, предназначенная для организации распределенных вычислений. BOINC был одной из первых систем добровольных грид-вычислений и был спроектирован как бесплатная структура для всех, кто хотел бы начать проект распределенных вычислений.

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

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

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

Для оперирования проектами BOINC предоставляют Python-скрипты и интерфейсы для C++. Отмечается простота использования этих средств и полнота документации, так как основными пользователями системы являются исследователи, не обязательно обладающие глубокими знаниями в области программирования.

Клиентское приложение BOINC, которое занимается непосредственными вычислениями, может работать на системах Android, Windows, Unix и Mac OS, что увеличивает потенциальную вычислительную мощность, доступную для использования. BOINC является системой добровольных вычислений, из-за чего появляется необходимость ограничивать количество потребляемых ресурсов, будь то процессорное время, память или трафик. Поэтому в большинстве случаев задачи на устройство загружаются заранее и не поддерживается постоянное соединение с серверами системы. Принятие решений о выполнении конкретной задачи из пула загруженных принимается на конкретном устройстве, учитывая текущую загрузку устройства, а также крайние сроки выполнения задач.

3.3 Выводы

Платформа Everest имеет в себе множество хороших решений, которые были переиспользованы в платформе Sky:

* Приложения Everest по сути своей являются задачами в терминах платформы Sky, так как представляют собой некую функцию с входами и выходами. Разница состоит в том, что задачи не являются долгоживущими процессами, задачи доставляются на ресурсы только в нужное время, выполняются и прекращают свою работу. Кроме того, задача после себя оставляет некоторое количество артефактов в виде результатов, логов и дампов стандартных потоков. Из таких задач можно создавать различные задания разной степени сложности.

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

* Создание исходящих подключений от агента по протоколу WebSocket позволяет подключать к системе даже персональные компьютеры, а также дает возможность обходить файерволы и NAT. В платформе Sky это решение было переиспользовано, но на смену WebSocket пришли более современные двунаправленные потоки на основе gRPC, которые имеют более строгую схему и ряд других преимуществ.

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

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



4. Архитектура платформы Sky

Для того, чтобы перейти к описанию личного вклада в платформу, необходимо остановиться на её общей архитектуре. Многопользовательская платформа распределенных вычислений Sky была спроектирована в микросервисной архитектуре [6], которая поощряет модульный подход, где каждый модуль - каждый микросервис - отвечает за свою выделенную часть системы. Такой подход упрощает масштабирование платформы и повышает автономность системы, так как в случае отказа одной части, остальные части могут продолжать работу, если для конкретных операций не требуется участие отказавшей части.

На рисунке 4.1 можно видеть общую архитектуру платформы Sky. Платформа состоит из ряда модулей, каждый из которых работает независимо. Взаимодействия между элементами платформы происходит посредством вызова gRPC методов. Пользователь взаимодействует с системой с помощью интерфейса командной строки (CLI), который переводит пользовательские команды в HTTP запросы и отправляет их на обратный прокси. Остановимся более подробно на каждом элементе системы.



Рис. 4.1 Архитектура платформы Sky 10

3.4 Менеджер заданий и планировщик

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

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



3.5 Менеджер данных

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

3.6 Агент

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

3.7 Менеджер ресурсов

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

Будучи единственным компонентом системы, который имеет непосредственный доступ к ресурсам, менеджер ресурсов занимается поддержанием постоянного соединения с каждым активным агентом и занимается отправкой команд от менеджера данных и планировщика к агенту, а также уведомляет их в случае потери связи с агентом, что чаще всего свидетельствует о падении агента и потере данных. Отправка таких событий позволяет планировщику перезапускать задачи, которые не были выполнены.

3.8 Менеджер пользователей

Менеджер пользователей отвечает за информацию о пользователях и группах пользователей, предоставляет HTTP интерфейс для клиентов, а также gRPC методы для получения данных о текущих группах конкретного пользователя. Объединение пользователей в группу позволяет упростить процессы, связанные с выдачей прав на конкретные ресурсы/данные. Например, если компания владеет рядом ресурсов и все сотрудники компании могут ими пользоваться, то достаточно создать группу из всех сотрудников и дать права на ресурсы группе. Тогда при увеличении численности сотрудников не придется раздавать каждому из них права на все ресурсы, а достаточно добавить этих сотрудников в уже существующую группу.

3.9 Обратный прокси сервер

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



4. Описание решений

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

Компоненты реализованы на языке Go, который был выбран из-за своего удобства написания веб-приложений с микросервисной архитектурой, а также из-за его простоты и эффективности в многопоточной среде. Для взаимодействия между частями платформы используется высокопроизводительный RPC фреймворк gRPC, который широко используется в системах с микросервисной архитектурой. Фреймворк обладает важной возможностью - возможностью потоковой двунаправленной передачи сообщений, основанной на HTTP/2. Этим способом передаются сообщения между агентами и менеджером ресурсов.

4.1 Обратный прокси-сервер

Как было сказано ранее, платформа представляет собой несколько независимых микросервисов, связанных между собой gRPC методами. Однако, каждая из частей системы должна иметь ряд HTTP методов для пользовательских запросов, связанных с данными конкретного модуля.

Каждый из модулей платформы имеет свой собственный адрес, и для того, чтобы избавить пользователей системы от необходимости знать структуру системы (было бы нужно знать про каждый запрос, к какому модулю он относится), обычно используется обратный прокси-сервер, который служит входной точной для соединения пользователя с серверами. Он определяет на какой сервер будет передан каждый конкретный запрос клиента.

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

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

Для каждого запроса однозначно определяется к какой конечной точке он относится, затем, если выставлен флаг, производится авторизация по токену, который ожидается в заголовке “User-Token”. В случае успешной авторизации в заголовок “User-Id” проставляется идентификатор пользователя, а в случае неудачи пользователю отдается ошибка. Затем запрос направляется на конечный сервер.

Реализация на GitHub: https://github.com/dc-lab/sky/tree/master/reverse proxy

4.2 Менеджер пользователей

Менеджер пользователь отвечает за хранение информации о пользователях и группах пользователей. Для хранения используется реляционная СУБД PostgreSQL.

Для клиентов платформы менеджер обладает HTTP интерфейсом:

• POST /register - запрос на регистрацию пользователя. Возвращает объект пользователя с регистрационными данными, а также идентификатором и токеном, который нужно использовать для авторизации в системе;

• POST /login - запрос на вход в систему. Возвращает такой же объект, что и при регистрации пользователя;

• POST /change_password - запрос на смену пароля. Приводит к сбросу токена;

• GET /groups - запрос на получение всех групп, в которых состоит пользователь;

• POST /groups - запрос на создание группы;

• GET /groups/{id} - запрос на получение группы с конкретным id;

• DELETE /groups/ {id} - запрос на удаление группы с конкретным id;

• POST /groups/{id} - запрос на модификацию группы с конкретным id, принимает на вход списки идентификаторов пользователей на добавление и на удаление;

Помимо этого, менеджер предоставляет gRPC метод для получения списка групп конкретного пользователя, который нужен для менеджера ресурсов при получении списка доступных пользователю ресурсов.

Реализация на GitHub: https://github.com/dc-lab/sky/tree/master/user manager

4.3 Менеджер ресурсов

Менеджер ресурсов отвечает за хранение информации о ресурсах, а также за организацию взаимодействия с агентами.

Пользовательский HTTP интерфейс содержит следующие методы:

• POST /resources - создать ресурс

• GET /resources - получить список ресурсов пользователя

• GET /resources/{id} - получить информацию про конкретный ресурс

• DELETE /resources/{id} - удалить конкретный ресурс

• POST /resources/{id} - модифицировать ресурс с конкретным id

Про каждый ресурс менеджер хранит следующую информацию: идентификатор, имя, владелец ресурса, список пользователей и список групп пользователей, которые имеют доступ к ресурсу. Эти данные хранятся в реляционной СУБД PostgreSQL.

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

Рассмотрим протокол общения менеджера ресурсов с агентом. Общение происходит с использованием потоковой двунаправленной передачи сообщений по gRPC в формате protobuf [7]. Запросы имеют следующий формат:

Рис. 5.1 Формат сообщения от менеджера ресурсов к агенту



Рис. 5.2 Формат сообщения от агента к менеджеру ресурсов

При подключении к менеджеру агент отправляет сообщение типа TGreetings, в котором посылает токен ресурса. Это необходимо для того, чтобы понимать на каком именно ресурсе запущен агент. Сообщения любого другого типа игнорируются до тех пор, пока не будет предоставлен зарегистрированный в системе токен.

При создании задания в платформе планировщик принимает решение, на каком ресурсе необходимо запустить задачи. В случае, если для выполнения задачи требуются какие-либо файлы, менеджер данных посылает запрос на загрузку данных в менеджер ресурсов, а он в свою очередь транслирует сообщение типа TStageInRequest на нужный ресурс. После чего агент загружает данные с менеджера данных по HTTP и передает на менеджер ресурсов запрос типа TStageInResponse, который сигнализирует об окончании загрузки ресурсов или содержит ошибку. Это событие передается в менеджер данных, что активизирует дальнейшую обработку задачи.

После доставки данных менеджер заданий отправляет запрос на запуск задачи на ресурсе, который транслируется в запрос типа TTaskRequest. После этого агент начинает выполнение задачи. Текущий статус задачи приходит с некоторой периодичностью на менеджер ресурсов в сообщении типа TTaskResponse, эти сообщения передаются на менеджер заданий, который использует их для отображения текущего статуса задачи пользователю.

После окончания обработки задачи менеджер данных обращается к менеджеру ресурсов с запросом на скачивание файлов с ресурса, этот запрос транслируется в сообщение типа TStageOutRequest, в ответ агент посылает список выходных файлов в сообщении TStageOutResponse и начинает загрузку файлов на менеджер данных по HTTP.

Кроме того, предусмотрены запрос на остановку уже запущенной задачи TCancelTaskRequest и запрос на удаление результатов задачи TDeleteTaskRe- quest.

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

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

Реализация на GitHub: https://github.com/dc-lab/sky/tree/master/resource manager



5. Тестирование системы

Было проведено интеграционное тестирование платформы, в котором каждый из компонентов системы был поднят на серверах, выделенных в сервисе Яндекс Облако. После этого была заполнен конфигурационный файл обратного прокси сервера, в котором были указаны все HTTP методы системы с соответствующими адресами серверов, а также были заполнены конфигурационные файлы компонент, в каждом из которых указываются адреса остальных компонент для доступа к gRPC методам.

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

Также было проверено, что перезапуск элементов системы (временное падение) не приводит к отказом системы в целом.

Проверить какое количество ресурсов может быть подключено к системе не удалось из-за недостатка физических машин, на которых можно было бы запустить агента.



Заключение

Поставленные задачи были выполнены и в результате были получены готовые к использованию компоненты: обратный прокси-сервер, менеджер ресурсов и менеджер пользователей. Менеджеры имеют HTTP интерфейсы для взаимодействия с пользователем, а также обладают gRPC методами для нужд других компонент системы. Также был реализован интерфейс командной строки, позволяющий легко обращаться к HTTP методам менеджеров.

Из перспектив дальнейшей деятельности по развитию реализованных компонент платформы можно назвать перенесение хранения сообщений к ресурсам в базы данных, что позволило бы запускать одновременно несколько серверов менеджера ресурсов, к которым могли бы независимо обращаться агенты и другие компоненты системы. Это дало бы возможность выдерживать больше количество запросов в секунду и большее количество одновременно подключенных агентов. Ещё одним улучшением было бы хранение информации о загрузке ресурсов в колоночных СУБД для того, чтобы пользователь мог получать информацию о нагрузке в динамике.



Библиографический список

1. ”gRPC” [Электронный ресурс] Доступен: https://grpc.io. [Дата обращения: 20.05.2020]

2. Sukhoroslov O., Volkov S., Afanasiev A. A Web-Based Platform for Publication and Distributed Execution of Computing Applications // 14th International Symposium on Parallel and Distributed Computing (ISPDC). IEEE, 2015, pp. 175-184.

3. Fette and A. Melnikov, “The WebSocket Protocol,” RFC 6455 (Proposed Standard), Internet Engineering Task Force, Dec. 2011. [Электронный ресурс]. Доступен: http://www.ietf.org/rfc/rfc6455.txt. [Дата обращения: 20.05.2020]

4. Sukhoroslov O., Afanasiev A. Everest: A Cloud Platform for Computational Web Services. In Proceedings of the 4th International Conference on Cloud Computing and Services Science (CLOSER 2014). SCITEPRESS - Science and and Technology Publications, 2014, pp. 411-416.

5. D. P. Anderson, "BOINC: a system for public-resource computing and storage," Fifth IEEE/ACM International Workshop on Grid Computing, Pittsburgh, PA, 2004, pp. 4-10, doi: 10.1109/GRID.2004.14.

6. Jamshidi, P., Pahl, C., Mendonca, N., Lewis, J. and Tilkov, S. (2018). Microservices: The Journey So Far and Challenges Ahead. IEEE Software, 35(3), pp.24-35.

7. “Protocol Buffers,” Google. [Электронный ресурс]. Доступен: https://de- velopers.google.com/protocol-buffers. [Дата обращения: 20.05.2020].

Размещено на Allbest.ru

...