[12] AWS의 RDS와 Github Actions

01. AWS RDS vs EC2 직접 설치

AWS에서 데이터베이스를 구축하는 방법은 크게 가상 서버인 EC2에 직접 설치하는 방식과 관리형 서비스인 RDS를 활용하는 방식으로 나뉜다. 이 두 방식은 관리 책임의 범위 (Shared Responsibility Mode)에서 가장 큰 차이를 보인다.

 

1. EC2 (Elastic Compute Cloud) 란?

EC2란 클라우드에서 제공하는 가상 서버 그 자체를 뜻하는, IaaS의 대표적인 모델이다. 즉, 사용자는 AWS 데이터 센터에 있는 물리적 자원을 논리적으로 쪼개어, 원하는 사양(CPU, RAM 등)의 가상 컴퓨터를 할당 받는 것을 의미한다. 이러한 EC2는 웹 서버, 연산 서버, 커스텀 DB 환경 등에 활용된다.

 

사용자는 할당 받은 가상 서버에 운영체제를 비롯한 소프트웨어를 직접 설치해야 할 뿐만 아니라, 운영체제 설정 변경, 보안 패치, 데이터 백업, 소프트웨어 업데이트 등 인프라 전반에 걸친 관리 작업을 직접 수행해야 한다.

 

2. RDS (Relational Database Service) 란?

RDS란 데이터베이스 운영에 최적화된 환경을 제공하는 관리형 서비스를 뜻하는, PaaS에 가까운 모델이다. 즉, 사용자는 직접 서버와 데이터베이스를 구축할 필요없이, 즉시 사용 가능한 상태의 데이터베이스 인터페이스를 제공 받는 것을 의미한다.

 

사용자는 서버 본체에 직접 접근하는 대신 제공된 엔드포인트 주소를 통해서만 해당 데이터베이스에 접속할 수 있을 뿐만 아니라, ES2와 달리 운영체제의 관리 권한을 AWS가 소유하여 사용자는 오직 데이터베이스 관리와 관련된 권한과 책임만 부여 받는다.

 

3. EC2 vs RDS

	EC2	RDS
개념	범용 가상 서버	데이터베이스 전용 관리 서비스
설치 작업	OS 설정부터 DB 설치까지 직접 수행	클릭 한 번으로 자동 설치 및 구성
제어권	OS를 포함한 전체 제어 가능 (Root 권한)	데이터베이스 설정만 가능
OS 접근	SSH로 접속해서 OS 수정 가능	불가능
백업 / 패치	사용자가 수동으로 스케줄링 및 수행	AWS 설정에 따라 자동 수행
유연성	높음 (환경 커스텀 가능)	낮음 (지원되는 엔진 내 사용)
편의성	낮음 (관리 포인트 많음)	높음 (운영 자동화)
주요 용도	웹 서버, 연산 서버, 커스텀 환경	데이터베이스 저장 / 관리

 

4. EC2 직접 운영 대비 RDS의 강점

앞서 언급한 것과 같이, RDS는 인프라 관리 부담을 덜어줄 뿐만 아니라 운영 안정성과 효율성 측면에서 다음과 같은 차별화된 기능을 제공한다.

 

RDS의 차별화 기능
자동 패치 (Automated Patching)	사용자가 설정한 유지보수 시간에 맞춰 DB 엔진의 보안 패치 및 업데이트를 자동으로 진행
다중 AZ 고가용성 (Multi-AZ)	버튼 하나로 다른 가용 영역에 복제본을 생성하여, 메인 DB 장애 시 자동 장애 극복(Failover)이 발생
읽기 전용 복제본 (Read Replicas)	읽기 전용 복제본을 생성하여 조회 쿼리을 분산함으로써 성능 최적화에 용이

 

	EC2	RDS
관리 부담	설치, 업데이트, 백업 등을 모두 직접 수행	자동화된 관리 환경 제공 (백업, 패치 등)
안전성	장애 발생 시 직접 복구	장애 발생 시 자동 복구 및 인스턴스 교체
확장성	사양 변경 시, 복잡한 수동 작업 수반	클릭을 통해 인스턴스 사양 및 용량 변경 가능
비용	순수 서버 인스턴스 비용만 발생	관리 비용이 포함되어 상대적으로 단가가 높음

 

5. RDS가 적합하지 않을 수 있는 상황

RDS 비적합 상황
OS 계층 접근 필요	특정 운영체제 설정이나 시스템 레벨의 라이브러리 활용이 필수적인 경우
비표준 DB 엔진 사용	AWS가 공식적으로 지원하지 않는 특수 엔진이나 지원이 종료된 구버전을 사용해야 하는 경우
커스텀 최적화 및 확장 프로그램	DB 엔진 소스코드 수정, 커널 파라미터 미세 튜닝, 혹은 AWS 권한 문제로 설치 불가능한 외부 플러그인이 필요한 경우
비용 극대화 전략	인건비나 운영 효율보다 순수 인프라 비용 절감이 최우선인 소규모 프로젝트인 경우

 

---

 

02. Github Actions 트리거 (Trigger)

1. Github Actions이란?

Github Actions은 소프트웨어 개발 워크플로우를 자동화해 주는 도구를 뜻한다. 즉, 특정 이벤트가 발생했을 때, 독립적인 컨테이너를 동적으로 할당받아, 그 내부에서 미리 정의된 스크립트를 실행하는 시스템을 의미한다.

 

2. Github Actions 트리거 (Trigger) 란?

Github Actions 트리거란 워크플로우 실행을 유도하는, 실행의 스위치를 뜻한다. 즉, Github 환경 내에서 발생하는 특정 사건(Event)을 감지하여, 해당 컨테이너의 실행 시점을 결정하는 웹훅(Webhook) 기반의 매커니즘을 의미한다.

 

3. 주요 트리거 유형

GitHub Actions에서 가장 빈번하게 사용되는 트리거들을 CI/CD 파이프라인의 목적에 따라 분류하면 다음과 같다.

 

1. 지속적 통합의 시작 (push)

개발자가 로컬에서 작업한 코드를 원격 저장소인 Githiub 특정 브랜치에 업로드하는 순간 발생하는 트리거를 뜻한다. 즉, 새로운 코드가 병합될 때마다 단위 테스트(Unit Test)를 수행하고, 코드 변경 사항이 기존 시스템의 안정성을 깨뜨리지 않는지 즉각적으로 검증하는 트리거를 의미한다.

 

2. 코드 품질 관리의 관문 (pull_request)

특정 브랜치의 코드를 다른 브랜치로 병합(Merge)하기 위해 검토를 요청하는 순간 발생하는 트리거를 뜻한다. 즉, 팀원의 코드 리뷰 전, 빌드 성공 여부 및 정적 코드 분석 결과를 미리 확인하여 불필요한 리뷰 시간을 줄이는 코드 리뷰 도우미 역할을 수행하는 트리거를 의미한다.

 

3.  정기적 유지보수 (schedule)

사용자가 설정한 주기(Cron 표현식 기반)에 따라 정기적으로 실행되는 트리거를 뜻한다. 즉, 트래픽이 적은 시간에 전체 통합 테스트, 만료된 로그 정리, DB 인덱스 재구성, 보안 취약점 스캔 등을 수행하는 주기적인 점검 및 유지보수에 적합한 트리거를 의미한다.

 

4.  수동 제어 및 배포 (workflow_dispatch)

Github UI 내에서 관리자가 수동으로 버튼을 눌러 워크플로우를 실행할 때 발생하는 트리거를 뜻한다. 즉, 자동 배포가 위험할 수 있는 운영 환경에 대해, 담당자가 최종 승인 후 수동으로 배포를 진행하고자 할 때 사용되는 트리거를 의미한다.

 

3. 주요 트리거와 CI/CD 시나리오

 

트리거 유형	동작	시나리오
push	특정 브랜치에 커밋 발생	지속적 통합 (CI, Continuous Integration) : 변경 시마다 자동 테스트 및 정적 분석 수행
pull_request	PR이 생성 및 업데이트	코드 리뷰 도우미 (Code Review Helper) : merge 전, 빌드 안정성 및 품질 검증
schedule	지정된 주기(Cron)	정기적 유지보수 (Maintenance) : 정기적인 시스템 점검 및 데이터 정리
workflow_dispatch	UI에서 관리자가 수동 실행	지속적 배포 (CD, Continuous Deployment) : 운영 환경 배포 전 최종 수동 확인