Architecture

Orca is basically an Elastic Container service that uses YARN for resource management. Users can deploy standard Java .war (Web application archives that contain a web.xml). Orca wil launch Jetty containers that host the user web application on Hadoop YARN. It will also start a Proxy service/Load Balancer to front the application. Future versions of Orca will be able to scale the number of Jetty containers based on load.

1. The Client App contacts the ResourceManager and requests for an ApplicationMaster.

• Each deployed Web application will have its own ApplicationMaster
• The Client request also contains the application .war file (which it will request to be a LocalResources)
• The Client request will also specify the minimum / maximum number of containers required for the Application.
• If an ApplicationMaster has started successfully, the response to the client request would contain
  1. the Admin endpoint of the ApplicationMaster
  2. The public IP:PORT to which accepts HTTP requests (IP:PORT of the ProxyServer/LoadBalancer)

2. The ResourceManager Contacts a NodeManager on one of the nodes and starts the ApplicationMaster on it.

3. The ApplicationMaster requests for the minimum number of WebContainers to be launched and waits for the WebContainers to register back to ApplicationMaster

• The WebContainers are essentially Java Processes that embeds a Jetty Server.
• The Containers will also house a thread that
  1. Registers with the ApplicationMaster on startup
  2. Sends period Heart beats to the AppMaster

4. The ApplicationMaster also asks the RM for a node to host a ProxyServer/LoadBalancer (possibly nginx).

• This could be an standard Loadbalancer such as nginx.
• Another option would be to build a custom loadbalancer + autoscaler (which should be fairly easy for a first cut.. if we use an embedded Netty Container)
• The LoadBalancer state, as well as the number of nodes within the scaling group is stored in-memory (or can be persisted onto HDFS or HBase so the AM can survive restarts)

5. The WebConatiners send HeartBeats to the ApplicationMaster. (As previously mentioned, these heartbeats can also contain system monitoring information such as open connections/used memory to asses load)

• The Heartbeats can also contain other information such as number of open connections, memory usage etc.
• The ProxyServer/LoadBalancer process also sends Heartbeats to the Application Master

6. Based on Load information from the WebContainers, The ApplicationMaster can make changes to the LoadBalancer/AutoScaler configuration (change weights, add/remove nodes etc)

• The ApplicationMaster can make requests to the RM for additional Containers if the connection count / memory per container exceeds a threshold
• It can also release Containers, if load decreases.

7. An Admin can query the ApplicationMaster using the Admin Endpoint returned by the client is Step 1

8. The HTTP endpoint (ip:port), obtained from the Client response in Step 1 is subsequently used to accept requests. This request will then be routed by the LoadBalancer/AutoScaler to the appropriate WebContainer.