AWS, 배포, DevOps, CI/CD, 테스트

SIMWOOHYUN·2025년 6월 4일

[AWS, 배포, DevOps, CI/CD, 테스트]

1. 개요

현대의 애플리케이션 개발 및 운영(DevOps) 환경에서는 안정적이고 자동화된 배포 파이프라인 구축이 필수적입니다. AWS(아마존 웹 서비스)는 다양한 서비스와 도구를 통해 이런 요구를 효과적으로 지원합니다.
이 포스트에서는 AWS를 활용한 배포 환경 설정부터 배포 도구 설정, 그리고 배포 환경 테스트까지의 과정을 단계별로 정리합니다.

2. 배포 계획 수립

배포 환경을 구성하기 전, 먼저 다음 사항들을 명확히 정의해야 합니다.

목표 환경(Production, Staging 등)
- Production: 실서비스 환경, 높은 가용성/확장성 필요
- Staging: 사용자 테스트 또는 QA용 환경, Production과 최대한 유사하게 구성
서비스 아키텍처
- 웹 서버(예: EC2, ECS, Lambda 등)
- 데이터베이스(예: RDS, DynamoDB)
- 파일 스토리지(예: S3)
- 네트워크(VPC, Subnet, Security Group 등)
- 로드 밸런싱(ELB) / Auto Scaling
연속 통합(Continuous Integration) / 연속 배포(Continuous Deployment) 요구사항
- 코드 저장소(GitHub, CodeCommit 등)
- 빌드/테스트 자동화(Jenkins, GitHub Actions, AWS CodeBuild)
- 배포 자동화(AWS CodeDeploy, CodePipeline 등)
보안 및 권한 관리
- IAM(Role, Policy)을 통한 최소 권한 원칙
- VPC 내 리소스 접근 제어
- SSL/TLS 인증서(AWS Certificate Manager) 등

3. 배포 환경 설정

3.1 VPC 및 네트워크 구성

VPC 생성
- CIDR 블록 예시: 10.0.0.0/16
Subnets 구성
- Public Subnet: 외부 인터넷 연결이 필요한 리소스(예: ALB, NAT Gateway)
- Private Subnet: 내부 리소스(예: EC2 웹 서버, RDS)
Internet Gateway 연결
- Public Subnet이 인터넷과 통신할 수 있도록 설정
NAT Gateway 생성
- Private Subnet의 리소스가 외부로 나갈 때 사용하는 게이트웨이
Route Table 구성
- Public Subnet -> IGW (Internet Gateway)
- Private Subnet -> NAT Gateway
Security Group / NACL 설정
- 최소 권한 원칙: 필요한 포트만 오픈
- 예시: 웹 서버(EC2) 80/443 포트 오픈, SSH(22) 접속은 특정 IP 제한

3.2 컴퓨팅 리소스(EC2, ECS, Lambda 등)

EC2 인스턴스 생성
- AMI: Amazon Linux 2
- Instance Type: t3.medium (테스트 환경), m5.large (프로덕션 환경)
- 키 페어(Key Pair) 설정: SSH 접속용
ECS + Fargate 사용 (선택 사항)
- 도커 이미지를 업로드할 ECR(Elastic Container Registry) 생성
- ECS 클러스터 생성 후 Fargate 태스크 정의 작성
Lambda 함수 (서버리스 배포)
- 간단한 기능이라면 Lambda + API Gateway로 구현
- IAM Role 설정: 최소 권한 원칙

3.3 스토리지 및 데이터베이스

S3 버킷 생성
- 정적 파일(이미지, CSS, JS 등) 호스팅 용도
- 버전 관리(Versioning) 옵션 활성화
- 접근 제어: 공개 읽기/쓰기 권한 최소화
RDS 인스턴스 생성
- 엔진: MySQL 8.0 또는 PostgreSQL 13
- 멀티 AZ 배포 옵션 활성화 (프로덕션 환경)
- 스토리지 유형: General Purpose (SSD) 또는 Provisioned IOPS
- 보안 설정: Private Subnet에 배치, 보안 그룹으로 접근 제어
DynamoDB 사용 (선택 사항)
- NoSQL 방식의 스케일 아웃이 필요한 경우 선택
- 온디맨드 또는 프로비저닝된 용량 모드 설정

3.4 로드 밸런싱 및 Auto Scaling

Application Load Balancer(ALB) 생성
- 리스너: HTTP(80), HTTPS(443)
- ACM(AWS Certificate Manager)에서 발급받은 SSL 인증서 연결
Target Group 설정
- 대상: EC2 인스턴스 또는 ECS 태스크
- 헬스 체크 경로: /health 엔드포인트 지정
Auto Scaling Group(ASG) 구성
- 최소/최대 인스턴스 개수 정의
- 스케일 아웃/인 정책: CPU 사용률, 요청 수 등
- Launch Template 또는 Launch Configuration 작성: AMI, 인스턴스 유형, Security Group 등을 포함

3.5 도메인 및 DNS(Route 53)

호스팅 영역(Hosted Zone) 생성
- 루트 도메인(example.com) 또는 서브도메인(api.example.com) 연결
레코드 세트 설정
- A 레코드 또는 CNAME 레코드: ALB DNS 이름을 가리키도록 설정
- 서브도메인별 레코드 필요 시 추가

4. 배포 도구 설정

4.1 AWS CLI 및 로컬 환경 설정

AWS CLI 설치 및 구성

# AWS CLI v2 설치 (예시: Linux)
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

# AWS CLI 구성
aws configure
# AWS Access Key ID [None]: YOUR_ACCESS_KEY
# AWS Secret Access Key [None]: YOUR_SECRET_KEY
# Default region name [None]: ap-northeast-2
# Default output format [None]: json

IAM 사용자/역할(Role) 생성
- 최소 권한 원칙에 맞춘 사용자 또는 역할 생성
- 예시 정책: EC2, S3, RDS, CodeDeploy, CodePipeline 접근 권한

4.2 AWS CodeCommit (소스 저장소)

리포지토리 생성
- AWS Console -> CodeCommit -> 리포지토리 생성
- HTTPS 또는 SSH 방식으로 클론 가능

로컬 Git 리포지토리 연동

git remote add origin https://git-codecommit.ap-northeast-2.amazonaws.com/v1/repos/my-app-repo
git push -u origin main

4.3 AWS CodeBuild (빌드 및 테스트)

빌드 프로젝트 생성

소스: CodeCommit 또는 GitHub 연동
환경: 매니지드 이미지(예: AWS 기본 Ubuntu 이미지)

빌드 스펙(buildspec.yml) 생성

version: 0.2

phases:
  install:
    commands:
      - echo "빌드 환경 설정 중..."
      - pip install -r requirements.txt
  build:
    commands:
      - echo "애플리케이션 빌드 및 테스트 실행"
      - pytest tests/
      - npm install
      - npm run build
  post_build:
    commands:
      - echo "빌드 결과 아티팩트 업로드"
artifacts:
  files:
    - '**/*'
  base-directory: build_output/

환경 변수 설정
- AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY (역할을 활용하거나 CodeBuild 서비스 역할 사용)
- Custom 환경 변수: NODE_ENV, DB_HOST 등

4.4 AWS CodeDeploy (배포 자동화)

애플리케이션 및 배포 그룹 생성
- AWS Console -> CodeDeploy -> 애플리케이션 생성 (배포 유형: EC2/On-Premises 또는 ECS)
- 배포 그룹 정의: 대상 인스턴스, 로드 밸런서, 서비스 역할 설정

앱 사양 파일(appspec.yml) 작성

프로젝트 루트 디렉터리에 appspec.yml 파일 추가

version: 0.0
os: linux
files:
  - source: /
    destination: /var/www/my-app
permissions:
  - object: /var/www/my-app
    owner: ec2-user
    group: ec2-user
    mode: 755
hooks:
  BeforeInstall:
    - location: scripts/install_dependencies.sh
      timeout: 300
      runas: ec2-user
  AfterInstall:
    - location: scripts/restart_server.sh
      timeout: 300
      runas: ec2-user
  ApplicationStart:
    - location: scripts/start_server.sh
      timeout: 300
      runas: ec2-user
  ValidateService:
    - location: scripts/health_check.sh
      timeout: 300
      runas: ec2-user

주요 훅 스크립트 예시
- install_dependencies.sh: 의존성 설치 (예: npm install 또는 pip install -r requirements.txt)
- restart_server.sh: 이전 버전 프로세스 종료
- start_server.sh: 새 버전 애플리케이션 시작 (pm2 start, gunicorn 등)
- health_check.sh: Health Check 엔드포인트 요청하여 정상 동작 여부 확인

4.5 AWS CodePipeline (CI/CD 파이프라인)

파이프라인 생성
1. Source Stage
  - 소스 제공자: CodeCommit / GitHub
  - 브랜치: main
2. Build Stage
  - 빌드 프로바이더: CodeBuild
  - 앞서 생성한 빌드 프로젝트 지정
3. Deploy Stage
  - 배포 프로바이더: CodeDeploy
  - 애플리케이션 및 배포 그룹 지정
파이프라인 동작 흐름
1. 소스 코드 변경이 발생하면 자동으로 트리거
2. CodeBuild가 코드를 빌드하고 테스트
3. 빌드 성공 시, CodeDeploy가 지정된 EC2/ECS에 배포 진행
4. 배포 성공 시 알림(CloudWatch Event 또는 SNS) 전송

5. 배포 환경 테스트

배포 환경이 제대로 구성되었는지 확인하기 위한 테스트 항목 및 방법을 정리합니다.

5.1 인프라 구성 검사

VPC 네트워크 테스트
- EC2 인스턴스에서 인터넷 연결 확인: ping google.com
- Private Subnet 인스턴스에서 외부 접근(업데이트, 패치 등) 테스트
Security Group 및 방화벽 설정 확인
- ALB -> EC2 웹 서버 80/443 포트 정상 연결
- SSH(22) 접근이 허용된 IP 범위만 접속 가능한지 확인
로드 밸런서 헬스 체크
- ALB의 Target Group 헬스 체크 지점(/health) 정상 응답 여부 확인
- 비정상 인스턴스가 자동으로 제외되고, 정상 인스턴스만 트래픽이 전달되는지 확인

5.2 배포 파이프라인 검증

CodePipeline 동작 테스트
- Git 커밋 후 브랜치에 푸시 -> 파이프라인 자동 빌드/배포 트리거 확인
- 빌드 로그(CodeBuild) 및 배포 로그(CodeDeploy)에서 오류 유무 확인
빌드 및 테스트 자동화 검증
- 테스트 케이스 미포함 코드 커밋 시 빌드 실패 확인
- 커버리지 도구(Coverage)나 린터(Linter) 점검 설정 시, 품질 게이트 통과 여부 확인

5.3 애플리케이션 동작 테스트

기본 기능 테스트
- 웹 애플리케이션 로그인/회원가입, CRUD 기능 정상 동작 여부 확인
- API 엔드포인트 정상 응답(HTTP 상태 코드 200) 및 올바른 데이터 반환 확인
무중단 배포(Blue-Green 또는 Canary) 테스트 (선택 사항)
- Blue-Green 배포 시, Green 환경에서 충분히 테스트 후 트래픽 전환
- Canary 배포 시, 일부 트래픽만 새 버전으로 라우팅하여 모니터링 후 점진적 전환
부하 테스트(Load Testing)
- Apache JMeter, Locust 등을 사용해 동시 접속 부하 테스트
- CPU/메모리, 네트워크 사용량, 응답 시간 등 모니터링
- 주요 성능 지표(가용성, 응답 시간, 에러율) SLA 준수 여부 확인

5.4 모니터링 및 로깅 설정 검증

CloudWatch (로그 및 지표 수집)
- EC2, ALB, RDS 등 주요 리소스의 CPU, 메모리, 디스크 I/O 지표 수집
- 애플리케이션 로그(CW Logs) 설정: 로그 그룹/스트림 정상 생성 확인
CloudWatch Alarm 설정
- CPU 사용률 80% 초과 시 알람 발생
- HTTP 5xx 응답률 증가 시 알람 발생
- 알람 발생 시 SNS 또는 Slack 알림 연동 확인
AWS X-Ray (분산 추적)
- 마이크로서비스 아키텍처인 경우, 서비스 간 호출 추적 및 병목 분석
- X-Ray 대시보드에서 트레이스 정상 수집 확인

6. 결론 및 향후 과제

결론 요약
- VPC, 서브넷, 보안 그룹 등을 활용해 안전한 네트워크 구축
- EC2/ECS/Lambda를 통해 유연한 컴퓨팅 환경 구성
- S3, RDS, DynamoDB 등 스토리지 및 데이터베이스 서비스 활용
- CodeBuild, CodeDeploy, CodePipeline을 이용한 CI/CD 파이프라인 자동화
- CloudWatch, X-Ray 등을 활용한 모니터링 및 로깅 설정
- 배포 환경 테스트를 통해 안정적 배포 및 운영 환경 확보
향후 과제
- 보안 강화: WAF(Web Application Firewall), GuardDuty, Inspector 등을 도입해 보안 진단 강화
- 인프라 코드화(Infrastructure as Code): Terraform 또는 CloudFormation 기반으로 인프라를 코드로 관리
- 무중단 배포 전략: Blue-Green, Canary 배포 워크플로우 도입으로 배포 위험 최소화
- 비용 최적화: AWS Cost Explorer를 활용해 비용 모니터링 및 예산 관리
- 자동 스케일링 고도화: 예측 스케일링(Predictive Scaling), 스팟 인스턴스 활용 등으로 효율성 강화

참고 자료

SIMWOOHYUN

cs 21

이전 포스트

Selenium을 활용한 E2E 테스트 케이스 개발

다음 포스트