[우테코] 스탬프크러쉬 팀의 클라우드 서버 역할 분담: 개발 서버, 데이터베이스 서버, 인프라 서버로 분리한 이유

 

 

 

 

안녕! 

우아한테크코스 5기 [스탬프크러쉬]팀 깃짱이라고 합니다. 

 

스탬프크러쉬 서비스의 소스 코드 바로가기

GitHub - woowacourse-teams/2023-stamp-crush: 흩어져있는 종이쿠폰 한번에 관리하자✨ - 스탬프크러쉬💮👊

 

 

이번 포스팅 주제는 스탬프크러쉬 팀의 클라우드 서버 역할 분담 결정 과정이다.

 

포스팅에서 잘못된 내용이 있다면 댓글로 언제든 알려주세요

 

 

 

💋 EC2 할당: 서버 역할 분담

 

우리 팀은 단 세 대의 EC2를 할당받았다. 

EC2는 아마존에서 컴퓨터를 빌려주는 것이다. 

빌리는 이유는? 아무래도 아마존은 프로니깐 내 컴퓨터가 배포 서버를 하는 것보다는 안정적이겠지? 

그리고 때에 따라 돈만 내면 개수를 늘리거나 컴퓨터 성능을 업그레이드 하는 것도 가능하다. (현실 컴을 늘리거나 업그레이드하는 것보다는 덜냄)

 

세 대를 아래와 같이 나눴다. 

각각 펼쳐보면 아래와 같이 나눈 이유가 있다!

 

 

1. 데이터베이스 서버 

 

별도의 서버는 외부 접근에 대한 보안 설정을 더욱 강화할 수 있다. (예를 들어 방화벽)

데이터베이스 서버를 독립적으로 운영하면 개발 서버의 장애가 데이터베이스에 영향을 주지 않기 때문에 안정적이다. 

 

근데 아직 이 서버는 사용하지 않고, H2 데이터베이스 사용해서 개발중이라서 다음에 더 자세히 설명해보려고 한다(ㅎㅎ)

 

2. 개발 서버 

 

우리가 작성한 애플리케이션의 코드가 돌아갈 서버다.

서버가 4개였다면 프론트엔드 서버와 백엔드 서버를 서로 다른 서버에 두었겠지만, 이번에는 개수가 3개인 관계로 동일한 서버 서로 다른 포트 번호로 놓았다. 

 

가장 고민했던 부분은, 어떻게 개발 서버로 들어온 요청에 대해서 프론트엔드 서버로 들어온 요청인지, 백엔드 서버로 들어온 요청인지 구분하는 방법이었다. 

 

몇 가지 방법이 있을 텐데, 우리가 고민한 건 아래 두 가지다. 

 

1. 애플리케이션 서버 앞에 웹서버를 두고, 들어오는 요청을 (어떻게든 구분해서) 서로 다른 포트로 포워딩한다.

2. 백엔드 애플리케이션에 내장된 톰캣 내에서 프론트엔드 코드를 빌드한 파일을 함께 실행한다. 

 

우리는 이중 1번을 택했다.

먼저 떠오른 방법이 1번이라 왜인지 더 일반적이라고 생각하기도 했고 (느낌지향 프로그래밍 ㅈㅅ합니다ㅠㅠ)

프론트엔드 역시 나중에 웹서버(Nginx)에 정적 리소스들을 옮겨놓고 싶다고 했다. 

 

결과는 아래와 같다. 

그림 제나랑 한땀한땀 직접 그림. 출처: 깃짱&제나

 

우리가 할당받은 EC2는 인바운드 포트는 80(http 기본)이랑 443(https 기본)였다. 

일단 80 포트로만 외부 요청을 받을 수 있도록 했다. 

 

들어오는 요청을 받아주기 위해서 Nginx 웹서버를 두었다.

Nginx는 사실 여러 기능이 있지만, (정적 리소스 전문가, 로드밸런싱 등등) 우리 팀은 딱!!! 포트 포워딩 용으로 쓰기로 했다. 

 

포트 포워딩이라 함은... 80 포트로 들어온 요청을 다른 포트번호로 보내주는거다. 

80으로 들어온 요청을 받아서 uri를 딱 봐서, 그냥 /로 들어온거면 프론트엔드 서버가 돌고있는 3000 포트로 포워딩하고, 앞에 /api가 prefix로 붙어있는 uri라면 백엔드 서버 톰캣이 돌고있는 8080 포트로 포워딩한다. 

 

우리가 사용하는 EC2 서버의 스펙은 모두 각각 t4g.small였다. 

Nginx를 경량화된 웹 서버이기 때문에, 처리량이 크게 증가하지 않는 한 일반적인 웹 요청에 대해서는 t4g.small의 2 vCPU와 2GB의 RAM으로도 충분한 성능을 제공할 수 있다고 생각했다. 

근데 만약에 JS Build Code와 Spring Boot Tomcat을 함께 실행한다면, 성능 부족의 가능성이 있다고 생각했다. 

JS Build Code는 자원을 많이 요구하며, Spring Boot Tomcat은 Java 언어 기반의 웹 애플리케이션으로 메모리와 CPU 사용량이 높기 때문이다. 

 

인스턴스 성능이 부족해질 경우를 대비해야 한다.... (아래에 더 나옴)

 

3. 인프라 서버 

 

우리가 사용하는 EC2 서버의 스펙은 모두 각각 t4g.small였다. 우리는 자동 배포를 위해서 Docker 컨테이너를 사용하여 Jenkins를 설치하기로 결정했는데, Jenkins와 Docker 컨테이너를 함께 사용하면서 여러 작업을 동시에 처리한다면 리소스 부족으로 인해 성능 저하가 발생할 수 있다고 생각했다. 특히, 동시에 여러 개의 빌드를 수행하거나, 프로젝트 규모가 점점 커질수록 현재 서버의 성능이 부족할 수 있다고 판단했다. 따라서 다른 서버와 함께 사용할 수 없어서 별도로 하나의 서버를 할당하게 되었다. 

 

t4g.small은 인스턴스 유형 중 하나로, t4g 시리즈의 작은 크기다. 이 인스턴스 유형은 2 vCPU와 2GB의 RAM을 가지고 있으며, 튜리보스트(Turbo Boost) 기술을 사용하여 최대 3.3 GHz의 프로세서 속도를 제공한다.

 

인프라 서버 역시나 CPU 사용량이 어느 정도 되는지 확인해 봤는데, 클라우드 서버가 상당히 힘겨워하는 모습이라서, 어쩔 수 없이 세 서버 모두 Swap 메모리를 할당했다.

 

 

---

 

💋 Swap 메모리 할당 

 

쉽게 말해서, 메모리는 늘리고 싶은데 돈은 없을 때 영끌해서 쥐어짜는 메모리다.

디스크 일부를 메모리 공간으로 사용하는 것이다.

 

설정은 우테코 크루 주노의 Swap 메모리 할당하기라는 글을 보고 따라했다. 

 

무지성으로 따라치는거 참 싫어하는데, 이건 도무지 이해하고 넘어갈 시간이 없어서 일단 따라 치면 된다. 

(아래 내용 따라 치면 되는데, 위에 걸린 링크 따라가서 치는걸 추천한다.)

 

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile