Hello, I'm Taehyun Kim from 'This is My Architecture'.
Today, we have Sanggi Choi from Spoon Radio.
We'll talk about the architecture of Spoon Radio.
Hello.
Please introduce Spoon Radio.
The world is created from many people's stories.
Spoon Radio is a real-time audio platform that collects and connects those stories.
The advantage is that anyone with a smartphone can become a DJ or
listener anytime, anywhere.
Here is the Spoon Radio architecture using different AWS services.
What is the architecture for?
Spoon Radio customers are divided into DJs and listeners.
I'll explain the way DJs open the live rooms.
A DJ requests to open a live room with ALB and API server.
As soon as the live room is opened, the API server requests to open a chat room by the chat server
and then to assign a live-streaming server by the streaming server.
And all this information is stored in RDS Aurora.
At the same time, it is stored in DocumentDB, too.
Secondly, from the listener's point of view,
they receive personal feeds of live information generated by DJs
or they receive the real-time ranking information.
At this time, if the listener receives a request through the API server that
"I'm going to listen to a certain broadcast through the API server",
the API server delivers the live chat information with streaming information that this listener wants.
After that, this listener connects to the chat server
and then listens to the chat.
The listener also listens to live music
through AWS CloudFront.
There is Nginx in this CloudFront backbone.
This Nginx
looks at the live-streaming service.
The meta information is confirmed through ElastiCache Redis.
Spoon Radio provides a global service,
so there must have been a lot of concerns.
Please explain which part was the most important
and how you solved the problem.
Network latency is the most important.
The network latency
between the DJ and the streaming server was the most important.
So we configured streaming servers
in several AWS regions.
We used a latency-based routing policy
in Route 53
to overcome that latency.
Network latency was the most important
for global streaming service.
To solve the problem,
you can understand that Spoon Radio used a policy
of latency-based routing for Route 53.
Here you can see that some servers use ElastiCache.
They're used for different purposes.
Please explain the purpose and how they're used.
We are using ElastiCache Redis for three purposes.
First, we use it
to deliver real-time ranking information to listeners.
When a DJ creates a room with API server
and the listener actually participates in the broadcasting room,
the API server stores all these data
in ElastiCache Redis
and delivers real-time ranking information to the listener.
Secondly, we use it in the chat server.
The pop-ups on the chat server
are processed using ElastiCache Redis.
Finally,
the dynamic routing of the streaming server
also uses ElastiCache Redis.
Spoon Radio uses ElastiCache
as a pop-up for the chat server,
and it is used for storing other meta information.
You can also see Aurora and DocumentDB that
are being used.
Please explain what information is stored
and how the stored data is finally serviced.
All information exchanged between DJs and listeners
is stored in RDS Aurora by default.
At the same time,
all services caused by users
are stored in DocumentDB.
RDS Aurora
and DocumentDB
configure personalized feeds to provide the recommended live information
to users.
Recommendation service that is provided by using Aurora and DocumentDB
seems very interesting.
Spoon Radio is a streaming service,
but Rekognition is used.
What's the purpose of using Rekognition?
Some DJs often upload
background images
as unhealthy images.
Spoon Radio
puts a lot of effort to make
healthy audio streaming.
As part of it, all content uploaded
by users
will be saved in S3.
AWS Lambda is triggered at the same time
as it is stored in S3.
In Lambda, Rekognition Content Moderation is used
to determine whether the image is a healthy image
or an unhealthy image.
The result is submitted to the operator.
If the image is unhealthy,
we don't make it exposed to users.
Thanks for your time, today.
Please tell us about Spoon Radio's future plans.
Spoon Radio is being serviced in many countries around the world.
We are planning
to use AWS EMR Spark with
SageMaker for the advanced recommended information.
We plan to efficiently operate the Spoon Radio infrastructure configuration
using the AWS services listed here,
as well as other high availability services.
I can't wait to see the better future of Spoon Radio.
Thank you.
'This is My Architecture'.
Thank you.