[AWS] DevOps, CI/CD, 운영 및 비용 관리 (Code Series, Fargate, CloudWatch, Trusted Advisor) _250901

CI/CD 

 

 

 

EC2가 생성되고 코드가 올라가서 컴파일하고 테스트해서 AWS가 지정하는 S3에 보관하고 그걸 또다른 어플리케이션에서 그 소스를 가져가거나 코드 파이프라인이나 코드디플로이로 그 코드를 배포하는 단계.

 

클라우드는 여러 빌드를 동시에 처리하도록 해줌

 

관리할 빌드 서버가 없음 ? 컴파일 하고 테스트해서 s3에 올리면 생성되었던 ec2는 terminate 됨.

 

 

 

시험 핵심: 서비스 역할 분담

언급된 각 서비스의 정확한 역할을 구분하는 것이 중요합니다.

1. CI (지속적 통합) 영역 - 이미지 생성 및 저장

• GitHub Actions: 코드를 빌드하고(CI), 그 결과물(Docker 이미지)을 **AWS의 저장소(ECR)**까지 안전하게 옮기는 역할을 합니다. 즉, 빌드 과정을 AWS 밖에서 처리합니다.
• ECR (Elastic Container Registry): 빌드된 Docker 이미지 저장소로서, ECS가 사용할 이미지를 보관하는 중앙 허브 역할만 합니다.

2. CD (지속적 배포) 영역 - 서비스 구동

• ECS (Elastic Container Service) (가장 중요): 실제 서비스가 구동되는 최종 배포 환경입니다. ECR에서 최신 이미지를 가져와서 컨테이너 인스턴스를 업데이트하고 관리합니다.
• CodePipeline / GitHub Actions CD: 배포를 실행하는 오케스트레이터 역할입니다. **"ECR에 이미지 올라왔으니, ECS는 이제 새 이미지를 실행해라"**라는 명령을 전달합니다.

이 구조는 AWS의 CodeBuild나 CodeDeploy 대신 GitHub Actions를 빌드 및 배포 조율 도구로 사용하면서도, AWS의 핵심 컴퓨팅 자원(ECS)과 저장소(ECR)를 활용하는 유연한 방식입니다.

 

* Jenkins

Jenkins: CI/CD의 조율자

젠킨스는 지속적 통합(CI)과 지속적 전달/배포(CD) 과정을 자동화하는 데 특화된 도구예요. 개발자가 코드를 푸시할 때부터 최종적으로 사용자에게 배포될 때까지의 모든 단계를 **"파이프라인"**이라는 형태로 연결하고 관리합니다.

역할	설명
지속적 통합 (CI)	개발자가 코드를 Git(GitHub/GitLab)에 올리면, 자동으로 감지하여 코드를 빌드(Compile)하고 테스트 실행
지속적 배포 (CD)	빌드와 테스트가 성공하면, 자동으로 컨테이너 이미지를 만들거나, 결과물을 운영 서버(EC2, ECS 등)에 배포
플러그인 생태계	수많은 플러그인을 통해 Git, Docker, AWS 서비스(EC2, S3, ECS 등), Slack 알림 등 거의 모든 개발 도구와 연동

 

🔑 AWS Code 서비스와의 관계 (시험 대비)

젠킨스는 AWS의 Code 시리즈가 등장하기 전부터 CI/CD를 주도해 온 툴입니다. AWS 자격증 시험에서는 이 둘의 장단점과 역할 분담을 비교할 줄 알아야 합니다.

구분	Jenkins	AWS CodePipeline/CodeBuild/CodeDeploy
운영 방식	사용자가 직접 서버에 설치/관리 (자가 관리형).	AWS가 서버리스(Serverless) 방식으로 완전히 관리 (관리형 서비스).
유연성	매우 높음 (오픈 소스라 자유로운 커스터마이징 가능).	AWS 서비스 내에서만 작동하므로 유연성이 상대적으로 낮음.
비용/관리	서버(EC2) 비용과 관리 인력이 필요함.	사용한 만큼만 지불하며, 관리 부담이 없음 (CodeBuild는 서버리스).
시험 관점	온프레미스 또는 AWS 외부 환경에서 사용되던 CI/CD 도구, AWS CodePipeline의 대안 또는 경쟁자

---

 

강의록: AWS DevOps (CI/CD) 및 애플리케이션 서비스

---

1. AWS DevOps의 개념과 철학 (데브옵스)

강의에서는 DevOps를 단순히 기술이 아닌 문화와 철학으로 강조했습니다.

• DevOps 정의 (시험 빈출/핵심)
  • **개발(Dev)**과 **운영(Ops)**의 합성어로, 개발자와 운영자 간의 장벽을 허물고 협업과 소통을 통해 개발 주기를 단축하고 서비스의 안정성을 높이는 조직 문화입니다.
  • 핵심: 개발 사이클이 짧아지면서 (모놀리식 → 마이크로서비스) 개발과 운영의 교집합이 커지고, 클라우드 환경에서는 1인이 이 두 역할을 상당 부분 담당하게 되었습니다.
• 모놀리식 vs. 마이크로서비스 (시험 빈출)

구분	모놀리식 (Monolithic)	마이크로서비스 (Microservices)
구조	하나의 거대한 코드베이스 (모든 기능이 연결)	작고 독립적인 서비스들로 분리
배포/업데이트	느림 (전체를 껐다 켜야 함)	빠름 (해당 서비스만 배포/업데이트)
장점	개발 초기 단순함	유연성, 확장성, 빠른 배포
단점	오류 발생 시 전체 서비스에 영향, 개발/배포 주기 김	복잡한 관리 (오케스트레이션, 모니터링 필요)

---

2. CI/CD 파이프라인의 구성 (지속적 통합/배포)

DevOps 철학을 기술적으로 구현하는 것이 CI/CD이며, 컨테이너 환경에서 그 이점이 극명하게 나타납니다.

용어	과정	설명	컨테이너 단계
CI (지속적 통합)	개발 (Code) → 빌드 (Build) → 테스트 (Test)	코드를 컴파일하고, 컨테이너 이미지화하며, 통합 및 테스트를 거쳐 **저장소(Repository)**에 올리는 과정.	Dev → Build
CD (지속적 전달/배포)	배포 (Provisioning) → 실행 (Deploy) → 모니터링 (Monitor)	저장소에 있는 결과물(이미지/코드)을 가져와 실제 운영 환경에 자동 배포하고 서비스하는 과정.	Ship → Run

 

---

3. AWS DevOps 코드 삼총사 (Code Series)

AWS는 CI/CD 각 단계를 위한 전용 서비스들을 제공합니다. 이 서비스들의 역할 분담은 시험에 매우 중요합니다.

서비스	CI/CD 단계	역할 및 특징 (시험 빈출)
CodeCommit	소스 관리 (VCS)	AWS 기반의 Git 저장소 서비스. (⚠️ 신규 고객 서비스 종료 추세이므로, 현재는 GitHub나 GitLab을 주로 연동하여 사용함.)
CodeBuild	빌드 및 테스트 (CI)	코드를 컴파일, 테스트, 컨테이너 이미지화하는 서비스. 핵심: 임시 EC2 기반 환경이 생성되어 빌드 후 자동으로 종료되므로, 빌드 서버를 관리할 필요가 없음 (Serverless 특징). 결과물은 S3 또는 ECR에 저장됨.
CodeDeploy	배포 (CD)	EC2, Fargate, Lambda, On-Premises 등 다양한 환경에 배포를 자동화하는 서비스. 핵심: 배포 시 가동 중지 시간을 최소화하며, 실패 시 자동 롤백(Rollback) 기능을 제공. 대상 서버에 에이전트(Agent) 설치 필요 (EC2/On-Premise).
CodePipeline	파이프라인 (Orchestration)	CI/CD 전 과정을 자동으로 연결하고 순서를 관리하는 서비스. (소스 → 빌드 → 배포 단계를 묶어주는 틀).

 

 

---

4. 마이크로서비스/컴퓨팅 자원 (Compute Resources)

강의에서 언급된 컴퓨팅 자원의 역할 및 Fargate의 개념은 컨테이너 서비스의 핵심입니다.

• ECS/EKS/Lambda: 마이크로서비스를 실행하는 대표적인 컴퓨팅 자원.
  • ECS (Elastic Container Service): AWS 자체 컨테이너 오케스트레이션 서비스.
  • EKS (Elastic Kubernetes Service): 쿠버네티스 관리형 서비스.
  • Lambda (람다): AWS 내부 Firecracker (마이크로 VM) 기반으로 함수를 실행하는 서버리스 컴퓨팅.
• Fargate (파게이트) (⭐가장 중요/빈출)
  • 개념: ECS/EKS를 위한 서버리스 컴퓨팅 엔진입니다.
  • 핵심: 고객이 EC2(VM)를 직접 관리(운영, 확장, 보안 패치 등)할 부담을 AWS가 대신 가져가고, 고객은 컨테이너 이미지 관리에만 집중하게 합니다.
  • EC2 관리 부담이 없는 컨테이너 실행 환경을 제공합니다.

---

5. 모니터링 및 보안 서비스 (Monitoring & Security)

배포된 서비스의 운영 상태를 확인하고 문제 발생 시 추적하는 서비스입니다.

서비스	역할 및 특징 (시험 빈출)
CloudWatch	통합 모니터링 및 로깅
CloudTrail	API 호출 로깅 (감사)
X-Ray	분산 추적 (API Flow) 그래프로 보여줌.
GuardDuty	지능형 위협 탐지
Inspector	특정 OS의 취약점을 볼 수 있음
Security Hub	AWS화 되어서, 계정이라던가 그런 것들을 처음부터 체계화해줌

 

---

6. 기타 서비스 (Other Services)

• RDS (Relational Database Service): AWS에서 관계형 데이터베이스(MySQL, PostgreSQL 등)를 쉽게 설정, 운영, 확장할 수 있도록 관리해주는 서비스. (곧 실습 예정)
• Step Functions (스텝 함수): 여러 AWS 서비스를 논리적인 워크플로우로 연결하여 순차적으로 실행(오케스트레이션)하는 서버리스 서비스. (예: Lambda A 실행 후 → SQS에 메시지 전송 → Lambda B 실행)
• EventBridge (이벤트 브릿지): CloudWatch Events에서 이름이 바뀐 서비스. AWS 서비스, SaaS 애플리케이션 및 자체 애플리케이션에서 발생하는 데이터를 이벤트 버스로 라우팅하여 다른 서비스(Lambda 등)를 트리거하는 이벤트 기반 아키텍처의 핵심.

하이브리드 구성 vpn 전용선으로 연동되었을 경우, 온프레미스의 것도 모니터링 가능

단일위치(한 계정)에서 모니터링 가능

자동알람 모니터링 지원

 

관측성 모니터링 Observility

모니터링은 실황 상황에대한 반응을 보는것

<> Observility는 그 모든 것을 통찰하고 앞으로 어떻게 개선해나갈지 보는 높고 넓은 시선

코드느 모든 api 활동들 저장

잘못된 api 코드로 인하여 추적이 가능하여야 한다.

비정상적 계정활동 감시

 

 

s. AWS Trusted Advisor identifies ways to improve your AWS infrastructure across 5 unique pillars: Security, Performance, Cost Optimization, Fault Tolerance, and AWS Service Quotas. 

권장조치수: 당장조치

권장조사항목수: 경고

발견된문제없는 항목수: 잘하고 있음

 

 

 

2부: 운영, 감사, 비용 관리

1. CI/CD 컨테이너 워크플로우 (복습 및 정리)

강의 초반에 다시 언급된 컨테이너 워크플로우는 DevOps의 기본 축입니다.

• CI (지속적 통합): 코드를 짜고 (Dev) → 컨테이너 이미지화 (Build) → 이미지 저장소(Repository, AWS ECR 등)에 올리는 것까지가 CI 단계입니다.
• CD (지속적 전달/배포): 저장소에 있는 이미지를 끌어와 → 컨테이너에 싣고 실행하는 것 (Ship → Run)이 CD 단계입니다.

이 Build, Ship, Run의 개념을 머릿속에 두고, 이제 이것이 실제로 운영될 때 필요한 서비스들을 살펴봅시다.

---

2. 핵심 모니터링 및 감사 서비스

2-1. CloudWatch (⭐최빈출: 통합 모니터링)

AWS에서 모니터링 관련 질문이 나온다면 거의 90% 이상 CloudWatch를 묻는다고 생각하시면 됩니다.

• 역할: AWS 리소스 및 애플리케이션에 대한 **지표(Metric), 로그(Log), 이벤트(Event)**를 수집하고 추적하여 단일 위치에서 중앙 집중식 모니터링을 제공합니다.
• 특징 (시험 빈출):
  • Hybrid/On-Premise 지원: AWS 환경뿐만 아니라, VPN이나 전용선으로 연결된 온프레미스 서버의 모니터링도 동일하게 수행할 수 있습니다.
  • 대시보드 (Observability): 고객 사용자 정의에 맞게 중요한 항목을 배열하여 대시보드를 만들 수 있습니다. 최근에는 단순 모니터링을 넘어 **관측성(Observability)**이라는 더 넓은 개념(통찰 및 개선까지 포함)으로 많이 불립니다.
  • 자동 알람: 지표에 따라 자동 알람을 설정하여 문제가 발생했을 때 즉시 대응할 수 있도록 합니다.

2-2. CloudTrail (⭐최빈출: API 활동 로깅/감사)

CloudTrail은 보안 감사 및 사후 추적을 위해 반드시 알아야 하는 서비스입니다.

• 역할: AWS 인프라 전체에서 발생하는 모든 API 활동을 기록하고 저장합니다. (사용자의 콘솔 로그인, EC2 생성/종료, 설정 변경 등 모든 행위가 API 호출입니다.)
• 특징 (시험 빈출):
  • 로그 형식: JSON 형식의 로그로 기록되며, 누가(IAM User), 언제, 어떤 요청(API Call)을 했는지 상세하게 남깁니다.
  • 활용: "갑자기 EC2가 종료되었을 때, 누가 종료했는지 역추적"하는 등의 감사(Audit) 목적으로 사용됩니다.
  • 보안: 비정상적인 계정 활동 등을 감시하는 데 핵심적인 데이터 소스입니다.

---

3. Trusted Advisor (⭐시험 빈출: 계정 최적화 조언)

Trusted Advisor는 AWS 환경 개선을 위해 실시간으로 권장 사항을 제공하는 서비스입니다. 하지만 누구나 전체 기능을 쓸 수 있는 것은 아닙니다.

3-1. Support Plan과 연동 (매우 중요)

Trusted Advisor의 전체 기능은 AWS의 유료 Support Plan 중 Business 이상을 구독해야만 제공됩니다.

Support Plan	비용 (월/최소)	특징	타사소프트웨어 지원	Trusted Advisor 제공
Basic (기본)	무료	기본적인 고객센터 접근	X	5개 범주 중 일부 검사만 제공
Developer	$49	개발 관련 문의 (응답 시간 12시간 이내)	X	5개 범주 중 일부 검사만 제공
Business	$100	비즈니스/운영 문의 (응답 시간 1시간 이내)	O	5개 범주 전체 기능 제공
Enterprise	$15,000	핵심 비즈니스 지원 (응답 시간 15분 이내)	O	5개 범주 전체 기능 제공

Sheets로 내보내기

3-2. 5가지 범주 (⭐암기 필수)

Trusted Advisor는 고객의 인프라를 분석하여 다음 5가지 범주에 대한 개선 조언을 제공합니다.

1. 비용 최적화 (Cost Optimization): 미사용 또는 비용 효율이 낮은 리소스(예: 유휴 EC2 인스턴스)에 대한 비용 절감 방안을 제시합니다.
2. 성능 (Performance): 리소스 설정이 효율적인지 확인하고 성능 개선 방안을 제공합니다.
3. 보안 (Security): IAM 루트 사용자 키 사용 등 보안 모범 사례를 따르고 있는지 확인합니다.
4. 내결함성/이중화 (Fault Tolerance): 고가용성 및 서비스 연속성을 위한 이중화 구성에 문제가 없는지 점검합니다.
5. 서비스 한도 (Service Limits): 계정별 리소스 사용 한도에 임박한 항목을 경고합니다.

💡 조치 등급:

• 빨간색 느낌표: 당장 조치해야 하는 위험 수준.
• 노란색 삼각형: 권장 조치가 필요한 경고 수준.
• 초록색 체크: 양호한 상태.

---

4. AWS 요금 체계의 이해

AWS의 비용 구조는 시험에 직접적으로 출제되므로, 기본적인 요금 모델을 이해해야 합니다.

• 종량제 (On-Demand): 사용한 만큼 초/시간 단위로 지불합니다. AWS의 기본 원칙입니다.
• RI (Reserved Instances) / Saving Plans (시험 빈출)
  • **컴퓨팅 자원 (EC2, Fargate, Lambda)**에 대해 1년 또는 3년 사용을 미리 약정하고 큰 폭의 할인을 받습니다.
• 볼륨 기반 할인 (Volume-Based Discount)
  • **네트워크, 스토리지 (S3)**처럼 특정 리소스를 지정하여 예약하기 어려운 영역에 대해, 대량 사용을 약정하면 요율을 낮춰주는 할인 모델입니다. (사용량이 많을수록 단가가 낮아짐.)

EC2 요금 과금 기준 (⭐빈출)

• Amazon Linux: 초 단위로 과금됩니다. (30분 사용 시 30분 비용만 청구.)
• 그 외 OS (Windows, Red Hat 등): 시간 단위로 과금됩니다. (1초를 사용해도 1시간 비용이 청구됨.)

이 내용은 특히 비용 최적화(Cost Optimization) 관련 문제에서 자주 등장하니 꼭 기억해 두세요!

---

조언: 오늘 다룬 CloudWatch, CloudTrail, Trusted Advisor의 5대 범주는 출제자들이 가장 사랑하는 부분이에요. 각 서비스의 기능이 겹치지 않도록 **"모니터링 (CloudWatch) vs. API 감사 (CloudTrail) vs. 최적화 조언 (Trusted Advisor)"**로 확실하게 구분하면 시험에서 절대 헷갈리지 않을 거예요!