서비스를 운영하다 보면 사용자가 지속적으로 증가함으로 데이터 양이 늘거나 CPU나 메모리 사용량이 늘어 하나의 서버로는 감당이 안되는 경우가 존재합니다. 이런 경우 서버 확장을 해야 합니다.
오늘은 서버 확장 방법인 Scale-Up(스케일업)과 Scale-out(스케일아웃) 에 대해서 살펴보도록 하겠습니다.
Scale-up (스케일업)
기존 시스템에 CPU, 메모리, 디스크와 같은 내부 컴포넌트 용량을 키우거나 , 이것이 불가능할 경우 새로 더 큰 용량의 시스템을 구매해 서비스를 옮기는 방법을 말합니다. 즉, 하드웨어 적인 부분을 교체 또는 새로 구매하는 것을 말합니다.
이는 부품을 쉽게 추가할 수 있으면 시스템 설계 변경 없이 서비스 사용량을 쉽게 늘릴 수 있다는 장점이 있습니다.
하지만, 스케일 업을 하기 위해서는 애초에 CPU를 여러 개 꽂을 수 있고, 메모리 뱅크를 많이 가진 보드를 보유하고 있어야 합니다. 즉, 하드웨어 허용 범위내에서만 스케일 업이 가능하다는 이야기입니다. 기존에 가지고 있던 하드웨어의 범위를 넘어섰을 경우엔 새로운 장비로 교체하는 방법밖에 없습니다. (그만큼 비용이 발생 및 기존 장비 비용 낭비)
또한, 스케일 업은 일정 수준을 넘어가면 비용 대비 성능의 증가폭이 떨어집니다.
다른 문제점으로는 서버가 한 대로 관리가 되니, 서버에 장애가 발생했을 경우 장애를 해결할 때까지 서비스를 중지할 수 밖에 없습니다. 그만큼 서비스를 하지 못하는 상황이니 손실이 있겠죠?
정리하자면 다음과 같습니다.
장점
1. 시스템 변경 없이 서비스 사용량을 쉽게 늘릴 수 있습니다.
- 기존 시스템에 추가 CPU를 장착할 공간 또는 매모리를 장착할 여유가 된다면 추가만 하면 됩니다. 시스템 변경 또는 설계를 할 필요가 없습니다.
2. 데이터의 일관성 보장
- 하나의 서버로 관리되기 때문에 데이터 정합성 문제가 발생하지 않습니다.
단점
1. 비용 대비 성능 효과가 낮습니다.
- 일정 시점에 도달하면 투자하는 비용 대비 성능 향상이 미미합니다.
2. 서버 장애 시 손실비용이 큽니다.
- 하나의 서버로 관리하니 서버 장애 발생 시 복구까지 서비스 중지가 될 것이며, 그대로 손실로 이어지게 됩니다.
3. 하드웨어의 허용 범위 내에서만 확장이 가능합니다.
그럼 스케일 업은 언제 사용할까요?
- 한 대의 서버에서 모든 데이터를 처리하므로 데이터 갱신이 빈번하게 일어나는 ‘데이터베이스 서버’에 적합한 방식입니다.
이러한 스케일 업의 문제들로 인해 가능하면 스케일 아웃을 사용하여 시스템의 용량을 높입니다.
Scale-out (스케일 아웃)
스케일 업은 하나의 서버의 하드웨어적인 용량을 키우지만, 스케일 아웃은 동일한 용량의 서버를 여러 대 배치하는 것 입니다. 만약 사용자 백 명의 요청을 처리하는 서버가 한 대 구동된다면 5백 명의 요청을 처리하기 위해서 5대의 서버를 병렬로 운영하는 방법입니다.
스케일 아웃 방식은 서버 한 대가 장애로 다운되더라도 다른 서버로 서비스 제공이 가능하며, 하드웨어 적인 용량에 제한되지 않기 때문에 확장이 무제한으로 가능합니다.
하지만, 스케일 아웃을 구성하고 유지하려면 별도의 복잡한 아키텍처의 이해가 필요합니다. 여러 서버에 균등하게 분산시키기 위해 로드 밸런싱(load balancing)이 필요하고, 이는 서버를 확장할수록 문제 발생의 잠재 원인 또한 추가한 만큼 늘어나게 됩니다.
또한 여러 대의 서버를 사용함으로써 데이터 정합성 이슈가 발생할 수 있습니다. 이로 인해 모든 서버에서 데이터 일관성을 유지하게 하기 위한 설계 및 관리가 복잡해집니다.
💡 로드밸런서 : 부하분산. 한 대의 서버로 부하가 집중되지 않도록 트래픽을 관리하는 장치. 이로써 가용성 및 응답시간을 최적화 시킬 수 있다.
정리하자면 다음과 같습니다.
장점
1. 하나의 서버에 장애가 발생하더라도 서비스를 운용하는데 크게 영향을 미치지 않습니다.
- 하나의 서버에 장애가 발생하여도 다른 서버로 서비스를 제공하면 되기 때문에 서비스가 전면중지될 가능성이 낮습니다.
2. 하드웨어 적인 제한이 없기에 확장이 무제한으로 가능합니다.
- 하나의 서버에 장애가 발생하여도 다른 서버로 서비스를 제공하면 되기 때문에 서비스가 전면중지될 가능성이 낮습니다.
단점
1. 시스템 설계 및 운영을 담당하는 엔지니어가 분산처리를 위한 아키텍처에 대한 이해도가 필요하며, 프로세스 및 네트워크 장비가 추가적으로 발생할 수 있습니다.
- 로드밸런서 등에 대한 이해가 필요합니다.
2. 데이터 정합성 이슈가 발생합니다.
- 서버가 여러대로 나누어지기 때문에 데이터 불일치 현상이 발생할 수 있습니다. 이로인해 데이터 일관성을 위한 방법을 모색해야 합니다.
언제 사용할까요?
- 네트워크 서버 설계 및 소프트 웨어 변경 비용이 더 클 수 있기 때문에 모든 서비스에 적합한 방식은 아니고 클라우드 환경 및 대규모 서비스 환경에서 권장되는 방법입니다.
References
* IT 엔지니어를 위한 네트워크 입문 책
'기타' 카테고리의 다른 글
| [CI/CD] CI/CD란? - 지속적 통합/지속적 배포 (0) | 2021.12.28 |
|---|---|
| 다중 서버에서의 Session 불일치 현상과 해결 방법 (0) | 2021.11.07 |
| 면접 질문 정리 (1) (0) | 2021.10.13 |
| [8주차] 멘토링 키워드 (0) | 2021.10.06 |
| [7주차] 멘토링 키워드 (0) | 2021.09.29 |
댓글