Welcome to 'This is My Architecture' New Zealand.
I'm Ondrej, and I'm with another Andre from Lancom.
Welcome to the show.
Great to be here. Thanks.
Can you tell me about Lancom and this solution?
Yeah, absolutely.
So Lancom Technology,
we're based here in Aotearoa, in New Zealand.
We're a technology provider.
So think, software development, cloud infrastructure, that sort of thing.
And today I'd like to share this architecture
we developed for a video conferencing solution
that connects loss adjusters in the insurance industry
to clients that are making insurance claims.
So basically, what the application does is
it connects those loss adjustment agents via a remote video call
that's facilitated by a custom web app to clients
that are connected just through their phone,
sharing that video stream through the camera.
And it allows them to perform remote assessments of any damages relating to that claim.
Perfect. So you get agents connecting to the clients.
How do you actually connect the video? How does it work?
Absolutely. So we've got our two sets of users,
and they both connect to a video platform called OpenVideo.
It's an open source platform that is hosted on EC2.
So OpenVideo facilitates those video sessions and using a protocol called WebRTC.
And it allows the agents to view those damages
just through the camera on the client's phone and assess those damages.
So once the call is finished,
a recording of that is saved onto disk on the EC2 instance.
So we have a little script that's just running here
and that will pick up those raw recording files
and upload them to S3 where they can be later processed.
Now you have to send the video to S3 and you need to process them.
So how do you do that?
So what we do is when the files are uploaded to S3,
that triggers an event notification to SQS,
and those messages are pulled by a service running on ECS Fargate.
So what the service does is it takes the raw files that are uploaded to S3
and processes them with a tool called FFmpeg.
So that tool will combine the audio and video streams of both parties
and produce an output that is encoded to a more consumable format
called HLS or HTTP Live Streaming.
And then those process files are uploaded back into S3.
So we've got our video files there,
and they're saved to S3 for later review by the loss adjustment agents.
When I work with my insurance company,
I usually call them during the business hours.
How do you handle the peaks and the highs and the lows?
Yeah. So, of course, these companies have times of peak traffic
where there are many sessions ongoing and so lots of recordings to process.
So we've leveraged the scalability of Fargate to handle this.
We have auto scaling policies that look at the size of the SQS queues.
So how many messages are waiting to be processed?
So as that number increases, we have more messages coming in.
We are able to scale up the number of tasks automatically.
So the number of tasks increases,
and we're able to process those videos faster
and reduce the amount of time that the loss adjustment agents
are waiting to review their videos.
And then can you then scale down if you need to as well?
Yeah, absolutely. So when the number of messages goes down
or in the case of some small businesses, outside of business hours,
It may even go all the way to zero,
and we can scale that all the way down to zero as well.
So that really saves on the costs there.
I love the flexibility for the big and small businesses.
That's a good benefit of using Fargate.
I see, at the same time, you're also using EC2.
Can you walk us through what made you chose different technologies?
Absolutely. We've leveraged Fargate where we can,
and that the benefits that it provides as being a serverless service.
But in the case of OpenVideo, it supports a EC2 based deployment.
That's the option that we had to take,
and so we were able to utilize this sort of flexibility
of EC2 platform to support that part of the architecture
and deliver a complete solution.
Consider being a lot of videos where all the agents are connecting,
how do you make sure that you manage the storage costs for the platform?
Yeah. So you can see we've got S3 Glacier here.
What we have is essentially some lifecycle policies
that will allow us to reduce those long term storage costs.
So there is a lot of data when we're processing,
we're actually outputting multiple different resolutions to support dynamic playback.
But those process files then can end up being up to two times larger
than the raw files themselves.
So there's a lot of data to manage,
but it's important that we retain those recordings
in the long term for legal reasons.
So to manage the storage costs after a certain amount of time has passed,
we delete the process video files, and then for the original raw recordings,
we migrate those to S3 Glacier, and that really reduces those long-term storage costs.
And then in the event that we need to restore any of those archived recordings,
we can simply take that raw file and put it through the same process again
and restore the video to its original state.
That's a perfect use case for Glacier
when you can store the raw file and process them again if you need to.
But thank you for sharing this architecture, in particular,
the details that made you choose between Fargate and EC2.
Thanks for having me.
It's great to share our experience with AWS.
Thank you for watching 'This is My Architecture' New Zealand.