[슬축생 프로젝트] 8. Vultr로 이사가기 & 도커로 배포 자동화 하기!

시작하며

우리 개발팀에서 큰 프로젝트를 시작하기 위해 슬축생 프로젝트는 이제 마무리 하고 쭉 유지보수 정도만 하는것으로 결정되었다. 그래서 마지막으로 프론트에서 UI/UX 개편을 조금 한 뒤에 클라우드를 이사를 가서 안정화 시키고 쭉 사용하려고 한다.

클라우드를 왜 이사하지?

일단 앞에 글에서도 다뤘겠지만 한번 aws로 이사하려다 월 100g 무료 트래픽에 멈칫해서 여전히 무료 오라클 클라우드 하나에 리얼서버와 테스트 서버 모두 넣어서 사용하고 있었다. 하지만 이제 프로젝트를 마무리하면서 모니터링 툴들을 사용하고 싶었는데 그럴려면 일단 지금 하나로 뭉쳐있는 서버를 찢어야 된다고 생각을 했다. 그리고 또한 지금 사용하는 서버가 4코어에 24기가 램인데 이 성능에서는 장애를 마주할 수 없을것 같아서 일부러 1코어 1기가 램인 최소사양인 클라우드를 선택해서 장애들을 마주하고 개선하고 싶은 마음이 컸다.

어떤 클라우드를 사용할까? 

난 인프랩의 ceo님인 쭈님의 역사에 굉장한 팬인편이여서 하루에도 몇번 인프랩실 log를 계속 읽곤한다. 아마 지금 한 50번째 읽은것 같다.

초반 원자 단계에서 conoha 클라우드라는곳으로 이전했다는 로그를 봤다. 매우 가성비가 좋아서 선택했다고 하셨다, 물론 지진 문제 때문에 다시 옮기시긴 했지만. 그래서 코노하 클라우드를 봤는데 월 요금제가 상당히 저렴했다, 트래픽도 무제한인데 일정이상 사용하면 qos가 걸린다고 했다. 일단 후보로 정하고 다른 클라우드들을 알아보던중 vultr라는 클라우드를 알게 되었다. 전에 워드프레스로 제휴마케팅 블로그를 운영할때 가끔 듣던 클라우드였는데 알고보니 정말 코노하만큼 가성비도 좋았고 UI/UX가 깔끔하고 직관적이여서 좋았다.

그래서 가격적인 면과 제공하는 기능, UI/UX에서 오는 신뢰감 때문에 vultr를 선택했다. 일본어보단 영어에 익숙해서 선택한것도 있다.

Vultr 클라우드 구성과 배포 자동화

일단 백엔드 서버 같은 경우에는 vultr안에서 모두 구성하였고 제일 앞단에 Firewall을 둬서 오라클에서보다 적극적이고 깐깐한 룰들을 구성해서 사용하고 있다. Vultr가 확실히 UI가 좋다보니 손쉽게 사용할 수 있기도 하고 회사에서 방화벽 개발도 혼자 다 하다보니 이런 보안적인 부분에 더 신경을 쓸 수 있는것 같다. 인스턴스는 백엔드 서버, MySQL DB서버를 사용했다. DB 같은 경우에는 vultr에서 제공해주는 DB 서버 요금제가 있었지만 너무 비싼탓에 그냥 우분투 인스턴스를 받아서 직접 설치하고 외부 접속을 막고 내부 통신할 수 있도록 세팅했다.

VPC안에 묶어서 모두 내부망 대역대에서 서로 통신할 수 있도록 세팅하였다, 사실 배포 자동화할때 DB 외부 접속을 허용하면 좀 간단하게 넘어갈 수 있는 부분이 있었지만 내부망을 사용할 수 있음에도 불구하고 네트워크 쿼리를 외부로 한번 뺏다 다시 들어오는게 별로 좋지 않다고 생각했다. 

배포 자동화는 위처럼 도커와 깃허브 액션을 이용했다. main 브랜치에 pr을 머지한다면 깃허브 액션이 자동으로 빌드 및 테스트를 하고 도커 이미지를 생성해서 도커 허브로 업로드 해준다. 업로드가 정상적으로 완료되었다면 서버의 ssh에 접속해서 latest 이미지를 풀 해서 기존의 컨테이너를 삭제하고 새로운 컨테이너를 실행해준다.

리얼 서버 이사 일정

아직 현재 운영되고 있는 리얼 서버를 완전 이전한것은 아니다. 아직도 서비스는 오라클 클라우드에서 돌아가고 있고 vultr에는 미리 환경 구성을 끝낸것 뿐이다. 이제 우리 동아리가 2월에 3기 마무리를 하고 3월달부터 4기를 시작하는데 그 사이 기간에 여러가지 부분을 더 보완하고 옮기고 시작할 예정이다. 서버별로 모니터링 툴들도 붙여보고 지금까지 불편했던 부분들도 모두 개선하려고 한다!