위클리페이퍼09-2: 클라우드 환경에 프로그램 배포하기
Q3. AWS RDS를 활용하는 주요 이점과 EC2에 직접 데이터베이스를 설치하여 운영하는 것과 비교했을 때의 차별점에 대해 설명해주세요. 그리고 RDS를 사용하는 것이 적합하지 않을 수 있는 상황도 함께 언급해주세요.
Q3-1. 답변
AWS RDS를 활용하는 주요 이점
- 운영 및 관리 자동화
- 데이터베이스 백업, 소프트웨어 패치 적용, 하드웨어 프로비저닝, 모니터링 등 시간이 많이 소요되는 데이터베이스 관리 작업을 AWS가 자동으로 처리 가능
- 고가용성과 신뢰성
- 다중 AZ(Multi-AZ) 배포를 통해 동기식 복제본을 유지하며, 장애 발생 시 대기 인스턴스로 자동 Failover를 지원하여 다운타임을 최소화하고 데이터 내구성을 보장
- Failover : 대기 중인 예비 서버나 인스턴스로 자동 전환하는 것
- 다중 AZ(Multi-AZ) 배포를 통해 동기식 복제본을 유지하며, 장애 발생 시 대기 인스턴스로 자동 Failover를 지원하여 다운타임을 최소화하고 데이터 내구성을 보장
- 유연한 확장성
- 애플리케이션의 수요 변화에 맞춰 클릭 몇 번으로 컴퓨팅 및 스토리지 Resource를 쉽게 확장(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를 설치하여 운영하는 것이 더 적합
Q4. GitHub Actions Workflow에서 사용할 수 있는 다양한 Trigger 유형을 설명하고, 각 트리거 유형이 적합한 CI/CD 시나리오에 대해 설명하세요.
Q4-1. 답변
GitHub Actions에서 Trigger란?
Workflow를 실행시키는 이벤트를 의미
- 코드가 올라갈 때나
- 특정 시간이나 외부 신호에 의해서도 자동화를 시작 가능
주요 트리거 유형 및 활용 시나리오
- 이벤트 기반 Trigger (Event-driven)
- 가장 보편적인 방식으로, 저장소 내의 변경 사항에 반응
- push
- 특정 branch에 코드가 commit되거나 merge되었을 때 실행
- 적합한 시나리오
- main branch에 코드가 merge된 후 바로 배포(CD) 를 진행
- pull_request
- PR이 생성, 동기화(update), 재오픈될 때 실행
- 적합한 시나리오
- 코드 리뷰 단계에서 테스트(Unit Test)나 Lint 체크를 자동화해서 결함이 있는 코드가 branch에 merge되는 것을 방지하는 Quality Gate 역할
- 수동 Trigger (Manual)
- 사용자가 직접 버튼을 눌러 Workflow를 실행
- workflow_dispatch
- GitHub UI나 API를 통해 수동으로 실행.
- 적합한 시나리오
- 정기 배포 외에 긴급 롤백(Rollback) 을 수행하거나, 특정 환경(Staging, QA)에 선택적 배포를 해야 할 때
- 스케줄 Trigger (Scheduled)
- 정해진 시간에 주기적으로 실행.
- schedule
- cron 표현식을 사용하여 실행 시간을 설정. (예:
0 0 * * *는 매일 자정) - 적합한 시나리오
- 주기적인 Batch 작업, 의존성 라이브러리의 보안 취약점을 점검하는 Daily Scan, DB 백업
- cron 표현식을 사용하여 실행 시간을 설정. (예:
- 연쇄 및 외부 Trigger (Chained & External)
- 다른 Workflow의 결과나 외부 서비스의 신호를 받음
- workflow_run
- 특정 Workflow가 완료/성공/실패된 후 실행
- 적합한 시나리오
- “build 및 테스트” Workflow가 성공한 직후에 “배포” Workflow를 실행하고 싶을 때
- repository_dispatch
- GitHub 외부 시스템(예: 사내 관리 도구, 다른 클라우드 서비스)에서 Webhook을 보내 실행
- 적합한 시나리오
- 외부 CMS에서 콘텐츠가 업데이트되었을 때 정적 사이트(SSG)를 다시 build해야 하는 경우
Leave a comment