Welcome to 'This is My Architecture'. I am Hawn.
And today, we have Erik from Heimdall Data joining us.
Welcome, Erik. And thank you for joining us.
Thank you.
So before we get into your architecture,
can you tell me a little bit about Heimdall?
Yes.
Heimdall is an ISV partner of Amazon.
And what we do is we provide a software solution that's a proxy,
database proxy, that sits between client applications,
Lambda functions, and the database itself.
And within the software, it provides a wide variety of different functions
in order to improve the scale and performance of applications,
and just help simplify the life of developers.
So, let's say I'm a developer,
so walk me through the flow of how that would help.
Okay.
So whether you've got an application server
or Lambda function,
they are going to connect to an NLB
that will then distribute database queries
as if it were the database
into one or more proxies via an auto-scaling group.
These proxies then provide one of the several
or any one of several functions
via caching or read/write split, which we're about to talk about today,
all in accessing the database.
Okay, so you said read/write split. So how does that orchestration work?
Okay.
So the whole idea here is that most applications aren't designed
to access multiple application or database nodes,
because the database nodes are read/write
or as, in the case of a secondary server,
it is a read-only node.
And the applications aren't designed to know
when it's safe to use that second server.
So what Heimdall does, is as the proxy
it monitors the traffic that's going through the Heimdall
or going through the proxy.
It is able to determine what tables are being written to,
and what tables are being read from, out of the database.
So let's say you've got a write going into the primary server.
We know that it is no longer safe
to read that same table from the reader
until, a long enough has occurred that
that data is now on the secondary server.
Great.
So I noticed that the proxy is in a cluster.
So how do you ensure there's no drift among the different nodes within there?
Okay.
What Heimdall does is when we see the DML happening,
we leverage the pub/sub interface of ElastiCache.
It's something an interface is very similar to SNS,
although very low latency.
So the proxy will come through,
will write an invalidation message against that pub/sub interface,
and then it will synchronize that
with all the other proxies.
So by doing that, all the nodes know what is happening on any individual node
and they're able to operate as one
even though they're distributed across many physical instances.
That's cool.
So, as a developer, what do I need to do? Do I have to make some code changes?
Nope, you don't, okay? Heimdall takes care of everything.
We understand what tables are being written to,
what are being read from, we synchronize that.
We also do something that we call lag detection.
- Wow. - Okay.
What lag detection is
is independent of all the traffic the application's doing.
We write into the primary database.
We let it synchronize over to the secondary database.
And then we read what we wrote.
And what we're writing is a timestamp.
So by reading it back in,
we're able to tell how long it takes for data
to go from the primary to the secondary.
We then use the last write time on the table,
plus that replication lag to determine what is safe to do
when we do a read.
Is the secondary safe? And it's all automatic.
That's the beauty of it.
So application developers can now scale their database
from one writable server, to let's say, an Aurora cluster with 15 readers.
That's fantastic.
I definitely can see how that will make it easier
for the developer's life.
So what are some of the benefits that you've seen...
Where your customer has seen with this architecture?
Okay.
Oh, we literally have customers that are using 15 read replicas.
Wow.
And because of the way that we handle everything,
we're able to effectively use all 15 replicas.
If you even try to implement this on your own,
most developers would try to use the reader endpoint
of your Aurora cluster, for example,
but because of DNS and the way load balancing happens,
you'll often get very different loads on the different databases.
So even if you tried to implement this,
it generally isn't going to get you the same results that you get with us.
Okay.
So what are the other benefits that,
you know, that your customers have seen with this architecture?
Okay.
So on top of the read/write split, we have other functionality.
We've got another video, we talk about our caching logic,
which is very much related to how we do the read/write split.
But we also do connection pooling and multiplexing
in order to reduce the number of connections on a database.
And then in particular, with Postgres derived databases,
lowering the connection count
can be very important to improve performance.
Thank you for going over your architecture.
It's definitely very beneficial for the developers
to give that lift in the application with little to no code changes
and having to handle the connection pooling and replication.
- So that's really awesome. - Thank you.
And thank you for watching 'This is My Architecture'.