[DevOps] Scale-Up과 Scale-Out

Scale-Up과 Scale-Out

1. 서론

본 포스트는 서버 업그레이드 기법인 Scale-Up과 Scale-Out에 대해 정리하였다.
서비스의 운영과정에서 경제적, 기술적인 이유로 서버의 규모를 변경해야하는 상황이 생기는데, 이때 서버 규모를 확장하는 방법에 따라 장단점이 있기 때문에 이에 대해 정확히 알고있어야 한다.

2. Scale-Up

Scale-Up은 간단히 말해 개별 서버의 사양을 보다 높은 사양으로 업그레이드 하는 것을 말한다. 예를 들어 컴퓨팅 성능이나 스토리지의 용량 증대를 이유로 서버에 스토리지를 추가하거나 CPU, 메모리 등의 하드웨어적인 측면의 업그레이드이다 (만약 하이퍼바이저를 통해 가상화된 서버라면 자원의 할당량을 증가시키는 것이다.) 추가적인 네트워크 구성 없이 성능 증강이 가능하고, 업그레이드에 따른 추가적인 관리 비용이나 운영이슈가 낮으며 서비스 구조 설계 자체가 비교적 쉽다.

하지만 서버자체의 성능을 하드웨어적인 측면에서 업그레이드 하는 방식이기 때문에 물리서버의 경우 즉각적이고 유동적으로 서버 규모를 조절하기 어렵고, 성능을 증가시키는 방법이기 때문에 성능확장에 한계가 있고 비용 증가폭도 크다는 문제점이 있다. 서버의 물리적 성능은 고정적이기 때문에 활용되지 못하는 불필요한 자원이 있을 수 있고, 서버의 성능이 증가하였더라도 한 서버에 대한 부하는 여전히 집중적이기 때문에 장애 발생시 전면 장애가 발생할 수도 있다는 문제점도 있다. 

이러한 Scale-Up은 서버 자체의 성능을 높여 업그레이드하는 방법이기 때문에 Vertical Scaling(수직적 스케일링)이라고 한다.

3. Scale-Out

Scale-Out은 Scale-Up과 달리 개별 서버의 사양을 높히지 않고 서버의 개수를 추가하여 업그레이드 하는 방식을 말한다. 개별 서버의 성능은 기존과 동일하지만, 여러 대의 서버를 로드밸런서를 통해 여러대의 서버로 서비스의 처리 부하를 분산시켜 성능 향상을 이끌어 낼 수 있다. 
하나의 장비에서 처리하던 부하를 여러 장비로 나누어 처리하여 성능을 업그레이드 하는 방식이기 때문에 서버의 개수를 조절하여 즉각적이고 유동적인 서버 규모 조절이 가능하고, 이론상 성능은 처리 서버의 개수와 비례하므로 지속적인 확장도 가능하다. 그로인해 활용되지 못하는 불필요한 자원이 적은 편이며 그때그때 필요한 만큼의 서버를 추가해 용량과 성능확장을 장기적인 용량 증가 추이의 예측 없이 서버 규모를 조절할 수 있다.  그리고 비교적 저렴한 서버들을 이용하여 서버규모를 조절할 수 있기 때문에 비용적인 부담도 적은 편이다. 또한 부하자체가 여러 대의 서버로 분산되어있기 때문에 한 서버에 장애가 발생하였더라도 다른 서버들을 통해 해당 서버의 부하를 처리할 수 있으므로 전면 장애의 가능성이 낮다.

하지만 Scale-Out을 이용하려면 여러대의 서버들이 연결되어 서비스 부하를 병렬로 분산하고 이를 처리하는 서비스 구조에 대해 높은 이해도가 필요하다. 그리고 서버의 개수가 증가한다는 것은 문제 발생의 잠재 원인 또한 늘어난다는 것이기 때문에 관리의 난이도가 올라가고, 여러 서버에 부하를 균등하게 분산시켜야하기 때문에 적절히 로드 밸런싱을 해줄 수 있는 로드밸런서가 필요하다.

이러한 Scale-Out은 서버를 추가하는 방식으로 성능을 확장하기 때문에 Horizontal Scaling(수평적 스케일링)이라고 한다.

Scale-Out이 설계 및 운영 난이도가 Scale-Up에 비해 높은 편이다. 하지만 이를 통한 경제적, 기술적 효율이 높기 때문에 서비스 종류에 따라 차이는 있어도 대부분의 서비스가 Scale-Up에서 Scale-Out으로 넘어가는 추세이긴하다. 그리고 꼭 무조건 Scale-Up과 Scale-Out 중 하나를 택하여 업그레이드 하는 것보단 상황에 맞춰 적절히 Scale-Up과 Scale-Out을 같이 사용한다면 훨씬 효율적인 서비스 구조가 만들어 질 수 있다.