서버의 분리

부트캠프의 최종 프로젝트 - Drink!t 을 진행하며 서버를 분리하게 된 이유를 적어보려 한다.

 

 

Scale - up , Scale - out

서버의 부하가 증가 함에 따라 2가지 방법이 존재하는데 스케일 업과 스케일 아웃이다.

 

스케일 업이란 말그대로 서버의 성능 자체를 올려서 트래픽을 원활히 처리하는것.

하지만 컴퓨터의 성능을 올린다는 것은 비용적인 부분에 부담이 클수밖에 없다.

스케일 아웃은 똑같은 성능의 서버를 복제해서 트래픽을 분산처리를 하는것.

 

당연히 프리티어 를 활용하고 있는 우리로서는 최고의 선택은 스케일 아웃이었고,

효과적으로 트래픽 분산 처리를 위해 로드밸런서를 활용했다.

 

로드밸런서는 크게 3가지 방식으로 나뉘어 볼 수 있는데

 

1. 라운드 로빈

각 프로세스별로 시간을 부여해주고 요청을 순차적으로 처리하는 방식

 

2. IP 해싱

들어오는 요청의 IP를 서버에 할당해 해당 서버로만 요청이 들어가게끔 하는 방식

 

3. 최소 연결

각 서버별로 처리하고 있는 요청수를 비교해 제일 적은 요청을 처리하고 있는 서버에 보내는 방식

 

이중에 우리는 라운드 로빈 방식을 채택했다.

 

그 이유로는 우리의 요청은 그닥 무거운 정보를 담고있거나, 혹은 요청 자체가 시간을 오래 끄는것도 아니라서 프로세스 자체에 시간이 짧게 부여되는 것에 대한 리스크도 없을뿐더러, 순차적으로 트래픽을 처리해주는것이 메리트였기 때문.

 

아래 트래픽 테스트에 대한 사진을 보고 어떻게 부담이 덜어지나를 보자.

왼쪽 그래프와 오른쪽 그래프의 차이는 로드 밸런서에 등록한 2개의 서버중

2개 다 가동했을 때와 1개만 가동했을 경우 이다.

 

명확하게 서버별로 1/2 로 부담이 줄어들게 되는것을 확인할 수 있다. 물론 1개의 서버만으로도 테스트 해봤던 트래픽에 대해서 원활히 처리가 가능한것을 확인 했으나, 트래픽 분산에 따른 CPU 사용량을 체크하여 부하 분산 처리가 되는 유의미한 데이터를 확인해보기 위함이었다.

 

서버의 분리에 대해 얘기하고자 하는데 서론이 길었던 이유가 있다.

 

먼저 서버를 복제 한다는것은 내가 해당 요청을 처리할 로직이 담긴것 또한 그대로 복사가 된다는 것을 의미한다.

2가지 예시를 들어서 비교를 해보려 한다.

 

1. 메인 서버가 모든 로직을 포함한 경우

2. 중요 로직별로 서버를 분리한 경우

 

우리 서버는 크게 4가지로 분류가 되어있는데

 

- 메인 서비스

- 프론트 서버

- OpenAI

- WebRTC

 

1번 예시로 생각을 해보자면 위 4가지 서비스가 하나의 서버에 다 담고있는것이다.

근데 4가지 중에 OpenAI 관련 트래픽이 몰려서 스케일 아웃을 해야 하는 상황이 생겼다고 가정해보자.

 

서버를 복제를 진행을 했는데 불필요한 나머지 3가지 서비스도 같이 복사되어지게 된다.

불필요한 데이터들이 담겨지게 되고 그만큼 효율성은 떨어지게 되는것.

 

2번 예시로 생각을 해보자

 

마찬가지로 스케일 아웃을 진행해야 한다 가정해보았을때,

서버를 복제해도 해당 관련 로직, OpenAI 에 대한 처리만을 하는 부분만 복제가 이루어지기 때문에 효율이 더 좋을수밖에 없는것.

 

서버를 분리함으로써 명확한 집중 관리가 가능해지게 되는것이기에 안할 이유가 없었다.