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
- 결함의 조기 발견으로 인한 비용 감소
- 위험 감소
- 품질에 대한 자신감
- 개발자가 새로운 기능을 추가하거나 오류를 수정하는 등의 작업 내용을 저장소에 반영하기 위해 커밋하는 단계
- 통합 서버는 저장소에 코드가 커밋되었음을 감지하고 빌드 환경에 코드를 다운로드
- 코드를 컴파일하고 통합
- 단위 테스트 및 코드 리뷰 수행
- 테스트 결과 생성
- 생성된 테스트 결과를 여러 수단(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 수행