웹서버와 WAS를 분리하면 아래와 같은 장점들을 얻을 수 있어 분리하기로 결정했습니다.
웹 서버를 사용하면 정적 파일 요청에 대한 전송이 빠르고 서버의 부담을 줄일 수 있습니다.
Reverse Proxy를 사용해 앞 단은 Nginx를 사용하고 뒷 단에는 WAS를 사용해 직접적인 Web Server로의 접근을 막을 수 있습니다.
또한, 웹서버와 WAS를 분리함으로서 확장하기 용이하고 장애 극복에 쉽게 대응이 가능해 무중단 운영에 적합합니다.
서버의 자원이 적고 효율성을 중요하게 생각한다는 점에서 Nginx를 선택했습니다.
Nginx는 비동기 이벤트 기반구조의 웹서버로 Apache에 비해 적은 양의 스레드가 사용되어 CPU 소모가 적고 클라이언트의 동시 접속에 잘 대응할 수 있습니다.
보안을 위해 Certbot을 이용해 SSL 인증서를 발급받아 HTTPS를 적용했습니다.
Nginx 설정파일
무중단 배포를 위해 PM2를 사용하기로 했습니다. 처음에는 pm2 start 명령어를 사용했지만 배포를 할 때 잠깐동안 서버가 꺼진다는 것을 알았습니다. 무중단의 의미가 무색해지기 때문에 더 찾아본 결과 reload를 알 수 있었습니다.
"scripts": {
"dev": "cross-env NODE_ENV=development nodemon --ignore test.json -r tsconfig-paths/register ./src/app.ts",
"prod": "tsc && tscpaths -p tsconfig.json -s ./src -o ./dist && cross-env NODE_ENV=production pm2 start ./dist/app.js",
"test": "cross-env NODE_ENV=production pm2 reload ecosystem.config.js --update-env"
},
reload는 적어도 하나의 프로세스를 남겨두고 다른 프로세스들을 하나씩 restart하는 방식이었습니다. 그래서 만약 하나의 프로세스만 사용하고 있는 경우 reload는 restart와 같아집니다.
"scripts": {
"dev": "cross-env NODE_ENV=development nodemon --ignore test.json -r tsconfig-paths/register ./src/app.ts",
"build": "tsc && tscpaths -p tsconfig.json -s ./src -o ./dist",
"prod": "pm2 reload ecosystem.config.js --env production",
"test": "cross-env NODE_ENV=production pm2 reload ecosystem.config.js --update-env"
},
아쉽게도 사용하고 있는 NCloud Instance의 Ubuntu 서버가 코어를 하나만 제공하기 때문에 reload를 사용해도 start/restart와 같아지게 되었습니다.이에 대한 해결책으로 Docker를 사용한 블루/그린 무중단 배포를 생각하게 되었고 추후 도입할 예정입니다.