Good morning, everyone.
Welcome to this episode of This is My Architecture.
My name is Marc and today I'm with Pierre,
from the Klap.
- Welcome, Pierre. - Hello Marc.
Well, tell me Pierre, could you tell us a little bit
about Klap's use case today?
Yes, so Klap does automated editing
and video processing for sports.
It is used for sports betting
or sport events of all kinds.
We manage large video streams,
for example, football matches,
we make edits, in which we include
all the goals of the football match
or statistics, such as the number of passes per player.
Right, and today you've created
your app solution directly on AWS.
Could you tell us more about it?
Yes, we used AWS and its cloud,
first for its storage, Amazon S3,
which allows us to manage huge videos
since we handle very high quality streams,
from 50 Mbps per second,
which is about 50 gigabytes for two hours of video.
Thus, we quickly have a lot of video to manage
and managing that in the AWS cloud
allows us not to manage videos on hard drives,
which creates reliability issues.
And in the same way, we also use a lot
of AWS Lambda for computations,
which also allows us
not to have a single server doing computations,
but to distribute computations in the Amazon Cloud.
All right, and could you describe
the architecture we have on the board?
Yes, then I'll show you the path used by a video
in the Klap cloud.
The video arrives in an Amazon S3 bucket
and the arrival of this video will automatically start
the execution, a Step Function execution.
This Step Function execution will trigger sequentially
four steps.
We start first with a Lambda
that will take this video
and transform it into thousands of frames
that will be stored again on Amazon S3
as PNG.
All right, so once you've generated
all these frames, what are you going to do with them?
Then these images are then analyzed
by a second Lambda.
But this second Lambda is going to list the images,
and since there's a large number of images,
there are a large amount of computations to do,
in fact, instead of doing the computation directly,
it's going to run a batch process,
in batches of 50 to 200 images in Lambda's
that are going to be run in parallel.
So, in practice, it's going to launch,
it can be 50 or 100 Lambda's in parallel,
or up to 1000 Lambda's,
since that's what we can do with AWS,
which will process
all the images of the video at the same time
and will extract, thanks to a TensorFlow model,
for example the position of the ball in each image
and store this position again
in an Amazon S3 bucket.
All right, so you have trained a TensorFlow model
and then imported it into a Lambda function.
Why did you choose the Lambda inference?
Lambda has a lot of advantages in this case.
First of all, it is a system that is extremely reliable
because as our computation is distributed,
if one of the computation units falls,
we can restart it dynamically.
Secondly, it's extremely scalable, as I explained,
regardless of the amount of video
we have to process.
You can constantly adjust the available computing capacity by simply
sending more Lambda's in parallel.
And finally, in terms of cost,
it's interesting because it allows us to manage
all our Lambda computations
and not have to pay for the scale up and scale down
that we can have on the usual instances.
All right, so on this second step,
you're going to generate features
that will be stored on S3.
What are you going to do with these features afterwards?
These features are processed by the following Lambda
in the Step Function execution.
This Lambda is similar to a decision engine,
i.e. we know where the ball is in each frame.
What we're going to do... we also know where the goal is.
We just have to look at
when the ball enters the goal,
in which frame, and decide at that moment
which editing we want to do.
In this case, we want a slow motion of the goal.
So, that decision is made
in that Lambda,
based on all the detections that were made in the frames,
and that will then allow us to edit.
All right, so once you've determined
the decision engine, how do you launch
the editing step?
Well, the editing step is not done
in a Lambda function.
It's done in an ECS cluster.
This ECS cluster carries EC2 instances.
These EC2 instances will carry
an FFmpeg engine that will do the actual editing of the video
and then send this video
to the streaming platforms...
All right.
...so that it can be viewed by the customers of our customers.
All right, and why did you choose specifically
ECS and not Lambda for this last step?
Well, at Klap, we're big fans of Lambda.
It's got a lot of advantages over the whole computation.
But the problem with this last function step
is that you can't have
a computation that lasts less than 15 minutes.
Let’s imagine that we want to edit a goal.
For the 20 minutes before that goal,
you have to do all the transcoding, etc.
These are rather heavy computations
and therefore the limitations that are inherent
to Lambda functions, in fact, can create
business problems for us, on this last step.
So we preferred to use an ECS Cluster,
which allows us to have fewer limitations,
to be freer.
And since it's not
the most expensive step for us,
we didn't need
to optimize a lot in this part.
This part, all right.
And could you share some figures
on the use of this architecture today?
So, this architecture today allows us
to process 1 to 5 million analyzed images per day
for costs that will be less than 10,000 euros per day.
It may seem expensive,
but video is extremely heavy to process.
The computations are heavy.
And compared to other solutions,
our analysis is very competitive.
The other advantage we have is that,
regardless of the amount of data we're going to have as input,
we can guarantee processing at least up to this step,
on this first part,
which will last less than five minutes.
For example, to process large batches
of our users' data archives,
this is an extremely fast solution.
All right, and what improvements
could you make to this architecture?
There's a lot of improvements.
The first point that is important for us
is to reduce the 5-minute slot,
to be able to reduce it on live streams, to be able to be able
to output a result in less than 30 seconds.
And for that, we hope to connect...
Well, we are currently connecting an Amazon Kinesis stream
that will replace the input by the S3 bucket
and that will allow to have more fluidity in the stream
and to manage the stream really in real time.
The other point is to transform,
to complete this architecture
with GPU processing at the Lambda level,
to be able to benefit from hybrid processing
and to be able to run larger
TensorFlow models,
which are not nowadays part of the Lambda functions.
All right.
Thank you Pierre for sharing your experience with us.
Thank you Marc for inviting us.
And thank you for following us on this episode
of This is My Architecture.
Goodbye.