무중단 배포
CI/CD 파이프라인 구축에서 가장 중요한 것은 무중단 배포다. 서비스가 업데이트될 때마다 클라이언트가 서비스를 이용하지 못하게 된다면, 사용자 경험이 현격히 하락할 것이다. 더군다나 웹 애플리케이션은 그 특성상 하루에도 여러 번 업데이트가 일어나기 때문에 서비스 중단 없이 배포가 이루어져야 한다.
서비스 배포에는 여러 전략이 있다.
- Rolling Update
- Blue/Green
- Canary
이중 Rolling Update는 이전에 Kubernetes를 다루면서 이미 한 번 구축해 본 경험이 있다.
Rolling Update
Rolling Update는 Kubernetes에서 컨테이너(정확히 말하면 Pod) 업데이트를 진행할 때 기본적으로 채택하는 배포 업데이트 방식으로, 컨테이너를 하나씩 업데이트해 나가는 방식이다. 이 방식은 컨테이너를 하나씩 업데이트하기 때문에 일정 시간 동안 존재하는 컨테이너 개수가 Blue/Green 전략보다 훨씬 적기 때문에 서버에 부하를 덜 준다는 장점을 가지고 있다. 그러나 Rolling Update는 컨테이너를 순차적으로 업데이트하기 때문에 서비스의 업데이트 이전 버전과 업데이트 이후 버전 모두 고객에게 제공된다는 단점을 가지고 있다.
Blue/Green 전략
Blue/Green 전략은 한 번에 모든 컨테이너를 변경하는 전략이다. Blue/Green 전략에서 Blue는 통상적으로 구버전 서버(컨테이너, Pod 등)를 일컫고, Green은 통상적으로 신버전 서버를 일컫는다.
업데이트 이전에 Blue 컨테이너 10개가 서버에서 구동되고 있다고 하자. 개발자에 의해 서비스에 새로운 기능 (Feature)이 개발되었고, 이를 Production에 반영해야 한다. 개발자의 코드는 동료 개발자와 PM에 의해 승인되어 main 브랜치에 merge되었고, CI/CD 파이프라인이 main 브랜치에 발생한 이벤트에 반응하여 새로운 버전의 서비스 배포를 시작한다.
기존 Blue 컨테이너를 서비스 중단 없이 새로운 Green 컨테이너로 교체해야 한다. 이를 위해 Blue 컨테이너는 일단 종료하지 않고 서비스를 계속 제공한다. 트래픽은 아직 Blue 컨테이너로 포워딩된다.
그리고 Green 컨테이너를 새로 생성한다. Blue 컨테이너의 개수에 맞게 10개를 생성한다. 현재 클러스터에는 Blue 컨테이너 10개, Green 컨테이너 10개, 총 20개의 컨테이너가 작동하고 있다.
Green 컨테이너가 제대로 작동하는지 확인한다.
Docker의 HEALTHCHECK 커맨드를 사용하거나, 아니면 curl을 활용해 health check용 엔드포인트에 API 요청을 보냄으로써 확인할 수 있다.
Green 컨테이너가 제대로 작동하는지 확인했으면 Blue 컨테이너로 향하는 트래픽을 모두 Green 컨테이너로 변경한다. 이후 Blue 컨테이너는 종료한다.
이처럼 Blue/Green 전략을 사용하면 중단 없이 서비스를 한 번에 새로운 버전으로 변경할 수 있다는 장점이 있다. 다만 상술한 바와 같이 배포 과정에서 작동 컨테이너의 개수가 필요한 컨테이너 수의 2배가 되기 때문에 노드에 부하를 줄 수 있다는 단점을 가지고 있다.
무중단 배포 환경을 구축하기 위해서 여러 방법을 고려해 볼 수 있다.
- Kubernetes Cluster를 직접 구성해서 Kubernetes를 활용하기 (kubeadm 등 활용)
- 클라우드 네이티브 Kubernetes 서비스를 활용하여 Kubernetes 활용하기 (비쌈)
- AWS Elastic Container Service 활용하기
- Docker와 CI/CD 파이프라인만으로 어떻게든 해내기
나는 여기서 Docker와 Jenkins를 활용하여 Blue/Green 환경을 구성해 보려고 한다. ECS를 활용하는 것이 가장 편하겠지만, 한번 스스로 Blue/Green 환경을 구성하는 경험을 해 보려 한다.
