CI/CD 방식과 각 장/단점

 

 

우선 간단히 적으면 다음과 같다. 

배포 전략	무중단	배포  롤백 가능성	인프라 비용	적용 용도
Blue-Green	✅	✅	높음	대규모 서비스, 빠른 롤백 필요
Canary	✅	✅	중간	점진적 배포, 성능 테스트 필요
Rolling	✅	❌	낮음	인프라 비용 절감, 지속적 배포
Recreate	❌	✅	낮음	단순한 서비스, 빠른 배포 필요
A/B Testing	✅	✅	높음	사용자 반응 기반 배포
Feature Toggle	✅	✅	낮음	코드 배포와 기능 배포 분리

 

여기서는 3가지 업데이트 방식만 보려고 한다 . 

 

 

1. 롤링 업데이트 방식

• 특정 비율로 조금씩 점진적으로 업데이트하는 방식이다. (예: 인스턴스 하나씩 새로 배포되는 )
• 다운 타임 제로라는 장점을 갖고 있다.
• 구글도 작은 서비스를 배포할 때 이방식을 사용하고 있다. 
• 문제점
  • 동시에 서비스의 여러 버전이 존재한다.
  • 롤백이 어렵다. 

 

2. blue-green 방식

• 새로운 배포를 미리 다른 곳에 미리 해두고, 배포 시점에 load balancer 로 트래픽만 바꾸는 방법.
• 빠른 롤백에 유리 그리고 유저입장에서 동시에 한가지 버전만 존재하기 때문에 1롤링 업데이트 방식의 단점을 커버할 수 있다. 
• 단,  문제점:
  • 두 버전이 동시에 존재해야해서 추가적인 인프라 비용 발생.
  • 장애 시에 오히려 그 트래픽을 모두 경험하게 됨
    • 그에 대한 대응으로 dns/ingress 를 이용해서 V2(새로 만들 트래픽)를 먼저 확인하는 등의 작업을 수행해야한다.

출처: redHat

3. canary

• 장애 시에 모든 트래픽에서 장애가 나는 2 blue-green 방식의 단점을 커버한다. 
• 일부 사용자 먼저 사용하게 하도록 트래픽을 특정 비율만큼 점진적으로 변환하는 방식이다. 
• 안정성 및 위험도 최소화
• 단점
  • 라우팅 설정등이 복잡, 배포 환경이 복잡. 체계적인 모니터링 체계가 필요하다. (그래도 istio 를 사용하면 좀 더 수월)
    • 특정 인스턴스에서 언제 배포가 이루어졌냐 등등의 정보를 따로 작성하도록 설정해야 트래킹이 가능할 것. 

 

 

함께 읽으면 도움되는 자료 : https://dev.classmethod.jp/articles/ci-cd-deployment-strategies-kr/

매번 헷갈리는 CI/CD 배포 전략 정리해버리기 | DevelopersIO

 

더 참고할 자료:

https://hyperconnect.github.io/2020/08/19/microsrv-deploy-3.html

https://semaphoreci.com/blog/what-is-canary-deployment