Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Easy Scalability with Akka - Scala Days 2015

20,078 views

Published on

Michael Nash presented "Easy Scalability with Akka" at Scala Days 2015 in San Francisco & Amsterdam. Learn more on our blog and watch the video: http://bit.ly/1KpX9Z6

Every enterprise developer these days needs to be an expert in building REST API systems to enable mobile applications, SOA architectures and single page javascript web apps. The challenge is that most REST API backends can’t quickly scale to the numbers of requests needed in a modern enterprise. In this talk, we will introduce enterprise developers to Akka in an engaging and simple way and give them the confidence that they could quickly and easily build an enterprise web service that scales in their own workplace. This live coding session will showcase Akka’s power by taking an existing REST API and improving its throughput drastically by introducing a distributed actor system. Starting from a simple RESTful application exposing read and write operations, we’ll introduce a series of Akka features and patterns, scaling the performance and reliability of the system progressively.

We will introduce the Actor pattern, and show how Akka brings this pattern easily and simply to the JVM. A simple actor system will separate concerns and serve as the basis of the exercise. Clustering will allow the system to grow and shrink dynamically, across one or more machines, with messages being passed transparently between nodes as needed. CQRS (Command-Query Response Separation) will decouple writes from reads and introduce non-blocking message handling, and Akka Persistence will make nodes tolerant to failure and avoid data loss.

We’ll show how simple decoupling via message-passing of the system components allows you to scale each part of your service to match changing load.

If you need more write performance, you can increase the number of nodes handling writes. Need more REST-API capability, increase the nodes binding to HTTP. Each element is independently elastic for full tuneability.

Throughout the process, we’ll use Gatling to gauge our results in the form of handled requests per second. Watch our application go from Fast to Enterprise-Level Web Scale in 45 minutes or less, with very little code.

Published in: Software
  • Login to see the comments

Easy Scalability with Akka - Scala Days 2015

  1. 1. Easy Scalability with Akka Distribute your domain
  2. 2. Who? ● BoldRadius Solutions ○ boldradius.com ○ Typesafe Partner ○ Scala, Akka and Play specialists ○ Ottawa, Saskatoon, San Francisco, Boston, Chicago, Montreal, New York, Toronto ● Michael Nash, VP Capabilities ○ @MichaelPNash ○ michael.nash@boldradius.com
  3. 3. What? What will I know in the next 45 minutes? ● Distributed Domain-Driven Design ○ What is it, and how does it apply to project? ○ What is CQRS and ES, and how to they relate? ● Akka ○ How to do DDDD and CQRS/ES with Akka ○ What is different in a DDDD Akka project, and why? ○ How does this kind of project scaled compared to a “normal” project, even with Akka?
  4. 4. Scalability ● Scalability is not performance ○ Performance increasing reduces response time ○ Scalability increasing improves capacity in relation to added resources ● Scalability can be... ○ Vertical (Scaling “up”): Bigger box (or boxes) ○ Horizontal (Scaling “out”): More boxes
  5. 5. ● The Actor model for the JVM ○ A share-nothing distributed message- driven compute model ○ Scala and Java APIs ● Like Erlang/Elixir processes, only better ○ Distributed by design, local is an optimization
  6. 6. CQRS and ES ● Command Query Responsibility Segregation ○ Separate the read and write paths of the problem ● Event-Sourcing ○ State is built from a journal of events ● One doesn’t need the other, but they can be combined very effectively
  7. 7. Event Sourcing
  8. 8. CQRS
  9. 9. Domain ● Your application’s domain is the part that relates to the problem ● The rest of your application is infrastructure, basically ● If you have a Payroll app, then Employees, Benefits, Pay Stubs are in your domain
  10. 10. DDDD ● Domain-Driven Design (DDD) is not only for Object-Oriented Systems ● Object-Oriented and Functional are not an either-or choice, or at odds with each other ● Distributed Domain Driven Design is a natural fit with the actor model
  11. 11. Traditional Domain Instances
  12. 12. Non-Distributed Domain ● Basic CRUD (Create, Read, Update, Delete) ● Writes and reads to same database ○ Always consistent ● Scaled via multiple identical replicas ○ and load balancing on HTTP ● Bottlenecks on contention ○ reads and writes interfere with each other
  13. 13. When we scale the traditional model… ● We add multiple servers ○ so there’s more than one copy of each domain instance (potentially) ● Each must read state every time ○ from the shared resource (the database) ● Each must write (fully) to the same shared resource to avoid conflict ● Scalability is limited
  14. 14. With Akka and DDDD ● Wouldn’t it be great if you could just keep your domain instances in memory? ● But how to recover from its volatile nature: an event journal!
  15. 15. But I have too many instances! ● Only active domain instances are in memory ● Instances activate and passivate as needed
  16. 16. Activation and Passivation
  17. 17. Ingredients ● Akka - Scala API ○ with Clustering and Persistence modules ● Cassandra ○ And the DataStax driver ● Typesafe Activator ○ For our template
  18. 18. What’s Different? ● Domain object instances are transient, and memory-resident when in use ● Reads and writes don’t contend for resources ● Cluster can be grown until domain instances per node = 1
  19. 19. What do you get? ● Scalability ○ Add nodes to handle higher load on the fly ● Failover ○ No single point of failure or contention ○ Instances can be created anywhere as needed ● Simplicity ○ Build your app without having to worry about scalability later
  20. 20. Consider your own domain ● Consider writes independently from reads ○ Are they really the same even now? ● Deployment structure is critical to get all benefits safely
  21. 21. Example Applications Online Auctions: Two implementations ● Users place bids for online auctions ● Most code shared ● Identical APIs ● Identical deploy structure, same machines, same number of nodes ● One CRUD, One CQRS/DDDD
  22. 22. CRUD Actor ● Uses Akka ● Receives request ● Writes to datastore directly
  23. 23. CRUD Actor
  24. 24. CQRS/DDDD Actor ● In-memory state ● Recovers state from journal on startup ● Uses become to change states ● Passivates on timeout
  25. 25. Test Setup 3 Cassandra Nodes (Clustered) 3 Akka processing Nodes (Clustered) 1 Front-end (Part of the Akka cluster) All Small AWS Instances 100 simultaneous users 100 auctions Two minutes of bidding
  26. 26. Simulation
  27. 27. Response Time Distribution CRUD CQRS Scale is different!
  28. 28. Response Time Percentiles: CRUD
  29. 29. Response Time Percentiles: CQRS Note that the scale is different!
  30. 30. Requests per Second: CRUD
  31. 31. Requests per Second: CQRS Scale is different!
  32. 32. Total Requests/Responses in 2 mins CRUD: 75,991 CQRS: 199,357
  33. 33. Adding more nodes... ● CRUD version ○ Contention increases ○ Diminishing benefit to adding more nodes ○ Tuning doesn’t help much ● CQRS version ○ No contention ○ Near-linear benefit until number of nodes = number of auctions ○ Tuning is very important (type of nodes too…)
  34. 34. Activator Template https://github.com/boldradius/akka-dddd-template Add your own domain!
  35. 35. Q & A michael.nash@boldradius.com
  36. 36. Further Reading

×