Docker Hub, AWS ECR, Google Artifact Registry 등과 같은 이미지 레지스트리를 사용하여 컨테이너 이미지를 배포한다.
이를 통해 이미지를 푸시하고, 다른 시스템이나 팀에서 해당 이미지를 사용할 수 있게 되어 동일한 환경에서 실행할 수 있다.
2️⃣ 컨테이너 배포
컨테이너 배포란 어플리케이션을 컨테이너화하여 서버나 클라우드 환경에 배포하는 과정을 의미한다.
🔷 단일서버
docker-compose를 이용하여 docker-compose up, down 으로 배포하고 중지할 수 있다.
🔷 프로덕션 환경 (실제 서비스가 운영되는 환경)
프로덕션 환경에서의 컨테이너 배포는 Docker Swarm, Kubernetes, AWS ECS 등과 같은 오케스트레이션 도구를 사용하여 여러 컨테이너를 자동으로 관리하며, 필요할때 배포할 수 있다.
하지만 단순히 컨테이너를 실행한다고 해서 서비스가 제공되는 것이 아니라,
오케스트레이션에서 제공되는 로드밸런서, 서비스 디스커버리, 자동 스케줄링을 사용해야 서비스를 제공할 수 있다.
3️⃣ 오케스트레이션 도구 특징
🔷 로드 밸런서
클라이언트로부터 들어오는 트래픽을 여러 컨테이너 인스턴스에 분산시켜 주는 역할을 한다.
컨테이너는 종종 동적으로 생성되거나 삭제된다. 예를 들어, Kubernetes나 Docker Swarm에서는 컨테이너가 새로운 버전으로 업데이트되면서 생성되거나 종료될 수 있다. 이때, 로드밸런서는 새로운 컨테이너를 자동으로 인식하고 트래픽을 해당 컨테이너로 전달한다.
즉, 로드밸런서는 클라이언트의 요청을 가장 적합한 컨테이너로 전송한다. 이를 통해 서비스의 가용성을 높이고, 각 컨테이너가 과부하되지 않도록 분산 처리한다.
🔷 서비스 디스커버리
서비스 디스커버리는 컨테이너가 동적으로 생성되거나 종료되는 환경에서, 클라이언트가 컨테이너 인스턴스를 찾을 수 있도록 지원하는 역할을 한다.
즉, 서비스 디스커버리가 어떤 컨테이너가 어떤 서비스를 제공하는지에 대한 정보를 로드밸런서나 다른 서비스에 전달하는 역할을 한다.
🔷 자동 스케일링
자동 스케일링은 트래픽 부하에 따라 컨테이너의 개수를 자동으로 조정하는 기능이다.
해당 기능은 로드 밸런서와 함께 동작한다.
예를 들어, 트래픽이 증가하면 컨테이너 인스턴스 수를 늘리고, 로드밸런서가 이들을 자동으로 트래픽 분배하는 구조이다.
🔷 자동 롤백
배포 중 문제가 발생하면 자동으로 이전 버전으로 되돌리는 전략이다.
❗️ 배포 자동화 CI/CD 오케스트레이션 도구를 사용하여 컨테이너를 자동으로 관리를 해주지만 자동 배포를 해주진 않는다. 따라서 CI/CD는 컨테이너 배포를 쉽게 도와주는 중요한 기법이다.
CI/CD는 지속적 통합과 지속적 배포의 약자로, 소프트웨어 개발 및 배포 프로세스를 자동화하여 빠르고 효율적으로 시스템을 관리할 수 있게 도와준다.
1️⃣ 지속적 통합 (CI) 개발자가 코드를 커밋할 때마다 자동으로 빌드하고 테스트하는 과정으로, 이렇게 하면 코드 변경이 시스템에 통합될 때 문제가 발생하지 않도록 미리 감지할 수 있다.
2️⃣ 지속적 배포 (CD) CI가 끝난 후, 지속적 배포는 이 이미지를 자동으로 배포하는 과정이다. 컨테이너 배포에서 CD는 새로운 컨테이너 이미지를 자동으로 배포한다.
대표적인 도구는 대표적으로 Jenkins, GitLab CI, GitHub Actions, CircleCI 등이 있다. 이러한 도구는 무중단 배포 기법을 지원하거나 플러그인/툴을 제공한다.
컨테이너 배포 전략( 전통적 배포, 무중단 배포)
1️⃣ 전통적 배포
과거에는 전통적 배포를 사용하여, 애플리케이션을 새로운 버전으로 업데이트하는 과정에서 서비스가 일시적으로 중단되었다.
예를 들어, v1 서비스가 실행 중일 때 v2 버전을 다운받는 상황이다.
그럼 v1 서비스를 종료시키는 시점부터 v2를 다시 시작하기 전까지 어플리케이션은 중단된다.
이렇게 서비스가 중단되는 시간을 다운타임(downtime)이라고 한다.
배포 중 서비스가 중단되므로 사용자가 일정 시간 동안 서비스에 접근할 수 없다.
따라서 고객 불만이나 서비스 가용성 저하 같은 문제가 발생하였다. 이러한 문제를 해결하기 위해 무중단 배포라는 개념이 등장하게 되었다.
2️⃣ 무중단 배포
무중단 배포란, 서비스가 운영되면서 중간에 재배포를 해도 서비스가 중단되지 않는 것을 뜻한다.
즉, 서비스는 중단 없이 계속 실행되고, 사용자 경험에 영향을 주지 않도록 점진적으로 업데이트가 이루어진다.
무중단 배포의 주요 기법
1️⃣ 롤링배포
기존 애플리케이션을 점진적으로 새로운 버전으로 교체하는 방식이다.
컨테이너 3개가 있다고 가정한다.
그러면 하나의 컨테이너는 로드밸런서에서 제거하고 해당 컨테이너로 가던 트래픽은 다른 컨테이너로 분산된다.
그리고 이때 해당 컨테이너를 v2로 교체한 후, 다시 로드밸런서에 연결된다.
해당 과정을 반복하여 점진적으로 새로운 버전으로 교체하는 방식이다.
장점
점진적 배포로 안정성을 확보할 수 있다.
이유는, 점진적으로 일부 컨테이너에만 새 버전을 적용시키기 때문에, 새로운 버전에서 문제가 발생해도 전체 시스템에 영향을 미치지 않는다. 따라서 문제가 발생한 부분만 롤백하거나 수정하면 되기 때문에 안정성을 확보할 수 있다.
단점
새 버전을 배포할때 잠시 서버 수가 감소하기 때문에 사용중인 컨테이너에 트래픽이 몰릴 수 있다. 즉, 서비스 처리 용량을 고려해야한다.또한 배포가 진행될 때 구버전과 신버전이 공존하기 때문에 호환성 문제가 발생할 수 있다.
🤔 트래픽이 몰리는 문제를 해결할 방법은 없을까?
오버 프로비저닝 컨테이너 수가 감소하여 트래픽이 몰려서 시스템에 부하가 걸리는 문제를 해결하기 위한 방법이다.
컨테이너가 3개 있다고 가정한다. 배포 전에 기존에 실행 중인 컨테이너 외에 추가로 1~2개의 새로운 컨테이너(예: v1 버전)를 생성한다. 배포가 진행되면서 기존 컨테이너는 하나씩 v2 버전으로 변경한다. 배포가 완료되면 추가된 컨테이너를 삭제하여 원래의 컨테이너 수(예: 3개)로 조정한다.
그러나 해당 방법을 사용하면 트래픽이 몰리는 단점은 해결할 수 있지만 리소스는 낭비가 된다. 따라서 많이 쓰이는 방법은 아니다.
2️⃣ 블루그린 배포
트래픽을 한 번에 구버전에서 신버전으로 옮기는 방법이다.
Blue/Green 배포 전략에서는 현재 운영중인 컨테이너의 그룹을 Blue라고 부르고, 새롭게 배포할 컨테이너 그룹을 Green이라고 부른다.
Blue와 Green의 컨테이너 그룹을 동시에 나란히 구성해둔다.
이후, 배포 시점에 로드 밸런서가 트래픽을 Blue에서 Green으로 일제히 전환시킨다.
-> 이 전환은매끄럽게이루어져서, 실제로 사용자가 인지할 수 있는 서비스 중단 없이 진행된다.
Green 버전 배포가 성공적으로 완료 되어 문제가 없다고 판단했을 때에는 Blue 컨테이너를 제거할 수 있다.
장점
롤링 배포와 달리 한번에 트래픽을 모두 새로운 버전으로 옮기기 때문에 호환성 문제가 발생하지 않는다.
단점
실제 운영에 필요한 컨테이너 수의 2배의 리소스가 필요하므로 비용이 증가할 수 있다.
3️⃣ 카나리 배포
새로운 버전을 일부 사용자에게만 제공하고 문제가 없는지 확인 후 점진적으로 확장한다.
새로운 버전 컨테이너를 처음부터 100% 적용하는 것이 아니라, 일부 트래픽(예: 10%)만 새 버전으로 라우팅한다.
오류가 발생하면 즉시 롤백 가능하다.
모니터링을 통해 이상이 없는지 확인하고 문제가 없으면 점진적으로 배포 비율을 증가시킨다.
최종적으로 모든 사용자가 새로운 버전을 사용한다.
장점
새로운 버전으로 인한 위험을 최소화 할 수 있다.
단점
롤링 배포와 마찬가지로 신/구 버전의 애플리케이션이 동시에 존재하므로 호환성 문제가 발생할 수 있다.
🤔 모니터링 및 로그 모니터링과 로그는 배포 중 예상치 못한 오류나 성능 저하를 빠르게 감지하고 해결할 수 있도록 도와준다. 무중단 배포를 진행하는 동안 문제가 발생했을 때 이를 빠르게 파악하고 롤백이나 대처를 할 수 있게 해준다.
예를 들어, Prometheus와 Grafana는 시스템의 상태를 실시간으로 모니터링하고 지표를 시각화하는 데 도움을 준다. 배포 중에는 서버의 CPU 사용량, 메모리 사용량, 응답 시간 등을 모니터링하여 배포가 잘 진행되고 있는지 확인할 수 있다.
로그 관리는 배포 중 발생하는 오류를 추적하고, 어떤 문제가 발생했는지 빠르게 파악할 수 있게 해준다.
배포 전략들의 선택 기준
2️⃣ 롤링 배포
서버 자원을 효율적으로 사용하고 싶은 경우, 롤링 배포는 새로운 버전의 컨테이너를 점진적으로 교체하므로 기존 서버를 활용하면서 배포할 수 있다.
롤링 배포는 구버전과 신버전이 동시에 동작하게 되므로 두 버전 간의 호환성이 중요하다. 따라서 API 호환성이나 데이터구조 변경이 없다면 롤링 배포가 유리하다.
점진적으로 배포할 수 있기 때문에, 작은 업데이트나 점진적인 기능 개선에 적합하다.
1️⃣ 블루그린 배포
서비스 아키텍처를 완전히 바꾸거나, 큰 기능 업데이트를 할 때 유용하다. 시스템 전체적인 변경이므로 빠른 롤백이 가능하고 호환성 문제 없이 전체 트래픽을 한 번에 새 버전으로 전환할 수 있다.
3️⃣ 카나리 배포
새로운 기능이나 중요한 시스템 변경이 있을 때, 전체 사용자에게 배포하기 전에 일부 사용자에게만 배포하여 피드백을 받고 리스크를 최소화하는 방식이다. 문제가 발생하면 해당 문제를 빠르게 수정할 수 있다.
카나리 배포는 사용자의 피드백을 실시간으로 반영할 수 있기 때문에, 사용자 경험을 고려한 배포가 필요할 때 유리하다.
점진적으로 배포하면서 문제를 빠르게 해결할 수 있기 때문에, 새로운 기능이나 대규모 업데이트를 도입하면서 리스크를 줄이고 안정성을 확보할 수 있다.
정리
컨테이너 배포의 무중단 배포는 서비스 중단 없이 애플리케이션을 업데이트하고 운영할 수 있는 핵심적인 과정이다. 배포 전략으로는 롤링 배포, 블루그린 배포, 카나리 배포가 있으며, 각각의 전략은 배포 과정에서의 리스크 관리 및 시스템 가용성을 최적화하는 방식으로 선택된다. 롤링 배포는 점진적인 업데이트로 호환성 문제를 최소화하고, 블루그린 배포는 전체 트래픽을 새로운 버전으로 일괄 전환하여 빠른 롤백을 지원하며, 카나리 배포는 일부 사용자에게만 새 버전을 배포해 피드백을 받고 리스크를 줄이는 방식이다. 이러한 전략들은 CI/CD와 오케스트레이션 도구를 활용해 효율적으로 자동화될 수 있다.
