Hi, welcome to 'This is My Architecture'.
I'm Yu Hua, I'm here today with Jose from DBS Bank.
Welcome, Jose.
Thanks for having me here.
So, Jose, can you share a bit about DBS Bank with us?
DBS Bank is a leading financial service group in Asia.
Nowadays we call ourselves the digital bank of Singapore.
So I know we are here today to talk about a serverless compute grid use case
within DBS Bank.
Can you share with us more details on that?
Our compute grid is being used to price exotic option trades,
which are using the mathematical models developed at DBS,
and application which calls the grid is Murex,
which is our main, primary trading application
and risk platform.
So before we dive deeper into the architecture itself,
can you share with us what was the challenge
that your team was trying to solve?
Okay.
In grid computing cluster, we have two major components,
which is the compute itself, and so this compute,
we have migrated from our physical servers
to AWS Cloud in the past, in 2017,
and we were able to save almost 80% of our infra cost.
Now the second component, which is a grid...
Grid scheduler software,
which is a third party software and it is being licensed based
on the number of cores in your cluster.
Now this itself actually limits us to scale as in when we need it.
Looking at your architecture,
I see that are multiple Amazon SQS queues being used.
Is there a rationale behind that design?
Yes.
So in Murex application we have multiple types of users,
like high-priority users and so what we have done,
we have divided the queues into high, medium, and low.
So that in case, for example, like when the trader makes his submission
to the grid, actually it hits the high queue,
and the back office users will be in the medium,
and the batch users are actually going to the low queue.
I see that you also have multiple AWS Lambda functions.
Out of curiosity, are they the same Lambda functions
or are they different?
Yes, they are same Lambda functions.
So when we started we only had one Lambda function for multiple queues,
and we found that the performance was not so good.
So what we have done is we have divided them,
we just duplicated them as same function,
just to manage our provisioned concurrency.
So by having provisioned concurrency,
for example, if I give a provisioned concurrency of 300 to high
and 200 to the low,
and then 100 here, then we have almost,
and a buffer of 500, so total 1,000 Lambdas.
I can actually better scale for each of the queues.
So interesting.
So with this design you can maintain a quality of service
for different groups of users.
Yes, you're right.
You're also using multiple different AWS storage services,
such as Amazon S3 and Amazon EFS.
Can you share with us what types of data
are you storing in those services?
Okay.
So for the computation we need a input data
which are non-sensitive in their nature,
so we used to save all the data
into the S3 bucket in the beginning,
including the binary,
but you know that whenever the binary is actually downloaded into the Lambda,
we found that actually,
the size is not enough
because we have lots of binary in financial models,
so what we have chosen is EFS.
So EFS is mounted now in each of our Lambdas
and then we can avoid the cold start for the Lambda itself,
because the binary is mounted in the Lambda itself.
So that's interesting.
So now EFS has become your binary repository in some sense.
Yes, you're right.
Can I also assume that the output from the AWS Lambda functions executions
are being stored in DynamoDB?
Yes.
So DynamoDB we have chosen because of the throughput,
which it gives and it works very well with the Lambda.
So we store our output...
In a DynamoDB,
as well as the status of the function itself,
what has happened to the function, right,
whether it is failed or successful.
So when we request the output actually, we check,
make sure that it is not a duplicated execution
of the Lambda function.
This is the use of DynamoDB.
That's interesting.
Elasticsearch, are you using it for monitoring purposes?
So yeah.
So Elasticsearch, what we are doing is our on-premise logs
and as well as all the AWS logs,
whichever the logs are actually coming from the Lambda,
everything is actually aggregated at Elasticsearch.
And then which we can use later
for end-to-end monitoring of the task computation,
while using Grafana.
Sure.
So, Jose, what are some of the future plans you have for this architecture?
Yes.
So today actually, when we execute our Lambda,
we are able to execute
3,000 to 4,000 Lambdas per minute,
assuming that the current limit is 1,000,
but we want to enhance this actually further.
So recently AWS has announced
that they have increased the CPU
and memory of the Lambda function itself.
So we want to try micro-batching,
so that one Lambda function
can execute multiple calculations in parallel.
So our target is to actually execute
almost 30 to 40 million calculations per day.
So this is very interesting architecture.
Thank you for sharing it with us today.
And I hope you enjoyed it as well.
And thank you for watching 'This is My Architecture'.