[Padong] 백엔드 구성 계획

About this offer

개요 실제 수정에 들어가기 전 prod, dev 를 어떻게 분리해서 개발하는지 대략적으로 정리해놓겠습니다 !! 백엔드 구성 프론트는 Vercel에 올렸고 백엔드는 EC2와 RDS로 따로 운영했습니다. 공모전 프로젝트라 비용은 줄이도록 노력하면서 운영 서버가 개발 작업의 영향을 받지 않도록 서버 단위로 분리하는 것을 목표로 잡았습니다. prod와 dev 서버를 EC2로 분리 처음에는 비용을 아끼려고 EC2 한 대에 prod와 dev 컨테이너를 함께 띄우는 방식을 고려했습니다. 하지만 컨테이너는 프로세스만 격리할 뿐 메모리, 디스크, CPU는 호스트를 공유합니다. dev에서 메모리를 과하게 쓰거나 로그로 디스크가 차면 prod까지 영향을 받고 서버 자체가 장애를 겪으면 둘 다 내려가기 때문에 서버를 분리했습니다. prod : ALB 뒤에 Auto Scaling이 적용된 EC2를 구성하고 각 인스턴스에서는 prod 컨테이너만 실행합니다. ALB에서 HTTPS 인증서와 도메인 연결을 처리하며 트래픽 증가에 따라 prod EC2가 자동으로 확장되도록 구성했습니다. dev : 트래픽이 거의 없으니 작은 인스턴스 한 대로 충분합니다. dev 서버는 외부에 공개할 필요가 없어서 보안 그룹에서 팀원 IP만 허용했습니다. Vercel Preview 프론트가 dev API를 호출할 때 요청은 Vercel 서버가 아니라 그 페이지를 열어 둔 사람의 브라우저에서 나갑니다. 그래서 팀원이 자기 노트북으로 Preview 페이지를 열면 그 노트북의 공인 IP가 서버에 도착하고, 등록된 IP면 통과합니다. Vercel 쪽 IP를 따로 허용할 필요는 없습니다. 서버가 나뉘었기 때문에 컨테이너마다 포트를 다르게 잡을 필요가 없고 이미지는 하나로 유지하되 서버마다 env만 다르게 주입합니다. 컨테이너에는 로그 크기 제한( max-size , max-file )을 걸어 디스크가 차는 일을 막았습니다. DB는 RDS 1개, 데이터베이스 2개 서버는 분리했지만 DB는 비용을 고려해 RDS 인스턴스 1개 안에 padong_prod 와 padong_dev 두 개의 데이터베이스 를 만드는 방식으로 갔습니다. 또한 DB 이름뿐 아니라 계정도 분리했습니다. prod_user 는 prod DB에만 dev_user 는 dev DB에만 권한을 줬기 때문에 dev 설정을 잘못 넣어도 운영 데이터를 건드릴 수 없습니다. 인스턴스를 공유하는 만큼 dev에서 무거운 쿼리를 돌리면 prod DB도 느려질 수 있다는 단점이 있습니다. 공모전 규모에서는 느려지지는 않을 거라고 생각했고 자동 백업을 켜고 RDS 접근은 EC2 보안 그룹에서 오는 요청만 허용했습니다. GitHub Secrets + Environments로 시크릿 관리 DB 주소와 계정, 비밀번호는 저장소에 두지 않고 GitHub Secrets로 관리했습니다. Settings의 Environments에 dev 와 prod 를 만들고 같은 이름의 시크릿에 환경별로 다른 값 을 넣었습니다. GitHub Actions가 실행되는 환경에 따라 같은 secrets.DB_URL 이 다른 값으로 풀리기 때문에, 워크플로 하나로 두 환경을 모두 배포할 수 있습니다. prod 환경에는 배포 승인자(Required reviewers)를 걸어 실수로 운영에 배포되는 것을 막았습니다. dev 브랜치 push → Actions(environment: dev) → dev EC2 → padong_dev main 브랜치 push → Actions(environment: prod) → prod EC2 → padong_prod

Offer details

Provider

velog

Source

velog-rss

Score

54.39

Confidence

49%