Designing for Scale

58
Designing for Scale Knut Nesheim @knutin Paolo Negri @hungryblank
  • date post

    20-Oct-2014
  • Category

    Technology

  • view

    4.106
  • download

    0

description

At wooga we build backends for games that have millions of daily users. In the gaming business we have a write heavy environment, with a high frequency of requests, traffic bursts and distribution across many nodes. These are all problems we need to solve and keep in mind in order to write a system that stands the chance of supporting the required load. How do you meet the challenge of writing a brand new system with performance in mind? Where should the line between necessary efficiency and premature optimization be drawn? How do you measure performances? How do we generate synthetic load that reflects real usage patterns? How do you know you have enough capacity? How do you combine all the above with safely introducing changes and new features working in a two people team? We had to answer to all the above questions and we want to share the solutions we found and the problems that we consider still open.

Transcript of Designing for Scale

Page 1: Designing for Scale

Designing for ScaleKnut Nesheim @knutin

Paolo Negri @hungryblank

Page 2: Designing for Scale

About this talk

2 developers and erlangvs.

1 million daily users

Page 3: Designing for Scale

Social GamesFlash client (game) HTTP API

Page 4: Designing for Scale

Social GamesFlash client

• Game actions need to be persisted and validated

• 1 API call every 2 secs

Page 5: Designing for Scale

Social GamesHTTP API

• @ 1 000 000 daily users

• 5000 HTTP reqs/sec

• more than 90% writes

Page 6: Designing for Scale

The hard nut

http://www.flickr.com/photos/mukluk/315409445/

Page 7: Designing for Scale

Users we expect

0

250000

500000

750000

1000000

July December

DAU

“Monster World”daily users

july - december 2010

Page 8: Designing for Scale

Users we have

0

50

march april may june

DAU

New gamedaily users

march - june 2011

Page 9: Designing for Scale

What to do?

1 Simulate users

Page 10: Designing for Scale

Simulating users

• Must not be too synthetic (like apachebench)

• Must look like a meaningful game session

• Users must come online at a given rate and play

Page 11: Designing for Scale

• Multi protocol (HTTP, XMPP) benchmarking tool

• Able to test non trivial call sequences

• Can actually simulate a scripted gaming session

http://tsung.erlang-projects.org/

Tsung

Page 12: Designing for Scale

http://tsung.erlang-projects.org/

Tsung - configuration

<request subst="true"><http url="http://server.wooga.com/users/%%ts_user_server:get_unique_id%%/resources/column/5/row/14?%%_routing_key%%"method="POST" contents='{"parameter1":"value1"}'></http></request>

Fixed content Dynamic parameter

Page 13: Designing for Scale

http://tsung.erlang-projects.org/

Tsung - configuration

• Not something you fancy writing

• We’re in development, calls change and we constantly add new calls

• A session might contain hundreds of requests

• All the calls must refer to a consistent game state

Page 14: Designing for Scale

http://tsung.erlang-projects.org/

Tsung - configuration

• From our ruby test code

user.resources(:column => 5, :row => 14)

• Same as<request subst="true"><http url="http://server.wooga.com/users/%%ts_user_server:get_unique_id%%/resources/column/5/row/14?%%_routing_key%%"method="POST" contents='{"parameter1":"value1"}'></http></request>

Page 15: Designing for Scale

http://tsung.erlang-projects.org/

Tsung - configuration

• Session

• requests

• Arrival phase

• duration

• arrival rate

A session is a group of requests

Sessions arrive in phases with a specific arrival

rate

Page 16: Designing for Scale

http://tsung.erlang-projects.org/

Tsung - setup

app server

app server

app server

tsung master

tsung workerHTTP reqs

Application

ssh

Benchmarkingcluster

Page 17: Designing for Scale

http://tsung.erlang-projects.org/

Tsung

• Generates ~ 2500 reqs/sec on AWS m1.large

• Flexible but hard to extend

• Code base rather obscure

Page 18: Designing for Scale

What to do?

2 Collect metrics

Page 19: Designing for Scale

http://tsung.erlang-projects.org/

Tsung-metrics

• Tsung collects measures and provides reports

• But these measure include tsung network/cpu congestion itself

• Tsung machines aren’t a good point of view

Page 20: Designing for Scale

HAproxy

app server

app server

app server

tsung master

tsung workerHTTP reqs

Application

ssh

Benchmarkingcluster

haproxy

Page 21: Designing for Scale

HAproxy

“The Reliable, High Performance TCP/HTTP Load Balancer”

• Placed in front of http servers

• Load balancing

• Fail over

Page 22: Designing for Scale

HAproxy - syslog

• Easy to setup

• Efficient (UDP)

• Provides 5 timings per each request

Page 23: Designing for Scale

HAproxy

app server

app servertsung

master

tsung worker

Application

ssh

Benchmarkingcluster

haproxy

• Time to receive request from client

Page 24: Designing for Scale

HAproxy

app server

app servertsung

master

tsung worker

Application

ssh

Benchmarkingcluster

haproxy

• Time spent in HAproxy queue

Page 25: Designing for Scale

HAproxy

app server

app servertsung

master

tsung worker

Application

ssh

Benchmarkingcluster

haproxy

• Time to connect to the server

Page 26: Designing for Scale

HAproxy

app server

app servertsung

master

tsung worker

Application

ssh

Benchmarkingcluster

haproxy

• Time to receive response headers from server

Page 27: Designing for Scale

HAproxy

app server

app servertsung

master

tsung worker

Application

ssh

Benchmarkingcluster

haproxy

• Total session duration time

Page 28: Designing for Scale

HAproxy - syslog

• Application urls identify directly server call

• Application urls are easy to parse

• Processing haproxy syslog gives per call metric

Page 29: Designing for Scale

What to do?

3 Understand metrics

Page 30: Designing for Scale

Reading/aggregatingmetrics

• Python to parse/normalize syslog

• R language to analyze/visualize data

• R language console to interactively explore benchmarking results

Page 31: Designing for Scale

R is a free software environment for statistical computing and graphics.

Page 32: Designing for Scale

What you get

• Aggregate performance levels (throughput, latency)

• Detailed performance per call type

• Statistical analysis (outliers, trends, regression, correlation, frequency, standard deviation)

Page 33: Designing for Scale

What you get

Page 34: Designing for Scale

4 go deeper

What to do?

Page 35: Designing for Scale

Digging into the data

• From HAproxy log analisys one call emerged as exceptionally slow

• Using eprof we were able to determine that most of the time was spent in a redis query fetching many keys (MGET)

Page 36: Designing for Scale

Tracing erldis query• More than 60% of runtime is spent

manipulating the socket

• gen_tcp:recv/2 is the culprit

• But why is it called so many times?

Page 37: Designing for Scale

Understanding the redis protocol

C: LRANGE mylist 0 2

s: *2

s: $5

s: Hello

s: $5

s: World

<<"*2\r\n $5\r\n Hello\r\n $5\r\n World\r\n">>

Page 38: Designing for Scale

Understanding erldis• recv_value/2 is used in the protocol parser

to get the next data to parse

Page 39: Designing for Scale

A different approach

• Two ways to use gen_tcp: active or passive

• In passive, use gen_tcp:recv to explicitly ask for data, blocking

• In active, gen_tcp will send the controlling process a message when there is data

• Hybrid: active once

Page 40: Designing for Scale

A different approach

• Is active sockets faster?

• Proof-of-concept proved active socket faster

• Change erldis or write a new driver?

Page 41: Designing for Scale

A different approach

• Radical change => new driver

• Keep Erldis queuing approach

• Think about error handling from the start

• Use active sockets

Page 42: Designing for Scale

A different approach

• Active socket, parse partial replies

Page 43: Designing for Scale

Circuit breaker

• eredis has a simple circuit breaker for when Redis is down/unreachable

• eredis returns immediately to clients if connection is down

• Reconnecting is done outside request/response handling

• Robust handling of errors

Page 44: Designing for Scale

Benchmarking eredis

• Redis driver critical for our application

• Must perform well

• Must be stable

• How do we test this?

Page 45: Designing for Scale

Basho bench

• Basho produces the Riak KV store

• Basho build a tool to test KV servers

• Basho bench

• We used Basho bench to test eredis

Page 46: Designing for Scale

Basho bench• Create callback module

Page 47: Designing for Scale

Basho bench• Configuration term-file

Page 48: Designing for Scale

Basho bench output

Page 49: Designing for Scale

eredis is open source

https://github.com/wooga/eredis

Page 50: Designing for Scale

5 measure internals

What to do?

Page 51: Designing for Scale

Measure internals

HAproxy point of view is valid but how to measure internals of our application, while we are live, without the overhead of tracing?

Page 52: Designing for Scale

Think Basho bench

• Basho bench can benchmark a redis driver

• Redis is very fast, 100K ops/sec

• Basho bench overhead is acceptable

• The code is very simple

Page 53: Designing for Scale

Cherry pick ideas from Basho Bench

• Creates a histogram of timings on the fly, reducing the number of data points

• Dumps to disk every N seconds

• Allows statistical tools to work on already aggregated data

• Near real-time, from event to stats in N+5 seconds

Page 54: Designing for Scale

Homegrown stats

• Measures latency from the edges of our system (excludes HTTP handling)

• And at interesting points inside the system

• Statistical analysis using R

• Correlate with HAproxy data

• Produces graphs and data specific to our application

Page 55: Designing for Scale

Homegrown stats

Page 56: Designing for Scale

Recap

Measure:

• From an external point of view (HAproxy)

• At the edge of the system (excluding HTTP handling)

• Internals in the single process (eprof)

Page 57: Designing for Scale

Recap

Analyze:

• Aggregated measures

• Statistical properties of measures

• standard deviation

• distribution

• trends