Scale Out과 Scale Up
서버 확장을 위한 방법에는 크게 두가지가 있는데 바로 Scale out과 Scale up이 그것이다. 한 대의 서버에서 감당할 수 있는 부하를 감당할 수 있도록 하는 것이 두 방법의 공통된 목표이다. 한 사람에게 주어지는 일이 많아서 감당이 안되면 이에 대한 대책으로 두 가지를 생각할 수 있다.
- 일을 하는 사람을 여럿으로 늘리는 것(Scale Out)
- 일을 더 잘하는 사람으로 교체하는 것(Scale Up)
이 바로 그것이다.
기존의 서버가 1GHz CPU, 2GB 메모리였다면,
- 스케일 아웃은 1GHz CPU, 2GB 메모리를 가진 서버를 한 대 더 붙이는 방법
- 스케일 업은 기존의 서버를 2GHz CPU, 4GB 메모리로 업그레이드하는 것
(수치가 2배인 것은 예시일뿐 꼭 2배일 필요는 없다)
당연하게도 두가지 방법 모두 장단점이 있기 때문에 목적에 따라 적합한 방법을 사용한다. 베이스캠프 Sprint에서는 스케일 아웃 방법을 선택했다. (고가용성의 목적도 충족하기 위해서) 아래는 내가 나름대로 정리한 각 방법의 특징 및 장단점이다. 위에 사람에 비유한 것을 떠올리면 쉽게 이해가 되었다. 비슷한 능력의 사람을 여럿 고용할 때와 뛰어난 능력의 사람을 한 명 고용할 때의 상황과 비슷하다고 느껴졌다.
Scale Out | Scale Up | |
---|---|---|
확장성 | - 수평 확장 - 지속적 확장이 가능하다(1대->2대->10대->…) |
- 수직 확장 - 성능 확장에 한계가 있다.(물리 장비의 기술적 한계가 있다.) |
장애 발생 시 | - 서버 하나가 죽어도 서비스 장애는 일어나지 않음 - 고가용성 |
- SPOF(Single Point of Failure) - 이 서버가 죽으면 서비스 전체 장애 |
관리 및 운영 | - 생각할게 많아짐 = 어려움 (멀티스레드 환경에서의 어려움을 생각하면 될듯) - 당장 로드밸런서부터 필요 - 메모리를 공유하지 않기 때문에 공유 스토리지가 필요 ex) Redis 등 |
- 확장에 따른 추가 관리 및 운영 필요 없음 |
활용 | 웹 서버 확장, 분산처리 시스템 | DB 서버 |
Leave a comment