Resilient Routing and Discovery

Simon Eskildsen, Shopify @Sirupsen

Shopify

Docker in Production serving the below for 1+ year



165,000+

ACTIVE SHOPIFY MERCHANTS

200+

DEVELOPERS

DATACENTERS

3000+

CONTAINERS RUNNING AT ANY TIME

12+

DEPLOYS PER DAY



10,000+

MAX CHECKOUTS PER MINUTE

$8 BILLION+

CUMULATIVE GMV

500+

SERVERS

Ruby on Rails

10+ years old

300M unique visits/month

LEAGUE OF APPLE, EBAY AND AMAZON

Building reliable bridges in large distributed systems

Cross DC Networking



Complexity



Cross Regional Networking Same Rack Networking



Inter process



Reliability



In process

Resiliency



Discovery



Routing

Reliability is your success metric for discovery and routing.

Shopify started this journey in the fall of 2014

Resiliency

Building a reliable system from unreliable components

(Micro)service equation



Uptime = AN



Number of services

Availability per service Total availability

Availability



100 90 80 70



10 50 100 500 1000

Services



99.98



99.99



99.999



99.95

MySQL Shard MySQL Master

Kafka External HTTP API redis-sessions



Resiliency Matrix



Checkout Unavailable Available Available Degraded Unavailable



Admin Unavailable Unavailable Degraded Available Unavailable



Storefront Degraded Available Available Unavailable Degraded

Objectives for large distributed systems

Building reliable systems from unreliable components

Explore resiliency, service discovery, routing, orchestration and the relationship between them

Recognizing and avoiding premature optimizations and overcompensation

Application should be designed to handle fallbacks

search



carts



sessions



cdn mysql

Avoid HTTP 500 for single service failing

.. or suffer the faith of the (micro)service equation

Sessions data store unavailable Customer signed out

Simulate TCP conditions with Toxiproxy

curl -i -d '{"enabled":true, "latency":1000}' \ localhost:8474/proxies/redis/downstream/toxics/latency

curl -i -X DELETE localhost:8474/proxies/redis



Toxiproxy[:mysql_master].downstream(:latency, latency: 1000).apply do Shop.first # this takes at least 1s

end



Toxiproxy[/redis/].down do session[:user_id] # this will throw an exception

end



https://github.com/shopify/toxiproxy

With fallbacks the system is still vulnerable to slowness.

ECONNREFUSED is a luxury, slowness is the killer.

Little’s law

Infrastructure operating normally



400 RPS 0.01s



0.01s 0.01s 0.01s 0.01s



0.002s

0.001s

0.01s

Database latency increases by 10x, throughput drops 10x



0.020s 0.10s



40 RPS 0.10s



0.10s 0.10s 0.10s



0.001s

0.01s

Beating Little’s law is your first priority as you add services

Resiliency Toolkits

Bulk Heads, Circuit Breakers, ..



Release It book



twitter/finagle



shopify/semian



netflix/hystr25 ix

26

Resiliency Maturity Pyramid



Region Gorilla



Latency Monkey



Kill Nodes (Chaos Monkey)



Production Practise Days (Games)



Resiliency Patterns



Application-Specific Fallbacks Toxiproxy tests and matrix



Testing with mocks



No resiliency effort

Discovery

Infrastructure source of truth



Services

Instances of services



Metadata

Deployed revision, leader, ..



Orchestration

Aid to make things happen across components

Location



Global

Geo-replicated discovery



Regional

Single datacenter

Discovery Backbone Properties

No single point of failure



Stale reads better than no reads: A > C Reads order of magnitude larger than writes



Fast convergence

New and Old School



Consul



DNS



Zookeeper Chef, Puppet, ..



Eureka Etcd



Network Hardcoded values

Pure DNS for as long as you can. Still works for us. Don’t overcompensate.

Pure DNS



Resilient



Failovers?



Simple



Slow convergence



API Supported



Not a data store Not for orchestration

Global discovery and orchestration most pressing issue for Shopify

Orchestration of datacenter failovers

Too many Sources of Truth



Component Network MySQL

Application Redis

Load Balancers



Source of Truth NetEng? DBAs?

Cookbooks Cookbooks Hardcode value in config file

Routing shops to the right datacenter



DNS: shop.walrustoys.com

CNAME walrustoys.myshopify.com

IPs for DC 2



Map shop to DC

DNS problematic when..

Multiple owners of data



Fast converge



Lots of change in instances

Zookeeper



Scalable stale reads Not complete discovery



Consistent



Complex clients



Orchestration Trusted



Operational burden Shoehorn

Complex client problem

Connecting directly risky Proxy pattern



Dumping to files



Stale reads

Routing

Routing responsibilities

Load balance

Protect applications against unhealthy resources: circuit breaker, bulk heads, rate limiting, …



Receive upstreams from discovery layer

Trusted



Scriptable



Resiliency



Dynamic upstreams



Discovery built in



TCP Library/Proxy



yours OS nginx haproxy vulcand

finagle smartstack



Don’t do this



Of course



It’s perfect



I got it



Easy Obviously, it’s Go



YES YES Maybe? YES



3rd party (ngx-lua). Not complete (no TCP

support).



Possible for HTTP via ngx-lua. No TCP yet



Sidekick for new upstreams.

Manipulate existing via ngx-lua



No, try via sidekick/ ngx-lua



Sidekick and reloads



Lua support in master



Not scriptable, only rate limiting built-in



(with iptables wizardry), manipulate



No, try via sidekick



existing admin socket



Landed in 1.9.0, stabilized in nginx+

Built as L4



middlewares, requires forking



SOME, only circuit breaker



Beautiful HTTP API



etcd support



No, only supports HTTP currently (not in

ROADMAP.md)



Proxy Proxy Proxy



YES, completely centered around

plugins



YES, sophisticated FailFast module



YES



Zookeeper support



Application-level



Library, requires JVM



Somewhat



However much HAProxy is, adapters



NO, same as HAProxy



YES



Zookeeper support Yes, uses HAProxy Proxy + discovery

With a polyglot stack, we just use simple proxies and DNS

Current Stack

Discovery



DNS Server



Chef



Zookeeper



Discoverable



Through proxy



ZK Proxy

Future Stack

Discovery



Server



DNS



Zookeeper



Discoverable



Through proxy



ZK Proxy

Docker’s future role in discovery, routing and resiliency

Final remarks

Figure out service discovery value for your company, don’t overcompensate—your metric is reliability

Infrastructure teams own integration points, don’t leave it up to everyone to jump in

Build resiliency into the system, don’t make it opt in, be able to reason about entire system’s state and test

Thank you

Simon Eskildsen, Shopify @Sirupsen

Server by Konstantin Velichko from the Noun Project basket by Ben Rex Furneaux from the Noun Project container by Creative Stall from the Noun Project

people by Wilson Joseph from the Noun Project mesh network by Lance Weisser from the Noun Project

Conductor by By Luis Prado from the Noun Project Jar by Yazmin Alanix from the Noun Project

Broken Chain by Simon Martin from the Noun Project Book by Ben Rex Furneaux from the Noun Project

network by Jessica Coccimiglio from the Noun Project server by Creative Stall from the Noun Project

components by icons.design from the Noun Project switch button by Marco Olgio from the Noun Project

Pile of leaves (autumn) by Aarthi Ramamurthy Bridge by Toreham Sharman from the Noun Project collaboration by Alex Kwa from the Noun Project converge by Creative Stall from the Noun Project

change by Jorge Mateo from the Noun Project tag by Rohith M S from the Noun Project



whale by Christopher T. Howlett from the Noun Project file by Marlou Latourre from the Noun Project

Signpost by Dmitry Mirolyubov from the Noun Project Arrow by Zlatko Najdenovski from the Noun Project

Chef by Ross Sokolovski from the Noun Project