Jung Hyun

위클리페이퍼09-2: 클라우드 환경에 프로그램 배포하기

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

Q1-1. 답변

AWS RDS를 활용하는 주요 이점

  • 자동화된 운영 및 관리
    • 데이터베이스 백업, 소프트웨어 패치 적용, 하드웨어 프로비저닝, 모니터링 등 시간이 많이 소요되는 데이터베이스 관리 작업을 AWS가 자동으로 처리 가능
  • 고가용성과 신뢰성
    • 다중 AZ(Multi-AZ) 배포를 통해 동기식 복제본을 유지하며, 장애 발생 시 대기 인스턴스로 자동 페일오버(Failover)를 지원하여 다운타임을 최소화하고 데이터 내구성을 보장
  • 유연한 확장성
    • 애플리케이션의 수요 변화에 맞춰 클릭 몇 번으로 컴퓨팅 및 스토리지 리소스를 쉽게 확장(Scale-up)하거나, 읽기 전용 복제본을 추가하여 확장(Scale-out) 가능
  • 보안성 강화
    • 저장 데이터 및 전송 중 데이터 암호화, VPC를 통한 네트워크 격리, IAM을 통한 접근 제어 등 데이터 보호를 위한 강력한 보안 기능을 기본적으로 제공

EC2에 직접 데이터베이스를 설치하는 것과의 차별점

EC2와 RDS의 가장 큰 차이는 관리 및 운영의 책임 범위에 있음.

  • EC2 인스턴스에 직접 설치 시
    • AWS는 하드웨어 인프라와 운영체제 설치 정도만 관리하며, 사용자가 데이터베이스 설치, 운영체제 및 DB 소프트웨어 패치, 백업 스크립트 작성, 고가용성 확보, 서버 확장 등을 모두 직접 구현하고 책임져야 함. 이로 인해 운영 부담이 크고 수동 업데이트 과정에서 인적 오류나 가동 중지 시간이 발생할 위험이 높음
  • RDS 활용 시
    • 하드웨어부터 운영체제 패치, 데이터베이스 설치 및 패치, 백업, 고가용성(Multi-AZ), 스케일링에 이르는 인프라 유지보수 영역을 AWS가 모두 대행함. 결과적으로 사용자는 인프라 운영 부담에서 벗어나 SQL 쿼리 작성, 데이터 모델링, 애플리케이션 성능 최적화 등 핵심 비즈니스 로직에만 집중할 수 있음.

RDS 사용이 적합하지 않을 수 있는 상황

  • 비용이 최우선인 단순 테스트/학습 환경
    • RDS는 관리형 서비스의 이점을 제공하는 대신 서버 운영비용 외에 서비스 관리 비용이 추가로 발생하므로, 단순한 테스트나 학습 목적이라면 로컬 DB를 사용하는 것이 비용 측면에서 더 합리적
  • 운영체제(OS) 수준의 직접 접근이 필요한 경우
    • 표준 RDS는 호스트 시스템에 대한 사용자의 직접적인 접근(SSH 등)을 허용하지 않음
  • 특수한 데이터베이스 설정이나 사용자 지정 확장이 필수적인 경우
    • 표준 RDS 환경에서는 제어할 수 없는 데이터베이스 내부의 고도화된 설정, 권한, 또는 지원하지 않는 외부 모듈(확장 프로그램) 설치가 필요할 수 있음. 이런 환경적 제약을 벗어나 데이터베이스나 운영체제 환경을 사용자 지정해야 한다면, RDS Custom 서비스를 이용하거나 EC2에 직접 DB를 설치하여 운영하는 것이 적합

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

Q2-1. 답변

GitHub Actions에서 Trigger란?

Workflow를 실행시키는 ‘이벤트’를 의미함. 단순히 코드가 올라갈 때뿐만 아니라, 특정 시간이나 외부 신호에 의해서도 자동화를 시작할 수 있음.

주요 트리거 유형 및 활용 시나리오

  1. 이벤트 기반 Trigger (Event-driven)
    • 가장 보편적인 방식으로, 저장소 내의 변경 사항에 반응
    • push
      • 특정 branch에 코드가 commit되거나 merge되었을 때 실행
      • 적합한 시나리오
        • main branch에 코드가 merge된 후 즉시 배포(CD) 를 진행하거나, 개발 branch에서 작업 내용을 공유할 때 build 확인용으로 사용
    • pull_request
      • PR이 생성, 동기화(update), 또는 재오픈될 때 실행
      • 적합한 시나리오
        • 코드 리뷰 단계에서 테스트(Unit Test) 나 Lint 체크를 자동화하여, 결함이 있는 코드가 branch에 merge되는 것을 방지하는 Quality Gate 역할을 수행합니다.
  2. 수동 Trigger (Manual)
    • 사용자가 직접 버튼을 눌러 Workflow를 가동
    • workflow_dispatch
      • GitHub UI나 API를 통해 수동으로 실행.
      • 적합한 시나리오
        • 정기 배포 외에 긴급 롤백(Rollback) 을 수행하거나, 특정 환경(Staging, QA)에 선택적 배포를 해야 할 때 유용
  3. 스케줄 Trigger (Scheduled)
    • 정해진 시간에 주기적으로 실행.
    • schedule
      • cron 표현식을 사용하여 실행 시간을 설정. (예: 0 0 * * * 는 매일 자정)
      • 적합한 시나리오
        • 매일 새벽에 수행하는 Batch 작업, 의존성 라이브러리의 보안 취약점을 점검하는 Daily Scan, 또는 사용량이 적은 시간대의 DB 백업에 적합
  4. 연쇄 및 외부 Trigger (Chained & External)
    • 다른 Workflow의 결과나 외부 서비스의 신호를 받음
    • workflow_run
      • 특정 Workflow가 완료(성공 또는 실패)된 후 실행
      • 적합한 시나리오
        • ‘build 및 테스트’ Workflow가 성공한 직후에만 ‘배포’ Workflow를 실행하고 싶을 때 사용합니다.
    • repository_dispatch
      • GitHub 외부 시스템(예: 사내 관리 도구, 다른 클라우드 서비스)에서 Webhook을 보내 실행합니다.
      • 적합한 시나리오: 외부 CMS에서 콘텐츠가 업데이트되었을 때 정적 사이트(SSG)를 다시 build해야 하는 경우에 활용됩니다.

Leave a comment

You may also enjoy