Aggregate Computing Platforms: Bridging the Gaps

Aggregate Computing: Bridging the Gaps

Roberto CasadeiPhD Student in CS&Eng

[email protected]

Department of Computer Science and Engineering (DISI)

Alma Mater Studiorum – Università of Bologna

Pervasive Computing course

R. Casadei Intro ACP Analysis Technology Wrap-up 1/49

[email protected]

Engineering apps AC: recap

Outline

1 Introduction

Engineering pervasive computing applications

Aggregate Computing: recap

2 Analysis for an Aggregate Computing Platform (ACP)

3 Technology: quick survey

4 Wrap-up



Outline

1 Introduction




Requirements

Analysis

Current framework


4 Wrap-up



The starting point of any engineering process

A vision that must be made concrete / top-down or bottom-up



Applications as the interface to the needs

Abstractly defined until some concrete underlying technology is identified



Aggregate Computing: bridging the gap to SASO systems

Supports the development and execution of Aggregate Computing applications



Zooming the AC layer



Outline

1 Introduction




Requirements

Analysis

Current framework


4 Wrap-up



Aggregate Computing (AC) » what

Goal: programming the collective behaviour of aggregates of devices

Main ideasI Macro-level programming with automatic macro-micro bridging

I DeclarativityI Support for “engineered emergence”

I Composition of aggregate behaviour with predictable dynamicsI Layers of reusable abstractions

I Abstraction from interaction-level and platform-level issuesI Inherent adaptivityI Inherent resiliencyI Operational flexibility



Compositionality in AC: exampletrait DistributedSum extends AggregateProgram {def distribSum(size:Double, metric: =>Double, v:Double): Double = {???

}}

trait Broadcast extends BlockG with ... { s: AggregateProgram =>def broadcast[V: Bounded](src: Boolean, value: V): V =G(src, value)(x => x, nbrRange)

}

trait SumCollect extends BlockC with ... { s: AggregateProgram =>def sumCollect(target: Boolean, value: Double): Double =C(value)(distanceTo(target,nbrRange))(_+_,0)

}

:Distributed sum

I Split the space into regions with grain sizeI Calculate the mean of field v in each region

I Collect the values and the number of nodes in the regionI Compute the averageI Propagate the computed value



Compositionality in AC: exampletrait DistributedSum extends AggregateProgramwith BlockG with BlockC with BlockSwith Broadcast with SumCollect with Utilities

{def distribSum(size:Double, metric: =>Double, v:Double): Double = {val leaders = S(size, metric)???

}}

:



Compositionality in AC: exampletrait DistributedSum extends AggregateProgramwith BlockG with BlockC with BlockSwith Broadcast with SumCollect with Utilities

{def distribSum(size:Double, metric: =>Double, v:Double): Double = {val leaders = S(size, metric)val potential = distanceTo(leaders, metric)???

}}

:



Compositionality in AC: exampletrait DistributedSum extends AggregateProgram ... with SumCollect {def distribSum(size:Double, metric: =>Double, v:Double): Double = {val leaders = S(size, metric)val potential = distanceTo(leaders, metric)val collection = sumCollect(leaders, v)val count = sumCollect(leaders, 1.0)val avg = collection / count

}}

:



Compositionality in AC: exampletrait DistributedSum extends AggregateProgram ... with Broadcast {def distribSum(size:Double, metric: =>Double, v:Double): Double = {val leaders = S(size, metric)val potential = distanceTo(leaders, metric)val collection = sumCollect(leaders, v)val count = sumCollect(leaders, 1.0)val avg = collection / countbroadcast(leaders, avg)

}}

:



Aggregate Computing (AC) » how

I Repeated executionI Provides reactivity and incremental adaptivity

I Broadcast + aligned interactionI Allows the construction of a “local” context for computation


Requirements Analysis Current framework

Outline

1 Introduction


Requirements

Analysis

Current framework


4 Wrap-up



Outline

1 Introduction




Requirements

Analysis

Current framework


4 Wrap-up



Requirements for an Aggregate Computing platform

High-level, Functional

FR1 Support the specification and configuration of AGGREGATE-SYSTEMsFR2 Support the runtime execution of AGGREGATE-APPLICATIONs

High-level, Non-functional

NR1 Scalability to a large number of NODEsNR2 Reliability

I An AGGREGATE-SYSTEM made of unreliable INFRASTRUCTURAL-COMPONENTs andunreliable NODEs should be able to continue operation even in face of faults.



Outline

1 Introduction




Requirements

Analysis

Current framework


4 Wrap-up



Requirements analysis

Approach: informal but systematic (cartesian)

I Give names to thingsI Refine meaning and relationshipsI Explore in (mentally simulated) use, adopt perspectives and visualizeI (Then, formalize early, when enough committed)

I AGGREGATE-LOGIC: the representation-independent view of someaggregate-level behaviour in space/time

I AGGREGATE-PROGRAM: an AGGREGATE-LOGIC expressed in some executablerepresentation

I AGGREGATE-SYSTEM: a set of networked NODEs supporting the collectiveexecution of AGGREGATE-PROGRAMs

I AGGREGATE-APPLICATION: a particular AGGREGATE-LOGIC running on a certainAGGREGATE-SYSTEM, aimed at solving some problem in some context



High-level, logical, informal model

I Starting point for a systematic characterisation of our (fuzzy) class of systemsI We think of no specific application/system, but a range of applications/systems

I to support/drive analysis and be concrete



Structure / Interaction / Behaviour decomposition

(Logical) Structure

I DEVICEs (aka NODEs, AGENTs)I Have an identity (UID)I Have SENSORs and ACTUATORs

(Logical) Behaviour/Interaction

I A DEVICE can only directly communicate with the DEVICEs of itsNEIGHBOURHOOD

I A DEVICE computes its part of AGGREGATE-LOGIC on a round-by-round basisI Steps of a round of execution

1) Retrieve the device’s CONTEXT (SENSOR-DATA, NBR-DATA)2) Execute LOCAL-AGGREGATE-LOGIC to produce OUTPUT + EXPORT3) Broadcast EXPORT to NEIGHBOURHOOD4) Feed ACTUATORS with OUTPUT

This characterization is mainly logical and “standard”

I Many questions arise: who? what? where? when? how?



Analysis » execution rounds I

SCHEDULING-POLICY: who decides when a round has to be executed?

I A SCHEDULER (owned by a device or external)

Construction of the CONTEXT using up-to-date SENSOR-DATA and NBR-DATA

I Ideally, we’d like to separate the time/frequency in which these information arecollected from the time in which they are received

I Retrieval of SENSOR-DATA: request/response to device’s SENSOR or sampling ofan incoming SENSOR-DATA-STREAM

I Note: location data (e.g., GPS coords) may need to be sent to theTOPOLOGY-MANAGER

I Retrieval of NBR-DATA: request/response to a FIELD-MANAGER or sampling of anincoming NBR-DATA-STREAM

Who actually executes the AGGREGATE-LOGIC for a given DEVICE?

I An AGGREGATE-LOGIC-EXECUTOR (owned by a device or external)



Analysis » execution rounds II

Broadcast of EXPORT to NEIGHBOURHOOD

I By the DEVICE itself (if it knows how to reach its NEIGHBOURHOOD)I But the DEVICE’s awareness of communication is questionable

I “No matter who you are! I know where you are” [ZM04]

I The DEVICE may simply send its computation descriptors (EXPORTs) to theFIELD-MANAGER

I The FIELD-MANAGER in turn may delegate the task to an EXPORT-PROPAGATOR

I which must then know the NEIGHBOURHOODs and how to reach them

Invocation of ACTUATORs

I In general, we may have ACTUATION-DATA-STREAMs directed to ACTUATORswhich may be controlled by (but still decoupled from) rounds.



Analysis » neighbourhood

NBR-POLICY: how is NEIGHBOURHOOD determined?

I May be communication-determined (i.e., my neighbours are those I can reach)I May be spatially-determined (i.e., derived from the devices’ position in space)I May be ad-hoc (i.e., application-specific)

Who owns the knowledge of a device’s NEIGHBOURHOOD?

I A TOPOLOGY-MANAGER (owned by a device or external)

Who uses the knowledge of a device’s NEIGHBOURHOOD?

I The EXPORT-PROPAGATOR

Properties of NEIGHBOURHOOD

I It is usually dynamicI Can be asymmetric



Analysis » configuration

How do components locate (the address of) other components?

I DEVICEs should be addressable to support e.g. peer-to-peer interaction or thethe delivery of ACTUATION-DATA

I The mappings between DEVICEs’ UIDs and their ADDRESS may be kept in aREGISTRY

I Devices should also be given some CONFIGURATION data – so that they know theADDRESS of required services

How do AGGREGATE-LOGIC-EXECUTOR obtain the AGGREGATE-LOGIC to execute?

I Can be provided at deployment or configuration time



Logical components emerging from analysis (dev-centric)

It comes natural to assign many responsibilities to the DEVICEs (cf., p2p setup)..



Logical components emerging from analysis (sys-centric)

It comes natural to consider DEVICEs only as situated contexts..



Many kinds of deployments

Such flexibility demands for fluid responsibilities



The data perspectiveData payloads

I SENSOR-DATA: map from sensor UIDs to sensor valuesI ACTUATION-DATA: map from actuator UIDs to actuation valuesI NBR-DATA (i.e., EXPORTS): map from neighbour UIDs to exportsI CONTEXT-DATA = SENSOR-DATA + NBR-DATA

Control data

I SCHEDULE-DATA (i.e., TICKs)I ...

Configuration data

I Deployment data, addresses, ...I ...

Analysis from a data (flow) perspective

» On an app-specific basis, analysis of Volume-Velocity-Variety-Veracity» Further analysis: persistent vs. transient data» Further analysis: replication, partitioning, ...» Analysis of data flow can help architectural design (cf., reactive architectures)



Outline

1 Introduction




Requirements

Analysis

Current framework


4 Wrap-up



SCAFI: state-of-art



AC Platform: state-of-art

Key features

I Actor-based (Akka)I Two styles

a) fully decentralised (P2P)b) server-based (mediating interactions)

I Simple object-oriented API façadeI Easy configuration (file, cmd-line, programmatically)

Limitations (work-in-progress)

I Not ready for use across the InternetI Serialization issues and constrained architecture due to nested designI Tightly coupled with SCAFI-core



AC actor platform: overview



AC actor platform: building



AC actor platform: modular actor design



AC actor platform: styles


Outline

1 Introduction



4 Wrap-up


Message-oriented middlewares

Why: decoupling consumers from producers (in both space and time)

RabbitMQ

I General purpose message brokerI Supports protocols such as AMQP, MQTT, STOMP etc.I Flexible routingI Concepts: publishers, brokers, consumers, exchanges, bindings, queues, ...

Apache Kafka

I Distributed, partitioned, replicated commit-log-based publish-subscribemessaging system

I Persistent messagingI Concepts: producers, consumer instances/groups, topics, cluster of brokers,

per-topic partitioned log, log retention, ...


StreamingDimensionsI Types of datasets: bounded vs. unboundedI Types of processing: batch vs. streaming

Why: need for processing that execs continuously as long as data is being produced

Apache Flink

I Stream processing framework for distributed, high-performing, always-available,and accurate data streaming applications

I Concepts: data sources, transformations, data sinks, dataflow, operatorsubtasks, stream partitions, flexible windows for stream aggregation...

I Deployment modes: cloud / on premise / cluster (managed by YARN or Mesos)I Guarantees exactly-once semantics for stateful computations (checkpointing)

Apache Storm

I Concepts: topology as graph of spouts (sources) and bolts; streams asunbounded sequences of tuples; groupings defining how streams are partitionedamong the bolt’s tasks

I Trident: exactly-once, high-level API, enabling micro-batching within a stream


Lightbend Fast Data Platform


NoSQL data stores and spatial indexes

Why: in Aggregate Computing, data has peculiar characteristics and access patterns

I Nodes are often spatially situated and mobileI Locality principle (cf., neighbourhood)

I Typical query: “get most recent exports of my neighbours”

Spatial DBs and spatial indexes

I Redis supports geospatial indexesI Commands: GEOPOS, GEOADD, ...

I Neo4J (graph DB) and Neo4j Spatial plug-inI PostGIS: spatial and geographic objects for PostgreSQL


Automated cluster managementWhy: abstract over resources and support distributed, fault-tolerant, elasticdeployments

Apache Mesos: a distributed systems kernel for managing clusters

I Provides APIs for resource management and scheduling across datacenter andcloud environments

DC/OS: the datacenter operating system, based on Mesos

I Manages multiple machines in the cloud or on-premises from a single interfaceI Deploys containers, distribute services and legacy apps into machinesI Provides networking, service discovery and resource management to keep the

services running and communicating with each otherI Marathon: a container orchestration platform for Mesos and DC/OS

Docker: SW containerization platform

I Docker Swarm for managing clusters of Docker engines

Kubernetes: platform for automating container operations

I Supports automating deployment, scaling, & management of containerized apps


Outline

1 Introduction



4 Wrap-up


Summary: key ideas

Aggregate programming

• A macro-programming approach to CASs, formally grounded in Field Calculus• Allows composition of (self-stabilizing) SASO patterns.

The abstract model is decoupled from the execution strategy

• Aggregate computing is suitable for exec across several platforms/infrastructures• From ad-hoc networks to cloud/fog computing• Can be extended to dynamically exploit available/heterogeneous infrastructure

SCAFI: a Scala framework for Aggregate Programming

• Provides an internal DSL for field-based computations• Provides simulation facilities• Provides an actor-based platform for building aggregate systems


Perspectives, projects, future works I

Algorithms and SCAFI library

I Flocking and mobility (De Castri/Foschi/Paolucci)I Anticipative Gradient (Berlini)

SW engineering (AC as a case study)

I AC Platform analysis/design and impl/refactoring (Scala)I Actor-based platform bootstrap (Casadei [Cas])I GUI interface to simulator: bootstrap (Varini) & refactoring (Aguzzi)

I Testing/debugging of AC appsI Load/performance testing of AC appsI Tools and automation support in SCAFI

I Continuous Integration (Fantini)


Perspectives, projects, future works II

Integration and applications

I SCAFI on Android (Radaelli, Collini)I SCAFI-Alchemist integration proof-of-concept (Costanzi [Cos])I Web/RESTful interfaces to AC systems, Web of Things (WoT)

AC and Service/Cluster/Cloud Computing

I AC and IoT platforms (Farneti [Far])I Development of a custom PaaS for ACI Prototyping a scalable AC cluster with open-source solutions (Paolucci)I Reactive AC architectureI Fields like Big Data and NoSQL solutions (Riciputi)


Perspectives, projects, future works III

Innovative themes and experiments

I AC and computer security (Mantani [Man])I Aggregate processes (Foschi)I AC and complex networksI AC and topological methods (math-oriented)

MiscellaneousI Comparing AC to BSP-based graph processing systems (Pregel/Giraph)


Application scenarios

I Crowd engineeringI Distributed sensingI Contextual servicesI Smart cityI Smart homeI Industry 4.0I WSNsI Swarm intelligence (robots, drones)I Rescue scenarios


Project example #1: exploration

Scenario: exploration of unknown environments (Mars?)

I Mobile robotsI Must move and stay at the right distance, communicating frequentlyI May need to come back or send information (e.g., hop-by-hop) to a fixed base of

operationsI Assumption: no infrastructure, peer-to-peer communication (ad-hoc network)I Progression: analysis - design - simulation - evaluationI Extension: rescue


Project example #2: dynamic platform reconfiguration

Goal: draft a simple solution design for dynamic reconfiguration of system nodes

I Cf., MAPE designI Monitoring: monitor local status of infrastructureI Analyze: determine the best option for communication and interaction (wrt to

QoS)I Plan: plan a gentle reconfigurationI Execute: distribute the reconfiguration data and commandsI Application example on top: crowd density monitoring and warning servicesI Progression: analysis, design, prototype


Project example #3: AC and WoT

Goal: provide a web interface to system nodes

I E.g., for de/activation of sensorsI E.g., to command actuators (e.g., for mobility)I E.g., to query device stateI Not every node may be able to connect to Internet and support this

I Internet-enabled neighbour nodes may still be able to provide such info

I In practice: design a set of ReSTful services and a web interfaceI Application example on top: distributed sensing


References

References I

[Cas] Roberto Casadei.Aggregate programming in scala: a core library and actor-based platform fordistributed computational fields.Master’s thesis.

[Cos] Simone Costanzi.Integrazione di piattaforme d’esecuzione e simulazione in una toolchain scalaper aggregate programming.Master’s thesis.

[Far] Thomas Farneti.Design and deployment of an execution platform based on microservices foraggregate computing in the cloud.Master’s thesis.

[Man] Giacomo Mantani.Towards security-aware aggregate computing.Master’s thesis.

R. Casadei Appendix 49/49

References

References II

[ZM04] Franco Zambonelli and Marco Mamei.Spatial computing: An emerging paradigm for autonomic computing andcommunication.In Workshop on Autonomic Communication, pages 44–57. Springer, 2004.

R. Casadei Appendix 50/49