인프런 백엔드 인턴십을 진행하면서 아쉬웠던 점은 API 머신이 된 듯 코드에만 너무 몰두해 인프라에 신경쓰지 못한 것이다.

지금 이 시점에서는 프로젝트가 마무리 되었지만 처음 인프라를 구축한 것부터 현재 인프라로 배포되기까지의 과정을 간단하게 기록하고자 한다.

초기 인프라 구조는 어떻게 되어있나?

기존에 가지고있던 스켈레톤 프로젝트를 기반으로 아래와 같은 환경에서 개발했다.

발그림으로 그린 초간단 개발 환경

npm start의 명령어를 docker run으로 지정해두었기 때문에 코드를 수정하고 서버를 재시작하면 컨테이너가 실행되도록 했다.

도커의 장점은 어느 환경이든 이미지만 가지고 있다면 개발부터 배포까지 편리하게 구축할 수 있다는 것인데 이 점을 빌어 칸반보드의 배포까지 쌈뽕하게 할 수 있었다.

나름 신경 쓴 첫 배포 인프라 아키텍처

배포 과정

1. 서비스 아키텍처

데이터베이스의 경우 (도커 컨테이너로 서비스할 시) 확장성 및 유지보수 등의 단점을 고려하여 AWS RDS를 사용했고 칸반보드 서버는 동일하게 배포된 코드를 빌드하여 이미지를 컨테이너로 띄우는 방식으로 아키텍처를 설계했다.

2. Jenkins를 활용한 CI/CD 구축

2-1 젠킨스 설치

ci-server를 구축하고 젠킨스를 도커 이미지로 실행하였다. 이유는 간단하다. 젠킨스를 ubuntu에 직접 설치한다면 많은 과정이 필요하다. 젠킨스를 컨테이너로 실행한다면 이 과정을 생략하고 필요에 따라 확장과 업그레이드가 용이하기 때문에 도커를 선택했다.

2-2 젠킨스 Item 생성

젠킨스에서 CI/CD 프로젝트를 구축하기 위해서 아이템(Item)을 생성하고 Freestyle 프로젝트 설정을 다음과 같이 했다.

git clone

github 브랜치에 소스가 push되면 빌드되도록 설정해주었다.

실제 서비스라면 push 시에 빌드되도록 설정하는 건 위험할지 모른다는 생각이 들었다. 아무리 테스트를 완벽하게 했다고 한들 배포하고 난 뒤 에러가 발생할 수 있는 경우의 수도 배제할 수 없지 않을까?
따라서 사용량이 가장적은 새벽시간에 스케줄을 걸어두거나 push를 새벽에 하거나 하는것이 좋은 방법일 듯하다.

빌드 후 조치

/usr/local/bin/docker-compose --env-file /root/.development.env build

/usr/local/bin/docker-compose --env-file /root/.development.env up -d

소스코드를 Kanban-server로 복사하고 해당 서버에서 이미지 빌드와 컨테이너 실행을 한번에 시키는 방식으로 배포되는 구조이다.

개선하게 된 계기

단순하게 이미지를 빌드해서 올려서 배포 프로세스를 단순화 하는 것만이 도커의 장점이 아니라는 것은 잘 알고 있었다. 그저 첫 배포에 성공했다는 사실에 감격해서 만족하고 있었다는 사실을 깨닫고 나니 초라해 보이는 인프라 아키텍처만 남아있었다

도커는 빠르고 쉽게 확장할 수 있는 아키텍처를 구축할 수 있도록 지원하는데 이미지를 기반으로 서비스 성능을 유연하게 조정할 수 있는 장점이 있다. 현재는 단일 컨테이너가 적합한 서비스 규모지만 향후 서비스 사용량이 많아질 경우를 고려하여 확장에 유연한 아키텍처로 업그레이드 해야겠다고 결심했다.

또한 앤서블을 인프라스트럭처 자동화 도구로 사용하여 도커 컨테이너를 관리하고 배포하는 프로세스를 구축하고 시스템의 유연성과 안정성을 높이기로 했다.

2탄에서는 앤서블을 도입하여 개선된 인프라 아키텍처가 완성된 내용을 다뤄보겠다!