[DevOps] 프로젝트 Dev/Prod 서버 아키텍처 설계 경험 정리

INTRO

이 포스팅은 카카오테크 부트캠프 클라우드 네이티브 제주 2기 과정 마지막 팀 프로젝트에서 DevOps를 담당하며 진행했던 업무와 트러블슈팅을 기록한 내용입니다.

저희가 개발한 Modie는

"일회성 모임을 쉽고 빠르게 모집하고, 일정 조율부터 정산까지 한 번에 해결할 수 있는 서비스"입니다.

Modie 서비스의 1차 출시가 완료된 후, 본격적인 2차 기능 개발에 돌입하기 전에 그동안의 과정을 블로그에 정리해보고자 합니다.

• 서비스 링크: https://modie.site

MODiE

 

---

프로젝트 구조

프로젝트는 React와 Spring Boot를 기반으로 개발하였고,
저는 이 개발된 결과물이 안전하게 운영될 수 있도록 배포 인프라를 구축하는 역할을 맡았습니다.

이전까지는

• EC2 인스턴스에 Docker를 띡 설치해서 배포하거나,
• GitHub Actions + ECR + Nginx 조합으로 포트 스왑(Blue-Green 배포)만 겨우 구현해본 정도였습니다.

그래서 이번 프로젝트 초반에는 조금 막막했지만,
그 당시 블루그린 배포를 처음 해봤을 때 "어렵다" 보다는 "재밌다!" 라는 느낌이 더 강했기에
크게 거부감 없이 DevOps 업무를 맡아 진행할 수 있었습니다.

---

본격 구축 이야기

서론이 길었는데,
이제 어떤 방식으로 인프라를 구축했는지 기록해보겠습니다.

최종 구축한 시스템 아키텍처는 다음과 같습니다.

---

Dev / Prod 시스템 아키텍처

Dev, Prod 시스템 아키텍처

---

원래 정석은

Dev → Sandbox → Staging → Production
이렇게 단계별로 서버를 분리하여 세팅하는 것이 관리나 운영 면에서 훨씬 용이합니다.

멘토님께서도 이 구조를 추천해주셨습니다.

하지만 그 조언을 들은 시점은 이미

• Dev 서버
• Production 서버
  구성이 모두 끝난 뒤였고,
  출시 일정이 임박해 있는 상황이라 서버 구조를 새로 뜯어고칠 수는 없었습니다.

결국 이번 프로젝트에서는 Dev 서버 1대, Prod 서버 1대를 가지고 개발과 운영을 병행했습니다.
(운영할 인스턴스 수가 많지 않아 큰 문제는 없었습니다.)

다만 이번 경험을 통해

"정석 구조로 서버를 나누어 관리하는 것이 얼마나 중요한지"
깨달을 수 있었습니다.

---

Dev 서버 설명

Dev 서버는 단일 EC2 인스턴스에

• GitHub Actions
• Amazon ECR
• Nginx 포트 스왑 방식
  을 이용해 배포 자동화 환경을 구축했습니다.

개발 중 기능 추가나 수정사항이 생기면,
코드를 Push → 자동 빌드 → 새로운 컨테이너 이미지를 ECR에 Push → 서버가 Pull하여 교체하는 흐름입니다.

---

Prod 서버 설명

Prod 서버는

더 많은 트래픽을 안정적으로 감당할 수 있는 구조를 목표로 설계했습니다.

그래서

• Auto Scaling Group(ASG)
• Application Load Balancer(ALB)
  를 활용해 자동 스케일 아웃 구조를 만들었습니다.

또한,

• GitHub Actions로 자동 빌드
• Amazon ECR로 컨테이너 이미지 저장
• EC2 인스턴스에서 Pull하여 롤링 배포

이 흐름을 통해 실서비스 운영에 적합한 인프라를 구축할 수 있었습니다.

 

다음 포스팅에선 데브서버와 프로덕션 서버의 디테일 한 부분을 다뤄보겠습니다.