Scale-Up vs Scale-Out, 사용자가 증가할 때 서버를 확장하는 두 가지 방법

Notice

Recent Posts

Recent Comments

Link

« 2024/10 »
일	월	화	수	목	금	토
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

Tags more

Archives

Today

Total

관리 메뉴

아리아 날다

Scale-Up vs Scale-Out, 사용자가 증가할 때 서버를 확장하는 두 가지 방법 본문

Server

Scale-Up vs Scale-Out, 사용자가 증가할 때 서버를 확장하는 두 가지 방법

Aria Park 2022. 9. 16. 01:05

온라인 서비스 서버 확장

현재 온라인으로 플리마켓을 구현해보는 프로젝트를 진행하고 있습니다. 오프라인 플리마켓은 정해진 시간에 한정적인 제품을 저렴한 가격에 판매하기 때문에 동시간에 수많은 구매자가 몰려 대기하고, 입장이 늦어지면 원하는 제품을 구매할 수 없다는 단점이 있는데요. 이번 프로젝트는 그런 오프라인 플리마켓의 단점을 보완하고자 진행하게 되었습니다.

이번 프로젝트를 포함해 무신사, 지그재그, 에이블리 등과 같은 온라인 패션플랫폼은 앞으로도 사용자가 계속해서 증가할 것으로 전망하고 있습니다. 그렇다면 과연 사용자가 늘어남과 동시에 생기는 트래픽 문제를 서버는 어떻게 감당하는 걸까요?

서버를 확장하는 방법, Scale-Up & Scale-Out

블랙 프라이데이같은 할인 시즌에 수많은 사용자의 트래픽을 서버가 처리하기 위해선 어떻게 해야할까요? 간단하게 더 좋은 성능의 서버로 업그레이 하거나, 서버를 여러대 설치해 나눠서 처리하면 해결할 수 있을 것 같은데요. 상황에 따라서 두 방법 중 한가지 방법을 선택해서 해결 할 수 있습니다. 여기서 서버를 업그레이드 하는 방법을 Scale-Up이라고 하고, 서버를 여러대 설치하는 방법을 Scale-Out이라고 합니다.

Scale-Up:

현재 사용 중인 서버의 성능을 업그레이드해서 처리 능력을 향상시키는 방법

Scale-Up의 장점

단순히 서버의 장비를 추가 또는 교체하는 작업이라 구축 및 설계가 간단합니다.
별도의 컨트롤러나 네트워크 인프라 비용이 발생하지 않습니다.
여러대의 서버를 관리하지 않아도 되기 때문에 데이터 정합성 문제에 자유롭습니다.

* 데이터 정합성: 어떤 데이터들의 값이 서로 일치하는 상태

"서버가 업그레이드 되면 무조건 좋은 거 아닌가? 서버 확장이 필요하면 Scale-Up으로 처리하면 되겠네!"

하지만 서버 성능을 향상시키는 것은 제한적이고, 그 외에도 여러 단점이 존재합니다.

Scale-Up의 단점

하나의 서버에 추가할 수 있는 부품의 개수가 제한적입니다.
한정된 자원을 초과하여 성능을 향상시키기 위해서는 서버 자체를 변경하는 작업이 필요합니다.
하나의 서버에서 모든 트래픽을 처리해야 하기 때문에 심각할 경우 부하가 걸렸을 때 해당 서버가 복구되기 전까지 서비스를 중단해야 하는 상황에 빠질 수 있습니다.

서비스를 중단하는 상황은 비즈니스에서 최악의 상황으로 이러한 문제를 사전에 대비할 수 있는 또다른 서버 확장 방법이 존재하는데요. 그 방법이 바로 이어서 설명할 Scale-Out 입니다.

Scale-Out:

비슷한 사양의 서버를 추가하여 성능을 증가시키는 방법

Scale-Out의 장점

클라이언트의 요청을 나눠서 처리하기 때문에 하나의 노드에서 장애가 발생하더라도 다른 노드에서 서비스 제공이 가능하고, 시스템의 가용성을 높일 수 있습니다.
필요에 따라 더 많은 서버를 추가하고 감소하는 작업(pay-as-you-grow)이 가능하기 때문에 확장에 유연합니다.
분산 처리가 가능하기 때문에 트래픽이 집중되어 부하가 발생하는 것을 분산할 수 있습니다.

*가용성: 서버와 네트워크, 프로그램 등의 정보 시스템이 정상적으로 사용 가능한 정도

"여러 대로 나눠서 처리하니까 Scale-Up보다 빠르고 고성능으로 서버를 업그레이드할 필요도 없기 때문에 비용 측면에서도 훨씬 유리하니 Scale-Out이 더 좋은 방법 아닐까?"

틀린 말은 아니지만 어느 방식이 더 좋은 방식이고 나쁜 방식인지는 나눌 수 없고 Scale-Out 역시 단점이 존재하기 때문에 이를 잘 고려해서 선택해야 합니다.

Scale-Out의 단점

Scale-Up에 비해 확장에 유연하긴 하지만 Scale-Out역시 무한정 확장은 불가능합니다.
여러 대의 서버를 관리하기 위한 설계와 구현이 복잡해지고 이에 따른 관리 비용이 증가합니다.
서버 각각의 성능과 안정성 측면에서 Scale-Up 방식보다 불리합니다.
여러 대의 서버로 요청을 처리하도록 분산 서버 환경을 만들면 각 서버별로 로그인 세션 정보가 다른 세션 불일치 문제가 발생합니다.

그렇다면 Scale-Out에서 서버에 걸리는 부하 분산 처리는 어떻게 이루어질까요?

로드 밸런싱(Load Balancing)

처리해야할 업무나 요청을 여러대의 서버로 나누어 처리하는 것으로 한대의 서버로 부하가 집중되지 않도록 트래픽을 관리해 각각의 서버가 최적의 효과를 낼 수 있도록 합니다. 로드밸런싱 기술을 제공하는 서비스 또는 장치를 로드 밸런서(Load Balancer)라고 하고 클라이언트와 네트워크 트래픽이 집중되는 서버들 사이에 위치합니다.

로드 밸런싱 알고리즘

라운드 로빈(Round Robin Method): 서버에 들어온 요청을 순서대로 돌아가며 배정하는 방식
가중 라운드 로빈(Weighted Round Robin Method): 서버마다 가중치를 매기고 가중치가 높은 서버에 클라이언트 요청을 우선적으로 배정하는 방식
IP해시방식(IP Hash Method): 클라이언트의 IP주소를 특정 서버로 매핑하여 요청 처리하는 방식
최소 연결 방식(Least Connection Method): 가장 적은 연결 상태를 보이는 서버에 우선적으로 트래픽을 배분하는 방식
최소 리스폰 타임(Least Response Time Method): 서버의 현재 연결 상태와 응답 시간을 모두 고려해 트래픽을 배분하는 방식

비용 측면에서 봤을 때 둘은 어떤 차이가 있을까?

출처: https://www.factioninc.com/blog/hybrid-multi-cloud/scale-up-vs-scale-out-scale-out-nas-meets-multi-cloud/

Scale-Up은 서버 능력 대비 가격이 선형적이지 않고, Scale-Out은 선형적 입니다. 따라서 단기간에 빠르고 정확한 처리가 필요한 OLTP(Online Transaction Processing) 환경에서는 고성능의 Scale-Up 방식이 적합하지만, 병렬 프로그래밍이 필요하고 장기적으로 서비스를 운영해야 하는 웹 서버와 같은 환경에서는 Scale-Out 방식이 비용측면에서 효율적입니다.

Scale-Out 방식을 이용한 온라인 플리마켓 서비스 서버 확장

Q1. 왜 Scale-Out을 선택했나요?

A1. Scale-Out을 선택했을 때 한 대의 서버에만 부하가 발생했을 때 장애가 걸려 시스템이 다운되는 현상을 예방할 수 있습니다. 예약 시스템을 도입할 예정인데 이 때 걸리는 부하 처리를 효율적으로 하기 위해서 Scale-Out을 선택했습니다.

Q2. 예약 시스템이 있다는 건 평소에 트래픽이 없다가 정해진 시간에만 몰린다는 것 아닌가요? 그런 경우에는 Scale-Up으로도 충분히 서버 확장이 가능하지 않나요?

A2. 현재 진행 중인 온라인 플리마켓 프로젝트는 특정 시간에 트래픽이 몰리는 경향이 있지만 판매자가 마켓을 오픈할 수 있는 시간을 분산시켜 꾸준히 많은 사용자가 유입될 수 있도록 구현할 예정입니다. 사용자의 마켓 선호도와 판매자의 마켓 인기도에 따라 특정 시간대에 더 많은 유입이 있을 수는 있지만 결론적으로 서비스 자체는 수 많은 거래 정보를 조회하는 요청을 병렬적으로 처리해야 합니다. 또 온라인 패션 플랫폼 특성상 시스템 가용성을 높이는 것 또한 매우 중요한 문제이므로 Scale-Out이 적합할 것이라는 결론을 내릴 수 있었습니다.

마무리

지금까지 서버를 확장하는 Scale-Up, Scale-Out 방식 각각의 특징과 장단점에 대해서 알아보았습니다. 이번 프로젝트에 어떤 방식을 선택해서 적용할 지에 대한 답은 내렸지만 여전히 "세션 불일치"라는 Scale-Up의 치명적인 단점에 대해서는 고민해 보아야 합니다. 다음 포스트에서는 Scale-Out에서의 데이터 정합성 문제를 해결하기 위해서는 어떠한 방법들이 있는지 알아보도록 하겠습니다.