프로젝트 개요
학부에서 여러 팀 프로젝트를 수행하면서 관계형 데이터베이스 ERD 를 설계하는 일이 많았습니다. 다양한 ERD 설계 툴을 사용해 보고, 지난 프로젝트 동안 팀원 간의 ERD 설계의 경험을 바탕으로 버전 관리 기능과 공유 기능이 있는 ERD 툴의 필요성을 느껴서 AUTOSQL을 제작하게 되었습니다.
시연 동영상
개선 및 문제 해결
AWS 로 Development 환경 이관 작업 진행 중
Legacy Infra
현재 Autosql 의 인프라는 Oracle Cloud 의 Compute 인스턴스에 다음과 같이 배포되어 있습니다.
•
Nginx의 Reverse Proxy 기능으로 랜딩페이지와 React 앱, Node 앱에 트래픽을 포워딩
•
React App 과 Node App 프로세스는 PM2로 관리
•
데이터베이스는 Local 에 상주하여 오직 Node App 과 통신
현재 어플리케이션 배포 과정
프론트와 백엔드의 배포는 각각 담당자의 Github Repository 의 소스코드를 pull 하여 배포되고, 그때 마다 PM2 와 Nginx 를 restart 하는 방식으로 어플리케이션의 변경 사항을 적용합니다.
문제 상황
1.
오류 개선이나 기능 추가가 어려움
•
프론트와 백엔드 소스코드가 각각 담당 개발자의 repository 에 분산되어 있음
•
매번 소스코드 변경시 서버에 원격 접속하여 서버 프로세스들을 재시작하고 정상적으로 동작하는지 확인해야 함
2.
무수히 많은 단일 장애점
•
Oracle Cloud 의 Compute Instance 하나에 모든 어플리케이션과 데이터베이스가 배포되어 있어서 Oracle Cloud 또는 Instance 자체 장애 발생시 모든 어플리케이션이 Down 됨
•
어플리케이션의 Replicas 는 각각 하나 씩만 존재함
3.
데이터베이스 백업이 이루어지지 않음
•
로컬에 배포되어 있는 데이터베이스 Backup 에 대한 정책이 마련되어 있지 않음
개선 방법
1.
CI, CD 를 위해 Github Organization 에 repository 를 통합하고 Github Actions 을 통한 지속적인 배포 파이프라인 필요
•
Github Organization : https://github.com/autosql
•
Frontend : https://github.com/autosql/frontend
•
Backend : https://github.com/autosql/backend
2.
AWS 로 모든 인프라를 이관하여 가용 영역에 어플리케이션 분산 및 Replicas 를 2개 이상 유지
•
테라폼으로 AWS 인프라를 관리
•
백엔드는 ECS 클러스터에 배포, 프론트엔드는 CloudFront 에 배포
•
Infrastructure : https://github.com/autosql/infra
3.
AWS 관리형 데이터베이스 RDS 를 사용하거나, 인스턴스에 데이터베이스를 구축하여 S3 로 백업하는 등의 백업 정책 마련 필요
현재 데이터베이스 구축에 대한 방법을 구상하고 있습니다.
대안 1 : RDS 로 관리하고 데이터베이스 인스턴스 유형을 db.t2.micro 로 둠
Pros
•
백업 정책 마련할 필요 없음
•
가용성이 보장됨
Cons
•
월 6$ 의 비용
최소한의 컴퓨팅 리소스와 비용 절감 필요
어플리케이션 컴퓨팅 리소스 사용량 (상시)
App | CPU ( 2 vCPU / %) | Memory (680mb / mb) |
Nginx (Worker) | 0 % ~ 0.1 % | 13.6 mb |
React App | 0 % | 32 mb |
Node App | 0 % ~ 0.1 % | 47 mb |
Mysql | 0.1 % | 36.04 mb |
높은 트래픽 발생시 어플리케이션의 컴퓨팅 리소스 사용량은 체크하지 못하였으나
상시 가동에 필요한 리소스는 매우 낮으므로 AWS 에 인프라 구축시 컴퓨팅 리소스를 최대한 사용하지 않는 방향으로 인프라를 구축해야 합니다. 따라서
•
프론트엔드 React App 과 HTML은 S3 Bucket 에 배포
◦
현재 구현되어 있는 React App 은 CSR 방식이므로 정적 리소스 형태로 배포해도 문제가 없다고 판단
◦
S3 bucket 의 정적 웹 호스팅 기능을 사용하여 CloudFront 와 연결
⇒ 개발 환경 구축 동안 잦은 캐시 무효화 및 많은 배포로 인해 6월 3주차에 CloudFront 비용이 99$ 나 과금되어 CloudFront 를 내리고 Nginx 웹서버의 Reverse Proxy 기능으로 트래픽을 S3 Bucket 로 Forwarding 하는 방식을 선택
•
Node App 은 컨테이너라이징하여 ecs Fargate 에 배포하는 방식을 선택
◦
API 서버를 유지하기 위해 EC2 인스턴스로 구축시 최소 2개의 인스턴스를 가동해야 가용성이 보장되므로 EC2 에 배포하는 것은 선택하지 않음
◦
ECS 는 AWS 관리형이므로 클러스터 비용은 무료이고, 컴퓨팅 비용을 최소화 하고자 FARGATE 유형에 배포하는 방식을 선택
◦
예상 비용 월 10$
테라폼 cli 를 사용하며 불편한 점을 Bash Script 로 개선
1. 디렉터리 구조로 환경 분리
테라폼으로 autosql 인프라 구성시 처음에는 다음과 같은 디렉터리 구조로 개발을 하였습니다.
/
|
|- modules
|
|- live
Bash
•
modules 디렉터리에 vpc, frontend 등 어플리케이션 Tier 별 디렉터리로 묶어 모듈 구성
•
terraform.workspace 를 사용하여 리소스의 네이밍 컨벤션을 지정하여 환경 별 배포시 리소스 이름 중복 제거
다만 디렉터리를 이와 같이 분리할 경우
현재 어떤 환경이 인프라에 배포되어 있는지 눈에 명확하게 보이지 않았습니다.
따라서 live 디렉터리를 → 배포 환경 별 디렉터리로 다시 구분하여 구성하였습니다.
/
|
|- modules
|
|- dev
Bash
•
현재 dev 환경만 구축 중임
•
디렉터리 구조만 보더라도 현재 어떤 환경이 구축되어 있는지 명확해짐
2. 디렉터리 구조 분리 + terraform workspace
현재 구현되어 있는 테라폼 module 들은 리소스 이름에 var.env 를 포함하여 네이밍을 지정하였습니다.
따라서 디렉터리 구조로 환경을 분리했더라도 모듈의 input 으로 env 변수에 terraform.workspace 값을 지정해주어야 합니다.
이중으로 환경을 분리하여 실수로 다른 환경의 인프라가 prod 환경의 인프라로 배포되는 상황을 방지할 수 있는 좋은 수단이라고 생각하였습니다.
/
|
|- modules
|
|- dev
|- vpc
|- backend
Bash
이중으로 환경을 분리하여 인프라를 구성한 결과
테라폼 커맨드 사용시 매번 다음과 같은 순서로 커맨드를 입력해야 했습니다.
cd ./dev/backend
terraform workspace show
terraform workspace select dev
terraform apply -var-file=../../global/g.tfvars -var-file=./variable.tfvars
Bash
•
매번 cd 커맨드로 디렉터리를 이동해야 함.
•
매번 terraform workspace 가 dev 로 설정되어 있는지 확인하고, 설정되어 있지 않다면 dev 환경을 선택해야함.
3. do-terraform 스크립트를 적용
디렉터리 구조로 배포 환경을 명확히 하고 terraform.workspace 로 모듈 구성을 편리하게 하고자 이중으로 환경을 분리하였으나 매번 불필요한 커맨드를 많이 입력하게 되어 그 과정을 단 한번의 커맨드로 단축하고자 스크립트를 작성하였습니다.
do-terraform 스크립트를 root 디렉터리에서 사용하면 다음과 같이 사용할 수 있습니다.
/
|- do-terraform.sh
|
|- modules
|
|- global
|- g.tfvars
|- dev
|- backend
|- main.tf
|- variables.tf
|- outputs.tf
|- var.tfvars
Bash
$ ./do-terraform.sh -g ./global/g.tfvars -y -l autosql-terraform-logging ./dev/backend dev apply
Bash
•
./dev/backend 의 테라폼 코드를 dev workspace 에서 apply 함
•
-g 옵션을 통해 프로젝트 내에 글로벌하게 적용될 변수들의 값을 포함시킴
•
-y 옵션을 통해 테라폼 autoapprove 옵션을 적용
•
-l 옵션을 통해 do-terraform 스크립트의 커맨드 log 를 S3 bucket 에 sync 함
•
추가로 현재 작업 디렉터리내에 있는 ./*.tfvars 파일을 모두 -var-file=./*.tfvars 형태로 커맨드를 수행함
추후 방향
•
스크립트를 계속 develop 하여 github actions 에서 사용가능한 형태로 제작
•
다른 terraform 관리 툴을 사용하여 테라폼 구성
