Hi and welcome to, ‘This is My Architecture.’
I'm Don and I'm joined by Charlie with Equifax.
Hi Don. Hey Charlie.
Why do you tell us a little about Equifax?
Sure, so Equifax is a rebuilt company from the ground up with an emphasis
in enablement in the cloud.
Excellent, so tell us about the application that we're going
to walk through today. So the application we're going
to talk about is myequifax.com, it's our primary asset for consumers
to manage and monitor their credit.
Okay, so you will walk us through from the consumer, their mobile device,
through the architecture? Sure, so from the top down,
they can come in over web or mobile.
They will come in through an application load balancer
which will lead into an EKS cluster, which is a composition
of EC2 on-demand instances and spot instances
from the spot instance marketplace in AWS.
Following that, the multiple applications that are deployed on that cluster
will actually make database connections to Aurora Global,
and then also to document storage engine for different, you know,
no SQL implementations or storage documents.
And so, with respect to Aurora Global,
what we're talking about here is acid compliance transactions, right?
And then of course, over on the document storage
we're talking no SQL. Okay.
So things like credit reports, information about the individual
are stored in the data storage that you have?
So why don't we do this, why don't we break this down
and go through it piece by piece.
So with respect to EKS here, so I see the on-demand instances
and I see spot instances, so the first things that comes
to mind is you know, reliability. That's right, that's right.
And so Kubernetes gives us a lot of those constructs,
and really where it boils down to is in liveness
and readiness probes with respect to EKS.
And what those do is they tell EKS the control plane
that those applications are ready to receive traffic.
Okay, so from a cost optimization standpoint,
it sounds like you can blend different instance families
across different AZs to tap into different capacity pools?
Absolutely, yeah. So when we talk about spot instances
in the AWS marketplace, and so just to take it from the hut,
you know, from the top down.
What we're talking about here is really a 60/40 split
in respect to spot instances, and 40% on-demand instances.
So we've got spot on this side, and we've got on-demand on this side.
And when we talk about the different architectures
and the different capacity pools that are available
across different regions, that's really where, you know,
the Graviton2 processors, ECR with manifest list
building those docker images from multiple architectures
with Docker X. Okay, so I have to imagine
you have quite a few consumers that are hitting this.
So again, back to reliability. You mentioned Graviton2,
so you know, we have ECR. Can you talk about you know,
kind of how your pipeline, what it looks like to deploy?
Absolutely, yeah. So we have a global pipeline
that actually, so I'll write this out here.
We've got a global pipeline, build pipeline
that actually runs all of our SDLC, our unit test, integration test.
Also deploys across multiple regions and multiple accounts
into this exact same architecture across multiple regions.
Okay, alright. So why don't we move
down to the persistence here. So we have Aurora Global,
so I assume we're talking multi-region, right?
That's clearly going to have an impact on your applications.
Can you talk about what you had to do to actually enable that?
Absolutely, yeah. So Aurora Global is
a multi-region replicating transactional database, SQL database.
The particular flavor that we're using is Postgres.
And so, it's Postgres over the wire from a driver compliance standpoint.
So you can imagine, we've got our applications running on EKS.
Those are actually talking to Aurora Global instance over Postgres.
And then that data is actually replicated
on the AWS backbone between the Aurora Global writers
and readers. And so to answer your question,
the applications actually implement a dynamic data source.
And so we drive those configurations from a configuration server.
And so really what happens is,
let's imagine that we're in the West Coast,
and there's a failure on the writer.
The property that served from the configuration server
to the application is the only thing that has to change.
And then through dynamic refreshing in the application context it will fail over
and start talking to the writer in the different region.
Interesting, so I think what I'm seeing here is a combination
of an event driven configuration, an event driven notification
likely because spot instances are going to have a termination notification.
Can you talk kind of, how those pieces come together
to create this highly reliable database?
Absolutely. So AWS actually gives
us something they call the node-termination-handler.
And what that is, that's just a pod that actually runs on our clusters
or a number of pods. And what that pod does,
and we'll call this the node-termination-handler.
What that does is it listens to events from AWS across the control plane
on when one of these spots instances will actually be reclaimed.
And you only get a two-minute warning.
Okay, so you're able to, with your architecture you're able
to react quickly enough? Absolutely.
So when that event occurs, the pods that are actually running
on these spot instances, and we'll just throw out some pods
out here with these applications. And remember those liveness
and readiness probes are actually configured as well.
There's a two minute warning, that node gets reclaimed
and those pods, the node-termination-handler
will reshuffle those pods over to a running node
as that node gets replaced.
Interesting, so what's next for the architecture?
So we're going to replicate this globally.
And we're going to take this, so we're in the UK and Australia,
and of course in the US, and even Canada.
And the savings that we actually see here is about a 60%, 70%,
even upwards of 80% savings by going with the spot instance model
with a combination of the EC2 on-demand instances.
And so what we're really playing with here is this ratio.
How many spot instances can we use versus how many on-demand instances
can we use to optimize that cost savings.
Alright, well thank you very much for sharing this innovative architecture.
Taps into a lot of the well architected framework pillars that we emphasize,
so we have cost optimization, we have reliability.
And this is really an interesting approach to having both
from a compute standpoint and a persistence standpoint,
how you've handled that. Thanks for your time today.
Sure. And thank you for watching.