AWS ECS를 활용한 오토 스케일링을 구현하기에 앞서,
스케일링의 개념과 필요성에 대해 정리한 서론입니다.
백엔드 웹 서버에서 발생하는 대용량 트래픽을 효율적으로 처리하려면 어떻게 해야 할까?
1차적으로 메인 서버의 코드 레벨에서 데이터 캐싱, 쿼리 최적화, 시간 복잡도 최적화 등을 통해
근본적인 서버의 응답속도를 높이는 것이 방법이 될 수 있다.
하지만 아무리 코드 레벨의 최적화가 잘 되어 있다 한들, 다량의 트래픽이 예상치 못하게 발생한다면
서버에 부하가 생길 수 있고, 서버가 다운되는 등 가용성의 문제가 발생할 수 있다.
본 포스팅에서는 이런 트래픽 급증에 대처하기 위한 서버 스케일링에 대해 다룰 예정이다.
✅ 서버 스케일링이란?
스케일링(Scaling)은 서버 시스템의 처리 능력을 증가시키거나 감소시키는 작업을 의미한다.
다시 말해, 트래픽 변화에 대응하여 서버 인프라를 조정하는 것이다.
스케일링 방식에는 스케일 업-다운 , 스케일 인-아웃으로 두 가지 방식이 존재한다.
📌 스케일 업-다운 (Scale Up-Down)
- 스케일 업 (Scale Up) : 기존 인스턴스의 성능(리소스)을 증가시키는 것을 의미한다. CPU, 메모리, 디스크 용량 등을 늘려 한 인스턴스가 더 많은 부하를 처리할 수 있도록 한다.
- 스케일 다운 (Scale Down) : 스케일 업과 반대로 트래픽이 감소할 때 인스턴스의 사양을 낮춰서 비용을 절감하는 것을 의미한다.
스케일 업-다운은 다른말로 수직적 확장(vertical scaling)이라고도 하며, 한 대의 서버 성능을 높이거나 낮추는 방식이다.
이는 단일 서버의 성능을 최적화하는 데 유리하지만 고가용성을 확보하기에는 한계가 있다.
트래픽 증가에 맞춰 스케일 업을 한다고 해도, 결국 단일 인스턴스를 사용하기 때문에 해당 인스턴스에 문제가 생기면 전체 서비스가 중단될 수 있기 때문이다.
📌 스케일 인-아웃 (Scale In-Out)
- 스케일 아웃 (Scale Out) : 시스템의 처리 능력을 높이기 위해 추가 인스턴스(서버)를 추가하는 방식을 의미한다. 트래픽이 증가하게 되면 더 많은 서버를 추가하여 부하를 분산한다.
- 스케일 인 (Scale In) : 시스템의 처리 능력이 과잉일 때, 불필요한 인스턴스를 제거하여 리소스를 절약하는 것을 의미한다. 즉, 트래픽이 감소하면 서버의 수를 줄여 비용을 절감한다.
스케일 인-아웃은 수평적 확장(horizontal scaling)이라고도 한다. 여러 대의 서버를 추가하거나 제거하는 이 방식은 부하 분산에 유리하며 고가용성을 확보하는데 용이하다.
✅ AWS 오토 스케일링
웹 서버에 발생하는 트래픽 증감에 맞춰, 서버 스케일링을 통해 대처할 수 있다는 것을 알아보았다.
하지만 트래픽 발생 상황을 관리자가 항상 모니터링을 하며, 그에 맞게 서버를 수동으로 스케일링 하는 것은
굉장히 피곤하고 귀찮은 일이 될 것이다.
고맙게도 AWS에서는 이러한 수고를 덜 수 있게, 오토 스케일링이란 기능을 제공한다.
AWS 오토 스케일링은 스케일 인-아웃 방식을 지원하며, 트래픽 증감에 맞춰 ECS Fargate(EC2) 인스턴스의 수를 자동으로 조정하여 애플리케이션이 항상 최적의 성능과 비용 효율성을 유지할 수 있도록 해준다.
이 기능을 통해 우리는 웹 서버를 배포함에 있어 대용량 트래픽에 유연하게 대응할 수 있고, 비용 효율적으로 인프라를 운영할 수 있다.
이러한 인프라 구조를 그림으로 간단하게 그려보면 위 그림과 같다.
외부로부터 들어오는 트래픽은 AWS의 로드 밸런서(ELB)를 거치게 되고, 해당 트래픽은 ECS에서 관리되는 Fargate 인스턴스에 분산되게 된다. 그림에서 인스턴스의 갯수는 3개로 그려졌지만, 이는 오토 스케일링에 의해 더 늘어날 수도, 더 줄어들 수도 있다. 즉, 따로 관리가 필요 없는 서버리스(server-less) 인프라라고 할 수 있겠다.
이번 포스팅에선 오토 스케일링의 개념과 필요성에 대해 알아보았으니, 다음 포스팅에선 본격적으로
실제 웹 애플리케이션을 AWS ECS를 통해 배포하고, 오토 스케일링을 적용해볼 예정이다.
'TIL' 카테고리의 다른 글
[Spring][Redis] RedisTemplate을 활용한 캐싱 처리 (0) | 2024.03.29 |
---|---|
[Spring][Redis] Redis 캐싱 기능을 활용한 조회 성능 개선 (CacheManager) (0) | 2024.03.28 |
[Spring][DB] 데이터의 순서 컬럼 정렬 전략 (0) | 2024.03.22 |
JWT의 무상태성 (+쿼리 최적화) (0) | 2024.03.08 |
[Spring] CRUD 기능 구현 중 알게 된 Dto를 사용해야 하는 이유 (0) | 2024.02.26 |