How we used Kafka to scale our Database Infrastructure...Today’s agenda Introduction to Espresso...

Post on 21-May-2020

10 views 0 download

Transcript of How we used Kafka to scale our Database Infrastructure...Today’s agenda Introduction to Espresso...

How we used Kafka to scale our Database Infrastructure

Basavaiah Thambara(Basu) Staff Site Reliability Engineer

( https://www.linkedin.com/in/basavaiaht )

Today’s agenda

Introduction to Espresso

Espresso - Replication

Espresso with MySQL Replication

Espresso with Kafka Replication

Advantages of Using Kafka

How Kafka Based Replication Works

Conclusion & References

Espresso

Document store MySQL RDBMS & k-v Stores

Consistent & Partition tolerance

Espresso : Features

Multi-colo writes

Bulk import export

Secondary Indexing

Schema Evolution

Change data capture

Linkedin Profiles

Linkedin Invitations

Linkedin InMails, etc.

Espresso : Use CasesLINKEDIN

Espresso : Current Scale

O(100)Clusters

O(10K)Servers

O(100)Databases

O(PB)Data

O(M)Peak QPS

Espresso : Basic Architecture

● Client/Application

● Router

● Helix

● Zookeeper

● Storage node

Espresso : Replication Requirements

Read Scaling BackupsHigh Availability

Disaster Recovery

Multi-colo writes

Espresso : Local Replication

● MySQL Replication

● 3 Copies

● Per Node Replication

● Node Failure

P1 P2 P3

Node 1

P1 P2 P3

Node 2

Node 3

P1 P2 P3

P4 P5 P6

Node 4

P4 P5 P6

Node 5

Node 6

P4 P5 P6

Q1 Q2 Q3

Node N -2

Q1 Q2 Q3

Node N -1

Node N

Q1 Q2 Q3

Master Slave Replication

Legacy Architecture

Espresso : Cross Colo Replication (Legacy)

● Databus

● Data Replicator

● Colo failure

Remote Data Center

Client

Router

API Server

Storage Node

API Server

Storage Node

API Server

Storage Node

DataBusData Replicator

Online Data Center

Client

Router

API Server

Storage Node

API Server

Storage Node

API Server

Storage Node

Data ReplicatorDataBus

Limitations : Per Instance Replication

Poor Resource Utilization

Cross Colo Replication (Legacy)

Limitations : Per Instance Replication

● Databus

■ tightly coupled to storage node

■ operational complexity

■ Uses SSD,higher cost to serve

● Cluster expansion is painful

■ Lot of manual steps

■ Needs databus expansion

■ Requires downtime

Remote Data Center

Client

Router

API Server

Storage Node

API Server

Storage Node

API Server

Storage Node

DataBusData Replicator

Online Data Center

Client

Router

API Server

Storage Node

API Server

Storage Node

API Server

Storage Node

Data ReplicatorDataBus

Limitations: Per Instance Replication

● Upon master failure, single

node gets traffic

● Human intervention to

bring up slaves

● Slave-less situation might

lead to outage

Master Failure Slaves Failure

P1 P3

P1 P3

P1

P2

Node 1

P2

Node 2

Node 3

P2 P3

Master Slave

P1 P3

P1 P3

P1

P2

Node 1

P2

Node 2

Node 3

P2 P3

P1 P3

P1 P3

P1

P2

Node 1

P2

Node 2

Node 3

P2 P3

P1 P3

P1 P3

P1

P2

Node 1

P2

Node 2

Node 3

P2 P3

Offline

Espresso : Replication Using Kafka

● Per partition replication

● Flexible partition placement

● Every node serves traffic

● Data replicator uses kafka

New architecture

Advantages: Per Partition Replication

Better resource utilization.

1

Advantages: Per Partition Replication

Better resource utilization.

Resource Utilization (Legacy)

Resource Utilization ( )

1

Advantages: Per Partition Replication

Better resource utilization.

1

Easy cluster expansion.

2

Cluster Expansion

Initial cluster state with 12 partitions,

3 storage nodes, replication factor=3

Cluster Expansion

Adding a node: Helix will send

offline to Slave for new node

Cluster Expansion

Once partitions on new node

are ready, transfer ownership

and drop old

Cluster Expansion

Cluster state after expansion

with 12 partitions, 4 storage

nodes, r=3

Advantages : Per Partition Replication

Node failure

■ parallel mastership handoff

■ parallel restore of slaves

Advantages: Per Partition Replication

Better resource utilization.

1

Easy cluster expansion.

2

No human intervention.

3

Advantages: Per Partition Replication

Single platform.

6

Cost savings.

5

Databus complexity eliminated.

4

Internal replication

Cross colo replication

Change capture for nearline

Requirements

1

Implementing Kafka based replication

● Broker and producer config

● Implement

2Solution

Requirements

1

Implementing Kafka based replication

Guaranteed Delivery

Exactly Once(sort of)

In-Order

Implementing Kafka based replication

● Broker and producer config

● Implement

2Solution

Broker config

● Kafka broker config■ replication factor =3■ min.isr = 2■ Disabled unclean

leader elections

Implementing Kafka based replication

● Broker and producer config

● Implement

2Solution

Producer Config● acks = “all”● Infinite retries● block.on.buffer.full = true

● max.in.flight.requests.per.connection = 1● linger.ms = 0● on non-retryable exception

■ destroy producer■ create new producer■ resume from last checkpoint

Global Transaction Identifier

● Global transaction identifier(GTID)● Unique

Replication flow

Message protocol

MySQLMySQL

Message protocol - Mastership Handoff

MySQLMySQL

Message protocol - Mastership Handoff

MySQLMySQL

Message protocol - Mastership Handoff

MySQLMySQL

Checkpointing - Producer

MySQLMySQL

Checkpointing - Producer ...

MySQLMySQL

Checkpointing - Consumer

MySQL MySQL

3:101@2

Producer Failure

MySQLMySQL

3:101@2

Producer Failure...

MySQLMySQL

Producer Failure...

MySQLMySQL

Producer Failure...

MySQL MySQL

3:103@6

Producer Failure...

MySQL

3:103@6

MySQL

Producer Failure...

MySQL MySQL

3:103@6

Producer Failure...

MySQL

3:103@6

MySQL

Zombie Writes

MySQLMySQL

Zombie Writes...

MySQLMySQL

Zombie Writes...

MySQLMySQL

Zombie Writes...

MySQL MySQL

Zombie Writes...

MySQL MySQL

Conclusion

● LinkedIn leveraged Kafka to scale Espresso● Kafka helped to Unify data pipelines● Reduced operational complexity● Saved $$$

Q&A?