Kubernetes, анализ данных и бессерверные вычисления команда Яндекс.Облака представила шесть новых


Оглавление (нажмите, чтобы открыть):

Бессерверные вычисления: что это такое и почему это важно

Предприятиям простительно думать, будто бессерверные вычисления — всего лишь одна из вызвавших много шума технических концепций. В действительности же она наполнена серьезным содержанием, пишет на портале ComputerWeekly Стюарт Бёрнс, эксперт по виртуализации и Linux.

Термин появился недавно. А концепция зародилась лет десять назад, когда ее неудачно попыталась реализовать некая забытая ныне компания.

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

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

Определение

Иногда термин некорректно применяется к контейнерам, микросервисам и другим абстракциям. В действительности же он обозначает «функцию как сервис» (Function as a Service, FaaS).

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

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

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

Важнее, наверное, то, что эластичное горизонтальное масштабирование становится очень простым.

Снижение затрат

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

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

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

Поясним вопрос о расходах на простом примере. Использование виртуальной машины в облаке Amazon Web Services обойдется в несколько десятков долларов в месяц, а при бессерверных вычислениях — на две трети дешевле. Но этот показатель может сильно варьироваться, поэтому нет единого решения на все случаи жизни.

Минусом является то, что все осуществляется через вызовы API и потому зависит от корректности программ и вызовов.

Целесообразность перехода

Прежде чем переходить на бессерверные вычисления ради сокращения расходов следует принять во внимание некоторые обстоятельства.

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

Следует также отметить, что в бессерверных вычислениях применяются не все языки программирования. Следует поинтересоваться, какие из них использует выбранный провайдер FaaS. AWS Lamba, например, поддерживает Go, Node.js, Java, C# и Python.

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

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

Кластеры Kubernetes в облаке

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

Начать пользоваться

Когда сложное становится проще

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

Быстрое создание тестовых сред, автоматизация процессов непрерывной интеграции и доставки (CI/CD).

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

Как работает сервис

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

Преимущества Kubernetes

Легкое масштабирование и развертывание

Управляйте состоянием и размером кластера, исходя из нагрузки на проект. Расширяйте кластер во время пиковых нагрузок и уменьшайте его, когда нагрузка на ресурс падает.

Простая миграция приложений

Легко переносите контейнеризированные приложения в облако Selectel. Полная совместимость приложений, работающих в стандартной среде Kubernetes, гарантирована.

Быстрый старт

Создавайте кластер Kubernetes, просто указав характеристики и нужное количество нод в панели управления Selectel.

Без дополнительных платежей

Платите только за потребленные ресурсы виртуальных машин: ядра, память, диски, плавающие IP, балансировщик нагрузки.

Свежие версии

Работайте с последними версиями Kubernetes для обеспечения совместимости с вашей инфраструктурой.

Удобная работа с кластерами Kubernetes

Prometheus и Grafana для мониторинга состояния кластера

Следят за нагрузкой кластера и визуализируют метрики в пользовательском интерфейсе. Kubernetes разворачивает Prometheus и Grafana по умолчанию, вам не нужно ничего делать самим.

Управление через Kubernetes Dashboard и kubectl

С помощью графического интерфейса для Kubernetes можно просматривать статус и детальную информацию объектов кластера, а также управлять ими. Сервис запускается в кластере по умолчанию.

Балансировщики нагрузки

В кластере можно запустить внутренний и внешний балансировщики нагрузки.


  • Ingress Controller (Traefik) настроит внешние URL и терминирует SSL для приложений, запускаемых внутри кластера.
  • Балансировщик нагрузки Selectel распределит трафик между мастер-нодами.

Готовы начать использовать?

Обратите внимание

Облачные серверы

Используйте масштабируемые облачные серверы Selectel для решения своих задач.

Выделенные серверы

Арендуйте серверы для решения любых задач.

Облачное хранилище

Работайте в высокопроизводительном объектном хранилище данных от Selectel.

Kubernetes – Serverless computing своими руками

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

Идея безсерверных (serverless) вычислений заключается в том, что она позволяет вам, как разработчику, сосредоточиться только на написании кода. При использовании подхода безсерверных вычислений вы просто загружаете код куда-нибудь, а дальше он сам запускается всякий раз, когда вы или сторонний сервис его вызываете. Проще говоря, безсерверные вычисления освобождают вас от сложностей создания контейнеров Docker или настройки и поддержки кластеров Kubernetes.

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

Для начала экспериментов с безсерверными вычислениями вам понадобятся:

Если работающий кластер Kubernetes у вас уже есть, то далее мы с вами сделаем следующее:

  • Запустим Dashboard в Kubernetes кластере
  • Установим Kubeless
  • Напишем облачную функцию
  • Зарегистрируем нашу функцию в Kubeless
  • Вызовем написанную нами функцию

Запуск Kubernetes Dashboard

Если у вас уже есть запущенный кластер Kubernetes, то скорее всего Dashboard у вас уже установлена. Проверить это можно командой:

$ kubectl get pods —all-namespaces | grep dashboard

Если Dashboard отсутствует, выполните следующую команду:

$ kubectl create -f https://git.io/kube-dashboard

Доступ к Dashboard по-умолчанию осуществляется через проксирование к нему запросов командой

$ kubectl proxy Starting to serve on 127.0.0.1:8001

Сам Dashboard при этом становится доступен по адресу http://localhost:8001/ui .

Как только доступ к Kubernetes Dashboard получен, можно переходить к установке Kubeless.

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

Используйте следующие команды для установки Kubeless:

$ curl -L https: //github.com/skippbox/kubeless/releases/download/0.0.7/kubeless_linux-amd64.zip > kubeless.zip

We are going to install the controller in the kubeless namespace . Are you OK with this : [Y/N]

INFO[ 0002 ] Initializing Kubeless controller. pkg=controller

INFO[ 0002 ] Installing Kubeless controller into Kubernetes deployment. pkg=controller

INFO[ 0005 ] Kubeless controller installation finished! pkg=controller

INFO[ 0005 ] Installing Message Broker into Kubernetes deployment. pkg=controller

INFO[ 0007 ] Message Broker installation finished! pkg=controller

Далее можно либо скопировать kubeless в /usr/local/bin , либо прописать его расположение в $PATH . Я выберу первый вариант:

$ sudo cp kubeless /usr/ local /bin

Протестируйте работу Kubeless, выполнив команду:

$ kubeless function ls

NAME HANDLER RUNTIME TYPE TOPIC NAMESPACE

Если зайти в Kubernetes Dashboard, можно увидеть пространство имен kubeless , которое дополнительно покажет, что Kubeless был успешно установлен.

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

Вот не сложный пример:

for post in posts:

ПРИМЕЧАНИЕ: эта функция для простоты понимания сознательно написана без какой-либо обработки ошибок или проверок ввода. Не используйте эту функцию в ваших реальных приложениях.

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

Сохраните эту функцию в файле, например, /tmp/test-function.py и переходите к следующему разделу.

Регистрация функции в Kubeless


Наш следующий шаг — зарегистрировать функцию с помощью Kubeless. Регистрация функции с помощью Kubeless включает в себя передачу Kubeless следующей информации:

  • Имя, которое вы будете использовать для доступа к функции
  • Протокол, к которому вы будете обращаться к функции (здесь, HTTP)
  • Окружение, в котором будет исполняться запущенный код (здесь, Python)
  • Имя файла, содержащего код функции
  • Имя функции внутри файла

Вся эта информация легко передается в Kubeless при помощи команды kubeless function create :

$ kubeless function create get_titles —trigger-http —runtime python27 —handler test-function.get_titles —from-file /tmp/test-function.py

Давайте разберем этот пример:

Команда kubeless create get_titles сообщает Kubeless зарегистрировать новую функцию с именем get_titles . Эта функция будет доступна по сети по протоколу HTTP. Обратите внимание, что имя не обязательно должно быть точно таким же, как имя функции в фале.

—trigger-http сообщает Kubeless, что функция будет вызываться через HTTP. Также можно запускать функцию другими способами, но это не тема данной статьи.

—runtime python27 сообщает Kubeless, что необходимо использовать Python 2.7 для исполения кода.

—handler test-function.get_titles сообщает Kubeless имя функции для вызова внутри Python модуля. Вы наверняка заметили в приведенном выше коде Python, что функция называется get_titles() .

—from-file /tmp/test-function.py сообщает Kubeless, что необходимо загрузить и использовать файл /tmp/test-function.py в качестве исходника для этой функции.

Как только команда завершит выполнение, проверьте, что функция зарегистрирована в Kubeless, используя команду kubeless function ls :

$ kubeless function ls

Чтобы удалить эту функцию, выполните команду:

$ kubeless function create get_titles —trigger-http —runtime python27 —handler test-function.get_titles —from-file /tmp/test-function.py

Давайте разберем этот пример:

Команда kubeless create get_titles сообщает Kubeless зарегистрировать новую функцию с именем get_titles . Эта функция будет доступна по сети по протоколу HTTP. Обратите внимание, что имя не обязательно должно быть точно таким же, как имя функции в фале.

—trigger-http сообщает Kubeless, что функция будет вызываться через HTTP. Также можно запускать функцию другими способами, но это не тема данной статьи.

—runtime python27 сообщает Kubeless, что необходимо использовать Python 2.7 для исполения кода.

—handler test-function.get_titles сообщает Kubeless имя функции для вызова внутри Python модуля. Вы наверняка заметили в приведенном выше коде Python, что функция называется get_titles() .

—from-file /tmp/test-function.py сообщает Kubeless, что необходимо загрузить и использовать файл /tmp/test-function.py в качестве исходника для этой функции.

Как только команда завершит выполнение, проверьте, что функция зарегистрирована в Kubeless, используя команду kubeless function ls :

$ kubeless function ls

Чтобы удалить эту функцию, выполните команду: $ kubeless function delete get_titles

Бессерверные вычисления в облаке – тренд современности или необходимость?

Как известно, ранее веб-приложения разворачивались на веб-серверах, работающих исключительно на физических машинах, и зачастую разработчику программного обеспечения нужно было знать о тонкостях сервера. А чтобы приложение полноценно функционировало, помимо разработки, требовалось потратить время на установку, конфигурацию и подключение всевозможных компонентов решения, не говоря о выполнении регулярных обновлений ОС и обеспечении безопасности. Хотя управление серверами – прямая обязанность системного инженера, эти задачи зачастую ложились на плечи разработчиков. Но с появлением облака многое изменилось: теперь в приоритете бессерверный подход. О том, что это такое и как здесь помогает облако, расскажем далее.

Особенности разработки ПО

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

От физических серверов к облаку

За последние десятилетия облачные технологии заметно продвинулись и улучшились. Изменения произошли на уровне сети и платформы, а также затронули операционные системы и приложения. То, с чем приходится работать сейчас, практически потеряло сходство с тем, что было ранее. Вспомним 90-е годы: для запуска сервисов разработчики использовали физические серверы, а процесс установки ОС и приложений, включая настройку и конфигурацию, занимал много времени. И если возникала необходимость масштабировать физические серверы, процедура обходилась довольно дорого. Это не могло продолжаться вечно – перемены были неизбежны.

И действительно, появились виртуальные машины и гипервизор, которые помогли сократить время, затрачиваемое на создание новой вычислительной единицы, до нескольких минут, а с появлением контейнеров – и вовсе до считанных секунд. Параллельно развился и созрел DevOps, что привело к еще большему распространению провайдеров и IaaS (инфраструктуры как услуги) и PaaS (платформы как услуги). Теперь клиенты делегируют решение задач провайдерам, освобождая себя от проблем с серверами, установкой ПО и многого другого. А если в ходе работы приложению потребуется больше ресурсов, их всегда можно нарастить буквально в несколько кликов.

Особенности serverless-подхода

Следующий значительный шаг в облачном подходе связан с появлением в обиходе термина «бессерверный», который, по сути, представляет собой «функцию как услугу» (FaaS).

С другой стороны, serverless – это подход к разработке программного обеспечения, целью которого является устранение необходимости управления инфраструктурой путем:

  • Использования функции как услуги для выполнения кода.
  • Использования внешних служб и API (сторонних продуктов, предоставляемых по модели SaaS).

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

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

Текст подготовлен с использованием материала Cloud Zone

Бессерверные вычисления

Знакомство с бессерверными технологиями

Что такое бессерверные вычисления?

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

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

Основные преимущества бессерверных вычислений

Забудьте об управлении инфраструктурой

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

Динамическая масштабируемость

Бессерверные вычисления позволяют динамически увеличивать и уменьшать масштаб инфраструктуры в считаные секунды в соответствии с требованиями любой рабочей нагрузки.

Ускоренный вывод на рынок


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

Более эффективное использование ресурсов

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

Шаблоны бессерверных приложений

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

Бессерверные функции

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

Бессерверная служба Kubernetes

Разработчики могут использовать собственные контейнеры в полностью управляемых кластерах, которые оркестрирует Kubernetes. Масштаб таких кластеров можно автоматически увеличивать и уменьшать при внезапных изменениях объема трафика, свойственных нестабильным рабочим нагрузкам.

Бессерверные рабочие процессы

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

Среды бессерверных приложений

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

Бессерверный шлюз API

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

Преимущества комплексной бессерверной платформы

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

Бессерверные вычисления: что это такое и почему это важно

Предприятиям простительно думать, будто бессерверные вычисления — всего лишь одна из вызвавших много шума технических концепций. В действительности же она наполнена серьезным содержанием, пишет на портале ComputerWeekly Стюарт Бёрнс, эксперт по виртуализации и Linux.

Термин появился недавно. А концепция зародилась лет десять назад, когда ее неудачно попыталась реализовать некая забытая ныне компания.

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

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

Определение

Иногда термин некорректно применяется к контейнерам, микросервисам и другим абстракциям. В действительности же он обозначает «функцию как сервис» (Function as a Service, FaaS).

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

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

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

Важнее, наверное, то, что эластичное горизонтальное масштабирование становится очень простым.

Снижение затрат

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

Мастер Йода рекомендует:  Грамотная стратегия брендинга – залог успешного продвижения

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

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

Поясним вопрос о расходах на простом примере. Использование виртуальной машины в облаке Amazon Web Services обойдется в несколько десятков долларов в месяц, а при бессерверных вычислениях — на две трети дешевле. Но этот показатель может сильно варьироваться, поэтому нет единого решения на все случаи жизни.

Минусом является то, что все осуществляется через вызовы API и потому зависит от корректности программ и вызовов.

Целесообразность перехода

Прежде чем переходить на бессерверные вычисления ради сокращения расходов следует принять во внимание некоторые обстоятельства.

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

Следует также отметить, что в бессерверных вычислениях применяются не все языки программирования. Следует поинтересоваться, какие из них использует выбранный провайдер FaaS. AWS Lamba, например, поддерживает Go, Node.js, Java, C# и Python.

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

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

Kubernetes – Serverless computing своими руками

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

Идея безсерверных (serverless) вычислений заключается в том, что она позволяет вам, как разработчику, сосредоточиться только на написании кода. При использовании подхода безсерверных вычислений вы просто загружаете код куда-нибудь, а дальше он сам запускается всякий раз, когда вы или сторонний сервис его вызываете. Проще говоря, безсерверные вычисления освобождают вас от сложностей создания контейнеров Docker или настройки и поддержки кластеров Kubernetes.

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

Для начала экспериментов с безсерверными вычислениями вам понадобятся:

Если работающий кластер Kubernetes у вас уже есть, то далее мы с вами сделаем следующее:

  • Запустим Dashboard в Kubernetes кластере
  • Установим Kubeless
  • Напишем облачную функцию
  • Зарегистрируем нашу функцию в Kubeless
  • Вызовем написанную нами функцию

Запуск Kubernetes Dashboard


Если у вас уже есть запущенный кластер Kubernetes, то скорее всего Dashboard у вас уже установлена. Проверить это можно командой:

$ kubectl get pods —all-namespaces | grep dashboard

Если Dashboard отсутствует, выполните следующую команду:

$ kubectl create -f https://git.io/kube-dashboard

Доступ к Dashboard по-умолчанию осуществляется через проксирование к нему запросов командой

$ kubectl proxy Starting to serve on 127.0.0.1:8001

Сам Dashboard при этом становится доступен по адресу http://localhost:8001/ui .

Как только доступ к Kubernetes Dashboard получен, можно переходить к установке Kubeless.

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

Используйте следующие команды для установки Kubeless:

$ curl -L https: //github.com/skippbox/kubeless/releases/download/0.0.7/kubeless_linux-amd64.zip > kubeless.zip

We are going to install the controller in the kubeless namespace . Are you OK with this : [Y/N]

INFO[ 0002 ] Initializing Kubeless controller. pkg=controller

INFO[ 0002 ] Installing Kubeless controller into Kubernetes deployment. pkg=controller

INFO[ 0005 ] Kubeless controller installation finished! pkg=controller

INFO[ 0005 ] Installing Message Broker into Kubernetes deployment. pkg=controller

INFO[ 0007 ] Message Broker installation finished! pkg=controller

Далее можно либо скопировать kubeless в /usr/local/bin , либо прописать его расположение в $PATH . Я выберу первый вариант:

$ sudo cp kubeless /usr/ local /bin

Протестируйте работу Kubeless, выполнив команду:

$ kubeless function ls

NAME HANDLER RUNTIME TYPE TOPIC NAMESPACE

Если зайти в Kubernetes Dashboard, можно увидеть пространство имен kubeless , которое дополнительно покажет, что Kubeless был успешно установлен.

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

Вот не сложный пример:

for post in posts:

ПРИМЕЧАНИЕ: эта функция для простоты понимания сознательно написана без какой-либо обработки ошибок или проверок ввода. Не используйте эту функцию в ваших реальных приложениях.

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

Сохраните эту функцию в файле, например, /tmp/test-function.py и переходите к следующему разделу.

Регистрация функции в Kubeless

Наш следующий шаг — зарегистрировать функцию с помощью Kubeless. Регистрация функции с помощью Kubeless включает в себя передачу Kubeless следующей информации:

  • Имя, которое вы будете использовать для доступа к функции
  • Протокол, к которому вы будете обращаться к функции (здесь, HTTP)
  • Окружение, в котором будет исполняться запущенный код (здесь, Python)
  • Имя файла, содержащего код функции
  • Имя функции внутри файла

Вся эта информация легко передается в Kubeless при помощи команды kubeless function create :

$ kubeless function create get_titles —trigger-http —runtime python27 —handler test-function.get_titles —from-file /tmp/test-function.py

Давайте разберем этот пример:

Команда kubeless create get_titles сообщает Kubeless зарегистрировать новую функцию с именем get_titles . Эта функция будет доступна по сети по протоколу HTTP. Обратите внимание, что имя не обязательно должно быть точно таким же, как имя функции в фале.

—trigger-http сообщает Kubeless, что функция будет вызываться через HTTP. Также можно запускать функцию другими способами, но это не тема данной статьи.

—runtime python27 сообщает Kubeless, что необходимо использовать Python 2.7 для исполения кода.

—handler test-function.get_titles сообщает Kubeless имя функции для вызова внутри Python модуля. Вы наверняка заметили в приведенном выше коде Python, что функция называется get_titles() .

—from-file /tmp/test-function.py сообщает Kubeless, что необходимо загрузить и использовать файл /tmp/test-function.py в качестве исходника для этой функции.

Как только команда завершит выполнение, проверьте, что функция зарегистрирована в Kubeless, используя команду kubeless function ls :

$ kubeless function ls

Чтобы удалить эту функцию, выполните команду:

$ kubeless function create get_titles —trigger-http —runtime python27 —handler test-function.get_titles —from-file /tmp/test-function.py

Давайте разберем этот пример:

Команда kubeless create get_titles сообщает Kubeless зарегистрировать новую функцию с именем get_titles . Эта функция будет доступна по сети по протоколу HTTP. Обратите внимание, что имя не обязательно должно быть точно таким же, как имя функции в фале.

—trigger-http сообщает Kubeless, что функция будет вызываться через HTTP. Также можно запускать функцию другими способами, но это не тема данной статьи.

—runtime python27 сообщает Kubeless, что необходимо использовать Python 2.7 для исполения кода.

—handler test-function.get_titles сообщает Kubeless имя функции для вызова внутри Python модуля. Вы наверняка заметили в приведенном выше коде Python, что функция называется get_titles() .


—from-file /tmp/test-function.py сообщает Kubeless, что необходимо загрузить и использовать файл /tmp/test-function.py в качестве исходника для этой функции.

Как только команда завершит выполнение, проверьте, что функция зарегистрирована в Kubeless, используя команду kubeless function ls :

$ kubeless function ls

Чтобы удалить эту функцию, выполните команду: $ kubeless function delete get_titles

Бессерверные вычисления: облачная инфраструктура нового поколения

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

Вероятно, это звучит знакомо: облачной инфраструктурой в виде сервиса конечным пользователям тоже управлять не требуется, этим занимаются провайдеры – Amazon Web Services, Microsoft Azure и др. Так называемые бессерверные вычисления развивают эту концепцию: облачные сервисы выполняют код, написанный разработчиками, расходуя ровно столько ресурсов, сколько для этого нужно – ни больше ни меньше. Как только наступает заранее заданное событие, запускающее код, бессерверная платформа выполняет задачу. Конечному пользователю не нужно уведомлять провайдера о том, как часто будут происходить события-триггеры. Каждый раз, когда выполняется функция, заказчик платит доли цента. Некоторые считают, что данную концепцию лучше было бы назвать «функциями в виде сервиса» (functions as a service, FaaS) или «событийно-зависимыми вычислениями».

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

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

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

Особенности бессерверных вычислений

Считается, что создателем нового рынка стала компания Amazon Web Services, представившая в 2014 году платформу бессерверных вычислений Lambda. По словам Мэтта Вуда, генерального менеджера AWS по стратегии, новшество было создано по образцу одного из самых популярных продуктов компании – Simple Storage Service, или S3.

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

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

В традиционной облачной среде IaaS пользователи готовят к работе виртуальные машины, хранилища, базы данных, а также инструменты обеспечения безопасности и администрирования. Затем на виртуальные машины загружаются приложения, а для масштабирования ресурсов используются балансировщики нагрузки и другие средства. С помощью административного ПО оптимизируется размер экземпляров и осуществляется поиск виртуальных машин, непреднамеренно оставленных во включенном состоянии. Lambda и другие платформы FaaS предлагают другую модель. Код предоставляется в форме функций. Когда происходит событие, вызывающее такую функцию, Lambda ее выполняет. Больше ничего не требуется – не нужны планирование мощности и балансировка нагрузки, только задания, которые надо выполнять.

По словам Вуда, это удобно в целом ряде случаев. Например, можно написать функцию Lambda, которая всякий раз при загрузке снимка в S3 будет создавать его копии различных размеров для настольных компьютеров, смартфонов и планшетов. Возможно также создание функции, которая при каждом внесении записи в базу данных будет загружать ее в хранилище Amazon Redshift для последующего анализа. Многие заказчики, пользуясь Lambda, связывают сервисы AWS друг с другом для формирования отчетов, планирования и подготовки данных к анализу.

Еще одна важная область применения – крупномасштабные среды Интернета вещей с мгновенным откликом. Недавно в AWS представили платформу Greengrass, позволяющую выполнять функции Lambda на устройствах без надежных средств связи, когда не всегда есть возможность передать данные в облако. Например, функция Lambda может выполняться непосредственно на камере видеонаблюдения, каждый раз при распознавании движения включая запись и отправляя съемку в базу. Отпадает нужда в виртуальной машине, круглосуточно работающей в ждущем режиме, – событийно-зависимый код выполняется автоматически всякий раз, когда наступает соответствующее событие. В компании FireEye, поставляющей средства сетевой безопасности, признаются, что, благодаря использованию Lambda вместо экземпляров EC2, удалось сократить затраты на виртуальные машины на 80%.

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

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

Недостатки

Бессерверные вычисления не панацея, и у них есть свои недостатки. В частности, сам рынок еще очень незрелый. Управлять крупномасштабными приложениями, работающими в бессерверном режиме, весьма сложно, отмечает Крейг Лаури, директор по исследованиям Gartner. Не хватает инструментов для координации выполнения групп функций. Слабо развито соответствующее ПО безопасности, мониторинга и оптимизации. Бессерверные вычисления требуют от разработчиков иного подхода к созданию приложений, и это, возможно, самое важное. «В этом отношении существует целый ряд требований, обусловленных архитектурными ограничениями подобных платформ», – поясняет Лаури.

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

Существует и еще одна опасность – это привязка к оператору. Приложение, разработанное для какой-либо FaaS-платформы, не так-то просто перенести на другую – локальную или действующую в публичном облаке. Поскольку рынок еще очень молод, сегодня у каждой бессерверной платформы свой особый набор компонентов. AWS Lambda, в частности, тесно интегрирована со многими другими продуктами AWS. По словам Вуда, поскольку Lambda поддерживает популярные языки программирования, такие как Node.js, Python и Java, в принципе код приложений Lambda можно переносить. «Специального языка для работы с Lambda нет», – подчеркивает Вуд.

В целом, как считает Лаури, бессерверные вычисления, или FaaS, – весьма мощная альтернатива существующим вычислительным парадигмам, основанным на виртуальных машинах и контейнерах: «Lambda – это нечто совершенно новое. Уверен, что в дальнейшем многие будут создавать эффективные крупномасштабные приложения, целиком базирующиеся на бессерверных платформах. Но они подходят не для всех задач». Например, в Lambda не смогут работать базы данных и другие приложения, требующие сохранения состояния.

Рынок бессерверных платформ

После AWS, которая первой предложила платформу бессерверных вычислений, аналоги появились и у других крупных поставщиков IaaS. По словам Вуда, на самом деле многие сервисы AWS являются «бессерверными» – не только Lambda, но также S3, NoSQL-СУБД DynamoDB и размещаемая реляционная СУБД Aurora. Все эти продукты не требуют от пользователя предварительного планирования расхода ресурсов и администрирования инфраструктуры.

Пользователи Lambda получают до миллиона бесплатно обрабатываемых запросов в месяц, а каждый последующий миллион стоит 20 центов. В AWS тоже взимают плату по тарифу, зависящему от затрат времени на вычисления, – по 0,00001667 долл. в расчете на гигабайт в секунду; время округляется до 0,001 мс.

Аналогичные расценки действуют для сервиса Microsoft Azure Functions, общедоступная версия которого была введена в действие в ноябре прошлого года. Google Functions, в свою очередь, сейчас находится в стадии бета-версии, предлагается до 2 млн бесплатных запросов в месяц. Стоимость выполнения одной транзакции в Google Functions чуть выше, а тарифы на время обработки ниже. В IBM не публикуют расценки на пользование OpenWhisk. По словам топ-менеджеров, отличительная особенность платформы бессерверных вычислений IBM – разработка в открытых кодах в качестве проекта Apache Software Foundation. Теоретически заказчикам дается возможность выполнять код OpenWhisk где угодно.

Еще есть ряд стартапов, предлагающих платформы бессерверных вычислений, а также их компоненты и административные инструменты. В качестве примера можно привести компанию Iron.io, которая предлагает соответствующий сервис на основе контейнеров Docker.

Как отмечают в Gartner, рынок бессерверных вычислений еще настолько молод, что пока ни победителей, ни проигравших нет, хотя дольше всех на нем работает AWS. Важнее всего, считают аналитики, определиться, для чего можно использовать бессерверные системы. Например, FaaS может выполнять роль «клея» для различных сервисов в облаке конкретного оператора, но приложения Интернета вещей не обязательно привязывать к конкретному облаку.

– Brandon Butler. Serverless explainer: The next generation of cloud infrastructure. Network World. April 3, 2020

Поделитесь материалом с коллегами и друзьями

Применение облачных вычислений для анализа данных большого объема в умных городах Текст научной статьи по специальности « Автоматика. Вычислительная техника»

Аннотация научной статьи по автоматике и вычислительной технике, автор научной работы — Массобрио Рензо, Несмачнов Серхио, Черных Андрей, Аветисян Арутюн, Радченко Глеб

В этой статье рассматривается вопрос применения анализа данных большого объема с использованием облачных вычислений для решения задач анализа дорожного траффика в контексте «умных» городов. Предложенное решение базируется на модели параллельных вычислений MapReduce, реализованной на платформе Hadoop. Анализируются два экспериментальных случая: оценка качества общественного транспорта на основе анализа истории местоположения автобусов, и оценка мобильности пассажиров при помощи анализа истории покупок билетов с транспортных карт. Оба эксперимента используют реальную базу данных системы общественного транспорта Монтевидео в Уругвае. Результаты эксперимента показали, что рассмотренная модель действительно позволяет эффективно обрабатывать большие объемы данных .

Похожие темы научных работ по автоматике и вычислительной технике , автор научной работы — Массобрио Рензо, Несмачнов Серхио, Черных Андрей, Аветисян Арутюн, Радченко Глеб,

Towards a Cloud Computing Paradigm for Big Data Analysis in Smart Cities

In this paper, we present a Big Data analysis paradigm related to smart cities using cloud computing infrastructures. The proposed architecture follows the MapReduce parallel model implemented using the Hadoop framework. We analyse two case studies: a quality-of-service assessment of public transportation system using historical bus location data, and a passenger-mobility estimation using ticket sales data from smartcards. Both case studies use real data from the transportation system of Montevideo, Uruguay. The experimental evaluation demonstrates that the proposed model allows processing large volumes of data efficiently.

Текст научной работы на тему «Применение облачных вычислений для анализа данных большого объема в умных городах»

Применение облачных вычислений для анализа данных большого объема в умных городах

Аннотация. В этой статье рассматривается вопрос применения анализа данных большого объема с использованием облачных вычислений для решения задач анализа дорожного траффика в контексте «умных» городов. Предложенное решение базируется на модели параллельных вычислений MapReduce, реализованной на платформе Hadoop. Анализируются два экспериментальных случая: оценка качества общественного транспорта на основе анализа истории местоположения автобусов, и оценка мобильности пассажиров при помощи анализа истории покупок билетов с транспортных карт. Оба эксперимента используют реальную базу данных системы общественного транспорта Монтевидео в Уругвае. Результаты эксперимента показали, что рассмотренная модель действительно позволяет эффективно обрабатывать большие объемы данных.

Ключевые слова: облачные вычисления; big data; умные города; интеллектуальные транспортные системы, большие объемы данных.

Для цитирования: Массобрио Р., Несмачнов С., Черных А., Аветисян А., Радченко Г. Применение облачных вычислений для анализа данных большого объема в умных

городах. Труды ИСП РАН, том 28, вып. 6, 2020 г., стр. 121-140. Б01: 10.15514/18РКА8-2020-28(6)-9

Одной из задач умных городов является использование информационных и коммуникационных технологий для управления ресурсами городского хозяйства с целью поднятия качества услуг, предоставляемых горожанам. Использование этих технологий позволяет снизить инфраструктурные и эксплуатационные расходы, повысить эффективность использования ресурсов и способствовать улучшению взаимодействия жителей и администрации [1]. Чаще всего такие технологии применяются в области транспортного сервиса из-за его ключевой роли в жизни современного города.

Сегодня во многих развитых городах общественный транспорт решает одну из важнейших задач в формировании городской инфраструктуры, обеспечивая мобильность жителей [2]. Особенно большую роль общественный транспорт играет в густонаселенных районах. Однако, многие транспортные системы не соответствуют постоянно растущим требованиям. Чтобы решить эту проблему, правительство должно иметь глубокое понимание всей ситуации и деталей, включая ежедневную статистику использования транспорта [3]. Однако, ссылаясь на недостаток финансов и человеческих ресурсов, администрация обычно оперирует чрезвычайно ограниченным объемом частитчно устаревшей информации для принятия решений. Чаще всего, данные собираются, но не анализируются, что приводит к тому, что они используются для улучшения инфраструктуры общественного или личного транспорта в «сыром» виде. По этой причине, процесс принятия решений относительно транспортной ситуации обычно затягивается. Модель умного города позволяет анализировать данные из многих источников, чтобы понять транспортную ситуацию в городах.

Интеллектуальные транспортные системы (ИТС) играют ключевую роль в транспортных системах умных городов. ИТС — это системы, объединяющие в себе синергетические технологии, искуственный интеллект и инженерные принципы, применяемые к транспортным системам для увеличения пропускной способности, безопасности, эффективности и уменьшения воздействия на окружающую среду [4]. ИТС позволяют собирать данные о транспорте и способах передвижении в городах [5]. В больших городских зонах ИТС генерирует огромное количество информации, из которой необходимо извлечь полезную информацию о передвижении жителей. В этой статье представлена платформа для эффективного анализа больших данных ИТС за счёт преимуществ облачных вычислений. Облачные вычисления включают в себя систему методов, которые позволяют использовать все преимущества множества вычислительных элементов для комплексного решения задач посредством распределенных вычислений. Когда исследователи сталкиваются со сложными задачами, такими как обработка

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

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

Мастер Йода рекомендует:  Какой у вас профессиональный уровень в IT — Опрос от Tproger


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

Статья организована следующим образом. В разделе 2 описываются основные концепции облачных вычислений, представляется парадигма Мар11ес1исе и платформа Наскюр. В разделе 3 представлен обзор смежных источников по вопросам, связанным с умными городами и обработки данных ИТС. Отдельный акцент сделан на распределенной и облачной обработке таких данных. В разделе 4 представлена модель облачной системы анализа данных ИТС. Раздел 5 посвящен обзору двух экспериментальных случаев и анализу полученных результатов. В разделе 6 представлены основные результаты исследования, определены основные направления дальнейшего развития работы.

2. Облачные вычисления, парадигма Мар[%ес1исе и платформа Нас1оор

В этом разделе описаны основные концепции облачных вычислений, модель Мар11ес1исе и ее реализация в рамках платформы Наскюр.

2.1 Распределенные вычисления и облачные вычисления

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

функциональной декомпозиции или же декомпозиции предметной области. За последние двадцать лет, распределенные вычисления были успешно внедрены в различных прикладных областях [6].

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

Облачные вычисления очень часто используются и для работы с большими объемами данных. Одна из самых распространенных вычислительных моделей для обработки больших объемов данных — это модель MapReduce.

MapReduce — это парадигма программирования для обработки данных большого объема при помощи параллельных (или распределенных) алгоритмов на базе вычислительных кластеров, вычислительных сетей и облачных вычислительных систем.

Парадигма MapReduce состоит из двух простых операций. Первая операция, с помощью функции распределения (Map), выполняет (параллельно, на множестве вычислительных элементов) перечень задач, таких как фильтрация, сортировка и (или) непосредственно вычисления. Вторая операция — это сведение (Reduce) результатов выполнения функции распределения [10]. Вычисления, которые используют парадигму MapReduce, называют задачами MapReduce. Такая задача имеет два этапа решения: распределение и сведение. Первый этап выполняется в четыре шага: чтение данных, анализ распределения, комбинирование и непосредственное распределение. Результат этих процедур — список узлов и данных, которые обрабатываются на этих узлах. Второй этап состоит также из четырех шагов: перемещение, сортировка, сведение и вывод результата вычислений.

Библиотеки для парадигмы MapReduce написаны на множестве языков программирования. Самая распространенная — Apache Hadoop, описана ниже.

Сегодня Hadoop — это одна из самых популярных платформ, использующих модель MapReduce для обработки больших объемов данных. Hadoop — это распределенная вычислительная система, которая использует файловую систему с открытым исходным кодом Hadoop Distributed File System (HDFS) [11].

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

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

2.4 Реализация парадигмы MapReduce на платформе Hadoop

Реализация парадигмы MapReduce на платформе Hadoop является самой распространенной и известной. Хотя MapReduce и проста для понимания, ее не всегда просто реализовать в виде алгоритмов для функций распределения и сведения.

В рамках платформы Hadoop, распределитель обычно принимает сырые данные в файловой системе HDFS. Данные, по умолчанию в текстовом формате, для распределителя представляют собой строки с ключом, равным байтовому смещению начала строки от начала файла. Задача MapReduce состоит из входных данных, кода программы и процедур для распределения. Пользователь может реализовать свои модули разделения, методы чтения записей, форматы входных данных и комбинаторы в зависимости от потребностей [7].

Вычислительный кластер в Hadoop состоит из корневого узла и подчиненных ему узлов. Корневой узел поддерживает несколько возможных ролей: менеджер задач, исполнитель, узел имен, и узел хранения. Подчиненные узлы могуть играть одну из двух ролей — узел хранения или исполнитель. Менеджер задач координирует все задачи системы с помощью списка задач исполнителей. Исполнитель запускает задачи и отправляет отчет о прогрессе работы менеджеру задач, который ведет статистику прогресса каждой задачи. Если задача завершается неправильно, менеджер задач может перезапустить ее на другом исполнителе. Именные узлы и узлы хранения относятся к кластеру HDFS.

Выполнение задачи MapReduce на платформе Hadoop выглядит следующим образом. В первую очередь, задача создается на клиентском узле, который запущен на виртуальной машине Java Virtual Machine (JVM). Далее, эта задача передает новую задачу менеджеру задач, который анализирует весь список запущенных и возвращает идентификатор новой задачи, после чегофайл, который необходимо выполнить и его кэш копируются на узлы. Далее, когда задача распределена, менеджер задач с помощью идентификатора инициализирует процесс обработки и подает входные данные. Исполнители возвращают менеджеру информацию о возможности запуска и доступной мощности. В зависимости от ответа менеджер задач назначает узлу выполнение или сведение. Узел-исполнитель извлекает ресурсы для обработки задачи и запускает новую JVM и выполняет функцию выполнения или сведения.

3. Обзор работ по смежным тематикам

Ряд статей, выпущенных в недавнее время, описывают применение распределенных и облачных вычислений для обработки больших данных, сгенерированных различными ИТС. В этом разделе мы проведем краткий обзор этих работ.

Преимущества анализа больших данных для систем общественного транспорта были представлены в работе [12]. Авторы проанализировали различные источники информации: траектория движения транспорта (координаты GPS, скорость передвижения), отчеты о неисправностях, передвижения людей (с помощью GPS и Wi-Fi сигналов), социальные сети (текстовые записи, адреса) и веб-логи (идентификаторы пользователей, комментарии). В статье описаны все преимущества и недостатки каждого источника информации. Также рассмотрено несколько новых идей для улучшения системы общественного транспорта с применением парадигмы ИТС, включая краудсорсинг для сбора и анализа актуальных данных о движении транспорта, сопровождение водителя и анализ поведения пассажиров. Кроме того, в статье представлен вывод о том, как внедрить технологию в систему общественного транспорта, чтобы она была совместима со следующими поколениями ИТС, которые повысят безопасность и эффективность поездок.

Методы интеллектуального вычисления недавно нашли применение при проектировании ИТС.

В работе [13] предложен метод последовательного поиска для прогнозирования ситуации на дорогах с использованием системы обнаружения транспортных средств (Vehicle Detection System) и алгоритма классификации к ближайших соседей (к nearest neighbors — kNN). Такое сочетание значительно превосходит традиционное использование алгоритма kNN, обеспечивая более точные результаты, сохраняя при этом высокую эффективность и стабильность.

В работе [14] представлено применение метода анализа данных на основе случайных лесов и Байесовского вывода для обработки больших объемов данных в системе микроволнового обнаружения транспорта (Microwave Vehicle Detection System). Главной целью работы является обнаружение факторов, провоцирующих аварии, в реальном времени. При анализе данных в час-пик, применяется модель надежности, учитывается увеличение объема и снижение средней скорости транспортного потока, индекс затора. Основной вывод анализа заключается в том, что пробки чаще всего являются основной причиной столкновений сзади.

В работе [15] представлен подход обучения с учителем, с использованием метода опорных векторов и Байесовской классификации, для построения системы прогноза транспортного потока в реальном времени. Сначала сырые данные проходят два этапа подготовки и фильтрацию шума. Это стандартный подход для подготовки данных в подобных исследованиях, и мы также будем 126

применять его в нашем эксперименте. Затем, модель транспортного потока исследуется Байесовской платформой. Методами регрессионного анализа моделируется пространственно-временная зависимость и отношения между дорогами. Эффективность такого метода исследуется на транспортных данных Кёнбусона, железной дороги Сеул-Пусан в Южной Корее. Результаты эксперимента показали, что подход с использованием метода опорных векторов в для оценки превосходит традиционные методы линейной регрессии с точки зрения точности.

В работе [16] была предложена модель для эффективного прогнозирования скорости движения на заданной местности. Она использует историю из различных источников, в том числе данные из различных ИТ С, погодные условия и особые события, происходящие в городе. Для получения точных результатов модель прогнозирования должна часто обновляться, чтобы использовать самые последние данные. Модель прогнозирования сочетает в себе алгоритм классификации к ближайших соседей и регрессию на основе Гауссовского процесса. Кроме того, результаты рассчитываются с использованием модели MapReduce, реализованной на платформе Hadoop. Экспериментальная оценка была выполнена на основе реального сценария, используя данные, полученные на Research Data Exchange — платформе для публикации данных ИТС. Данные собраны на участке дороги I5N в Сан Диего, штат Калифорния, США. Информация содержит скорость и величину расхода топлива, полученные с помощью петлевого детектора на дороге, а также данные о видимости, полученные с ближайшей метеорологической станции. Результаты экспериментов показали, что предложенный метод может точно предсказать скорость движения потока со средней ошибкой менее двух миль в час. Кроме того, за счет использования платформы Hadoop в кластерной инфраструктуре, а не на одной вычислительной машине, было достигнуто уменьшение времени обработки на 69%.

В работе [17] представлены результаты исследований проблем краткосрочного прогнозирования транспортного потока в реальном времени. В решении использовался алгоритм к ближайших соседей в распределенной среде MapReduce на платформе Hadoop. Предлагаемое решение рассматривает пространственно-временную корреляцию в транспортном потоке, т.е. текущий поток на определенном участке дороги зависит от прошлого (временное измерение) и от потока на соседних участках дороги (пространственное измерение). В реализованном алгоритме, эти два фактора можно контролировать с помощью весов. Экспериментальный анализ проводился с использованием данных траекторий более 12 ООО такси в Пекине, оборудованных GPS-датчиками, в 15-дневный период в ноябре 2012 года. Первые 14 дней данных использовались для обучения системы, а последний -для вычисления результатов. Предложенный алгоритм позволил уменьшить среднюю абсолютную ошибку от 8,5% до 11,5% в среднем в сравнении с тремя существующими методами, основанными на алгоритме к ближайших

соседей. Кроме того, предлагаемое решение в лучшем случае достигает вычислительную эффективность 0,84.

В работе [23] предложено использовать многокритериальные ячеистые генетические алгоритмы MOcell для оптимизации расписаний автобусного парка с автобусами различной вместимости.

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

4. Предлагаемая модель

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

4.1 Архитектура системы

Задача разбивается на два этапа: 1) этап предварительных вычислений для подготовки входных данных к следующему шагу; 2) этап обработки данных ИТС с использованием распределенных облачных вычислений. Для организации вычислений и определения структуры используется подход Master/Slave (ведущий/ведомый). На рис. 1 представлена концептуальная схема разрабатываемой платформы.

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

На этапе распределенных вычислений используется подход декомпозиции по данным. После этапа предварительных вычислений отфильтрованные и отсортированные данные разбиваются на части и передаются нескольким вычислительным элементам. Ведущий процесс является ответственным за распределение данных и назначение каждой части данных ведомым процессам для обработки. Каждый ведомый процесс получает от ведущего часть данных. Такая структура соответствует категории вычислительных систем Single Program Multiple Data (SPMD), согласно которой ведомые

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

Unstructured data Apply filters

Distributed computing stage

Рис. 1. Концептуальная схема разрабатываемой платформы Fig. 1. Conceptual scheme of the developed platform

4.2 Реализация с применением MapReduce

При разработке распределенной вычислительной системы для анализа данных ИТ С использовалась платформа Hadoop и была применена парадигма MapReduce. Система соответствует данной парадигме, так как между ведомыми процессами взаимодействий не происходит, а взаимодействия между ведущим и ведомыми процессами ограничены лишь распределением данных и сбором результатов вычислений. В Hadoop реализован стандартный подход MapReduce, в котором используется один главный узел и несколько рабочих узлов. Главный узел, используя процесс JobTracker, посылает задачи различным процессам TaskTracker, каждый из которых связан с определенным рабочим узлом. Как только все ведомые процессы заканчивают назначенные им задания, каждый процесс TaskTracker передает результаты обратно процессу JobTracker в главный узел.

В Hadoop реализован механизм обеспечения отказоустойчивости. Дополнительно, для улучшения работы механизма отказоустойчивости при работе с данными ИТС используются следующие особенности: 1) возможность отбрасывания поврежденных входных данных в случае наличия поврежденной информации в записи; 2) встроенный механизм репликации HDFS для хранения данных в различных вычислительных узлах.

5. Практические примеры

В этом разделе описывается применение разработанной платформы для обработки двух разных типов данных ИТС. В обоих случаях

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


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

В этом практическом примере рассматривается задача вычисления метрик качества обслуживания системы общественного транспорта с использованием данных GPS-навигаторов, установленных в автобусах [24]. Данные содержат информацию о местоположении каждого автобуса в конкретный момент времени. Эта информация обновляется каждые 10-30 секунд. Для определения эффективности системы общественного транспорта основной задачей является введение соответствующих метрик, таких как: 1) реальное время, затрачиваемое каждым автобусом на путь между заранее заданными и отмеченными местами в городе; 2) статистическая информация о задержках каждого автобуса на конкретном маршруте для определения перегруженных мест. Данные должны быть должным образом организованы для возможности определения закономерностей объема потока пассажиров и загруженности дорог в различные дни недели, а также в различное время дня. Существует как минимум две целевые группы, которым разработанная система принесет пользу: пассажиры и городская администрация. С помощью информации, которая получена на основе обработки исторических данных и данных реального времени, пользователь системы общественного транспорта сможет принять более выгодные решения о собственном перемещении (например, выбрать определенный автобусный маршрут, совершить пересадку). Эта информация может предоставляться посредством интеллектуального мобильного приложения или сайта. Для городской администрации такая информация полезна для планирования долгосрочных изменений автобусных маршрутов, расписания движения, положения автобусных остановок, а также для выявления конкретных проблемных ситуаций.

Схема разработанной системы представлена на рис. 2. Автобусы посылают данные о местоположении на облачный сервер. На сервере происходит MapReduce-обработка собранных данных GPS различных автобусов в реальном времени. Результаты вычислений передаются в мобильное приложения для использования конечными пользователями и мониторинговое приложение для использования городской администрацией. На этапе предварительных вычислений, ведущий процесс подготавливает данные, фильтруя те записи, которые хранят ненужную информацию (например, поврежденные данные GPS). Дополнительно данные фильтруются таким образом, чтобы включать только записи из временного промежутка, задаваемого пользователем. В конце этапа записи сортируются по идентификационному номеру автобуса, что позволяет увеличить эффективность работы следующего этапа. 130

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

Экспериментальная оценка производится на основе облачной инфраструктуры Cluster FING, предоставленной Республиканским университетом Уругвая [18], для вычислений используются 24-ядерные процессоры AMD Opteron 6172 Magny Cours с тактовой частотой 2,26 ГГц, 24 Гб оперативной памяти и операционная система CentOS Finux 5.2.

Для экспериментального анализа используются реальные исторические данные ИТС, предоставленные правительством г. Монтевидео, Уругвай. Автобусные компании Монтевидео обязаны посылать данные о местоположении автобусов и о продажах билетов правительству города. Автобусная сеть Монтевидео достаточно сложна и насчитывает 1383 автобусных маршрута и 4718 автобусных остановок.

Real-time bus data

Puc. 2. Архитектура системы облачной обработки данных ИТС Fig. 2. Architecture of the ITS cloud data processing system

В этом практическом примере рассматривается полный набор данных о продажах билетов и местоположении автобусов за 2015 год, в котором содержится около 200 Гб данных. Данные о местоположении автобуса содержат информацию о месте нахождения каждого автобуса с интервалами от 10 до 30 секунд.

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

Таблица 1. Результаты замеров производительности

Table 1. Performance measurement results.

#1 #D #м #R Ti(s) TN(s) Sn EN

10 3 14 8 1333.9 253.1 5.27 0.22

10 3 22 22 1333.9 143 9.33 0.39

10 30 14 8 2108.6 178 11.84 0.49

10 30 22 22 2108.6 187.3 11.26 0.47

20 3 14 8 2449 351.1 6.98 0.29

20 3 22 22 2449 189.8 12.9 0.54

20 30 14 8 3324.5 275.6 12.06 0.5

20 30 22 22 3324.5 238.8 13.92 0.58

20 60 14 8 4762 300.8 15.83 0.66

20 60 22 22 4762 264.7 17.99 0.75

30 3 14 8 3588.5 546.9 6.56 0.27

30 3 22 22 3588.5 179.6 19.99 0.83

30 30 14 8 5052.9 359.6 14.05 0.59

M #D #M #R Ti(s) TN(s) Sn EN

30 30 22 22 5052.9 281.1 17.98 0.75

30 60 14 8 5927.9 383.4 15.46 0.64

30 60 22 22 5927.9 311.4 19.04 0.79

30 90 14 8 7536.9 416.6 18.09 0.75

30 90 22 22 7536.9 349.2 21.58 0.9

60 3 14 8 7249.6 944 7.68 0.32

60 3 22 22 7249.6 362.1 20.02 0.83

60 60 14 8 10037.1 672.6 14.92 0.62

60 60 22 22 10037.1 531.4 18.89 0.79

60 90 14 8 11941.6 709.6 16.83 0.7

60 90 22 22 11941.6 648.9 18.4 0.77

60 180 14 8 19060.8 913.7 20.86 0.87

60 180 22 22 19060.8 860.3 22.16 0.92

Работа происходит на наборах данных ИТС объемом 10, 20, 30 и 60 Гб и на временных промежутках длительностью 3 дня, а также 1, 2, 3 и 6 месяцев. Для оценки производительности параллельного алгоритма используются стандартные метрики ускорения и эффективности.

В таблице 1 представлены результаты замеров вычислительной производительности системы при использовании различных сценариев и следующих изменяемых параметров: размер входных данных в Гб (#1), временной промежуток в днях (#D), количество процессов Map (#М) и Reduce (#R). Для каждого сценария определялись такие результаты, как время выполнения в секундах с использованием 1 ядра (Т1) и 24 ядер (TN), 132

ускорение (SN) и эффективность (EN). В таблице приведены средние значения после пяти незавсимых запусков каждого сценария.

Результаты в таблице 1 демонстрируют значительное увеличение производительности при использовании выбранного подхода по сравнению с последовательной реализацией, особенно на больших наборах данных. Ускорение при использовании 24 ядер достигает значения 22.16, что соответствует значению эффективности 0.92. Распределенная реализация позволяет сократить время работы на больших объемах данных с 6 часов до 14 минут. Такое увеличение производительности просто необходимо для быстрого реагирования городской администрации на возникновение непредвиденных ситуаций и для анализа различных метрик и сценариев, как обычными пользователями, так и администраторами системы. Использование 22 процессов Map и 22 процессов Reduce позволяет достигнуть наибольшей эффективности. Время выполнения возрастает на 15% в лучшем случае и на 9% в среднем по сравнению со сценариями, в которых используются 14 процессов Map и 8 процессов Reduce. При работе с малыми объемами данных процессы низко нагружены с вычислительной и пространственной точек зрения, и заметного выигрыша во времени выполнения по сравнению с последовательной реализацией нет.

5.2 Построение матриц отправления-прибытия с использованием исторических данных смарт-карт

Для решения задач оптимизации систем городского транспорта необходимо понимать шаблоны передвижения и распределения горожан. Обычно эта информация представляется в виде следующих матриц: 1) матриц отправления прибытия (Origin-Destination — OD-матриц), которые отражают количество людей, передвигающихся из конкретной точки города в определенный временной промежуток [19]; 2) матриц распределения, которые отражают количество автобусных билетов, проданных на каждой остановке в городе. Обычно эти матрицы строятся на основе опросов пассажиров и водителей. Однако такой подход не дает полного видения ситуации, не предоставляет актуальную информацию и требует больших вложений от городского правительства.

В этом практическом примере предлагается иной подход для построения матриц распределения и OD-матриц [25]. Мы вычисляем и обновляем их, используя обработку таких данных ИТС, как количество билетов, проданных с использованием смарт-карт и без их использования, а также данных о местоположении автобусов. Учитывая высокую вычислительную сложность обработки больших объемов данных ИТС, нами будет применяться модель распределенных вычислений, описанная в разделе 4.

Основной проблемой при генерации матриц распределения и OD-матриц с использованием данных о продажах билетов является то, что пассажиры

применяют смарт-карту только при посадке и не используют ее при выходе из автобуса. Следовательно, хоть начальный пункт каждой поездки известен, необходимо определить и конечный пункт. Более того, пассажиры, у которых есть смарт-карта, не обязаны применять ее для оплаты билета, они могут расплатиться наличными. Следовательно, записи о продажах билетов не хранят полную информацию, связанную с конкретным пассажиром, поэтому нельзя отследить несколько поездок одного и того же пассажира. Модель для построения ОБ-матриц основана на восстановлении последовательности поездок для пассажиров, использующих смарт-карту. Подобный подход описан в соответствующей литературе [20, 21, 22]. Мы предполагаем, что у каждой смарт-карты есть только один пользователь. Рассматриваемый подход основан на обработке каждой поездки, получении данных о начальном пункте поездки и точном/приближенном определении конечного пункта поездки. Для приближенного определения вводятся следующие понятия: поездка с пересадками и прямая поездка. Основные детали вводимых понятий описаны далее.

Мастер Йода рекомендует:  Задача на составление прямоугольника из слов одинаковой длины

Поездка с пересадками. В такой поездке пассажир при посадке в первый автобус оплачивает поездку смарт-картой, которая имеет уникальный идентификационный номер. Далее пассажир за ограниченный промежуток времени, указанный в билете, может сделать одну и более пересадок без покупки нового билета, а просто предоставив свою смарт-карту. Такой подход позволяет отследить, хранит ли запись информацию о новой поездке (т.е. о покупке нового билета) или же она хранит информацию о пересадке (т.е. о подтверждении смарт-карты). Мы предполагаем, что пассажиры не делают длительных пеших перемещений во время поездок и что пассажир, совершающий пересадку, выходит на остановке, которая находится ближе всего к той остановке, на которой он сядет на следующий автобус. Посадка на автобус после пересадки записывается в систему. Приблизительное место пересадки с одного автобуса на другой определяется как ближайшая автобусная остановка конкретного маршрута. Прямая поездка. В такой поездке не происходит пересадок. Дополнительно, последний этап поездки с пересадками рассматривается в качестве прямой поездки. В обоих случаях сложность состоит в точном определении пункта назначения. Для определения пунктов назначения мы вводим два предположения, которые часто используются в соответствующей литературе: 1) пассажиры начинают новую поездку на автобусной остановке, находящейся ближе всего к пункту назначения предыдущей поездки; 2) в конце дня пассажиры возвращаются на автобусную остановку, которая была пунктом отправки первой поездки текущего дня. Для определения пунктов назначения мы пытаемся построить «цепь» поездок каждого пассажира в определенный день. Для этого просматриваются все поездки, совершенные каждым пассажиром за 24 часа. Для каждой новой поездки мы пытаемся определить точку высадки, для этого ищется автобусная остановка, находящаяся в заранее


заданном радиусе от остановки предыдущей поездки. Также хранится лог поездок, которые не могут быть выстроены в «цепь» для определения эффективности метода.

В этом практическом примере на этапе предварительных вычислений, описанном в разделе 4, фильтруются те данные о продажах, которые несут неточную информацию. Мы предполагаем, что измерение GPS неточно, если положение автобуса удалено более чем на 50 метров от его маршрута. Отфильтрованные данные разбиваются на части по идентификационным номерам смарт-карт и передаются ведомым процессам. Таким образом, ведомый процесс обрабатывает информацию обо всех поездках определенного пассажира, поэтому взаимодействие между ведомыми процессами отсутствует. Для улучшения производительности в конце этапа предварительных вычислений записи сортируются по дате для последовательной передачи ведомым процессам.

Для экспериментального анализа использовался полный набор данных ИТС за январь 2015 года, который включал данные о продажах билетов и местоположении автобусов. В наборе данных находилась информация о более чем 500 тысячах смарт-карт (что соответствует более чем 13 миллионам поездок).

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

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

6. Заключение и дальнейшие исследования

В этой работе была разработана и реализована распределенная вычислительная система для облачной обработки больших объемов данных

ИТС с использованием парадигмы MapReduce на платформе Hadoop. Выполнен обзор литературы с обсуждением предыдущих попыток использования распределенных вычислений для обработки данных ИТС в контексте умных городов. Эффективность разработанной модели отражена и с использованием двух практических примеров: 1) вычисление метрик качества обслуживания системы общественного транспорта с использованием данных о местоположении автобусов; 2) построение OD-матриц на основе данных о продажах билетов. В обоих случаях распределенная модель позволяет значительно уменьшить время обработки больших объемов исторических данных. Экспериментальный анализ в обоих случаях был произведен с использованием реальных данных ИТС г. Монтевидео, Уругвай. Возможные направления дальнейших исследований: 1) использование различных источников данных ИТС; 2) разработка приложения для горожан с интуитивно понятным доступом к полученной информации; 3) применение полученной информации для решения оптимизационных задач, например, прокладка автобусных маршрутов, изменение мест автобусных остановок, расписание автобусов и т.д.

Благодарности. Работа выполнена при поддержке Правительства Российской Федерации, Акт 211, контракт № 02.А03.21.0011 и CONACYT (Consejo Nacional de Ciencia y Tecnología, México), грант номер 178415.

[1]. Deakin, М., & Al Waer, Н. (2011). From intelligent to smart cities. Intelligent Buildings International, 3(3), 140-152.

[2]. Grava, S. (2003). Urban transportation systems. Choices for communities.

[3]. Chen, C., Ma, J., Susilo, Y., Liu, Y., Wang, M.: (2020). The promises of big data and small data for travel behavior (aka human mobility) analysis. Transportation Research Part C: Emerging Technologies 68,285-299.

[4]. Sussman, J. S. (2008). Perspectives on intelligent transportation systems (ITS). Springer Science & Business Media.

[5]. Figueiredo, L., Jesus, I., Machado, J. Т., Ferreira, J., & de Carvalho, J. M. (2001). Towards the development of intelligent transportation systems. In Intelligent transportation systems (Vol. 88, pp. 1206-1211).

[6]. Foster I. (1995). Designing and Building Parallel Programs: Concepts and Tools for Parallel Software Engineering. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

[7]. White T. (2009). Hadoop: The Definitive Guide (1st ed.). O’Reilly Media, Inc..

[8]. Attiya H. & Welch J. (2004). Distributed Computing: Fundamentals, Simulations and Advanced Topics. John Wiley & Sons.

[9]. Buyya R., Broberg J., & Goscinski. A. M. (2011). Cloud Computing Principles and Paradigms. Wiley Publishing.

[10]. Dean J. & Ghemawat S. (2008). MapReduce: simplified data processing on large clusters. Commun. ACM 51, 1 (January 2008), 107-113.

[11]. Shafer, J., Rixner, S., & Cox, A. L. (2010). The hadoop distributed filesystem: Balancing portability and performance. In IEEE International Symposium on Performance Analysis of Systems & Software (pp. 122-133).

[12]. Zheng, X., Chen, W., Wang, P., Shen, D., Chen, S., Wang, X., . & Yang, L. (2020). Big data for social transportation. IEEE Transactions on Intelligent Transportation Systems, 17(3), 620-630.

[13]. Oh, S., Byon, Y. J., & Yeo, H. (2020). Improvement of Search Strategy With K-Nearest Neighbors Approach for Traffic State Prediction. IEEE Transactions on Intelligent Transportation Systems, 17(4), 1146-1156.

[14]. Shi, Q., & Abdel-Aty, M. (2015). Big data applications in real-time traffic operation and safety monitoring and improvement on urban expressways. Transportation Research Part C: Emerging Technologies, 58, 380-394.

[15]. Ahn, J., Ко, E., & Kim, E. Y. (2020). Highway traffic flow prediction using support vector regression and Bayesian classifier. In 2020 International Conference on Big Data and Smart Computing (BigComp) (pp. 239-244). IEEE.

[16]. Chen, X. Y., Pao, H. K., & Lee, Y. J. (2014). Efficient traffic speed forecasting based on massive heterogenous historical data. In Big Data (Big Data), 2014 IEEE International Conference on (pp. 10-17). IEEE.

[17]. Xia, D., Wang, В., Li, H., Li, Y., & Zhang, Z. (2020). A distributed spatial-temporal weighted model on MapReduce for short-term traffic flow forecasting. Neurocomputing, 179,246-263.

[18]. Nesmachnow S. (2010). Computación científica de alto desempeño en la Facultad de Ingeniería, Universidad de la República. Revista de la Asociación de Ingenieros del Uruguay 61 (1), 12-15.

[19]. Yang H., Sasaki Т., Iida Y., Asakura Y. (1992). Estimation of origin-destination matrices from link traffic counts on congested networks, Transportation Research Part B: Methodological, Volume 26, Issue 6, Pages 417-434.

[20]. Trépanier, M., Tranchant, N., & Chapleau, R. (2007). Individual trip destination estimation in a transit smart card automated fare collection system. Journal of Intelligent Transportation Systems, 11(1), 1-14.

[21]. Wang, W., Attanucci, J. P., & Wilson, N. H. (2011). Bus passenger origin-destination estimation and related analyses using automated data collection systems. Journal of Public Transportation, 14(4), 7.

[22]. Munizaga, M. A., & Palma, С. (2012). Estimation of a disaggregate multimodal public transport Origin-Destination matrix from passive smartcard data from Santiago, Chile. Transportation Research Part C: Emerging Technologies, 24, 9-18.

[23]. Peña D., Tchernykh A., Nesmachnow S., Massobrio S., Drozdov A. Y., Garichev S. N. (2020). Multiobjective vehicle type and size scheduling problem in urban public transport using MOCell. IEEE International conference Engineering & Telecommunications, Moscow, Russia.

[24]. R. Massobrio, A. Pías, N. Vázquez, & S. Nesmachnow (2020). Map-Reduce for Processing GPS Data from Public Transport in Montevideo, Uruguay. In 2do Simposio Argentino de Grandes Datos.

[25]. E. Fabbiani, P. Vidal, R. Massobrio, & S. Nesmachnow (2020). Distributed Big Data analysis for mobility estimation in Intelligent Transportation Systems. In Latin American High Performance Computing Conference.

Towards a Cloud Computing Paradigm for Big Data Analysis in Smart Cities

1 Renzo Massobrio

1 Sergio Nesmachnow

2 Andrei Tchernykh

Abstract. In this paper, we present a Big Data analysis paradigm related to smart cities using cloud computing infrastructures. The proposed architecture follows the MapReduce parallel model implemented using the Hadoop framework. We analyse two case studies: a quality-of-service assessment of public transportation system using historical bus location data, and a passenger-mobility estimation using ticket sales data from smartcards. Both case studies use real data from the transportation system of Montevideo, Uruguay. The experimental evaluation demonstrates that the proposed model allows processing large volumes of data efficiently.

Keywords: cloud computing; big data; smart cities; intelligent transportation systems. DOI: 10.15514/ISPRAS-2020-28(6)-9

For citation: Massobrio R., Nesmachnow S., Tchernykh A., Avetisyan A., Radchenko G. Towards a Cloud Computing Paradigm for Big Data Analysis in Smart Cities. Trudy ISP RAN/Proc.ISP RAS, vol. 28, issue 6, 2020. pp. 121-140 (in Russian). DOI: 10.15514/ISPRAS-2020-28(6)-9

Acknowledgment. This work is partially supported by Government of the Russian Federation, Act 211, contract № 02.A03.21.0011, and CONACYT (Consejo Nacional de Ciencia y Tecnología, México), grant no. 178415. Dataseis used in this paper are from Intendencia de Montevideo.

[1]. Deakin, M., & Al Waer, H. (2011). From intelligent to smart cities. Intelligent Buildings International, 3(3), 140-152.

[2]. Grava, S. (2003). Urban transportation systems. Choices for communities.

[3]. Chen, C., Ma, J., Susilo, Y., Liu, Y., Wang, M.: (2020). The promises of big data and small data for travel behavior (aka human mobility) analysis. Transportation Research Part C: Emerging Technologies 68,285-299.

[4]. Sussman, J. S. (2008). Perspectives on intelligent transportation systems (ITS). Springer Science & Business Media.

[5]. Figueiredo, L., Jesus, I., Machado, J. Т., Ferreira, J., & de Carvalho, J. M. (2001). Towards the development of intelligent transportation systems. In Intelligent transportation systems (Vol. 88, pp. 1206-1211).

[6]. Foster I. (1995). Designing and Building Parallel Programs: Concepts and Tools for Parallel Software Engineering. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

[7]. White T. (2009). Hadoop: The Definitive Guide (1st ed.). O’Reilly Media, Inc..


[8]. Attiya H. & Welch J. (2004). Distributed Computing: Fundamentals, Simulations and Advanced Topics. John Wiley & Sons.

[9]. Buyya R., Broberg J., & Goscinski. A. M. (2011). Cloud Computing Principles and Paradigms. Wiley Publishing.

[10]. Dean J. & Ghemawat S. (2008). MapReduce: simplified data processing on large clusters. Commun. ACM 51, 1 (January 2008), 107-113.

[11]. Shafer, J., Rixner, S., & Cox, A. L. (2010). The hadoop distributed filesystem: Balancing portability and performance. In IEEE International Symposium on Performance Analysis of Systems & Software (pp. 122-133).

[12]. Zheng, X., Chen, W., Wang, P., Shen, D., Chen, S., Wang, X., . & Yang, L. (2020). Big data for social transportation. IEEE Transactions on Intelligent Transportation Systems, 17(3), 620-630.

[13]. Oh, S., Byon, Y. J., & Yeo, H. (2020). Improvement of Search Strategy With K-Nearest Neighbors Approach for Traffic State Prediction. IEEE Transactions on Intelligent Transportation Systems, 17(4), 1146-1156.

[14]. Shi, Q., & Abdel-Aty, M. (2015). Big data applications in real-time traffic operation and safety monitoring and improvement on urban expressways. Transportation Research Part C: Emerging Technologies, 58, 380-394.

[15]. Ahn, J., Ко, E., & Kim, E. Y. (2020). Highway traffic flow prediction using support vector regression and Bayesian classifier. In 2020 International Conference on Big Data and Smart Computing (BigComp) (pp. 239-244). IEEE.

[16]. Chen, X. Y., Pao, H. K., & Lee, Y. J. (2014). Efficient traffic speed forecasting based on massive heterogenous historical data. In Big Data (Big Data), 2014 IEEE International Conference on (pp. 10-17). IEEE.

[17]. Xia, D., Wang, В., Li, H., Li, Y., & Zhang, Z. (2020). A distributed spatial-temporal weighted model on MapReduce for short-term traffic flow forecasting. Neurocomputing, 179,246-263.

[18]. Nesmachnow S. (2010). Computación científica de alto desempeño en la Facultad de Ingeniería, Universidad de la República. Revista de la Asociación de Ingenieros del Uruguay 61 (1), 12-15.

[19]. Yang H., Sasaki Т., Iida Y., Asakura Y. (1992). Estimation of origin-destination matrices from link traffic counts on congested networks, Transportation Research Part B: Methodological, Volume 26, Issue 6, Pages 417-434.

[20]. Trépanier, M., Tranchant, N., & Chapleau, R. (2007). Individual trip destination estimation in a transit smart card automated fare collection system. Journal of Intelligent Transportation Systems, 11(1), 1-14.

[21]. Wang, W., Attanucci, J. P., & Wilson, N. H. (2011). Bus passenger origin-destination estimation and related analyses using automated data collection systems. Journal of Public Transportation, 14(4), 7.

[22]. Munizaga, M. A., & Palma, C. (2012). Estimation of a disaggregate multimodal public transport Origin-Destination matrix from passive smartcard data from Santiago, Chile. Transportation Research Part C: Emerging Technologies, 24, 9-18.

[23]. Peña D., Tchernykh A., Nesmachnow S., Massobrio S., Drozdov A. Y., Garichev S. N. (2020). Multiobjective vehicle type and size scheduling problem in urban public transport using MOCell. IEEE International conference Engineering & Telecommunications, Moscow, Russia.

[24]. R. Massobrio, A. Pías, N. Vázquez, & S. Nesmachnow (2020). Map-Reduce for Processing GPS Data from Public Transport in Montevideo, Uruguay. In 2do Simposio Argentino de Grandes Datos.

[25]. E. Fabbiani, P. Vidal, R. Massobrio, & S. Nesmachnow (2020). Distributed Big Data analysis for mobility estimation in Intelligent Transportation Systems. In Latin American High Performance Computing Conference.

Kubernetes: разбираемся с системой управления контейнерами

Содержание статьи

С появлением Docker интерес к контейнерам вырос взрывообразно: разворачивать приложения оказалось настолько удобно, что технологию начали использовать буквально везде. Облачные сервисы уже дают быстрый доступ к большому количеству виртуальных машин, которыми нужно управлять. Поэтому без инструмента, позволяющего запускать контейнеры на множестве хостов, масштабировать и выполнять балансировку, уже не обойтись. Разберемся с решением, предложенным Google.

Проект Kubernetes

Проект Kubernetes, или K8S, стартовал в Google в 2014 году, первая публичная версия 0.1 была представлена сообществу практически через год — в июле 2015-го. Нужно, наверное, особо отметить, что разработка не начиналась с нуля. В основе K8S лежит суперсекретный (в буквальном смысле этого слова) проект Гугла Borg — фактически основа основ управления кластерами в этой корпорации, проект, наработками которого до этого гигант не особо хотел делиться. Многие из разработчиков Borg перешли в Kubernetes, а вместе с ними туда перекочевали все идеи и решения проблем — перенос контейнеров без потерь данных, балансировка нагрузки, обнаружение сервисов. То есть можно сказать, что K8S — точная копия того, что в Google создавали долгое время, но адаптированная и ориентированная к применению Docker. Сразу после анонса проекта совместно с Linux Foundation была сформирована Cloud Computing Native Foundation (CNCF), в которую вошли сама Google, Cisco, IBM, Docker и VMware. Задача CNCF — выработать единый стандарт и обеспечить взаимодействие между разработчиками.

В Kubernetes реализованы все функции, необходимые для запуска приложений на основе Docker в конфигурации с высокой доступностью (кластеры более 1000 узлов, с multi-availability и multi-region зонами): управление кластером, планирование, обнаружение сервисов, мониторинг, управление учетными данными и многое другое. Выглядит это пугающе, но вся внутренняя кухня скрыта от админа. Он просто размещает контейнеры, все остальное — забота K8S. Для реализации этого используется больше десятка сторонних взаимодействующих услуг, которые вместе обеспечивают требуемую функциональность. Например, за координацию и хранение настроек отвечает etcd, создание сетей между контейнерами — flannel. Это несколько усложняет первоначальную настройку (хотя в последних релизах это уже не так заметно), но позволяет при необходимости просто заменить любой компонент. Для состыковки служб используются разные CLI, API, которые уже совместно реализуют API более высокого уровня для сервисных функций, таких как планирование ресурсов. Нужная функциональность должна быть специально адаптирована для K8S. Например, обратиться напрямую к API Docker нельзя (точнее, можно, но очень и очень нежелательно), следует использовать Docker Compose.

Kubernetes представляет собой систему с несколькими концепциями. Многие из этих понятий проявляются как «объекты» или «ресурсы» RESTful API. Кроме общепринятых, таких как Node, Cluster и Replication controller, есть и весьма специфические.

  • Pods — единица планирования в Kubernetes. Группа или ресурс, в котором могут работать несколько контейнеров. Контейнеры из одного Pod будут запускаться на одном сервере и могут совместно использовать общие разделы. Объекты Pod описаны в так называемых PodSpec — YAML/JSON-файлах.
  • Services — набор контейнеров, которые работают вместе, обеспечивая, например, функционирование многоуровневого приложения. K8S поддерживает динамическое наименование и балансировку нагрузки Pods с помощью абстракций, гарантируя прозрачное подключение к Services по имени и отслеживая их текущее состояние.
  • Labels — пары ключ/значение, которые прикрепляются к Pod и фактически к любому объекту (сервису), позволяя их легко группировать, отбирать и назначать задания.
  • IP-per-Pod — в Borg сервисы использовали один IP и для распределения сетевых ресурсов применялись порты. Это накладывало ряд ограничений. В K8S возможно назначить каждому Pod отдельный адрес.
  • Namespaces — способ, позволяющий логически разделить единый кластер K8S на несколько виртуальных, каждый из них будет существовать в изолированном пространстве, ограниченном квотами, не влияя на других.

На всех узлах кластера minion устанавливаются агенты kubelet и kube-proxy (прокси-балансировщик). Агенты принимают из специального API сервера данные PodSpec (файл или HTTP) и гарантируют работоспособность указанных в нем объектов. Прокси обеспечивает перенаправление потоков между Pod. Мастер кластера содержит специальные компоненты — kube-controller-manager (менеджер сервисов) и kube-scheduler (планировщик), kube-apiserver, etcd и flannel. Доступ к API управления, кроме программного способа, можно получить через консольную утилиту kubectl и веб-интерфейс. С их помощью можно просматривать текущую конфигурацию, управлять ресурсами, создавать и разворачивать контейнеры.

Установка Kubernetes

Установка Kubernetes выполняется скриптом, и в процессе следует ориентироваться на официальную инструкцию, адаптировав ее к своему дистрибутиву. Она несложная, просто нужно быть очень внимательным. Мануалы из Сети работают не всегда, так как в разных версиях дистрибутива часто требуются различные действия и встречаются специфические проблемы, также разработчики по мере развития K8S меняют процесс развертывания и параметры в конфигурационных файлах. Установим в простейшем варианте K8S на одну систему master/minion в Ubuntu 14.04/16.04, так что нам не потребуются некоторые компоненты вроде сервера ключей. Перед установкой нужно составить список всех узлов и их сетевые параметры и роль. Проект предлагает исходные тексты и bash-скрипт.

Скрипт установки Kubernetes

Первый вариант дает чуть больше контроля, если что-то пойдет не так. Ставим приложения:

Для беспарольного входа генерируем ключ. Так как впоследствии понадобятся права root, то ключи генерируем для него. Все параметры оставляем по умолчанию, на запрос пароля жмем Enter.

Подтверждаем операцию и вводим свой пароль.

После этого пробуем войти. Должно пустить без запроса пароля:

Если серверов несколько, поступаем аналогично и копируем на них ключи. Несмотря на простоту, это очень важный момент. Малейшая ошибка — и дальнейшие действия ни к чему не приведут. Забираем актуальный релиз (файл большой, почти 1,5 Гбайт):

Или ветку master:

Архив содержит примеры и готовые настройки в kubernetes/cluster для самых разных конфигураций. Следует выбрать свою и запустить установочный скрипт. Так как ставим на Ubuntu, то выбираем этот вариант. Для начала нам нужно указать конфигурацию сети. Смотрим вывод ifconfig — настройку физического интерфейса и docker0 — и приступаем к настройке.

Конфигурационный файл config-default.sh

Это основные настройки, позволяющие запустить K8S. В файле также настраиваются параметры Docker и остальных компонентов, журналирование, мониторинг. Если к интернету подключение происходит через прокси, то его параметры следует прописать в PROXY_SETTING .

Теперь можно развернуть кластер.

Скрипт закачает и установит все необходимые компоненты (etcd), на все прописанные в конфиге ноды. В процессе потребуется указать пароль для управления узлом. По окончании получим сообщение Cluster validation succeeded. Причем скрипт повторно будет скачивать последний релиз K8S — чтобы не повторять это дважды, просто скопируй файл kubernetes.tar.gz в каталог kubernetes/cluster/ubuntu и подправь скрипт закачки download-release.sh .

Еще одна проблема, которую не могут устранить уже пару месяцев, — это ошибка при создании кластера:

Нужный файл расположен в каталоге kubernetes/server , его просто забыли положить на место. Это можно сделать вручную или добавить в cluster/ubuntu/download-release.sh две строки распаковки kubernetes-salt .

После чего master будет слушать на порту http://127.0.0.1:8080. Остановить кластер можно также одной командой:

Управляем кластером

Для управления K8S используется утилита kubectl. Настройки можно указывать прямо в командной строке или использовать заранее подготовленный YAML/JSON-файл. Чтобы было проще вводить команды, укажем в переменной PATH, где ее искать.

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

Добавить комментарий