NEHA DEODHAR: Hi, everyone.
I'm Neha Deodhar.
I'm an engineering manager on Cloud Spanner.
Today, I'm going to talk about how Cloud Spanner's
unique architecture can help you build and scale
your applications.
Do you have an application with global reach?
Or one with millions or even billions of users
who need highly accurate, real-time information?
The database that powers your application
can dictate your users' experience, your ability
to grow, and your global resilience.
Cloud Spanner is a highly available, strongly consistent,
relational database that is fully managed by Google Cloud.
To understand how Spanner can help your application scale,
be highly available, and resilient,
let's first understand Spanner's architecture.
Spanner will automatically divide your data
into chunks called splits.
These splits contain data from your tables and indices ordered
by the primary key.
Spanner will distribute and balance
the splits across multiple servers.
As your data size or load increases,
Spanner will automatically further split your data,
mod some splits, or rebalance splits across servers.
Spanner also creates multiple copies or replicas
of your data.
These replicas are stored across multiple zones and regions.
It uses the Paxos consensus algorithm
to keep the replicas in sync.
One of the replicas is elected to be the leader.
The leader replica is responsible for handling
and replicating the writes.
Transactions that read and write data from multiple splits
will use an extra layer of coordination
called two-phase commit.
One of the split leaders that is involved in the transaction
will act as the transaction coordinator
and will ensure the [INAUDIBLE] of the transaction.
When your application writes data to Spanner,
the write request is first sent to the split leader.
The leader will record the write,
and will replicate it to the other replicas.
When a majority of the replicas acknowledge the write,
the transaction is committed.
Now let's look at how you can configure your Spanner instance
to achieve high availability.
Primarily, Spanner has two types of configuration,
regional configuration and multi-regional.
In the regional configuration, Spanner
will create three copies of your data
and store them across three zones in a single region.
This is a good configuration for applications
that are regional or require low-latency reads and writes
all within a single region.
Using the Paxos consensus algorithm,
Spanner is able to provide four nines of availability, and even
zero-RPO, zero-RTO recovery from various types of failures,
like zonal network failures, machine or hardware failures.
In the multi-regional configuration,
Spanner will store multiple copies of your data
across three or more regions.
This is a good configuration for global applications
or if you have applications that need
to tolerate regional failure.
It provides five nines of availability,
which is Spanner's highest availability,
and zero-RPO, zero-RTO recovery from region, zone,
and other types of failures.
Based on your application reach, you
can also add read-only replica regions close to your users
for faster reads.
Now let's understand and try to unpack the various replica
and read types that we've seen, and how
you can use them to get the maximum benefit from Spanner.
Multi-region configurations always
contain two read-write regions and one witness region.
The read-write regions each store
two copies of your database.
The witness only stores the transaction logs and does not
store a full copy of your database.
Spanner will require a majority of two out of the three regions
to commit a write or three out of the five replicas
to commit a write.
So these regions are usually located close to each other
so that we can get reasonable write latencies.
One of the read-write regions is designated
to be the default leader region.
Spanner will place all the split leaders in the default leader
region.
Having the split leaders in a single region
ensures predictable and good latencies
for transactions that involve multiple splits.
You can change the default leader of your database
to align with your application's traffic or your application's
primary region, if needed.
Spanner's multi-region configurations
also support additional read-only replica regions.
These regions help you scale your application
by keeping a copy of your data close to your users
and providing low-latency reads.
Since read-only replicas do not participate
in voting for writes, they don't impact your write latencies.
Spanner supports two types of reads.
The default is what we call as a strong read.
This will always read the latest data.
However, it may require communication
with the leader to confirm that it has the latest data.
In a multi-regional configuration,
if the leader is in a different region than the replica
that you're reading from, then your application
might see higher latency due to the cross-region communication.
If your application is latency-sensitive and can
tolerate slightly older data, then we
recommend that you use stale reads.
A stale read will read data at an older timestamp.
For example, you can use a stale read
with the maximum staleness of 15 seconds.
Stale reads help you avoid communicating with the leader
and can solve low-latency reads.
Now let's understand how Spanner's architecture
can help your application get high availability
and global resilience.
Let's consider a scenario where the leader region fails.
Both zones and two copies of your data from the leader
region will be unavailable in such a failure.
In this scenario, replicas in the second redirect region
will automatically be elected to become leaders.
The leader change happens in the order of a few seconds.
During this time, Cloud Spanner clients will automatically
retry the intermittent failed requests,
so your application will not see any downtime even
with region failure.
Note that there could be a small increase
in tail latency due to the leader election and client
retries.
When the leader region comes back up,
the replicas in that region automatically
will become leaders again.
Now let's consider a non-leader region failure.
There is no impact to application
writes in this scenario.
Spanner will continue to have three replicas, two
from the leader region and one from the witness,
available to form the majority quorum for writes.
Reads that were previously being served
by the replicas in the failed region
will now automatically be served by the leader-region replicas.
So again, as before, your application
will not see any downtime in a non-leader region failure.
Now let's look at how Spanner handles zone failures.
The split leaders in the leader region
are distributed across two zones in the region.
In the case of regional configurations, where
the leaders are distributed across the three
zones in a region.
When a zone in the leader region fails,
replicas in the other available zones
will automatically be elected as the leader.
Again, your application will not see downtime.
It may have a slight increase in write latency during the leader
election and client retries.
Spanner's unique architecture gives you the peace of mind
that you have high availability, low latency, and resilience
against failures.
Businesses around the world are powering their users
using Spanner.
I hope that this presentation has
gotten you excited about using Spanner for your application.
To learn more, or start using Spanner,
please visit the Cloud Spanner page on Google Cloud.
Thank you.