이번 글에서는 배포 과정에 대해 작성하려고 합니다.
지난 글 이후 일정이 미뤄졌는데, 회사 프로젝트 마감 기간이 다가와서 프로젝트에 집중하느라 포스팅이 늦어졌습니다. AWS 비용이랑 배포 방법도 찾아보느라 오래 걸렸습니다. 🥲
1-1. 목표 및 제한 사항 확인
- ✅ 목표
- 1️⃣ 무중단 배포
- 서버 업데이트 하는 동안 서비스를 사용하지 못한다면 사용자에게 큰 피해를 끼칠 수 있다.
공지를 하여 서비스 이용 시간에 제한을 둘 수도 있지만 오랜만에 사용하는 사람, 공지를 못 본 사람, 공지사항을 업데이트하는 개발자 등에게 안 좋은 영향을 끼친다.
따라서 무중단 배포를 목표하였다.- 우리 회사 옆부서에서 간단한 사내 서비스를 만들었다. 프론트엔드 개발자 한 분이 만드셔서 무중단 배포를 도입할 여력이 없어 업데이트 시 항상 공지를 한다.
그 분의 말씀을 인용하자면 "공지 하는 게 귀찮고, 모두 공지를 확인해야 되는 상황을 해결하고 싶다."라고 무중단 배포가 아니었을 때 겪는 고충을 말씀해주셨다.- 2️⃣ 롤백
- 배포를 했을 때, 에러가 난다면 정상 동작하는 이전 버전으로 되돌려야 한다.
무중단 배포를 적용했더라도, 업데이트를 했을 때 에러가 난 상태에서 가만히 있는다면 에러를 해결하는 시간동안 서버를 먹통이 된다. 결국 롤백이 없다면 에러 발생 시 그대로 서비스 장애로 이어진다.
따라서 롤백 기능을 적용하는 것을 목표하였다.
- ❌ 제한 사항
- 1️⃣ Database(PostgreSQL)
- PGroonga(검색 관련 확장팩) 사용 중인데, Cloud 서비스에서는 Database에 확장팩을 마음대로 설치할 수 없다. 따라서 프로젝트에서 사용 중인 확장팩을 지원하는지 여부를 확인해야 한다.
AWS RDS는 PGroonga를 지원하지 않는다.- 2️⃣ 비용
- 개인 프로젝트이기에 많은 비용을 지불하기 힘들다. Cloud 서비스에서는 많은 기능들을 이미 만들어두고, 자신들의 서비스에 적용해뒀지만 이를 모두 사용한다면 비용이 만만치 않을 것이다.
- 월 10만원을 기준으로 잡았다. 내가 원하는 기능과 목표는 다룰 수 있는 최소한의 금액이라고 생각한다.
1-2. 배포 방법 고민
- 고려한 배포 방법 및 결정
- 1️⃣ AWS ECS
- 컨테이너 오케스트레이션을 지원하는 서비스
- 장점: 배포 자동화, 무중단 배포 방식 여럿 지원, 오토스케일링 지원... 등
- 단점: 가격
최대한 리소스를 줄이고, 컨테이너 개수를 줄인다고 하더라도 ECS의 비용은 생각보다 비싸다. 특히 개인 프로젝트에서 오토스케일링을 적용하고, 완전 관리형을 사용하기에는 '굳이?'라는 생각이 많이 들었다.
아래는 GPT에게 견적을 물어보았다.
필요한 vCPU, Memory, Container 개수를 알려주었을 때 약 5배 차이가 나는 것을 확인할 수 있다.
- 2️⃣ ✅ AWS EC2
- 가상의 컴퓨터를 대여하는 방식의 서비스
- 장점: 가격이 저렴하다. 제어권이 나에게 있다.
- 단점: 제어권이 나에게 있다. ➡️ 이게 진짜 단점...
가격이 저렴하고,나에게 제어권이 있어 학습하면서 운영까지 직접 해볼 수 있고, 하드웨어 관점 문제까지 마주해볼 수 있는 기회가 있다. 물론 제어권이 나에게 있다는 게 부담으로 다가오지만, 익숙해질 정도로 시도해보는 수 밖에 없다.- 결정한 이유: 2가지 이유 때문에 EC2를 사용하기로 결정했다.
- AWS RDS에서 PGroonga를 지원하지 않아 PostgreSQL Docker Image를 직접 사용하기로 했다. PGroonga가 설치된 PostgreSQL Docker Image를 가져와서 EC2 내부에 동작시키기로 했다.
- 가격과 학습 때문이다. 위에서 적정선으로 제시한 금액은 월 10만원이다.
EC2 2대를 빌린다면 월 5만원, ECS 컨테이너 3대는 월 18만원 수준이다.
(vCPU, Memory, Container 개수를 동일하게 측정하였다.)
따라서 직접 운영해보며 클라우드를 쓰지 않는 환경에서도 스스로 인프라를 구축할 수 있도록 운영해보려고 한다.
1-3. 배포 환경 결정
현재 인프라는 다음과 같다. 마지막에 최종 인프라는 따로 있습니다. 아직 덜 완성되었습니다.
- 프론트엔드
- AWS Amplify: 호스팅, CI/CD
- 백엔드
- AWS EC2: 가상 컴퓨터 대여
- Github Actions: CI/CD
- Docker: 런타임 환경을 동일하게 유지
- Docker-compose: 일괄 서버 실행
- 이외 인프라
- AWS ALB: HTTPS 및 라우팅
- AWS Route53: DNS(도메인 네임 시스템) 매핑
2-1. CI/CD 파이프라인
|
|---|
⬆️ CI/CD 파이프라인 2-2. 무중단 배포 적용
- 고려한 무중단 배포 종류
- ✅ Blue-Green
- 현재(Blue) 환경과 새로운(Green) 환경 두 개를 사용하여 새 버전인 Green이 정상 작동하면
트래픽을 Blue ➡️ Green으로 전환- 장점: 단순, 안정성
- 단점: 블루와 그린이 같이 동작하여 리소스 중복, 구성 복잡도
- 결정한 이유: 다른 배포 방식은 여러 인스턴스가 필요할 때 효율적이라고 생각했다. 또한 롤백이 간단하고 업데이트 버전과 아닌 버전이 공존한다면 운영 측면에서 부담이 클 것이라고 생각해 블루 그린 방식을 결정하였다.
- Rolling Update
- 인스턴스 또는 컨테이너를 순차적으로 교체
- 장점: 리소스 효율, 단계적 배포
- 단점: 롤백 복잡, 상태 일관성(업데이트된 버전과 아닌 버전이 공존)
- Canary
- 새 버전을 소수의 사용자에게 노출 후 문제 없다면 점진적 확대
- 장점: 리스크 최소화, 실사용 패턴 검증
- 단점: 롤백 복잡, 설정 복잡
- Blue-Green 적용 방법
- AWS ALB 사용하여 TG 분리하기
- ALB는 TG(Target Group)별로 Health Check를 통하여 인스턴스의 상태를 확인한 후에 트래픽을 변경하게 된다. 하지만 Health Check 간격, ALB 트래픽 전환 등 시간이 지연되기에 실제로는 몇 초 ~ 몇 십초가 걸리게 된다. 몇 초 이상 걸리는 것은 내가 원하는 무중단 배포가 아니다.
- ✅ Nginx 사용하여 EC2 내부에서 분리
- 반면 Nginx를 사용하면 conf 파일을 사용해 새로운 설정을 reload 하게 되고, 이 시간은 거의 실시간에 가까운 1초 이내에 트래픽이 변경된다. 따라서 1초 이내에 끝나는 이 방법을 결정하였다.
이를 Github Actions에 적용하여 현재 배포 버전이 무엇인지에 따라 Blue or Green으로 새 버전을 띄우고 트래픽을 변경하도록 자동화하였다.
|
|---|
⬆️ Blue-Green 배포 로그
|
|---|
⬆️ Nginx 사용한 트래픽 분리 2-3. 롤백 적용
Github Actions 배포 스크립트에서 업데이트된 버전의 서버를 띄운 이후 Health check를 진행한다.
검사에 통과하지 못하고, retry 횟수 모두 실패하게 되면 이전 버전의 서버를 종료하지 않고, 트래픽을 그대로 유지한다.
|
|---|
⬆️ 배포 실패 시 롤백 로그 3. 최종 인프라
배포까지 끝이 났다. 이제 실사용자 대상으로 테스트를 해볼 예정이다. 테스트도 하면서, 업데이트도 하고, 아직 미완성인 부분도 하나씩 해나가려고 한다. 다음에는 프로젝트 평가 및 후기로 오겠습니다. 🙂
|
|---|
⬆️ 최종 인프라 
Backend-Developer