Contents

AWS EC2에서 product 서버와 개발용 서버 같이 사용하기

 
 

프로젝트를 진행하다보면 필연적으로 프론트엔드와의 통신교류가 필요하고,
이 때마다 local server로 열기보단 상시 열려있는 server가 있는 것이 훨씬 편하다.

때문에 이러한 개발과정상 필요한 back-end의 통신교류용 API 서버를 AWS EC2에서 간편하게 열어 사용하는 방법에 대해 기술하려 한다.

초기

처음 통신교류를 위한 서버는 VScodeLive Share Extension을 이용하였다.
/images/vscode-live-share.gif
방법은 다음과 같다.

  1. extensions에서 Live Share 설치
  2. 좌측 사이드 메뉴에서 Live Share 아이콘 클릭
  3. Share 버튼을 클릭하면 실시간 공유가 시작된다.
  4. 여기서 Shared Servers를 클릭하고 상단 검색창에 포트 번호를 입력후, enter를 누르면 해당 포트로 서버가 공유된다.

 

과도기

VScode의 Live Share를 이용한 통신 교류 확인시, 몇가지 단점이 있었다.

  • 백엔드는 자신의 local 컴퓨터에서 항상 이 서버를 켜놔야한다.
  • 해당 서버가 공유되고 있는 동안에 코드를 수정하기가 난감하다.
    • 코드 수정 중 백엔드의 express가 중단될 때, 프론트에서는 아무 통보없이 서버가 멈추는 상황을 맞이하게 된다.
    • 그때마다 실시간으로 프론트에게 상황을 전달해줘야 한다.

 
때문에 상시 가동가능한 AWS의 EC2를 이용하여 개발용 서버를 하나 열어주는 방법을 선택하였다.

 
예를 들어,
version 1.0.0의 product 서버가 8000 port로 배포중이라면,
version 1.0.1의 dev 서버를 8001 port로 또 달리 배포를 하는 것이었다.

 
이 때 EC2 운용은 해당 프로젝트의 동일한 코드를 또다시 git clone하여 서버를 여는 방법이었다.
즉, test-project라는 프로젝트의 경우 해당 EC2에는

  • test-project
  • test-project-dev

이렇게 2개의 동일한 폴더가 설치되고,
product 배포용 main 브랜치와 통신교류용이자 개발용 dev 브랜치에서의 코드로 각각 서버를 돌리는 것이다.

 
당연히 몇가지 문제가 있었다.

  • EC2의 프리티어용 인스턴스를 사용해서인지 무거운 프로젝트의 경우 두번째 서버를 돌릴때, 일단 npm install에서부터 굉장히 오랜 시간이 걸린다.
  • 굳이 똑같은 코드인데 EC2에서 복수로 용량을 차지한다.

 

현재

몇 번의 테스트 결과 현재의 방법은 과도기의 방법과 크게 다르지 않지만 일단 과도기 방법의 단점은 모두 해결하였다.

간단하게, 하나의 프로젝트 폴더에서
git switch로 브랜치 전환 후,
npm distribute 명령을 dev용으로 하나 더 추가 실행하는 것이다.

"scripts": {  
	"distribute": "npm i --verbose && pm2 start dist/main.js --name <배포용 서버명> -i max",  
	"distribute-dev": "npm i --verbose && pm2 start dist/main.js --name <개발용 서버명> -i max",  
}

 

  • 배포용 서버를 가동할 땐,

    1. main 브랜치로 이동
    2. npm run distribute 명령어 실행
  • 개발용 서버를 가동할 땐,

    1. dev 브랜치로 이동
    2. npm run distribute-dev 명령어 실행

이후 코드 업데이트로 인한 서버 reload시에도 간단하게 git branch를 이동한 후, 개발용인지 아닌지 서버명만 정확하게 입력하여 reload 시켜주면 된다.

 
이런 식으로 명령어를 따로이 할 때 주의 사항은,

  • scripts 명령어와,
  • 명령어의 내용중 서버명

위 두가지 항목을 반드시 다르게 지정해야 한다.
자칫 기존 배포용 서버에 개발용 코드가 덮어씌기 될 수도 있기 때문이다.

 
현재의 이 방법은 무거운 npm install 과정을 main과 dev 모두 한번으로 처리할 수 있어서 AWS의 프리티어 인스턴스에서도 생각보다 가볍게(?) 잘 돌아간다.