위클리 페이퍼 - 12주차

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

AWS RDS(Relational Database Service)

 - AWS에서 제공하는 완전 관리형 관계형 데이터베이스 서비스(데이터베이스 인프라의 설정, 운영, 확장을 AWS가 대신 처리)

 

지원 데이터베이스 엔진

• MySQL
• MariaDB
• PostgreSQL
• Oracle Database
• Microsoft SQL Server 등

AWS EC2 (Elastic Compute Cloud)

 - AWS 클라우드에서 제공하는 가상 서버(인스턴스) 서비스

 - 다양한 운영체제와 애플리케이션을 실행할 수 있는 확장 가능한 컴퓨팅 용량을 제공

 

RDS 활용 시의 이점

1. 관리 부담 감소
   • 서버 설치, 패치, 정기 백업 등 복잡한 관리 작업을 AWS가 자동으로 처리
   • 데이터베이스 엔진의 마이너 버전 업그레이드 자동화
   • 모니터링과 성능 메트릭이 CloudWatch를 통해 기본 제공
2. 고가용성과 내구성
   • Multi-AZ(다중 가용 영역) 구성을 통해 장애 발생 시 예비 인스턴스로 자동 전환되어 서비스 중단을 최소화
   • Read Replica를 통한 읽기 성능 향상과 부하 분산
3. 보안 강화
   • VPC(Virtual Private Cloud) 내에 DB를 배치하거나, IAM(Identity and Access Management)을 활용해 접근 권한을 제어하는 등 보안 설정을 쉽게 강화
4. 간편한 백업과 복구
   • 몇 번의 클릭만으로 자동 백업을 설정할 수 있으며, 특정 시점으로 복구도 가능

EC2에 직접 DB를 설치하는 경우와의 차이점

항목	RDS 사용	EC2에 DB 직접 설치
설치 및 설정	AWS에서 자동으로 처리	사용자가 직접 설치 및 설정 필요
유지보수	자동 백업, 복구, 패치 지원	모두 수동으로 처리
장애 대응	자동 페일오버 지원(Multi-AZ)	수동 복구 또는 별도 이중화 구성 필요
보안 설정	IAM, VPC 등으로 손쉽게 설정	직접 구성해야 함(복잡한 설정)
시스템 제어 범위	제한적	전체 시스템 제어 가능
비용	라이센스 및 관리 비용 포함	사용한 EC2, 스토리지 자원에 대한 비용만 발생

RDS가 적합하지 않은 상황

• 세밀한 시스템 설정이 필요한 경우
  • RDS는 일부 시스템 설정이 제한되므로, 설정을 최적화해야 하는 특수한 경우에는 적합하지 않을 수 있음
• 소규모 프로젝트나 간단한 테스트 환경
  • RDS는 최소 스펙이 정해져 있어, 소규모 프로젝트나 테스트 환경에는 과한 선택일 수 있음
  • 이럴 때는 EC2에 직접 설치하거나 로컬 환경을 활용하는 것이 더 효율적

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

1. 코드 관련 트리거

1. push

• 특정 브랜치에 커밋이 push될 때 워크플로우 실행
• 적합한 시나리오
  • CI : 새 커밋마다 자동으로 빌드 및 테스트 수행
  • CD : 배포를 위한 브랜치에 푸시되면 자동으로 배포 수행

on:
  push:
    branches: [ main ]

 

2. pull_request

• PR(Pull Request)이 생성/업데이트될 때 워크플로우 실행
• 적합한 시나리오
  • PR 검증 : 변경사항이 main에 병합되기 전에 해당 코드에 문제가 있는지 확인

on:
  pull_request:
    branches: [ main ]

 

3. workflow_dispatch

• 수동으로 워크플로우 실행
• 적합한 시나리오
  • 운영 환경에 민감한 작업: 프로덕션 배포는 수동 실행만 허용

on:
  workflow_dispatch:
    inputs:
      environment:
        description: '배포 환경'
        required: true
        default: 'production'

 

4. repository_dispatch

• 외부 시스템에서 API 호출 시 워크플로우 실행
• 적합한 시나리오
  • 외부 CI/CD 도구와 연동
  • 다른 리포지토리에서 트리거 제어가 필요할 때

on:
  repository_dispatch:
    types: [custom-event]

2. 이슈 관련 트리거

1. issues

• 이슈가 열림, 수정, 닫힘 등의 이벤트 발생 시 실행.
• 적합한 시나리오
  • 이슈 생성 시 자동 템플릿 응답이나 알림 전송
  • 이슈 닫힘 시 관련 브랜치 삭제

on:
  issues:
    types: [opened, closed]

 

2. issue_comment

• 이슈나 PR에 댓글이 달릴 때 실행.
• 적합한 시나리오
  • 댓글에 명령어(/deploy)입력 시 자동 배포
  • 리뷰어 코멘트에 따라 테스트 재실행

on:
  issue_comment:
    types: [created]

 

3. pull_request_review & pull_request_review_comment

• pull_request_review : 리뷰 제출 이벤트
• pull_request_review_comment : 리뷰 코멘트 작성 이벤트
• 적합한 시나리오
  • 리뷰 승인 시 자동 병합
  • 특정 키워드 리뷰 코멘트로 빌드 재시작

3. 스케줄 기반 트리거

1. schedule

• 크론(Cron) 표현식으로 주기적으로 실행
• 적합한 시나리오
  • 정기 빌드 및 배포
  • 주기적인 종속성 업데이트 확인
  • 로그 백업이나 정리 작업

on:
  schedule:
    - cron: '0 0 * * *' # 매일 자정 실행

4. 기타 이벤트 트리거

1. workflow_call

• 다른 워크플로우에서 이 워크플로우를 호출 가능
• 적합한 시나리오
  • 공통 빌드/배포 파이프라인 모듈화
  • 여러 프로젝트에서 재사용하는 공통 테스크 워크플로우

on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string

 

2. release

• GitHub Release 생성,수정,게시 이벤트 시 실행
• 적합한 시나리오
  • 릴리스 태그 빌드 및 아티팩트 업로드
  • 릴리스 베포 자동화

on:
  release:
    types: [published]