.NET Fest 2019. Андрей Винда. Создание REST API с поддержкой высокой нагрузки

Тема доклада
KYIV 2019
Andrey Vinda
How to build & support high load REST API
.NET CONFERENCE #1 IN UKRAINE

.NET LEVEL UP .NET CONFERENCE #1 IN UKRAINE KYIV 2019
Betting revenue

Load statistics
Active users: 30 000
Passive users: 5000
Logins: 5000 (min)

Highload

15+ years of
experience
Many
different
products
Like new
technologies
Launched
several APIs
About myself

Business

Business
Business

Users

Opps, something went wrong

Business needs APIs

Login API
Authenticate Fast response High throughput
Resistance to
DDoS and Brute
Force attacks
High Availability
(99.99 %)

Standard building blocks
DATABASE CACHE SEARCH INDEXES QUEUE

Application with stateless services

Data shipping paradigm

Stateless architecture: Pros
Services are easy to scale
No state in services
When service server is dead – a new one
could be up without any crucial affect

Stateless architecture: Cons
Add latency
Non efficient access to data
Limits scalability
• Master / slave replication
• Sharding
Concurrency

Stateless architecture with Cache: Pros
Add latency
Non efficient access to data
Limits scalability
•Master / slave replication
•Sharding
Concurrency
Cache invalidation

What we want
DATA LOCALITY EASY SCALING DEFENSE

Defence
Fast analyze of
input requests
In-Memory
statistics of
success/failed
requests
Calculation on the
fly
Fast and
serializable access
to the cache

Data locality
Moving compute to data is
typically faster than moving
data to compute
For low latency flow Data intensive service

.NET alternatives

Actors as the universal primitives of concurrent
computation.
Actor can:
• Receive messages
• Make local decisions
• Create more actors
• Send more messages
• Determine how to respond to the next message
received
Actor model

• .NET Framework used to create Scalable,
Distributed, .NET Applications
• Focused on low response latency and high
concurrency
• Usable in any .NET application (but frequently used
with WebAPI Applications)
• Based on a system of VirtualActors
Orleans

Virtual actors
Actor instances always exist, virtually
• Application neither creates nor deletes them. They never fail.
• Code can always call methods on an actor
Activations are created on-demand
• If there is no existing activation, a message sent to it triggers instantiation
• Transparent recovery from server failures
• Lifecycle is managed by the runtime
• Runtime can create multiple activations of stateless actors (for performance)
Location transparency
• Actors can pass around references to one another or persist them
• These are logical (virtual) references, always valid, not tied to a specific activation

• Grains are C# classes
• Derived from GrainBase
• Implement an Interface (e.g. IPlayer, ISession)
• Messages passing = Calling Interface methods
• Ex: AddLoginSession (int playerId, Guid sessionId)
• Can be Stateless or Stateful
Orleans: Grain = Virtual actor

Orleans: Grains
Grains: Individually
isolated objects that
are messaging

Orleans: Concurrency model for Grains
Orleans uses a
cooperative
multithreading
scheduler
Scheduler schedules
only one message at a
time for a grain
A message is processed
completely before
another message is
scheduled
A message is processed
as a sequence of one or
more turns
(continuations)

Transparent
scalability by
default
New Silos can
be added at any
time
Location
transparency
Multiplexed
communication
Efficient
scheduling
Orleans cluster
Grains
Silo

Orleans cluster

Smart cache
Most popular pattern
Use cases
Read-only, write-though or write behind cache
State usually is backed by persistence storage
Orleans solution
Actor per data item
Time-based and/or explicit validation

An actor which keeps track
of a set of other actors
• Does not intervene in iteration with the
individual actors
• Its own state is just a list of references
to other actors
Registry

Orleans grains
Session Grain
Player Grain
Online Grain
Operator Grain IP Grain
Login Grain
Cache layer Statistics layerOnline layer
Grain Cache Service
Operator Cache Grain
Player Cache
Grain

Cache pre-population on startup
Update cache on a regular basis (Kafka loader)
In-memory statistics of all login attempts
• Regulation specific data is being stored in DB
All logged in players are in memory
Time regulation features are based on Timer
Orleans usage

Demo

Technologies

Protection & Security
HOW TO IDENTIFY
POSSIBLE FRAUD?
HOW TO PROTECT? WHAT TO ANALYZE? WHERE TO STORE DATA
FOR ANALYZING?

Protection
INCAPSULA CAPTCHA BLOCKS

Cookie challenge: If the client supports cookies, we respond to an
HTTP request with a cookie. Web browsers typically will store and
resend this cookie. Most bots do not support cookies and therefore will
not respond.
JS cookie challenge: After receiving an HTTP request, we respond
with a JS cookie, instructing the browser to perform an action. Web
browsers typically will execute the JavaScript instructions, on the other
hand most bots do not support a JS engine and therefore will not
respond
Incapsula

Captcha
Send a CAPTCHA challenge,
expecting a human
response to the challenge
LoginAPI generates captcha
value for current session
and stores it inside Orleans
Use a non-white
background with
interspersed or roughened

Fraud detection
Analyze
IP addresses
User-Agent
Amount of failed login attempts per minute
Amount of success login attempts per
minute

Block players from the login base on the analysis of failed and success attempts per period
Blocks

Communication schema
Client
Login API
JWT Secret
Credentials
Anonymous JWT
Credentials
Anonymous JWT
OKAuth JWT

Blue/Green deployment

Blue/Green deployment
Login API-A
Login API-B
Client
Credentials
* Cluster (default=A)
* Cluster A
Cluster B

Observability
Observability
Logs Metrics Traces

Orleans dashboard

Metrics

Fails
• Kafka consumer in the main thread
• Wrong configuration: connect App to Orleans
• Load testing (NBomber, JMeter, Gatling)
• Improper Captcha counters calculation

Questions
FB: https://www.facebook.com/andrey.vinda
Email: vindaav@gmail.com
Skype: vinda.andrew

.NET Fest 2019. Андрей Винда. Создание REST API с поддержкой высокой нагрузки

.NET Fest 2019. Андрей Винда. Создание REST API с поддержкой высокой нагрузки

Recommended

More Related Content

What's hot

What's hot(20)

Similar to .NET Fest 2019. Андрей Винда. Создание REST API с поддержкой высокой нагрузки

Similar to .NET Fest 2019. Андрей Винда. Создание REST API с поддержкой высокой нагрузки(20)

More from NETFest

More from NETFest(20)

Recently uploaded

Recently uploaded(20)

.NET Fest 2019. Андрей Винда. Создание REST API с поддержкой высокой нагрузки