What's the advantage of sharding in AWS Aurora?

Question

AWS' RDS docs on multi-master Aurora state the following:

In an Aurora multi-master cluster, each shard is managed by a specific DB instance, and a DB instance can be responsible for multiple shards.

Later in the same document, we read:

You can avoid resharding operations because all DB instances in a cluster can access all databases and tables through the shared storage volume.

So, a multi-master Aurora instance can be responsible for multiple shards. This is made possible in part because all DB instances access the same shared storage volume.

If multi-master Aurora instances can manage multiple shards, what's the advantage of using sharding at all? Why not just configure all instances to manage all shards? (Essentially obviating the need for sharding)

A theory

My suspicion is that not using sharding would lead to more deadlocks within Aurora's internals if different masters write to the same page at the same time. This, in turn, would lead to increased latency while Aurora retries the contentious write. Or, perhaps Aurora would generate an error and the application itself would have to retry the query. (I'm clearly not familiar enough with Aurora to know what happens, hence this question 😁)

Answer 1

What's the advantage of sharding in AWS Aurora?

What's the advantage of sharding in general?

It allows you to distribute your workload across multiple compute resources, each working with its own subset of data, thus giving you an option of horizontal scalability; you can add more shards if your data or your workload grow.

Traditionally a sharded application might look something like this:

Clients C1..3 would connect to servers S1..3 as appropriate, whereas each server would have its own isolated storage with a subset of data Dx.

It all works well until one of the servers fails. In that case the data it holds becomes unavailable to clients until the server is recovered. To improve availability replication is frequently used, placing redundant copies of data shards on other server' storage.

Thus, if a server should fail, other servers that store replicas of its data shards will pick up the load, so the clients continue to have access to all of the data. This comes at the cost increased network traffic due to replication and higher storage utilisation, because you need to store extra copies of data.

Multi-master Aurora solves the latter problem by providing a single storage volume that is simultaneously accessible by all servers.

This eliminates the need to send copies of data shards across the network and store their redundant copies elsewhere.

Under normal circumstances each server works only with the shards assigned to it, but if it fails, other servers can pick up the workload without extra cost.

Answer 2

I recall a conference presentation by Mark Callaghan of Facebook, talking about scalability of the InnoDB engine in MySQL. It was in the early 2010's. He said that storage technology had gotten good enough that it could handle more throughput than InnoDB could send it. That is, InnoDB's software architecture was the bottleneck, given fast enough storage. He said it was possible to run multiple InnoDB engines on a single storage volume, at peak write output, before saturating the I/O capacity of that volume.

He was talking about non-cloud hosting, but the same is true of Aurora's storage volume. As the storage technology gets more advanced, it was able to take more write traffic than a single Aurora writer instance could send it. So it makes sense to run multiple Aurora writer instances, writing to the same storage.

But every technology has a limit, even if the limit is greater than it used to be. You can't pump a million writes per second through either a single InnoDB database engine or the current generation of storage.

That's where sharding has become necessary. Suppose your application's traffic has increased so it needs to handle 1 million writes per second. But a single Aurora instance can only process 5k writes per second, so you'd need to split the writes over at least 200 clusters (assuming you could split the writes exactly evenly).

But if the latest generation storage volume is more advanced, so it could handle 20k writes per second. Then the multiple writers might help. Each writer can still only do 5k per second, because of software limitations. But two of them can in theory write to the same volume, which can handle the throughput of both. Therefore you don't need to split your database into as many shards; you can co-host multiple logical shards on the same cluster.

This all depends on practical matters, for example your app being able to balance the writes even over the writer instances very reliably. If there are "hotspots" or shards that receive a disproportionate amount of write traffic, then it doesn't work so well.

The Aurora documentation you linked to makes it sound like you could co-host all your shards on the same Aurora cluster, but this is probably not going to work out that way. Keep in mind their supposedly technical documentation is also part of their sales pitch, so they make it sound better than it really is.