위클리 페이퍼 12주차

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

 

AWS RDS의 주요 이점

• 안정성
  • AWS IAM, KMS(Key Management Service) 연동으로 보안 수준 강화.
    • RDS의 저장 데이터를 암호화 하고, 이 키를 AWS KMS로 안전하게 관리
  • VPC 내부에 격리된 DB 구성 가능.
    • 퍼블릭 노출 없이 프라이빗 서브넷(VPC) 안에서만 접근하도록 구성 가능
    • 외부 인터넷에서 직접 접근이 불가하여 해킹 위험을 최소화 할 수 있음
  • DB 접근 제어(IP 제한 등) 손쉽게 설정 가능.
• 자동 백업 및 복구
  • 특정 시점으로 복원 가능.
  • 매일 백업 자동 수행 (설정에 한해서)
  • 스냅샨 기반 수동 백업도 가능.
• 고가용성
  • Multi-AZ 구성 시 자동 장애 조치 지원.
    • Multi-AZ는 DB 인스턴스를 두 개의 가용영역(Availabillity Zone)에 자동 복제
    • 주 인스턴스 장애 시, AWS가 자동으로 예비 인스턴스로 전환
  • 읽기 전용 Replica 구성 가능 -> Read Performance 분산.
    • RDS는 읽기 전용 복제본(Read Replica)을 따로 만들 수 있음
    • 복제본에서 읽기 전용 쿼리를 처리하면, 메인 DB의 부하를 줄이고 성능 향상

EC2 직접 설치 VS RDS

항목	EC2 직접 설치	AWS RDS
설치/운영 편의성	수동 설치, 설정 필요 (OS, DB 버전, 보안 설정 등)	클릭 몇 번으로 DB 인스턴스 생성 가능
유지보수	직접 패치 및 백업, 모니터링 설정 필요	자동 패치, 백업, 모니터링 제공
스케일링	수동 스케일 업/아웃 설정 필요 (종종 다운타임 발생)	콘솔 또는 API로 손쉽게 확장 (중단 없이 가능)
가용성	직접 장애 조치 구성 필요 (예: 이중화, 마스터-슬레이브 구성)	Multi-AZ 자동 장애 조치 지원
보안 구성	VPC, IAM, 방화벽 직접 설정	기본 제공되는 보안 기능 사용 가능 (KMS, IAM, VPC, SG 등)
비용 유연성	낮은 비용으로 자유도 높은 구성 가능	관리 편의성 포함 → 약간의 비용 프리미엄 존재
버전 및 커스터마이징	DB 소스 설정까지 완전 제어 가능	DB 버전 제한 있음, 설정 일부 제한됨
모니터링	CloudWatch, Prometheus 직접 연동 필요	CloudWatch, Performance Insights 기본 제공

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

• 특수한 DB 설정이 필요한 경우
  • PostgreSQL의 wal_level, shared_buffers, fsync 등을 세밀하게 튜닝해야 한다면 제한이 있을 수 있음
  • OS 단에서 접근하거나 DB 소스 자체를 커스터마이징해야 하는 경우
• 라이선스 문제 or OpenSource 기반 DB가 아닌 경우
  • 상용 DB(Oracle, SQL Server 등)의 특정 라이선스 모델은 RDS에서 비효율일 수 있음
• 비용 민감형 서비스 or 단일 사용자 실습 환경
  • RDS는 관리형 서비스라 EC2 직접설치보다 약간 비쌀 수 있음
  • 트래픽이 적거나, 간단한 테스트용 DB는 EC2나 로컬 DB가 더 저렴할 수 있음
• 로컬 네트워크 통합 혹은 온프레미스 시스템과의 밀접한 연동이 필요한 경우
  
  • DB를 사내망 또는 특정 네트워크 구조에 맞춰야 하는 경우엔 RDS보다 EC2 구성이 적합

---

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

 

Github Actions는 다양한 이벤트 기반 트리거를 제공하며, 특정 조건이 만족되면 자동으로 워크플로우를 실행할 수 있도록 한다.

각 트리거는 특정한 CI/CD 시나리오에 적합하며, 효율적인 자동화 파이프라인 구축에 핵심적인 역할을 함.

 

Push

특정 브랜치에 코드가 푸시되었을 때 워크플로우 실행

ex: 개발자가 코드를 커밋하고 푸시하면 자동으로 테스트/빌드 실행

on:
  push:
    branches:
      - main
      - develop

• 기본 CI 파이프라인: 테스트, 빌드 자동 실행
• 실시간 코드 품질 검증

pull_request

PR(Pull Request)가 생성되거나 업데이트될 때 실행
ex: PR 제출 시 자동으로 테스트하고 리뷰어가 보기 쉽게 결과 제공

on:
  pull_request:
    branches:
      - main

• PR 기반 코드 리뷰: PR마다 테스트/빌드 결과 확인
• 병합 전 충돌/오류 방지

workflow_dispatch

수동으로 워크플로우 실행 (UI에서 버튼 클릭)
ex: QA 환경에 수동 배포, 긴급 패치 수동 트리거

on: 
  workflow_dispatch: 
    inputs: 
      environment: 
        description: 'Deploy environment' 
        required: true 
        default: 'staging'

 

• 배포 승인 후 수동 실행
• 운영 환경 배포 수동 트리거
• 테스트/스테이징에 옵션 주입

schedule (Cron 기반)

특정 시간/주기로 워크플로우 자동 실행
ex: 매일 자정에 자동 테스트, 주간 리포트 생성

on: 
  schedule: 
    - cron: '0 0 * * *' # 매일 00:00 (UTC 기준)

• 야간 자동 테스트
• 보안 패키지 검사
• 정기 백업/보고서 생성

release

GitHub 릴리스를 생성하거나 수정할 때 실행
ex: 태깅된 릴리스 빌드 후 배포

on: 
  release: 
    types: [published]

• 버전 태그를 기준으로 자동 배포
• 릴리스 노트 작성 및 업로드 자동화

workflow_call

다른 워크플로우에서 호출 가능한 재사용 워크플로우
ex: 공통 빌드/배포 로직을 여러 프로젝트에서 공유

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

 

• 모듈화된 CI/CD 파이프라인 구성
• 재사용 가능한 공통 테스트/배포 로직

issue, issues, pull_request_target, discussion, repository_dispatch 등

이 외에도 아래와 같은 다양한 트리거가 있음

트리거	예시
issues	이슈 생성/변경 시 자동 알림, 라벨링 등
pull_request_target	보안상의 이유로 PR 외부에서 생성 시 안전한 실행
repository_dispatch	외부 시스템에서 GitHub API로 이벤트 트리거
discussion	Discussion 생성 시 Slack 알림 전송 등

 

요약

트리거	예시
push	커밋 기반 자동 테스트, 린트
pull_request	PR 생성 시 자동 검증
workflow_dispatch	수동 배포, QA용 유연한 트리거
schedule	주기적 테스트, 리포트 생성
release	버전 태깅 후 배포 자동화
workflow_call	재사용 가능한 CI 템플릿 구성