WeTri 인프라, 배포 구축기 ‐ 6
- 지금까지 구축하고 사용했던 환경은 Dev 환경으로 두고, 똑같이 Production 환경을 구축하려고 했습니다.
- Dev 환경을 구축하면서, 정리했던 일련의 과정들을 밟아가더라도, 문제가 발생했습니다.
- 사람이다 보니, 잘못 클릭하거나 잘못 눌르거나 하는게 반복 되었습니다.
- 또한 NCP에서 이전에 없었던 것이 생겨나는 경우도 있었습니다.
- Dev 환경 구축할 때 없었던 LB 공인 IP 생성 버튼이 Production 환경을 생성할 때에는 존재했습니다.
- 변경 사항을 반영하기 위해, 문서를 계속 수정해야했습니다. 이 과정을 계속 반복하다 보니, IaC를 왜 이용하는지 뼈저리게 알게되었습니다.
- 최종적으로, Dev 그리고 Prod 환경을 구축했습니다.
- 지금까지 WeTri API 서버에는 단 한개의 컨테이너만 존재했습니다.
- 컨테이너 내부에는 Nest가 존재했고, 3000번 포트는 API 서버, 3003번 포트는 웹 소켓 서버가 되어있습니다.
- 서버 인스턴스에 Nginx를 두고 리버스 프록시로 각 포트로 이동할 수 있게 끔 만들어주었습니다.
- 문제는 다음과 같습니다. 각 서버 인스턴스에는 하나의 컨테이너만 올라가있는 상태입니다.
- 문제는 네이버 VPC 환경의 인스턴스의 최소 사양이 높다는 점 입니다.
- 비유하자면, 큰 집에 살면서 정작 사용하는 곳은 일부분인 것과 같다고 생각했습니다.
- 또한 다른 문제도 발생했습니다. Production 환경에 오토스케일링 기능을 추가했는데, 기존의 배포 방식인 Bastion-host로 Private Subnet에 있는 서버에 접속해 배포하는 것이 힘들어진다는 점 입니다.
-
2가지를 해결하기 위해서, 우선적으로 네이버에서 제공하는 SourceDeploy 서비스를 학습해보았습니다.
-
DevTools라는 카테고리 안에 Source Commit, Source Build, Source Deploy, Source PipeLine 등 소스코드부터 빌드, 배포, 파이프라인을 손쉽게 구현할 수 있는 기능이 존재했습니다.
-
이 중 Source Deploy를 이용해서 위 2개의 문제를 해결하려 했지만, 어려움을 격었습니다.
-
우선, Source Deploy를 이용하기 위해선 NCP가 제공하는 Source Commit을 사용해야했습니다.
-
Source Commit은 NCP에서 관리하는 Git 버전 관리 도구입니다.
-
Github을 이용해야하기에 과감하게 제외 시켰습니다.
-
다른 방법은 컨테이너를 이용한 배포임으로, 컨테이너 관리 도구에 대해 알아보았습니다.
-
도구들이 정말 다양했지만, 작은 규모의 관리 도구 그리고 러닝 커브가 제일 낮고 이미 설치되어있는 Docker Swarm을 이용했습니다.
-
Docker Swarm의 Replica를 이용하면 하나의 서버에 여러개의 같은 컨테이너를 띄울 수 있게됩니다.
-
또한 Ingress Routing Mesh를 지원하여, 같은 포트를 받는 여러개의 컨테이너가 내부 로드 밸런싱을 통해 처리할 수 있습니다. Termius를 이용해서, 실제로 Naver 로드밸런서의 헬스체크가 잘 오는지, 사용자 들의 요청이 잘 오는지 확인했습니다.
-
다른 하나는 Ochestaration 입니다. 하나의 매니저 역할 (지휘자)를 생성하고, 다른 서버 (Worker)가 Join하게 된다면, 매니저가 명령하는 것에 모든 Worker가 작동하게 됩니다.
-
이를 이용해서, Service를 배포할 수 있습니다. 또한 오토 스케일링으로 서버가 생성되게 된다면, Init 스크립트에 Join하는 로직과 현재 Replica 수를 받아서 + 2 한 상태로 Update하는 로직을 작성하게 된다면, 서버 내에 Scale 업이 가능합니다. → Down은 아직 구현하지 못했습니다.
-
또한 Docker Visualizer를 이용해서, 각각의 워커 노드의 컨테이너들이 잘 수행되고 있는지, Replica update가 잘 적용이 되는지 모니터링이 가능합니다!
