The document discusses the principles and advantages of building high-load applications using Akka, emphasizing the actor model for scalability and fault tolerance. It covers topics such as asynchronous communication, the benefits of Akka streams, and their application in big data scenarios, including transaction processing and complex event stream processing. The presentation highlights Akka's ability to efficiently utilize server resources while ensuring resilience and responsiveness in distributed systems.

1. How to build HighLoad application.
Akka Introdution

2. Agenda Presentation
This presentation about 1
2
3
4
Motivation.
Akka actor
On hands examples
Conclusion
5
Akka stream

3. Motivation
Why Do we need it?

4. What Do You know?
Scale out
High throughput
Work with an extra node
Work with data
Spark Streaming
Exactly know how to…
Scale up
High latency
Work with an extra processor
Work with cache
Streaming
Indirectly know how to..,
As a Big Data developer

5. Highload application
Problem is 1
2
3
4
Multithreading.
Deeply understanding. Executors, locks, async.
Bottlenecks
Network, database, algorithm
Load jump/Monitoring.
Data comes slowly and smoothly.(In real time).
Base line
Tuning JVM.
Stop the world5
Complexity.
From previous

6. Scale up
Scaling up by processor number (not by clock rate)
Parallel processing is capable of scaling

7. Parallel processing
1
2
No blocking code.
Blocking code is synchronous code.
Need to be in one thread
No side effect.
Blocking for mutable shared object.
Amdahl's law.
Speed up related to parallel processing

8. Amdahl's law
Execution latency & processor number

9. Side effects
1
2
3
Different objects uses shared object.
Shared object has mutable state.
Threads share the object

10. Again
Objects1
uses shared object2.
Is it a problem?
…
But everything is a thread.
Object is no thread safety.
Synchronization and lock?

11. AKKA in general
Problems Akka wants to solve

12. Akka Advantages
Actors and Streams let you build
systems that scale up, using the
resources of a server more efficiently,
and out, using multiple servers..
Simpler Concurrent & Distributed Sys.
Distributed systems without single
points of failure.
Load balancing and adaptive routing
across nodes.
Event Sourcing and CQRS with Cluster
Sharding.
Distributed Data for eventual
consistency using CRDTs.
Elastic & Decentralized
Building on the principles of The
Reactive Manifesto Akka allows you to
write systems that self-heal and stay
responsive in the face of failures.
Resilient by Design
Asynchronous non-blocking stream
processing with backpressure.
Fully async and streaming HTTP server
and client provides a great platform for
building microservices. Streaming
integrations with Alpakka..
Reactive Streaming Data
What declare and what want to achieve.
Up to 50 million msg/sec on a single
machine. Small memory footprint; ~2.5
million actors per GB of heap..
High performance

13. TimeLine Layout
2014
2013
2009
2006
Zero release Scala standard
Java 8 stable
version
First stable version
2018
It is quite stable product

14. Akka Landscape
Base. Actor model.
Distribution via JVM thread.
Akka Actor
Full server- and client-side HTTP sta
ck on top of akka-actor .
Distribution via world
Akka Http
Actors to persist their internal state.
Recovered after a JVM crash.
Reliability
Akka Persist
???
Akka Stream
Akka is not a library. Its distribution ideology.
Fault-tolerant decentralized peer-to-peer
based cluster.
Distribution via diferent nodes
Akka Cluster
Connectors & integration.
AWS, Cassandra, JDBC, Hbase.
Reliability
Alpakka

15. Akka actor
Why Do we need it?

16. Actor model is
The actor model adopts the philosophy that everything is an actor
Actors asynchronously communicates via messages
Decoupling sender and receiver via actor system
The actor system handle actors via mailing address

17. Actor is
1
2
3
4
Actor is an object in own thread.
Shared nothing. Encapsulated data
Direct communication and asynchrony
Process messages one by one

18. Actor can
Make local decisions
Create more actors
Send more messages
Modify own private state
In response to a message that it receives 1
2
3
4

19. Message is
1
2
3
4
Immutable.
Where should be all mutable info?
Serializable
Akka cluster allow send via network
Good practice
Declare in the same actor class
Bean like.
Possible big messages

20. Solution:
Actor
Model
Own thread
You could imagine Actor
as an thread safe object.

21. 모바일 이미지
You can implement
Locks and synchronization.
It is easy according to the nature of
actor.
Super vision.
Semaphore, Cyclic barer.
Easy
You can simply impress your
audience and add a unique zing
and appeal to your Presentations.

22. Simple communication

23. Harder Communication

24. Actor vs Object
Share nothing
Thread safe
Scalable UP
Simply scale out
Actor
Sharable state via fields
Thread unsafe
Hard to scale out
Object

25. Actor vs Thread
Light weight: ~2.5 million actor per GG
Self contained - shared nothing
Active.
Actor
Heavy weight: 2000-5000 at all
Shared state.
Have to call object.method()
Thread

26. Actor is not enough
1
2
3
Actor is not type safe.
Actor does not react on message overhead
Build complex flow is hard.

27. Akka Stream
Why? How? How exactly

28. Stream is enough
Type safe1
2
3
SDL based actors
Simplify workflow.
Build flows in declarative way
4 Streams are reactive

29. Publisher vs Subscriber
How to organize publisher and
subscriber communication. 1
2
3
Push based system.
Publisher send all data to subscriber.
Well for quick subscriber otherwise consumer
crash.
Pull based system.
Subscriber initialize request.
Well for slow subscriber but slow
Reactive system
Switch between push and pull

30. Publisher vs Subscriber
Content Here
You can simply
impress your
audience and add a
unique zing.
PUBLISHER SUBSCRIBER
Message
Demand
Negative acknowledge

31. Back-pressure
1
2
3
Buffer messages
For peak period
Drop elements
(Tail or head) If it is possible for
domain
Slow down producer.
If You have access to producer.
4
Fail

What to do with messages?

32. Basic concepts
1
2
3
4
Source
exactly one output, emitting data elements
to downstream processing
Sink
exactly one input, requesting and accepting data
elements.
Possibly slowing down the upstream producer
Flow
exactly one input and output, transforming data e
lements.
Should be connected to Source and Sink
RunnableGraph
Source (+ Flow) + Sink and run().
Stream is materialized and works

33. Code stream
1
2
3
4
Source
Sequence of integers
Sink
Reduce for calculated
Flow
* 10
RunnableGraph
All is completed

34. Simplify flow
1
2
3
4
Source + Flow = Source
Source + Sink = Runnable Graph
Flow + Flow = Flow
Flow + Sink = Sink
Construct any blocks
Block communication by Akka Streams

35. Conclusion
For big data development

36. Akka Use cases
1
2
3
4
Transaction processing(Online Gaming, Finance/Banking, Trading,
Statistics, Betting, Social Media, Telecom)
Scale up, scale out, fault-tolerance / HA
Service backend (any industry, any app)
Service REST, SOAP, Cometd, WebSockets act as message hub
Communications Hub (Telecom, Web media, Mobile media)
Scale up, scale out, fault-tolerance / HA
Complex Event Stream Processing
Scale up, scale out, fault-tolerance / HA5
Concurrency/parallelism (any app)
Just add the jars to your existing JVM project (use Scala, Java,
Groovy or JRuby)

37. Akka vs Spark

38. Around event vs around data
Time based
Focus on processing
Processed once
Event
Historical
Focus on storage
Processed several times
Data