AWS 기초이론 - Ci/CD & Code Deploy & Code Pipeline

in AWS on Basics

1. CI/CD

  • CI : Continuous Integration (지속적인 통합)
    • 개발자들이 자신의 코드를 일종의 중앙 Repository에 올려 test를 하고 다른 개발자들의 코드에 영향이 가지 않게 노력해야하는데 CI가 그 부분을 많이 덜어줌. 개발자들의 코드 충돌을 막아준다고 생각하면 됨.
  • CD : Continuous Deployment (지속적인 배포)
    • 버그 수정 등을 통해 지속적으로 프로그램을 배포함으로 사용자들이 사용 시에 불편함을 막기 위해 도입된 개념으로 덕분에 많은 것들이 자동화됨으로 개발자들의 짐을 덜어줌.

장점

  • 자동화 시스템(Automation) - 테스트
  • Incremental Change : 어떤 기능을 구현하기 위해 A, B, C 라는 작은 기능을 우선적으로 구현해야 한다면 우선 A를 구현하고 test를 거치고 B를 작업하는, 이처럼 점차점차 프로그램을 수정시키는 작업을 말하는데, CI/CD가 이런 기능을 가능케 함.
  • CI/CD 를 사용하지 않는 경우, 프로그램 에러가 발생하여 이전으로 돌아가려고 할 때 매번 백업과 TEST가 매우 번거로워 짐.


2. Code Deploy

  • 코드의 수정사항들을 production에 적용시켜 자동으로 배포하는 기능
  • 새로운 기능들의 빠른 배포
  • 소프트웨어 & 서버 다운타임 X
  • Manual 에러 X
  • 2가지 배포 방식 존재
    • Rolling 배포 : 현재 Production에서 돌아가고 있는 서버가 있고 기능을 추가적으로 구현해서 적용시키려고 할 때, 첫 배포시 75% 는 기존 Production, 나머지 25% 는 새로운 서버로 대체하고 두 번째 배포시 50: 50으로 점층적인 배포 방식
    • Blue/Green 배포 : Blue는 현재 Production, Green은 새로 배포할 것을 의미하고, Green은 Blue와 유사한 환경에서 개발과 테스트를 진행하면서 Blue의 트래픽양을 점점 줄이고 Green으로 옮겨가면서 최종적으로 blue를 셧다운 시키는 방식

그림1

  • 왼쪽 V0버전이 V1 버전으로 바뀌면서 하나씩 바꿔가는 방식
  • 치명적인 버그 발견시 이전으로 돌아가기는 어려움
    • V0 하나하나의 인스턴스에 배포를 통해 버전을 낮춰야함으로 한번에 돌아갈 수 없음

그림2

  • V0 버전의 트래픽을 줄이고 V1쪽으로 이동해가는 방식
  • 버그 발견시 ELB 세팅 변경을 통해 단순히 트래픽을 옮기면 이전 버전으로의 스위치가 용이


Rolling 배포는 그럼 언제 사용할까?

  • 첫 배포시, 다른 버전과 비교할 것도 없고 상대적으로 빠른 배포가 가능
  • Blue/Green 배포 방식은 하나의 새로운 Production 환경을 만들어 내기에 2개의 환경을 구축하는데 추가적인 비용이 들기 때문에 첫 배포시에는 적합하지 않음
  • 첫 배포가 아닐 경우는 Blue/Green 방식을 사용하는 것을 추천


3. Code Pipline

  • 빌드, 테스트, 배포 과정을 관리
    • 코드 변경시 Code Pipline은 이를 감지
  • 소프트웨어 및 어플리케이션 출시 자동화 기능
    • 빠르고 쉬운 디버깅을 가능케 해줌

그림3

  • Workflow 정의 : 코드 저장소에 코드 변경되었을 경우 시작되는 행위들을 정의
  • Staging 배포 : 기능을 테스트하는 단계를 거침
  • Production 배포 : 출시한다는 것
  • Code Pipline은 이 것들은 모두 자동화 시켜줌


© 2021. By Backtony