AWS Media Sharing System: Architecture Overview— AWS Solutions Architect
Let’s talk about Media Sharing Service Architecture
We have the following application’s requirements
- Hosting a social media web site where users in multiple countries upload media contents
- Highly Available in multiple regions for the most recently accessed content
- Latency sensitive service
To meet the aforementioned requirements,
we need Elastic Load Balancer and Auto Scaling Group first.
That’s because users from multiple countries will send requests simultaneously to upload their media contents like images, videos, and etc. If there is only one single server that handles those requests, its capacity needs to scale up in no time or horizontal scale out is definitely required.
Elastic Load Balancer distributes incoming network traffic to multiple Upload Web Servers (EC2 instances in Auto Scaling Group), and with the help of Amazon Cloud Watch’s monitoring system, Auto Scaling Group can manage the number of instances automatically.
Then, Amazon Simple Storage Service comes in to store media contents. Amazon S3 is a highly available and durable storage service so it is well suited for storing media contents.
But sometimes, uploading those raw media contents itself is not enough since some files need post-processing like video transcoding, image resizing. In this case, we can leverage Amazon SQS(Simple Queue Service) to execute the processing jobs. Thus, Upload Web Servers do push messages into SQS so that another fleet of EC2 instances in Auto Scaling Group can poll the messages to execute jobs in parallel process. For this kind of job execution, Spot Instances are recommended for cost efficiency.
Post-processed files can be stored in S3 Reduced Redundancy class because they always can be reproducible from original files stored in S3 Standard class.
and Then, media related data can be stored in RDS or Dynamo DB so that we can use them to execute RUD operation in the near future with better performance like S3 bucket name and object id and etc.
Furthermore, we need one more fleet of EC2 instances to serve as Web Servers for users to interact with. and when media contents are requested for every interaction, those contents can be served from Amazon Cloud Front(Content Delivery Network). Of course, the origin of CDN is S3. Amazon Cloud Front offers worldwide low-latency delivery.
Finally, we got a requirement for latency sensitive service from all different regions so we might need Route 53’s DNS service that supports latency-based routing for users all around the world.
