[소프트웨어공학] DevOps

수진·2023년 4월 23일
0

소프트웨어공학

목록 보기
8/20

DevOps Process

  • Plan: 요구사항 정의(무엇을 개발할지 결정)
  • Code: 구현 및 구현된 코드를 코드 저장소에 커밋(commit)
  • Build: 코드 저장소에 커밋된 코드가 문제가 없는지를 검사한(단위 테스트 및 코드 리뷰)후에 기존 코드와 통합
  • Test: 운영 환경에 배포할 상태가 되어 있는지를 테스트(사용자 인수 테스팅, 성능 테스팅 등)
  • Release: 최종 산출물(바이너리 형식)을 관리
  • Deploy: 최종 산출물을 실제 운영 환경(production environment)에 배포
  • Operate/Monitor: 로깅 등을 통해 운영 현황(이용자 웹 페이지 접속 경향, CPU나 메모리의 사용량과 같은 서버의 부하 상황 등)에 대한 데이터를 수집하고 분석하여 결과를 통지하고 다음 개발 계획을 위해 피드백

CI와 CD

  • CI(Continuous Integration): 지속적 통합
  • CD(Continuous Delivery): 지속적 전달

Bing Bang Integration: Integration Hell

  • 코드의 통합이 프로젝트 종료 시점에 이루어짐
  • 뒤늦은 결함 발견(결함은 빨리 발견할수록 비용의 감소)
  • 오류의 원인 파악 어려움
  • 배포 가능한 소프트웨어 부재
  • 제품에 대한 자신감 결여

1. Continuous Integration

  • 결함의 조기 발견으로 인한 비용 감소
  • 위험 감소
  • 품질에 대한 자신감
  1. 개발자가 새로운 기능을 추가하거나 오류를 수정하는 등의 작업 내용을 저장소에 반영하기 위해 커밋하는 단계
  2. 통합 서버는 저장소에 코드가 커밋되었음을 감지하고 빌드 환경에 코드를 다운로드
  3. 코드를 컴파일하고 통합
  4. 단위 테스트 및 코드 리뷰 수행
  5. 테스트 결과 생성
  6. 생성된 테스트 결과를 여러 수단(SMS, Slack, Email 등)을 통해 통지
    => CI의 모든 과정이 적절한 tool chain을 통해 자동화

2. Continuous Delivery

  • 시스템이 실제 운영 환경에 릴리스 준비가 되어 있는지를 확인하기 위해 다양한 테스트 환경에서 다양한 테스트 수행
  • Continuous Integration를 확장시킨 개념

3. 테스팅 환경

  • (QA) Testing Environment: QA 팀이 테스트하기 위해 사용하는 환경. 복잡하고 시간이 걸리는 테스트를 수행
  • Staging Environment: 실제 운영 환경과 동일한 환경. 실제 운영 데이터를 사용하여 (통합된) 시스템을 대상으로 사용자 인수 테스트(UAT)를 포함한 다양한 비기능적 테스트 수행(부하 테스팅, 성능 테스팅, 보안 및 장애 테스트 등)
  • Production Environment: 실제 운영 환경이며 Blue-green deployment나 Canary deployment 등의 배포 전략을 사용하여 배포가 이루어진다.

3.1 Testing Pyramid

  • Mike Cohn에 의해 제안
  • testing을 3종류로 나눔

1) Unit Testing

  • 각 컴포넌트가 의도한대로 동작하는지를 테스트
  • 각 컴포넌트가 의존하는 다른 컴포넌트는 가짜(test double)로 대체
  • 개별적인 unit을 대상으로 테스팅함

2) Integration Testing

  • 일반적으로 컴포넌트와 컴포넌트를 통합하여 실시하는 테스트를 의미하나 여기에서는 시스템이 외부 환경(DB, 파일 시스템, 외부 시스템)과 통합이 문제가 없는지 테스트하는 의존성 테스트를 의미

3) E2E Testing

  • End-to-End Testing
  • UAT(User Acceptance Testing)에 같은 의미로도 사용
  • 전체 시스템이 통합된 상태에서 사용자 관점에서 테스팅
  • 단위 테스트, 통합 테스트보다 훨씬 더 테스트가 복잡하고 시간이 많이 걸림

4. Continuous Deployment

  • Continuous Delivery는 실제 운영 환경으로 배포할 때 사람의 승인이 필요하지만 Continuous Deployment는 사람 개입없이 자동으로 배포(auto)

    + 알아두어야 하는 용어
    smoke test: 비용이 큰 품질조직의 테스트에 앞서서 프로그램의 중요한 기능이 잘 작동하는지 확인하기 위해 소프트웨어 빌드 후에 수행되는 소프트웨어 테스팅

5. 배포 전략

  • Production env로 배포할 때 서비스가 중단되는 시간이 없도록 하는 무중단(zero down time) 배포가 중요
  • 배포시 문제가 발생할 때 rollback(예전 버전으로 돌아감) 필요

5.1 Rolling Update

  • 기존 인프라에 구 서비스를 제공하는 서버를 하나씩 순차적으로 새로운 버전으로 대체하는 방식
  • 단점
    - 구버전과 새버전의 서비스가 혼재
    - 서버에 새버전으로 배포될 때 서버에 과부하 가능성 있음
    (나머지 서버들로만 request(사용자의 요구에 대응) 할 때 적은 수의 서버만 있는 상태에서 몰리게 됨)

5.2 Blue-green 배포

  • 2개의 동일한 운영 환경을 준비하여 동시에 교체하는 방법
  • 여분의 인프라 준비를 해야 하지만 Rolling update의 구버전과 신버전이 동시에 서비스 되는 시간이 없으며 배포동안 문제가 발생했을 때 Rollback이 쉬움
  • 새로운 운영 환경을 준비해야 하지만 한번에 서비스 전환이 이루어져 구버전과 신버전이 동시에 서비스되는 시간 X
  • 문제 발생 시, routing을 구버전으로 해주면 되기 때문에 Rollback이 쉽게 이루어질 수 있는 배포 방식
  • 비용이 비쌈
  • 한 상황 - Blue, 다른 상황 - Green
  • 한 번에 새 서비스를 제공하는 운영 환경으로 모든 사용자의 request를 routing 시킴

5.3 Canary

  • 구 버전의 서비스를 제공하는 서버들 중에서 일부 서버에 새 버전의 애플리케이션을 배포하고 이 서버들에 일부 사용자 그룹의 트래픽을 분산하도록 함. 별 문제가 발생하지 않으면 나머지 서버들도 교체하면서 사용자 비율도 증가시킴
  • 카나리는 소수의 사용자에게만 배포되기 때문에 blue/green 방식(사용자 전체에 영향을 줌)보다 상대적으로 영향이 적음
  • Capacity testing 수행

0개의 댓글