[세션레포트] Scaling on AWS for the first 10 million users #AWSreInvent #ARC201

안녕하세요. 클래스메소드의 정하은입니다.

이번 글에서는 AWS re:Invent 2024 에서 "천만 사용자를 위한 AWS 확장" 을 주제로 한 세션을 듣고 온 레포트를 작성하고자 합니다.

본 세션은 AWS 서비스를 이용하여 웹사이트 구축을 할 때 유저 수에 따라 어떻게 구성이 변화하는 지 알아보는 내용으로 구성되어있습니다.

이 세션에서는 AWS에서 비즈니스 인프라의 빠른 성장과 성공을 처리하기 위한 패턴과 기법에 대해 알아봅니다. 확장 시기와 확장 시기를 고려하는 방법, 캐싱이 가장 도움이 될 수 있는 부분, 애플리케이션을 새로운 서비스로 분리하는 과정을 알아봅니다. 이미 확장 가능성이 높은 AWS 서비스 활용법부터 분산 시스템 패턴 설계 방법까지, 초기 단계에서 일반적인 인프라 문제를 극복하는 데 도움이 되는 여러 가지 선택지가 있습니다. 각 단계에 따라 발생할 수 있는 인프라 문제를 극복할 방법을 알아보세요.

세션 영상은 유튜브에 공개 되어 있으니 참고 바랍니다.

세션 내용

유저수 > 1

우선 프론트엔드와 백엔드를 분리하는 방법부터 고려하게 되는데요.

통상적으로 프론트엔드 호스팅을 하기 위해 EC2 - ELB - CloudFront 구성으로 구축을 해왔을텐데요. 요즘에는 서버리스 서비스를 선택하는 추세로 변화하고 있습니다. 특히 AWS Amplify Hosting을 사용하는 것을 추천하고 있었습니다.

백엔드의 경우엔 Amazon EC2, Amazon ECS/Amazon EKS/AWS Fargate, AWS Lambda 등 여러가지 서비스 중에서 선택하게 되는데요. Amazon ECS와 AWS Fargate 조합을 추천하고 있었습니다. 프로비저닝이나 구성, 확장에 대하여 서비스에서 자동으로 관리해주기 때문에 개발자가 프로그램 개발에 더 집중할 수 있기 때문인 것 같아요.

API 구축 시에 사용하는 서비스도 Amazon API Gateway, Application Load Balancer, AWS AppSync 로 나뉘는데, 목적에 따라 선택할 수 있도록 치트 시트를 공유해주었습니다.

데이터베이스는 연결할 때는 Amazon Aurora Serverless v2 를 추천하였습니다. 컴퓨팅을 저장소와 데이터베이스에서 분리하여 수요에 맞게 컴퓨팅과 저장소를 개별로 확장할 수 있고 용량 관리가 쉽다는 점을 장점으로 들었습니다.

결과적으로 위와 같은 설계도로 완성이 되었네요!

유저수 > 10000

유저수가 증가함에 따라, 앞서 구축한 아키텍처로 운영하면서 애플리케이션의 처리속도가 느리거나, 처리량에 문제가 있을 경우가 있을텐데요. 이 문제를 해결하기 위해 모니터링이 필요한데, AWS에서 제공하는 모니터링 서비스인 Amazon CloudWatch와 AWS X-Ray를 활용해 분석이 가능합니다.

그리고 유저수가 증가함에 따라 데이터베이스 확장도 고려해야하는데, Amazon Aurora Serverless v2의 확장 기능과 용량에 대해서도 설명하였습니다. 재해복구를 위한 읽기 복제본에 대한 이야기도 있었구요.

AWS RDS Proxy를 사용하여 읽기복제본을 통합하고 보안과 성능을 향상시킬 수 있다는 점에 대해서도 언급하였습니다.

마지막으로 데이터베이스의 쿼리를 자동화하기 위해 Amazon ElastiCache를 사용할 수도 있습니다.

그리하여, 위의 내용을 모두 반영한 설계도가 완성되었습니다.

유저수 > 1000000

사용자가 백만, 천만명이 되면 회사의 규모도 커질텐데 다양한 부서가 생김에 따라 마이크로 서비스를 사용하는 것에 대해 고려가 필요하게 됩니다.

데이터베이스를 기능에 따라 여러 개로 분리하거나, NoSQL 서비스 (Amazon DynamoDB)를 이용해 대량의 데이터를 더 빠르게 처리하고 특수 목적의 데이터베이스로 사용할 수 있습니다.

백엔드의 경우, 애플리케이션을 데이터 패턴에 맞춰 새로운 연합 서비스로 분할하고, 내부 API 기반 서비스를 이용하여 동기식에서 비동기식 요청으로 전환합니다.

기회 비용 전환을 위해 Amazon SNS, Amazon SQS, Amazon Kinesis Data Streams 와 같은 서비스를 이용할 수도 있습니다. 이것도 목적에 따른 치트 시트를 공유해주었습니다.

그렇게 최종적인 설계도가 완성이 되었습니다!

마무리

위 세션 주제를 아마 3년전 AWS Summit 때에도 다루었던 기억이 있는데요. 최근에는 애플리케이션 설계 동향이 AWS Amplify, AWS Fargate와 같은 서버리스 서비스를 중심으로한 구축으로 변화하고 있다는 것에 놀랐습니다.

또한, AWS DevOps Professional 시험에 출제되었던 서비스들이 대거 나와서 시험 내용을 복습할 수 있는 기회가 되어 좋았습니다. 특히 개발자들이 애플리케이션 개발에 집중할 수 있도록 자체적으로 관리해주는 서비스를 위주로 사용하는 설계로 변화했다는 것은 AWS 서비스들도 그만큼 발전했다는 것을 증명하는 것 같아 기술의 변화는 정말 빠르다는 것을 느꼈습니다.