Scale Out과 Scale Up

서버 확장을 위한 방법에는 크게 두가지가 있는데 바로 Scale out과 Scale up이 그것이다. 한 대의 서버에서 감당할 수 있는 부하를 감당할 수 있도록 하는 것이 두 방법의 공통된 목표이다. 한 사람에게 주어지는 일이 많아서 감당이 안되면 이에 대한 대책으로 두 가지를 생각할 수 있다.

  • 일을 하는 사람을 여럿으로 늘리는 것(Scale Out)
  • 일을 더 잘하는 사람으로 교체하는 것(Scale Up)

이 바로 그것이다.

기존의 서버가 1GHz CPU, 2GB 메모리였다면,

  • 스케일 아웃은 1GHz CPU, 2GB 메모리를 가진 서버를 한 대 더 붙이는 방법
  • 스케일 업은 기존의 서버를 2GHz CPU, 4GB 메모리로 업그레이드하는 것

(수치가 2배인 것은 예시일뿐 꼭 2배일 필요는 없다)

Scale up 과 Scale out 적용을 잘못 사용한 사례 : 스마일서브 공식 블로그 [ IDC HOWTO ]

당연하게도 두가지 방법 모두 장단점이 있기 때문에 목적에 따라 적합한 방법을 사용한다. 베이스캠프 Sprint에서는 스케일 아웃 방법을 선택했다. (고가용성의 목적도 충족하기 위해서) 아래는 내가 나름대로 정리한 각 방법의 특징 및 장단점이다. 위에 사람에 비유한 것을 떠올리면 쉽게 이해가 되었다. 비슷한 능력의 사람을 여럿 고용할 때와 뛰어난 능력의 사람을 한 명 고용할 때의 상황과 비슷하다고 느껴졌다.

  Scale Out Scale Up
확장성 - 수평 확장
- 지속적 확장이 가능하다(1대->2대->10대->…)
- 수직 확장
- 성능 확장에 한계가 있다.(물리 장비의 기술적 한계가 있다.)
장애 발생 시 - 서버 하나가 죽어도 서비스 장애는 일어나지 않음
- 고가용성
- SPOF(Single Point of Failure)
- 이 서버가 죽으면 서비스 전체 장애
관리 및 운영 - 생각할게 많아짐 = 어려움 (멀티스레드 환경에서의 어려움을 생각하면 될듯)
- 당장 로드밸런서부터 필요
- 메모리를 공유하지 않기 때문에 공유 스토리지가 필요 ex) Redis 등
- 확장에 따른 추가 관리 및 운영 필요 없음
활용 웹 서버 확장, 분산처리 시스템 DB 서버

References

Leave a comment