[위클리 페이퍼] AWS RDS, GitHub Actions CI/CD

이번주 위클리 페이퍼의 주제는

AWS RDS를 활용하는 주요 이점과 EC2에 직접 데이터베이스를 설치하여 운영하는 것과 비교했을 때의 차별점에 대해 설명해보자. 그리고 RDS를 사용하는 것이 적합하지 않을 수 있는 상황도 함께 설명하자.

GitHub Actions 워크플로우에서 사용할 수 있는 다양한 트리거 유형을 설명하고, 각 트리거 유형이 적합한 CI/CD 시나리오에 대해 설명해보자.

 

 

AWS RDS

Amazon Relational Database Service(Amazon RDS)는 AWS 클라우드에서 관계형 데이터베이스를 더 쉽게 설치, 운영 및 확장할 수 있는 웹 서비스입니다. 이 서비스는 산업 표준 관계형 데이터베이스를 위한 경제적이고 크기 조절이 가능한 용량을 제공하고 공통 데이터베이스 관리 작업을 관리합니다

 

AWS에서는 RDS에 대해 위와 같이 설명하고 있다.

AWS RDS는 우리가 흔히 사용하는 관계형 데이터베이스들(MySQL, Oracle Database, PostgreSQL 등)의 엔진을 사용할 수 있고 자동 백업 기능과 스냅샷 기능으로 안정적인 데이터베이스 복원 프로세스를 제공해준다.
또한 CloudWatch와 연동해 DB에서 발생하는 오류 로그들이나 인스턴스를 모니터링 할 수 있다.

AWS RDS는 고가용성을 위해  Multi AZ를 지원한다. 마스터 RDS에 장애가 발생하면 다른 AZ(가용영역)에 설치되어 있던 RDS 인스턴스를 실행시켜 시스템이 중단하지 않고 서비스를 제공할 수 있게 해준다.
또한 데이터나 트래픽 증가 시 RDS는 데이터베이스를 쉽게 수직 또는 수평으로 확장할 수 있도록 해준다.

EC2에 직접 데이터베이스를 설치하여 운영할 수도 있다. 

RDS에 비해 훨씬 저렴하게 데이터베이스를 사용할 수 있다. 하지만 수동으로 직접 데이터베이스를 설치해야하고 RDS처럼 고가용성을 보장하려면 직접 수동으로 클러스터를 구성한다든가 해야한다. 보안에 관한 부분도 RDS는 VPC 설정, 자동 암호화 기능을 제공하지만 EC2에 데이터베이스를 설치해 운영할 경우 직접 구현해야한다. 

RDS 사용이 적합하지 않은 경우

하지만 AWS RDS에서 지원하지 않는 DB 엔진을 사용할 경우가 있을 수 있다. 

또한 비용 최적화가 필수적인 경우 RDS를 사용하기 적합하지 않다. 

그리고 운영체제나 DB 튜닝에 대해서 세밀한 제어가 필요한 경우 (커널 파라미터 조절 등) RDS는 적합하지 않다. 

 

 

 

GitHub Actions의 트리거 유형

GitHub Actions 워클플로우에는 다양한 트리거 유형이 있다. 트리거는 워클플로우가 실행되는 조건을 정의하는 설정이다.

GitHub Docs에서 워크플로우 트리거 유형을 정리해둔 페이지가 있다.

몇 가지 유형과 적절한 시나리오를 살펴보자.

 

1. push

커밋이나 태그를 푸시하면 워크플로우가 실행된다. 특정 브랜치에 푸시가 발생하는 경우메만 실행하도록 설정할 수 있다. (그 외에도 특정 태그가 푸시될 때 실행하기 등 여러 설정이 있다.)

<시나리오>  주요 브랜치 (main, dev 등)에 Push가 생길 때 자동 테스트/배포를 진행할 수 있다.

 

2. pull_request

워크플로우 대상 저장소에 Pull Request 관련 활동이 발생하면 워크플로우가 실행된다. (병합 충돌이 있는 경우 실행되지 않는다)

Pull Request에 리뷰나 코멘트가 생성되면 워크플로우가 실행되는 등 여러 파생 유형이 존재한다.

<시나리오>  main에 병합 전에 문제가 발생하는지 테스트 할 수 있다.

 

3. issue_comment

이슈나 PR에 코멘트를 작성하면 워크플로우가 실행된다.

<시나리오>  "/deploy" 와 같이 명령어 형식의 코멘트를 통해 작업을 실행할 수 있다.

 

4. repository_dispatch

외부에서 발생하는 활동에 대해 워크플로우를 트리거 할 수 있다. (GitHub API를 활용하여)

<시나리오>  외부 CI/CD 툴과 연동해 원하는 시점에 실행할 수 있다.