Edge Architecture for Dynamic Data Stream Analysis and Manipulation

Abstract

The exponential growth in IoT and connected devices featuring limited computational capabilities requires the delegation of computation tasks to cloud compute platforms. Edge compute tasks largely involve sending data from an edge compute device to a central location where data is processed and returned to the edge device as a response. Since most edge network infrastructure is restricted in its ability to dynamically delegate computation while retaining context, these events are commonly limited to a predefined task that the edge function is modeled to process and respond to. Edge functions traditionally handle isolated events or periodic updates, making them ill-suited for continuous tasks on streaming data. We propose a decentralized, massively scalable architecture of modular edge compute components which dynamically defines computation channels in the network, with emphasis on the ability to efficiently process data streams from a large amount of producers and support a large amount of consumers in real time. We test this architecture on real-world tasks, involving chaining of edge functions, context retention, and machine learning models on the edge, demonstrating its viability .

A Comparison with different architectures

In addition to the benefits accrued by our overarching edge architecture, there is room to break down individual components and compare them to other possible design choices. MQTT is one protocol chosen from the few emerging protocols of choice for the IoT world. While we evaluated both MQTT and CoAP and found both to be comparable, we chose MQTT for our pub/sub protocol as it had better library availability and broker seleciton. We compare our choice of MQTT with an HTTP based singnaling mechanism to support our architecture. In our architecture, we make use of MQTT as a signaling channel between subscribed clients waiting on streams of data, and between edge nodes coordinating execution of models on data. The key observation here is that our MQTT connection are seldom closed, and in most cases reused many times between the time they are established and close. The comparison made in [21] clearly shows the benefits of utilizing an open MQTT connection with exponential benefits over the same use case implemented using HTTP. Similarly to [21], we investigate the difference between 1, 10, and 100 messages each weighing 10 bytes, transmitted over MQTT and HTTP, over 10 trials. This simulates transferring simple instructions and EKV data locations in our computation channels. For MQTT we connect once and reuse the same connection to communicate all subsequent messages. For HTTP we use POST requests. All communication was evaluated between an edge node and a local client, emulating a real world scenario. Figure 8 and 9 show the log scale results for speed in ms, as observed in our test. Since HTTP grows as a factor of messages passed we see the benefit of opening a single MQTT connection to be used over multiple messages.

Fig. 8.

MQTT speed per number of requests compared at log scale of ms.

Fig. 9.

HTTP speed per number of requests compared at log scale of ms.

Another aspect worthy of comparison is the speed gain of using our architecture as compared to the same job implemented as a FAAS workflow, where results must be returned back to a user before the next function in a pipeline is started. We compare a simple numpy matrix multiplication task, called via our MQTT computation channels 1,10 and 100 times, where results are pushed to a MinIO storage instance. This is compared to the case where a function runs and returns a result directly to a client. In the case where we run our function more than 1 time, we compute the next result based on the previous functions result. In the FAAS like use case, the client sends back the result to the function, and in our architecture, the previous result is picked up from our MinIO instance. Figures 10 and 11 show the comparison between the two approaches. It can be seen that the impact on sending the little amount of data we use back and forth using HTTP POST requests, essentially does not change the POST requests time for execution. While the time increases using MQTT computation channels and ephemeral storage, where an extra call to the MinIO server is needed. However, even with this increase, it can be seen that as the amount of concurrent requests grow, the penalty incurred by POST requests is far more inhibiting then the extra hop to MinIO. As we have previously shown in our experiments, MQTT can be used for small scale data and speed up computation even more in cased where not much data is moved in the network.

Fig. 10.

Speed of calling our function via HTTP POST requests, and sending back the result for all cases where the function was called more than once. Compared at log scale of ms.

Fig. 11.

Speed of calling our function via an MQTT computation channel, send result to an ephemeral storage, and compute results based on previous function run for all cases where we call the function more than once. Compared at log scale of ms.