사용자가 늘어나게 된다면 서버를 어떻게 확장해야할까?

3 minute read

현재 사용자가 설정한 지역을 기반으로 이벤트 추천 서비스 프로젝트를 진행 중 입니다.
로그인 기능을 개발하는 중에 깊게 고민해서 풀어봐야 할 문제 상황이 발생을 했습니다. 우리 서비스를 이용하도록 유도하기 위해 홍보나 마케팅을 수단을 활용하여 시간이 지나 수 많은 사용자가 우리 서비스를 이용 한다고 가정했을 때, 과연 서버가 감당을 할 수 있을까? 하는 문제점이었습니다.

이렇게 사용자가 점점 늘어남에 따라 트래픽이 몰리게 된다면 서버를 어떤 식으로 확장 해야할까요?

서버를 늘리자! Scale-up VS Scale-out

대용량 트래픽에서도 견고할려면 우선, 서버의 크기를 늘려야 합니다. 서버의 크기를 늘리는 방법은 Scale-up 과 Scale-out 이 존재합니다.

Scale-up 이란?

scaleup

수직적 확장을 의미하며 추가적인 RAM, CPU 등을 컴퓨터에 달아 업그레이드 하는 방식입니다. 우선 내가 사용하는 기기에 부품을 달기만 하면 끝나기 때문에 업그레이드가 상대적으로 쉽고 라이센스 비용 또한 아낄 수 있는 장점이 있습니다.

하지만 각 컴퓨터마다 추가적인 부품을 달 수 있는 슬롯이 제한적이고, 장비가 업그레이드 될 때 마다 매번 갈아서 끼울 수 없어 지속적인 확장이 불가능 합니다. (그렇게 할려면 우선 비용적인 지출이 매우 클 수 밖에 없습니다)

해결책으로는 새로운 기기를 사용하는 방법인데, 서로 다른 독립적인 기기로 데이터를 옮기기 위해 기존의 데이터를 백업 시킨 후, 데이터 migration을 매번 하는 것은 매우 시간이 오래걸리고 복잡한 작업이라고 합니다. 더욱이 데이터가 방대해지면서 이 해결책은 무용지물이 되었습니다.

또한 하나의 서버를 확장했기 때문에 대용량 트래픽이 몰려 서버가 다운이 되어버리면 전면적인 장애로 이어져 큰 타격을 볼 수 밖에 없습니다.

MySQL 이라는 RDBMS를 우리 프로젝트에 사용을 하고 있는데 RDBMS는 Scale-up만 지원을 합니다. 왜냐하면 트래픽이 몰리게 되면 쿼리수의 급격한 증가와 그에 따른 병목현상이 발생하기 때문입니다. cpu나 메모리 수를 늘려야 동시 실행 수준이 높아지기 때문에 수직확장이 더 알맞다고 합니다.그러나 우리는 대용량 트래픽 상황을 고려하고 있는 만큼, 지속적인 확장이 불가하고 migration이 매우 어렵다면 다른 방법을 생각해봐야 할 것 같습니다.

Scale-out 이란?

scaleout

수평적 확장 이라고도 불리며 추가적인 부품을 다는게 아닌, 새로운 서버를 추가하는 방식입니다. Scale-up 에서 부품 추가의 한계를 극복한 방법으로 필요한 만큼 무제한으로 서버를 추가할 수 있어 해당 문제에서 자유롭습니다. 트래픽이 많이 몰리는 웹사이트의 경우, 로드 밸런스 기술을 통해 트래픽을 여러 서버로 분산시켜 작동할 수 있도록 설계하는 것이 가능하고 한 서버가 다운이 되더라도 다른 서버가 살아있기 때문에 전면장애의 우려가 매우 낮습니다.

그러나 Scale-out 역시 소프트웨어의 라이센스 비용이 들어갈 수 있습니다.

지금 시점으로는 오픈소스를 활용하여 최대한 줄일 수 있는 장점이 존재하긴 합니다.

또한, 여러 대의 서버를 사용하기 때문에 데이터 불일치 문제가 발생할 수 있습니다. 예를 들어, 사용자1의 로그인 요청을 서버1이 받아 처리를 해서 서버1에는 사용자의 데이터가 존재하지만 서버2에서는 그러한 요청을 받은 적이 없기 때문에 만약 다시 로그인을 시도했는데 서버2가 받았다면 로그인이 안되는 문제점이 발생합니다.

Scale-out 을 사용할 시 데이터의 불일치를 어떻게 해결할지 필히 고민을 해봐야 합니다.

그럼 어떤 방식을 써야할까?

Scale-out 을 사용하는게 적합한 경우는 개개의 처리는 단순하지만 다수의 요청을 동시 병행적으로 처리 해야만 하는 상황 이거나, 갱신할 데이터의 정합성 유지에 특별한 요건이 없을 경우 적절합니다.

웹 서버가 대표적인 Scale-out 방식이라고 합니다. 네트워크로부터 온 다수의 요청을 처리해야 하지만 처리의 방식은 비교적 간단합니다. 데이터로의 액세스는 기본적으로 읽기 전용이기 때문입니다.

만약 데이터베이스의 분할이 비교적 쉽다면 이러한 Scale-out의 장점을 적극적으로 활용을 할 수가 있습니다. 하나의 서버가 다운이 되어도 다른 서버에서 즉시 처리가 가능하기 때문이죠.

Scale-up 은 데이터베이스에 갱신이 자주 발생을 하는 경우 적절하다고 합니다. Scale-out처럼 다른 조건의 네트워크를 통해 통신하게 되면 지연이 되버라고 곧 전체의 장애로 번집니다. 서버를 추가해도 처리 능력이 비례하여 증가하지 않기 때문에 이러한 상황이라면 Scale-up이 적합하다고 볼 수 있을 것 같습니다.

‘FESTA’ 라는 이벤트 추천 웹 서비스를 개발하면서 우리 프로젝트에는 어떤 방식이 더 어울리고, 더 효율성이 좋을까 생각해보았습니다. 이벤트 추천 서비스의 특성상 마감일이 다가오며 발생하는 조회수의 증가로 다수의 신청접수를 처리해야할 필요성을 느꼈습니다. 해당 처리는 단순하지만 동시 병행적으로 처리해야 하기 때문에 트래픽을 분산처리 시켜주는 Scale-out 이 적합할 것 같다는 결론을 얻을 수 있었습니다! :)

하지만 Scale-out 은 앞서 언급한 것과 같이 데이터 불일치 문제를 해결해야만 온전히 그 기능을 사용할 수 있습니다. 데이터 불일치 문제를 해결하기 위한 Sticky Session, Session-Clustering, in-memory database 의 대한 정리는 다음 글에서 자세히 풀어보도록 하겠습니다~!