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
   

   View Slide

2. Myself
   Programmer & Future Memester
   Inquiries: ev@radi.ws
   Arguments: twitter.com/evadne
   

   View Slide

3. 1
   Journey to Orleans
   

   View Slide

4. One Stateful Server (Pet)
   Server
   Database
   

   View Slide

5. One Stateful Server (Pet)
   Server
   State
   Stored Here
   Database
   

   View Slide

6. Multiple Stateless Servers
   Server
   Load
   Balancer
   Server
   Server
   Server
   Database
   

   View Slide

7. Multiple Stateless Servers
   Server
   Load
   Balancer
   Server
   Server
   Server
   State
   Stored Here
   Database
   

   View Slide

8. No Consistency
   Server
   Load
   Balancer
   Server
   Server
   Server
   Database
   Cache
   

   View Slide

9. No Consistency
   Server
   Load
   Balancer
   Server
   Server
   Server
   Database
   Cache
   Also Here
   State
   Stored Here
   

   View Slide

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
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

13. Historical Context B⁄e
    > The actor model offers an appealing solution to these
    challenges by relying on the function shipping
    paradigm.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

16. Historical Context E⁄e
    > To build a correct solution to such problems in the
    application, the developer must be a distributed
    systems expert.
    

    View Slide

17. 2
    Orleans Primer
    

    View Slide

18. View Slide

19. Grain = identity +behavior[+ state ]
    User / jack@email.com
    In -memory
    or persisted
    class User : Grain , IUser
    

    View Slide

20. View Slide

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.
    

    View Slide

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.
    

    View Slide

23. 3
    In Through the BEAM
    

    View Slide

24. View Slide

25. Erleans: Erlang Orleans
    

    View Slide

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)
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

29. 4
    Time for Science
    

    View Slide

30. View Slide

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.
    

    View Slide

32. Demo: Inefficient Life
    Persistence (Default vs Custom)
    Communication
    Parallelisation
    

    View Slide