한 회사에서 애플리케이션을 AWS로 마이그레이션했습니다. 이 앱은 Application Load Balancer(ALB) 뒤에 있는 두 개의 EC2 인스턴스에서 실행됩니다. MySQL 데이터베이스는 별도의 EC2 인스턴스에서 실행되며 읽기 작업이 많습니다. 각 EC2 인스턴스는 자주 업데이트되는 정적 콘텐츠를 연결된 Amazon EBS 볼륨에 저장하며, 정적 콘텐츠는 업데이트될 때마다 각 EBS 볼륨에 복사되어야 합니다. 로드는 하루 종일 변동하며, 피크 시간 동안 애플리케이션이 모든 요청을 처리할 수 없습니다. 추적 결과 데이터베이스가 피크 읽기 트래픽을 처리할 수 없는 것으로 나타났습니다. 애플리케이션의 안정성을 높일 수 있는 솔루션은 무엇입니까?

정답은 애플리케이션을 컨테이너화하고 AWS Fargate를 사용하여 Amazon ECS 클러스터에서 실행하며, 정적 콘텐츠를 위해 Amazon EFS를 사용하고, AWS Application Auto Scaling을 구성하며, 데이터베이스를 Amazon Aurora MySQL Serverless v2로 마이그레이션하는 것입니다. ECS와 Fargate는 애플리케이션의 유연한 확장을 가능하게 하여 피크 로드를 처리합니다. EFS는 모든 컨테이너가 동일한 정적 콘텐츠에 액세스하고 업데이트를 쉽게 공유할 수 있도록 합니다. Aurora MySQL Serverless v2는 읽기 복제본을 통해 읽기 집약적인 워크로드에 대한 데이터베이스 확장성을 제공합니다. 오답 1은 Lambda를 사용하지만, EBS 볼륨은 Lambda 함수와 직접 마운트하여 공유하기 어렵고, 정적 콘텐츠 공유에 적합하지 않습니다. 오답 2는 Step Functions를 사용하는데, 이는 웹 애플리케이션의 백엔드 처리에는 적합하지만, 웹 서버 역할을 직접 수행하기 어렵습니다. 또한 Aurora Serverless v2는 리더 인스턴스가 필요합니다. 오답 3은 ECS와 Fargate를 사용하지만, 정적 콘텐츠를 위해 단일 EBS 볼륨을 사용하는 것은 여러 ECS 태스크 간에 공유하기 어렵고, 콘텐츠 업데이트 시 복사 문제를 해결하지 못합니다.