수직 확장 (Vertical Scaling) vs 수평 확장 (Horizontal Scaling)
1. 수직 확장 (Vertical Scaling)
정의
기존 서버의 성능을 업그레이드하거나 리소스를 추가하여 처리 능력을 향상시키는 방식입니다. 이를 통해 단일 서버의 하드웨어 성능을 개선하여 더 많은 요청을 처리할 수 있습니다.
특징
- 단일 서버 기반: 한 대의 서버에서만 성능이 개선되며, 서버가 다운되면 시스템 전체가 중단될 수 있습니다.
- 즉각적인 성능 개선: 하드웨어 업그레이드가 완료되면 즉시 성능 향상을 체감할 수 있습니다.
장점
- 관리 용이성: 시스템 구조가 단순하므로 관리와 운영이 간단합니다.
- 애플리케이션 변경 불필요: 대부분의 경우 기존 애플리케이션 코드를 수정하지 않아도 성능이 개선됩니다.
- 빠른 구현: 하드웨어 업그레이드로 바로 적용 가능하여 시간 소모가 적습니다.
단점
- 확장의 물리적 한계: 서버의 최대 용량에 도달하면 더 이상 업그레이드가 불가능합니다.
- 단일 장애점: 단일 서버에 의존하므로, 서버 장애 시 전체 시스템이 중단될 위험이 있습니다.
- 비용 문제: 고성능 하드웨어는 비용이 크게 증가하며, 장기적으로 비효율적일 수 있습니다.
예시)
- t2.medium 인스턴스를 t2.large로 업그레이드
- 물리적 서버에 RAM, CPU 코어 또는 디스크 용량 추가
2. 수평 확장 (Horizontal Scaling)
정의
여러 대의 서버를 추가하여 시스템의 처리 능력을 향상시키는 방식입니다. 각 서버는 동일한 역할을 수행하며, 로드 밸런싱을 통해 트래픽을 분산 처리합니다.
특징
- 분산 아키텍처: 여러 대의 서버가 협력하여 작업을 처리하며, 특정 서버에 장애가 발생해도 시스템이 가용성을 유지할 수 있습니다.
- 확장성: 필요에 따라 서버 수를 유동적으로 조정 가능하며, 클라우드 환경에서 특히 유용합니다.
장점
- 무한 확장 가능: 이론적으로 더 많은 서버를 추가하여 성능을 계속 확장할 수 있습니다.
- 높은 가용성: 장애 허용 설계를 통해 일부 서버에 문제가 생겨도 서비스가 중단되지 않습니다.
- 비용 효율성: 서버를 추가적으로 늘리는 방식이므로 초기 비용이 적으며, 필요에 따라 점진적으로 확장 가능합니다.
단점
- 운영 복잡성: 여러 대의 서버를 관리하고 모니터링하는 데 추가적인 노력이 필요합니다.
- 데이터 일관성 문제: 분산 환경에서는 데이터 동기화를 보장하기 위한 추가 설계가 필요합니다.
- 네트워크 의존성 증가: 서버 간 통신량이 늘어나 네트워크 병목 현상이 발생할 수 있습니다.
예시)
- Auto Scaling 그룹을 통해 t2.micro 서버를 추가 배포
- Kubernetes로 클러스터를 확장하여 트래픽 분산
- AWS Lambda와 같은 서버리스 아키텍처 활용
3. 수직 확장 / 수평 확장 비교
| 방식 | 설명 | 적용 상황 | 한계점 |
|---|---|---|---|
| 수직 | 서버 성능 up | 소규모 트래픽이나 간단한 애플리케이션에 적합 | 성능 향상에 물리적 한계가 있음 |
| 수평 | 서버 수량 up | 대규모 트래픽 처리, 가용성과 확장성이 중요한 경우 | 데이터 동기화나 로드 밸런싱 등 추가적인 설계 필요 |
추가 비교
-
확장 속도:
- 수직 확장: 하드웨어 업그레이드가 완료되면 바로 적용 가능
- 수평 확장: 서버를 추가하고 네트워크 구성 및 로드 밸런싱 설정까지 시간이 소요될 수 있음
-
비용:
- 수직 확장: 고성능 하드웨어는 초기 비용이 크고, 업그레이드 한계에 도달하면 비효율적
- 수평 확장: 클라우드 기반에서는 Pay-as-you-go 모델로 비용을 효율적으로 관리 가능
-
가용성:
- 수직 확장: 단일 장애점(Single Point of Failure)으로 인해 높은 위험
- 수평 확장: 서버 분산으로 장애 허용(Fault Tolerance)이 우수
₍ ᐢ. ̫ .ᐢ ₎