Scaling LinkedIn - A Brief History

The Presentation inside:

Slide 0


Slide 1

“ Scaling = replacing all the components of a car while driving it at 100mph Via Mike Krieger, “Scaling Instagram”

Slide 2

LinkedIn started back in 2003 to “connect to your network for better job opportunities.” It had 2700 members in first week.

Slide 3

First week growth guesses from founding team

Slide 4

400M 400M 350M 300M 250M 200M Fast forward to today... 150M 100M 50M 32M 0M 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 5

Slide 5

LINKEDIN SCALE TODAY LinkedIn is a global site with over 400 million members Web pages and mobile traffic are served at tens of thousands of queries per second Backend systems serve millions of queries per second

Slide 6

How did we get there? 7

Slide 7

Let’s start from the beginning

Slide 8


Slide 9

LINKEDIN’S ORIGINAL ARCHITECTURE LEO LEO ● Huge monolithic app called Leo ● Java, JSP, Servlets, JDBC DB ● Served every page, same SQL database Circa 2003

Slide 10

So far so good, but two areas to improve: 1. The growing member to member connection graph 2. The ability to search those members

Slide 11

MEMBER CONNECTION GRAPH ● Needed to live in-memory for top performance ● Used graph traversal queries not suitable for the shared SQL database. ● Different usage profile than other parts of site

Slide 12

MEMBER CONNECTION GRAPH ● Needed to live in-memory for top performance ● Used graph traversal queries not suitable for the shared SQL database. ● Different usage profile than other parts of site So, a dedicated service was created. LinkedIn’s first service.

Slide 13

MEMBER SEARCH ● Social networks need powerful search ● Lucene was used on top of our member graph

Slide 14

MEMBER SEARCH ● Social networks need powerful search ● Lucene was used on top of our member graph LinkedIn’s second service.

Slide 15

LINKEDIN WITH CONNECTION GRAPH AND SEARCH LEO RPC Member Graph Lucene DB Connection / Profile Updates Circa 2004

Slide 16

Getting better, but the single database was under heavy load. Vertically scaling helped, but we needed to offload the read traffic...

Slide 17

REPLICA DBs ● Master/slave concept ● Read-only traffic from replica ● Writes go to main DB ● Early version of Databus kept DBs in sync Main DB Databus relay Replica Replica Replica DB

Slide 18

REPLICA DBs TAKEAWAYS ● Good medium term solution ● We could vertically scale servers for a while ● Master DBs have finite scaling limits ● These days, LinkedIn DBs use partitioning Main DB Databus relay Replica Replica Replica DB

Slide 19

LINKEDIN WITH REPLICA DBs RPC LEO R/O R/W Main DB Member Graph Connection Updates Databus relay Search Profile Updates Replica Replica Replica DB Circa 2006

Slide 20

As LinkedIn continued to grow, the monolithic application Leo was becoming problematic. Leo was difficult to release, debug, and the site kept going down...

Slide 21

Slide 22

Slide 23

Slide 24


Slide 25

SERVICE ORIENTED ARCHITECTURE Extracting services (Java Spring MVC) from legacy Leo monolithic application Recruiter Web App Public Profile Web App LEO Profile Service Yet another Service Circa 2008 on

Slide 26

SERVICE ORIENTED ARCHITECTURE Profile Web App Profile Service ● Goal - create vertical stack of stateless services ● Frontend servers fetch data from many domains, build HTML or JSON response ● Mid-tier services host APIs, business logic Profile DB ● Data-tier or back-tier services encapsulate data domains

Slide 27

Slide 28

EXAMPLE MULTI-TIER ARCHITECTURE AT LINKEDIN Browser / App Frontend Web App Profile Mid-tier Content Service Service Connections Mid-tier Content Service Service Groups Mid-tier Content Service Service Edu Data Data Service Kafka Service DB Voldemort Hadoop

Slide 29

SERVICE ORIENTED ARCHITECTURE COMPARISON PROS ● Stateless services easily scale CONS ● Ops overhead ● Decoupled domains ● Introduces backwards compatibility issues ● Build and deploy independently ● Leads to complex call graphs and fanout

Slide 30

SERVICES AT LINKEDIN ● In 2003, LinkedIn had one service (Leo) ● By 2010, LinkedIn had over 150 services ● Today in 2015, LinkedIn has over 750 services bash$ eh -e %%prod | awk -F. '{ print $2 }' | sort | uniq | wc -l 756

Slide 31

Getting better, but LinkedIn was experiencing hypergrowth...

Slide 32

Slide 33

CACHING Frontend Web App Mid-tier Service Cache Cache DB ● Simple way to reduce load on servers and speed up responses ● Mid-tier caches store derived objects from different domains, reduce fanout ● Caches in the data layer ● We use memcache, couchbase, even Voldemort

Slide 34

“ hard problems in There are only two Computer Science: Cache invalidation, naming things, and off-by-one errors. Via Twitter by Kellan Elliott-McCrea and later Jonathan Feinberg

Slide 35

CACHING TAKEAWAYS ● Caches are easy to add in the beginning, but complexity adds up over time. ● Over time LinkedIn removed many mid-tier caches because of the complexity around invalidation ● We kept caches closer to data layer

Slide 36

CACHING TAKEAWAYS (cont.) ● Services must handle full load - caches improve speed, not permanent load bearing solutions ● We’ll use a low latency solution like Voldemort when appropriate and precompute results

Slide 37

LinkedIn’s hypergrowth was extending to the vast amounts of data it collected. Individual pipelines to route that data weren’t scaling. A better solution was needed...

Slide 38

Slide 39

KAFKA MOTIVATIONS ● LinkedIn generates a ton of data ○ Pageviews ○ Edits on profile, companies, schools ○ Logging, timing ○ Invites, messaging ○ Tracking ● Billions of events everyday ● Separate and independently created pipelines routed this data

Slide 40


Slide 41

A WHOLE LOT OF CUSTOM PIPELINES... As LinkedIn needed to scale, each pipeline needed to scale.

Slide 42

KAFKA Distributed pub-sub messaging platform as LinkedIn’s universal data pipeline Frontend service Frontend service Backend Service Kafka DWH Oracle Monitoring Analytics Hadoop

Slide 43

KAFKA AT LINKEDIN BENEFITS ● Enabled near realtime access to any data source ● Empowered Hadoop jobs ● Allowed LinkedIn to build realtime analytics ● Vastly improved site monitoring capability ● Enabled devs to visualize and track call graphs ● Over 1 trillion messages published per day, 10 million messages per second

Slide 44


Slide 45

Let’s end with the modern years

Slide 46

Slide 47

REST.LI ● Services extracted from Leo or created new were inconsistent and often tightly coupled ● was our move to a data model centric architecture ● It ensured a consistent stateless Restful API model across the company.

Slide 48

REST.LI (cont.) ● By using JSON over HTTP, our new APIs supported non-Java-based clients. ● By using Dynamic Discovery (D2), we got load balancing, discovery, and scalability of each service API. ● Today, LinkedIn has 1130+ resources and over 100 billion calls per day

Slide 49

REST.LI (cont.) Automatic API-documentation

Slide 50

REST.LI (cont.) R2/D2 tech stack

Slide 51

LinkedIn’s success with Data infrastructure like Kafka and Databus led to the development of more and more scalable Data infrastructure solutions...

Slide 52

DATA INFRASTRUCTURE ● It was clear LinkedIn could build data infrastructure that enables long term growth ● LinkedIn doubled down on infra solutions like: ○ Storage solutions ■ Espresso, Voldemort, Ambry (media) ○ Analytics solutions like Pinot ○ Streaming solutions ■ Kafka, Databus, and Samza ○ Cloud solutions like Helix and Nuage

Slide 53


Slide 54

LinkedIn is a global company and was continuing to see large growth. How else to scale?

Slide 55

MULTIPLE DATA CENTERS ● Natural progression of horizontally scaling ● Replicate data across many data centers using storage technology like Espresso ● Pin users to geographically close data center ● Difficult but necessary

Slide 56

MULTIPLE DATA CENTERS ● Multiple data centers are imperative to maintain high availability. ● You need to avoid any single point of failure not just for each service, but the entire site. ● LinkedIn runs out of three main data centers, additional PoPs around the globe, and more coming online every day...

Slide 57

MULTIPLE DATA CENTERS LinkedIn's operational setup as of 2015 (circles represent data centers, diamonds represent PoPs)

Slide 58

Of course LinkedIn’s scaling story is never this simple, so what else have we done?

Slide 59

WHAT ELSE HAVE WE DONE? ● Each of LinkedIn’s critical systems have undergone their own rich history of scale (graph, search, analytics, profile backend, comms, feed) ● LinkedIn uses Hadoop / Voldemort for insights like People You May Know, Similar profiles, Notable Alumni, and profile browse maps.

Slide 60

WHAT ELSE HAVE WE DONE? (cont.) ● Re-architected frontend approach using ○ Client templates ○ BigPipe ○ Play Framework ● LinkedIn added multiple tiers of proxies using Apache Traffic Server and HAProxy ● We improved the performance of servers with new hardware, advanced system tuning, and newer Java runtimes.

Slide 61

Scaling sounds easy and quick to do, right?

Slide 62

“ Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. Via  Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid

Slide 63

THANKS! Josh Clemm

Slide 64

LEARN MORE ● Blog version of this slide deck ● Visual story of LinkedIn’s history ● LinkedIn Engineering blog ● LinkedIn Open-Source ● LinkedIn’s communication system slides which include earliest LinkedIn architecture http://www.slideshare. net/linkedin/linkedins-communication-architecture ● Slides which include earliest LinkedIn data infra work

Slide 65

LEARN MORE (cont.) ● Project Inversion - internal project to enable developer productivity (trunk based model), faster deploys, unified services ● LinkedIn’s use of Apache Traffic server ● Multi Data Center - testing fail overs

Slide 66

LEARN MORE - KAFKA ● History and motivation around Kafka ● Thinking about streaming solutions as a commit log ● Kafka enabling monitoring and alerting ● Kafka enabling real-time analytics (Pinot) ● Kafka’s current use and future at LinkedIn ● Kafka processing 1 trillion events per day

Slide 67

LEARN MORE - DATA INFRASTRUCTURE ● Open sourcing Databus ● Samza streams to help LinkedIn view call graphs ● Real-time analytics (Pinot) ● Introducing Espresso data store

Slide 68

LEARN MORE - FRONTEND TECH ● LinkedIn’s use of client templates ○ Dust.js ○ Profile ● Big Pipe on LinkedIn’s homepage ● Play Framework ○ Introduction at LinkedIn https://engineering.linkedin. com/play/composable-and-streamable-play-apps ○ Switching to non-block asynchronous model

Slide 69

LEARN MORE - REST.LI ● Introduction to and how it helps LinkedIn scale ● How expanded across the company

Slide 70

LEARN MORE - SYSTEM TUNING ● JVM memory tuning ● System tuning ● Optimizing JVM tuning automatically

Slide 71

WE’RE HIRING LinkedIn continues to grow quickly and there’s still a ton of work we can do to improve. We’re working on problems that very few ever get to solve - come join us!

Slide 72

Slide 73