🤔 문제
어떤 웹사이트에서는 사용자들이 매일 정오에 새로운 사진과 콘텐츠를 업로드하면서 트래픽이 급증하는 커스텀 웹 애플리케이션을 운영하고 있습니다. 그러나 사용자가 시간 초과 문제를 자주 겪고 있습니다. 현재 아키텍처는 Amazon EC2 Auto Scaling 그룹을 사용하고 있으며, 애플리케이션은 부팅 후 사용자 요청에 응답하기까지 항상 1분이 걸립니다.
해당 아키텍처를 트래픽 변화에 더 잘 대응하도록 재설계하려면 솔루션 아키텍트는 어떻게 해야 하나요?
- Network Load Balancer를 느린 시작 구성(slow start configuration)으로 설정합니다.
- Amazon ElastiCache for Redis를 구성하여 EC2 인스턴스에서 직접 요청을 오프로드합니다.
- EC2 인스턴스 warm-up 조건이 포함된 Auto Scaling 단계적 스케일링 정책(step scaling policy)을 구성합니다.
- Amazon CloudFront가 Application Load Balancer를 Origin으로 사용하도록 구성합니다.
정답
정답. 3번
EC2 인스턴스 warm-up 조건이 포함된 Auto Scaling 단계적 스케일링 정책(step scaling policy)을 구성합니다.
[현재 문제]
현재 문제의 구성에서는 새로운 EC2 인스턴스가 트랜잭션에 응답할 수 있기 전에 서비스에 투입되고 있다.
이는 인스턴스가 과도하게 확장하는 Overscale을 야기할 수 도 있다.
[Step Scaling Policy]
단계적 스케일링 정책(step scaling policy)을 사용하면 새로 시작된 인스턴스가 준비(warm-up)되기까지 걸리는 시간을 초 단위로 지정할 수 있다.
지정된 준비(warm-up) 시간이 만료될 때까지 해당 EC2 인스턴스는 Auto Scaling Group의 집계된 메트릭에 포함되지 않는다.
확장 중(scaling out)일 때 Auto Scaling 로직은 준비 중(warm-up)인 EC2 인스턴스를 Auto Scaling Group의 Capacity에 포함시키지 않는다. 따라서 동일한 단계 조정 범위 내에서 발생하는 여러 알람 위반은 하나의 확장 활동으로 이어진다. 이를 통해 필요한 이상의 인스턴스 추가를 방지할 수 있다.
오답
[Slow Start Configuration]
Slow Start Configuration(느린 시작 구성)은 새로운 인스턴스가 부하가 걸리기 전에 천천히 트래픽을 수신하게 만드는 기능이다.
이 방식은 서버가 처음부터 갑자기 모든 트래픽을 받는 것을 방지하고, 서버가 정상적으로 작동할 수 있도록 점진적으로 트래픽을 분배한다.
일반적으로 Slow Start Configuration을 사용하면 새로운 인스턴스나 컨테이너가 가동된 후, 서서히 트래픽을 받아들이면서 적응할 수 있도록 도와준다.
이렇게 하면 갑작스러운 트래픽으로 인해 인스턴스가 오버로드되어 응답이 지연되거나 실패하는 상황을 피할 수 있다.
ALB와 NLB에서 사용 가능 하다.
