Processes & Grains — A Journey in Orleans

Transcript

1. Processes & Grains: A Journey in Orleans Evadne Wu Your Fellow Bodgemaster ev@radi.ws twitter.com/evadne
2. Myself Programmer & Future Memester Inquiries: ev@radi.ws Arguments: twitter.com/evadne
3. 1 Journey to Orleans
4. One Stateful Server (Pet) Server Database
5. One Stateful Server (Pet) Server State Stored Here Database
6. Multiple Stateless Servers Server Load Balancer Server Server Server Database
7. Multiple Stateless Servers Server Load Balancer Server Server Server State Stored Here Database
8. No Consistency Server Load Balancer Server Server Server Database Cache
9. No Consistency Server Load Balancer Server Server Server Database Cache Also Here State Stored Here
10. Problems Infrastructure Sprawl: It is not uncommon to have to spin up many more servers dealing with caching/ searching than those hosting the actual application Invalidation Issues: Loss of ACID guarantee from the database, often accepted as trade-off
11. Historical Context Orleans: Distributed Virtual Actors for Programmability and Scalability Philip A. Bernstein, Sergey Bykov, Alan Geller, Gabriel Kliot, Jorgen Thelin Microsoft Research Abstract High-scale interactive services demand high throughput with low latency and high availability, difficult goals to meet with the traditional stateless 3-tier architecture. The actor model makes it natural to build a stateful middle tier and achieve the required performance. However, the popular actor model platforms still pass many distributed systems problems to the developers. The Orleans programming model introduces the novel abstraction of virtual actors that solves a number of the complex distributed systems problems, such as reliability and distributed resource management, liberat- ing the developers from dealing with those concerns. At the same time, the Orleans runtime enables applications to attain high performance, reliability and scalability. This paper presents the design principles behind required application-level semantics and consistency on a cache with fast response for interactive access. The actor model offers an appealing solution to these challenges by relying on the function shipping paradigm. Actors allow building a stateful middle tier that has the performance benefits of a cache with data locality and the semantic and consistency benefits of encapsulated entities via application-specific operations. In addition, actors make it eas o implemen hori on al, social , relations between entities in the middle tier. Another view of distributed systems programmabil- ity is through the lens of the object-oriented program- ming (OOP) paradigm. While OOP is an intuitive way to model complex systems, it has been marginalized by the popular service-oriented architecture (SOA). One can still benefit from OOP when implementing service components. However, at the system level, developers
12. Historical Context A⁄e > With or without cache, a stateless middle tier does not provide data locality since it uses the data shipping paradigm: for every request, data is sent from storage or cache to the middle tier server that is processing the request.
13. Historical Context B⁄e > The actor model offers an appealing solution to these challenges by relying on the function shipping paradigm.
14. Historical Context C⁄e > Actor platforms such as Erlang and Akka […] still burden developers with many distributed system complexities because of the relatively low level of provided abstractions and system services.
15. Historical Context D⁄e > The key challenges are the need to manage the lifecycle of actors in the application code and deal with inherent distributed races, the responsibility to handle failures and recovery of actors, the placement of actors, and thus distributed resource management.
16. Historical Context E⁄e > To build a correct solution to such problems in the application, the developer must be a distributed systems expert.
17. 2 Orleans Primer
19. Grain = identity +behavior[+ state ] User / jack@email.com In -memory or persisted class User : Grain , IUser
21. Orleans Grains… …represent single-threaded processes; …can be configured to allow reentrant calls; …are scheduled cooperatively (never preempted); …are automatically activated to handle messages; …are automatically deactivated by the runtime.
22. Orleans Hosts (Silos)… …are responsible for hosting grains; …communicate with each other to form a cluster; …have view of where grains are at all times.
23. 3 In Through the BEAM
25. Erleans: Erlang Orleans
26. Erleans: Short Overview Each activated grain runs in one process. Process Registration is delegated to lasp_pg. ETS-backed provider for state persistence included! Grains are implemented as callback modules to :erleans_grain (similar to GenServer)
27. Erleans: Alternatives Swarm / Horde can be used to implement the distributed Registry. Barring that, pg2 (part of Erlang kernel) can be considered as well. The gen_statem behaviour in OTP can be used to implement deactivation timeout. An Elixir wrapper, GenStateMachine, can also be used if desired.
28. Erleans: Alternatives Swarm / Horde can be used to implement the distributed Registry. Barring that, pg2 (part of Erlang kernel) can be considered as well. The gen_statem behaviour in OTP can be used to implement deactivation timeout. An Elixir wrapper, GenStateMachine, can also be used if desired.
29. 4 Time for Science
31. Rules A live cell with fewer than 2 live neighbors dies; A live cell with more than 3 live neighbors dies; A live cell with 2 or 3 live neighbours still lives; A dead cell with 3 live neighbors comes to life.
32. Demo: Inefficient Life Persistence (Default vs Custom) Communication Parallelisation