This section describes the overall architecture of the current solution and includes a list of addressed components describing what they do, how they are implemented and how they interact with each other.
Front End
The front end consists of a web page containing both regular web content as well as func-tionality to support asynchronous communication with the back end. It could either consist of a page providing the regular use case for the service i.e. voting functionality or it could consist of a page providing administrative functionality. The page for the regular use case is incorporated into another service’s web page using an Iframe. The front end communicates with the back end using the API from Socket.IO and JavaScript. Messages are sent as plain text using JavaScript Object Notation (JSON).
Load Balancer
When a client first connects, it speaks with a load balancer that keeps track of all the running instances of the web servers and routes the client to one of them. The load balancer only routes the client when it is first connecting, after the client has been assigned a web server, the client speaks directly to the web server. The load balancer makes sure that a previously connected client always gets the same web server to talk to when it is reconnecting to the
4.2. System Overview 31
Figure 4.2: Overarching components in the reference solution. A web client fetches the static content from a static file store, which also contains the logic to communicate with the web server that contains the voting functionality. A web client connects to a web server using a load balancer. Any votes are put on a processing queue so that votes are bufferd to a data processing component that calculates a result and returns it using a notification system. The service also uses a database to store the global state of all events.
service. This is done using the load balancer HAProxy on an AWS Elastic Compute Cloud (EC2) instance.
Web Server
The web server consists of a cluster of AWS EC2 instances that are running Tornadio2 which is a python implementation of Socket.IO on top of the Tornado web server framework.
Socket.IO is used to provide many ways of communicating asynchronously with a client with
32 Chapter 4. Evaluation of Reference System
fallbacks when one does not work because of client limitations, such as web browser support for the current techniques. The server instances are horizontally scaled up or down using AWS Auto Scaling depending on use statistics.
Static File Store
The service uses a file store to host the static web content that is fetched by connecting clients. The file store functions as a regular web server for static web pages and a client fetches the page directly from the file store using point-to-point file transfer without talking to the web servers of the back end. The currently used file store is the key/value store Simple Storage Service or S3 from AWS which can also function as a web server.
Client Validation Cache
The web servers uses a remote cache to store client validation information. The AWS ElastiCache is used to store this data outside of a specific web server. When a client connects to a web server it first checks with the validation cache to see if there are already some data on that client.
Data Processing Queue
When a web server receives a vote from a client it puts the message on a queue that connects to the data processing system. This is used to buffer the messages that is sent to the processing system and decouple space and time between the web servers and the processing system. The current system uses AWS Simple Queue Service or SQS to provide this functionality.
Data Processing
The processing of messages that are sent in from the clients are offloaded on a stream data processing system called Storm. This component receives votes from the processing queue, computes a result and sends it to all of the web servers using a notification system. Storm is also responsible for storing the result and other statistics in a database. The results that are computed are typically the mean value for a voting question or the vote count for a categorical question. Storm is deployed as a cluster on a number of EC2 instances. Storm uses a spout for the interaction with the Simple Queueing Service (SQS) which listens for and receives messages from the queue. It uses a bolt for the Simple Notification Service (SNS) to send results to the notification system and a bolt for the Relational Database Service (RDS) to update the database.
Notification System
The notification system is responsible for relaying messages between web servers and the data processing component. When Storm computes a new result it transmits the result to all web servers using the notification system. The notification system is also used by the administrators of the service to relay when a question has been started or stopped to the other web servers that the administrator is not connected to. AWS Simple Notification Service or SNS is used as the notification system.