Blue-green deploys with Pulsar & Envoy in an event-driven microservice ecosystem - Pulsar Summit SF 2022

Pulsar Summit
San Francisco
Hotel Nikko
August 18 2022
Use Case
Blue-green deploys
with Pulsar & Envoy
in an event-driven
microservice
ecosystem
Kai Levy & Zach Walsh
Toast, Inc.

Kai and Zach both work on Toast’s
Scale team, building shared
infrastructure and solving problems of
messaging, routing and persistence at
scale.
Kai Levy
Senior Software Engineer
Toast
Zach Walsh
Senior Software Engineer
Toast

Agenda
Toast’s microservice ecosystem + Pulsar
Blue/green deployments at Toast
Driving Pulsar adoption
Our Envoy Proxy control plane
“The Pulsar Toggle”

We empower the restaurant
community to delight their guests,
do what they love, and thrive

Toast’s microservice ecosystem
How it started How it’s going

How it’s going (with Pulsar)

2018 Asynchronous messaging with RabbitMQ
● Order syncing between devices
● Change Data Capture (CDC)
A History of
Pulsar at
Toast

A History of
Pulsar at
Toast
2019 Pulsar pilot
● Initial exploration & testing
● Cluster productionalization
● First features, such as migrating change data
capture

Persistence & Stability
Seamless Pulsar
failover
● RabbitMQ: potential stability issues + in-memory data-storage = lost messages
○ Manual maintenance was a big burden
● Pulsar’s data replication & automatic topic balancing eliminated these concerns

Horizontal Scalability
broker 0
…
● Supports adding more topics without manual provisioning
● Throughput has grown more than 5x without any change in architecture
broker 1 broker 2 broker 3 broker n

A History of
Pulsar at
Toast
2019 Pulsar pilot
capture
2020 Full-fledged adoption
● Teams across Toast rapidly built features on top of
Pulsar to help restaurants survive the pandemic
● Decorated streams built on Pulsar, which enabled
more scalable consumers

CDC
notify-topic
Domain service
(Source of Truth)
service2
service1
service3
Full-fledged adoption
…
serviceN

CDC data decorator service
notify-topic decorated-stream
Domain service
(Source of Truth)
service1
…
serviceN

Order status notifications
Delivery & curbside arrival notifications for consumers
- helping restaurants pivot to digital
Tip pool tracking
Tip pooling information is kept up-to-date with orders
information
Loyalty points accrual
Consumer-facing loyalty programs help Toast
restaurants thrive
Restaurant availability
Third party platforms are notified when a restaurant
goes offline

● Change data capture (CDC)
A History of
Pulsar at
Toast
2019 Pulsar pilot
capture
2020 Full-fledged adoption
● Teams across Toast rapidly built features on top of
Pulsar to help restaurants survive the pandemic
● Decorated streams built on Pulsar, which enabled
more scalable consumers
2022 Next-gen order processing
● Critical replatforming projects in development will
help Toast reach the next level of scale
● Event-driven architecture being widely used for new
features

Pulsar adoption has grown steadily
user
adoption
(linear)

Toast client libraries
Providing Toast-specific functionality for free
1. Out-of-box authentication
2. Dead-letter topic guidance (+ topic registries)
3. Metric instrumentation
4. Message parsing
5. Pulsar client configuration
+

Authentication & authorization
● Automatic service authentication provided by the client libraries
○ Easy to use with any of our supported application frameworks
● Contributed a patch into the public Java client library

Dead-Letter Topics
● Standards for undeliverable messages
○ Per-subscription DLQs, or automatic
acknowledgement after redelivery
○ Integrated with service configuration

Topic registries with terraform
● Started with in-house provider
○ Now migrating to StreamNative provider
● Lets us manage namespace authorization
● Provide defaults for retention & persistence
● Central place for discovering events
Developers write infrastructure as code

Metrics
● Automatically report over 2 dozen
metrics
○ Consistent across services
● Critical for operations & monitoring
● Added our own custom metrics
● Adding APM integrations
ackLatency
ackTimeouts
auto-acknowledgements

Message Parsing
We parse Protobuf messages into friendly Kotlin data classes
● Our open-source, Kotlin-first
protocol buffer compiler
● One-line usage for engineers
building on our client

Configuration recommendations
Providing guidance around client settings
● Producer batching
● Acknowledgement timeout
● Receiver queue size
● Redelivery delay
● Unique consumer & producer names
Starting Pulsar consumer status recorder with config: {
"topicNames" : [ "persistent://…" ],
"topicsPattern" : null,
"subscriptionName" : "...",
"subscriptionType" : "Shared",
"subscriptionMode" : "Durable",
"receiverQueueSize" : 1000,
"acknowledgementsGroupTimeMicros" : 100000,
"negativeAckRedeliveryDelayMicros" : 500000,
"maxTotalReceiverQueueSizeAcrossPartitions" : 50000,
"consumerName" : null,
"ackTimeoutMillis" : 30000,
"tickDurationMillis" : 1000,
"priorityLevel" : 0,
"maxPendingChuckedMessage" : 10,
"autoAckOldestChunkedMessageOnQueueFull" : false,
"expireTimeOfIncompleteChunkedMessageMillis" : 60000,
"cryptoFailureAction" : "FAIL",
"properties" : { },
"readCompacted" : false,
"subscriptionInitialPosition" : "Latest",
"patternAutoDiscoveryPeriod" : 60,
"regexSubscriptionMode" : "PersistentOnly",

But something is still missing…

Agenda
Blue/green deployments at Toast (the problem)

Deployment and elevation practices
service v1 service v2
HTTP ingress control plane

service v2
service v1

service v2

service v1
service v2
service v2

shared pulsar subscription
Deploying changes to Pulsar consumers is risky

Mismatch in tooling
Our platform for request-driven service deploys was well ahead of our Pulsar
platform, causing developer frustration

Principle of least surprise
“In interface design, always do
the least surprising thing.”
- Basics of the Unix Philosophy

Elevations & deploys should
be safe, easy, uneventful!

Agenda
Blue/green deployments at Toast (the solution)

Pulsar operational tooling
Elevations & deploys weren’t easy on Pulsar
REST services Pulsar consumers
Can I validate my deploy
before prod traffic?
✅ ❌
Can I validate with a small
amount of prod traffic?
✅ ❌
Can I easily roll back? ✅ ❌
Can I easily roll forward? ✅ ❌
Contrast: REST services & Pulsar (in 2019)

Pulsar Consumer Elevation Requirements
1. Elevate traffic to new consumers as they are set to “active” in the control plane.
2. Avoid building a single point of failure.
3. Make this reusable for other background processes at Toast.
4. No performance hit or extra infrastructure.

Some options we considered
Message Router Pattern
incoming topic
Deploy
N
Deploy
N + 1
Router
Control
Plane
blue topic
green topic

Message Router Pattern - Problems
incoming topic
Deploy
N
Deploy
N + 1
Router
Control
Plane
blue topic
green topic
● But, the router is a single
point of failure
● More infrastructure to
monitor
● Two hops per message

Feature Flags
● Apps use a feature flag to
know whether to connect
● But, not integrated with our
control plane
● Requires more setup for
each consumer
incoming topic
Deploy
N
Deploy
N + 1
FF Off
FF On

Pausing Inactive Consumers
● The Feature Flag approach
is close
○ No extra infrastructure
○ No extra hops
● But, we’d need to integrate
it into our control plane
● Is this possible with Pulsar?
incoming topic
Deploy
N
Deploy
N + 1
inactive
active

Let’s see what the Pulsar source code has to say about pausing consumers.
What does Pulsar provide?
In Consumer.java:

Will pause() and resume() work?
Pulsar consumers Pulsar consumers with
pause()
Can I validate my deploy
before prod traffic?
❌ ✅
Can I validate with a small
amount of prod traffic?
❌ ❌
Can I easily roll back? ❌ ✅
Can I easily roll forward? ❌ ✅
What do operations look like if inactive consumers call pause()?

How do we get each consumer to call pause() or resume() at the right time?
How Would You Solve This?
● Pausing pulsar consumers is
easy. Knowing when to pause is
hard.
● Central control plane component
owns this data
● Let’s just poll that service
● What would that look like?
control plane
service Z

What’s Wrong With This?
● Used to be the pattern for
service discovery at Toast
● Subject to thundering herd
● Now, we leverage Envoy
control plane
service Z

How We Leverage Envoy
Envoy at Toast

Envoy is a reverse proxy
Deployed as a sidecar, forwards requests to their destination
Envoy acts as a proxy, forwarding requests upstream.
my-service menus
GET /menus/v2/menuItems GET /v2/menuItems
envoy

Envoy is eventually consistent
Routing changes are pushed asynchronously
Envoy sidecars across the fleet are pushed updates within ~1-2min of the
change.
Control Plane
…

Envoy knows service status
It gets a push each time any deploy goes active or inactive
We can leverage this to pause() or resume() consumers.

Envoy direct responses
Using an interesting Envoy feature to avoid single points of failure
It can intercept requests and reply with a direct response! This gets
the status info into the process where the Consumer is running.
*magic config*
GET /sidecar/v1/elevation/active
{ "active": true }
my-service envoy

“Pulsar Toggle” implementation
Leveraging our Envoy Control Plane to toggle Pulsar consumers
A thread polls the locally-running Envoy instance and
toggles the Pulsar consumer as needed

Some “gotchas”
Eventually consistent
Consumers don’t pause immediately - updates
propagate with some latency
Start paused
Wasn’t a way to subscribe in a paused state - we made a
patch to the Java client
More advanced elevation patterns
Currently we can’t support percent elevations of pulsar
traffic onto new deploys
Receiver queue size
Critically important to tune this parameter of consumers

Results
~30
Toggle users in Prod
across pulsar consumers &
background workers
0
Outages
No added load on any
critical systems
2
Contributions
To open source - the Java
client & the Camel
integration

Increased adoption
2x
New topics
Developers are adding
topics at twice the rate
since the Pulsar toggle was
released
user
adoption
(linear)

Users Love it!
65%
Increase
reported ease of use when
deploying pulsar consumer
changes
46%
Decrease
reported risk associated with
deploying pulsar consumer
changes
Positive feedback from satisfaction surveys with our users

Key Takeaways
Integration
Strong integration
with existing systems
is critical for org-wide
adoption.
Ease of Use
As we make our
Pulsar platform easier
to use, we see more
and more adoption.
Stability
Pulsar’s stability
through big growth
has been a killer
feature for us.

Kai Levy & Zach Walsh
Thank you!
klevy@toasttab.com
zachary.walsh@toasttab.com
Pulsar Summit
San Francisco
Hotel Nikko
August 18 2022
We’re Hiring!
careers.toasttab.com

Blue-green deploys with Pulsar & Envoy in an event-driven microservice ecosystem - Pulsar Summit SF 2022

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Blue-green deploys with Pulsar & Envoy in an event-driven microservice ecosystem - Pulsar Summit SF 2022

Similaire à Blue-green deploys with Pulsar & Envoy in an event-driven microservice ecosystem - Pulsar Summit SF 2022 (20)

Plus de StreamNative

Plus de StreamNative (20)

Dernier

Dernier (20)

Blue-green deploys with Pulsar & Envoy in an event-driven microservice ecosystem - Pulsar Summit SF 2022