AWS에서의 확장성 - Scale

클라우드 컴퓨팅(AWS) 환경에서 애플리케이션을 운영할 때 '확장성'은 성공의 핵심 요소입니다. 트래픽이 급증할 때 원활하게 대응하고,
트래픽이 없을 땐 비용을 절감하는 능력은 중요하죠.
AWS는 이러한 확장성을 지원하기 위해 크게
두 가지 방식[수직적 확장, 수평적 확장]을 제공합니다.

이번 글에서는 Scale-Up/Down[수직적], Scale-Out/In[수평적]의 개념을 명확히 알아보고, 각각 어떤 상황에 무엇을 사용해야 하는지 살펴보겠습니다.

---

⬆️⬇️ 수직적 확장: Scale-Up & Scale-Down

수직적 확장 = 단일 서버(인스턴스) 자체의 성능을 높이거나 낮추는 방식입니다.

• Scale-Up: 기존 서버의 사양(CPU, RAM, 스토리지 증)을 더 높은 것으로 변경하여 성능을 향상시킵니다.
• Scale-Down: 기존 서버의 사양을 더 낮은 것으로 변경하여 비용을 절감합니다.

특징 및 차이점

• 단일 서버: 확장의 대상이 서버 한 대에 국한됩니다.
• 성능 한계: 한 서버가 가질 수 있는 물리적인 리소스에는 한계가 존재합니다. AWS가 제공하는 가장 큰 인스턴스 타입 이상으로는 Up이 불가능합니다.
• 다운타임 발생: 대부분의 경우, 인스턴스 타입을 변경하려면 서버를 중지하고 재시작해야 합니다. 이때, 일시적으로 서비스 중단이 발생하게 됩니다. [중요]

언제 사용할까?

• Scale-Up은 애플리케이션의 구조를 변경하기 어렵거나, 단일 서버 내에서 높은 컴퓨팅 파워나 메모리가 필수적인 경우에 주로 사용합니다.
  Ex) t3.medium에서 r6g.large로 Scale-Up

• Scale-Down은 트래픽이 평소 수준으로 돌아왔을 때, 불필요하게 높은 사양의 인스턴스를 다시 낮은 사양으로 변경하여 비용을 최적화하는 경우에 적용됩니다.

---

↔️ 수평적 확장: Scale-Out & Scale-In

수평적 확장 = 서버(인스턴스)의 개수를 늘리거나 줄여서 전체 시스템의 처리 용량을 조절하는 방식

• Scale-Out: 기존 서버들과 동일한 사양의 서버를 여러 대 추가하여 워크로드를 분산시킵니다.
• Scale-In: 운영 중인 서버의 개수를 줄여 리소스를 회수하고 비용을 절감합니다.

특징 및 차이점

• 여러 서버: 여러 대의 서버가 하나의 클러스터처럼 동작합니다.
• 유연성 및 고가용성: 트래픽 변화에 따라 서버 수를 유연하게 조절할 수 있습니다.
• 무중단 확장: 수직적 확장과 달리 일반적으로 로드 밸런서 뒤에서 인스턴스가 추가되거나 제거되므로 서비스 중단 없이 확장이 가능합니다.
• 이론상 무한한 확장: 이론적으로는 인스턴스를 거의 무한대로 추가하여 확장할 수 있습니다.
• 분산 처리 설계 필요: 애플리케이션이 여러 서버에서 동시에 실행될 수 있도록 분산처리를 고려하여 설계해야합니다.

언제 사용할까?

• Scale-Out은 예측 불가능한 트래픽 변동에 대응하고, 대규모 사용자 요청을 처리하며, 높은 수준의 서비스 안정성이 요구될 때 필수적입니다.

• Ex) 웹 애플리케이션 서버: 쇼핑몰의 블랙 프라이데이 세일이나 콘서트 티켓 예매 사이트처럼 갑작스러운 트래핏 폭증이 예상될 때, AWS Auto Scaling Group을 사용해 Scale-Out을 자동화합니다. CPU 사용율이 70%를 넘으면 새 EC2 인스턴스를 자동으로 추가하고, 30% 아래로 떨어지면 기존 인스턴스를 제거(Scale-In)하도록 설정할 수 있습니다. 이 요청들은 ELB가 새로 추가된 인스턴스들에게 자동으로 분배해줍니다.

비교 정리

1. 수직적 확장(Vertical Scaling)

• 단일 서버의 성능(CPU, RAM)을 변경
• Scale-Up (사양 ↑), Scale-Down (사양 ↓)
• 서비스 중단 = 다운타임 발생 가능
• 인스턴스 타입 변경

2. 수평적 확장(Horizontal Scaling)

• 처리할 서버의 개수 변경
• Scale-Out (개수 ↑), Scale-In (개수 ↓)
• 분산 처리 설계 필요
• Auto Scaling Group, ELB, ECS, EKS

현대적인 클라우드 네이티브 애플리케이션은 대부분 두 가지 방식을 혼합한다고 합니다. 예를 들어, 충분히 강력한 사양의 인스턴스 타입을 기본으로 선택하고, 이를 Auto Scaling Group으로 묶어 트래픽에 따라 여러 대를 운영하는 하이브리드 전략이 가장 이상적이라고 합니다.

결론적으로, AWS에서 제공하는 다양한 확장성 옵션을 잘 이해하고, 애플리케이션에 맞는 최적의 전략을 수립하는 것이 가장 안정적이고 비용 효율적인 서비스를 만드는 것이라고 생각합니다!

오늘도 하고픈걸 향해 떠나는 zooy였습니다.
감사합니다 :)