90DaysOfDevOps (Day 34)

고태규·2025년 10월 31일
devops
0

DevOps

목록 보기
33/50
post-thumbnail

해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.

Day 34 - How to Implement Automated Deployment Pipelines for Your DevOps Projects

1. 자동화된 배포 파이프라인

자동화된 배포 파이프라인은 소프트웨어 전달 (Delivery) 프로세스를 능률적으로 처리하는 일련의 자동화된 프로세스이다.

개발자가 코드를 커밋하는 순간부터 빌드, 테스트, 프로덕션 배포에 이르기까지 모든 단계를 자동화하는 것을 목표로 한다.

핵심 목표

  • 효율성: 수동 개입을 최소화하여 프로세스 속도 향상

  • 신뢰성: 모든 변경 사항에 대해 일관된 테스트를 수행하여 안정성을 보장

  • 협업: 개발, 테스트, 운영 (DevOps, SRE) 등 모든 관련 팀이 단일화된 프로세스를 통해 협력

자동화의 핵심 이점

  • 더 빠른 시장 출시: 과거 월별, 분기별로 이루어지던 릴리스를 일별, 시간별로 단축시킬 수 있음.

  • 위험 및 오류 감소: 수동 배포 과정에서 발생하는 인간의 실수를 원천적으로 차단

  • 일관성 및 신뢰성: 모든 배포가 동일하며 자동화된 테스트 케이스를 통과하므로 신뢰할 수 있음.

  • 자동화된 롤백: 배포된 새 기능에 문제가 발생할 경우, 검증된 이전 버전으로 빠르고 안전하게 되돌아갈 수 있음.

  • 협업 문화 증진: 모든 팀이 자동화라는 공동의 목표를 위해 협력하게 됨.

2. 파이프라인의 핵심 구성 요소와 설정 방법

성공적인 자동화 파이프라인은 여러 핵심 구성 요소가 유기적으로 연결되어 작동한다.

2-1. 핵심 구성 요소

  • 소스 코드 저장소 (SCM): 모든 코드 변경 사항을 추적하고 관리하는 중앙 허브

    • Git, GitHub, Bitbucket, Subversion

  • 빌드 자동화: 소스 코드를 컴파일하고 필요한 라이브러리 및 패키지를 번들링하여 실행 가능한 아티팩트 (ex. JAR, 압축 파일, 도커 이미지) 를 생성

    • Maven - 주로 Java, Gradle, npm

  • 자동화된 테스팅: 코드의 품질과 안정성을 보장하기 위해 단위 테스트, 통합 테스트, 성능 테스트 등을 자동으로 실행

    • JUnit, JMeter, Selenium

  • 지속적인 통합 (CI): 개발자가 코드를 SCM에 커밋할 때마다 자동으로 빌드 및 테스트를 트리거 -> 오류를 조기에 감지하고 안정적인 코드 베이스를 유지하며 빠른 피드백을 제공가능

    • Jenkins, GitLab CI, Bamboo, CircleCI, Travis CI, TeamCity

  • 지속적인 배포 (CD) 및 구성 관리: CI 단계를 통과한 빌드를 실제 운영 환경 (프로덕션) 까지 자동으로 배포

    • 구성 관리와 IaC 도구: 배포 환경을 코드로 관리하고 일관되게 구성
      (ex. Ansible, Puppet, Chef, Salt, Terraform)

2-2. CI/CD 용어 차이

  • 지속적인 통합 (CI): 빌드 및 테스트 자동화

  • 지속적인 전달 (Continuous Delivery): CI를 통과한 빌드를 프로덕션에 배포할 수 있도록 준비하는 단계까지 자동화 (단, 실제 프로덕션 배포는 수동 승인을 통해 이루어짐)

  • 지속적인 배포 (Continuous Deployment): 모든 단계를 완전히 자동화하여, CI를 통과하면 자동으로 프로덕션까지 배포 (릴리스 신뢰도가 매우 높아야 가능)

2-3. 파이프라인 설정 4단계

  1. 올바른 도구 선택: 현재 기술 스택, 팀의 숙련도, 미래 확장성을 고려하여 Jenkins, GitLab CI 등 핵심 도구를 선택

  2. 배포 단계 정의: 코드가 프로덕션에 도달하기까지 거칠 단계를 명확히 정의
    ex. Staging 영역, Production 영역, 사전 배포 테스트, 사후 배포 검증

  3. 자동화된 테스팅 통합: 모든 단계마다 적절한 자동화 테스트를 통합하여 품질을 보장

  4. 버전 제어 구현: GitHub, Bitbucket 등을 통해 모든 코드 (애플리케이션 코드, 인프라 코드)를 철저히 버전 관리

3. 성공적인 파이프라인 운영 전략

파이프라인을 구축하는 것만큼이나 잘 운영하는 것도 중요하다.

운영 모범 사례로는

  • 큰 변경 사항을 한번에 배포하기 보다, 작게 나누어 배포 -> 문제 발생 시 원인을 빠르게 파악하고 롤백 용이

  • 배포 후 모니터링에서 문제가 감지되면, 즉시 이전의 안정적인 버전으로 되돌리는 메커니즘 구현

이 사례로 들 수 있다.

Case1: 복잡성 및 의존성 관리

  • 전통적인 모놀리식 (Monolithic) 아키텍처에서 마이크로서비스 (MSA) 로 전환하면서 서비스 간 의존성 관리가 복잡해지는 문제점 발생

  • 해결:

    • IaC (Infrastructure as Code) : Terraform 등을 사용해 인프라 구성을 코드화하여 복잡한 환경을 일관되게 관리
    • 컨테이너화 (Containerization) : Docker와 같은 기술을 채택하여 의존성을 패키징하고 배포 일관성 향상

Case2: 보안 문제

  • 파이프라인 전반에 걸쳐 Secrets 관리, 취약점 스캔 등 보안 유지가 중요

  • 해결 (DevSecOps):

    • 비밀 관리 도구: HashiCorp Vault와 같은 전문 도구를 사용하여 API 키, 데이터베이스 암호 등을 안전하게 저장하고 관리한다.

    • 파이프라인 내에 보안 스캔 단계를 통합


4. 모니터링과 로깅

파이프라인은 배포에서 끝나지 않는다. 배포된 애플리케이션을 지속적으로 관찰하는 것이 중요하다.

4-1. 모니터링 및 로깅의 중요성

  • 사전 예방적 문제 감지: 대시보드와 모니터를 통해 애플리케이션의 문제를 실시간으로 파악하고 장애가 발생하기 전에 대응가능

  • 확장성 보장: 사용자가 1명일 때와 10만 명일 때의 볼륨 변화를 모니터링하며 애플리케이션의 성장을 추적하고 대응가능

4-2. 모니터링 및 로깅 구현 방안

  • 자동화된 로깅: 애플리케이션에서 발생하는 모든 오류와 이벤트를 로그로 남겨, 문제 발생 시 원인을 빠르게 파악할 수 있도록 구현 필요

  • 실시간 알림: "디스크 볼륨 80% 사용"과 같이 임계값을 설정하고, 초과 시 즉시 알림을 받아 조치할 수 있도록 구현 필요

    • Prometheus (오픈소스 모니터링)

    • ELK Stack (Elasticsearch, Logstash, Kibana)

    • Grafana (시각화 대시보드)

    • Datadog, New Relic (상용 SaaS 솔루션)

4-3. 배포 파이프라인의 미래 동향

  1. 마이크로서비스: 모놀리식에서 벗어나 작고 독립적인 서비스로 전환하는 추세는 계속될 것

  2. 컨테이너 오케스트레이션: Kubernetes가 사실상의 표준이 되었으며, Rancher, Mesos 및 AWS(EKS), Azure(AKS), GCP(GKE)와 같은 클라우드 관리형 서비스가 시장을 주도하고 있는 상황

  3. 서버리스 아키텍처: 서버 관리가 필요 없는 이벤트 기반 아키텍처 (예: AWS Lambda) 로의 전환이 가속화되고 있음.

  4. AI/ML 도입: AI/ML 기술을 파이프라인에 적용하여 배포 실패를 사전에 예측하거나 리소스 사용량을 최적화하려는 시도가 증가하고 있는 추세

+ AWS Lambda?

AWS Lambda는 서버리스(Serverless) 컴퓨팅 서비스이다.

개발자가 코드를 실행하기 위해 서버를 직접 프로비저닝(생성)하거나 관리할 필요가 없으며, OS 설치, 보안 패치, 서버 확장, 로드 밸런싱 등 인프라와 관련된 모든 운영 작업을 AWS가 전적으로 관리한다.

개발자는 오직 '함수(Function)'라고 불리는 코드 조각을 작성하여 업로드하기만 하면 된다.

Lambda의 가장 중요한 특징은 이벤트 기반(Event-Driven)으로 작동한다는 점이다.

기존의 서버 (ex. EC2 VM or Container) 는 24시간 내내 실행 상태를 유지하며 요청을 기다린다.

반면 Lambda 함수는 평소에는 실행되지 않고 대기하다가, 특정 이벤트가 발생했을 때만 AWS에 의해 자동으로 실행되고, 실행이 끝나면 즉시 종료된다.

  • 주요 이벤트 Trigger

    • API Gateway: HTTP 요청이 들어왔을 때

    • S3: S3 버킷에 새로운 파일 (이미지, 로그 등)이 업로드되었을 때

    • DynamoDB Streams: 데이터베이스 테이블에 변경 (추가, 수정)이 생겼을 때

    • SQS/SNS: 메시지 Queue나 토픽에 새 메시지가 도착했을 때

    • EventBridge (CloudWatch Events): 특정 시간 (ex. 매일 오전 9시)이 되었거나, 다른 AWS 서비스에서 특정 이벤트가 발생했을 때

    • 기타: Kinesis, IoT Core 등 수많은 AWS 서비스와 연동

추가적인 Lambda의 특징은 '요청(이벤트)' 자체가 스케일링의 단위라는 점이다.

  • 요청 1개가 들어오면: Lambda 인스턴스 1개가 실행

  • 요청 1,000개가 동시에 들어오면: AWS가 1,000개의 독립적인 Lambda 인스턴스를 병렬로 실행

  • 요청이 0개가 되면: 모든 인스턴스가 사라지고 비용 0

즉, 사용자가 HPA (Horizontal Pod Autoscaler) 나 Auto Scaling Group 같은 스케일링 정책을 전혀 설정할 필요가 없으며, 트래픽이 0이든 10,000이든 플랫폼이 알아서 완벽하게 처리하는 장점을 가진 기술이다.

4. 결론

  • 자동화된 배포 파이프라인 핵심 이점: 시장 출시 시간 단축, 오류 감소, 팀 협업 증가

  • 핵심 구성 요소: 소스 코드 관리(SCM) → 빌드 자동화 → 자동화된 테스트 → 배포 자동화 → 지속적인 모니터링

이러한 파이프라인을 성공적으로 구축하고 운영함으로써 기업은 급변하는 시장 환경에 민첩하게 대응하고 더 나은 제품을 더 빨리 고객에게 제공할 수 있다.


profile
고태규
이전 포스트

90DaysOfDevOps (Day 33)

다음 포스트

90DaysOfDevOps (Day 35)

0개의 댓글