쿠버네티스로 알아보는 무중단 배포

CloudJun·2021년 12월 31일
0

이 글은 GDSC SoongSil에 먼저 작성하여 공유한 글을 제 블로그에도 올리는 글입니다.


소개

최근 서비스는 하나에 모든 기능이 있는 모놀리식(Monolithic) 구조에서 마이크로서비스 (Microervice) 구조로 바뀌며 자주, 그리고 많이 배포하는 식으로 바뀌어 나가고 있습니다. 하지만 배포가 많을수록 과거에 주로 사용했던 다운타임(Downtime)이 있는 배포는 더욱 민감해질수밖에 없습니다.

이번 게시글에서는 GDSC 숭실 인프라에서 스터디한 내용을 바탕으로 다양하게 사용되고 있는 서비스 배포 전략 기법을 Deployments를 통해 소개하겠습니다.

들어가기 앞서

쿠버네티스 Delployments는 애플리케이션을 배포하고 관리하는 역활을 담당합니다.
보통의 운영 상황에서는 Pod를 직접 생성하는 일은 매우 드물고 모든 관리는 Delpoloyments가 사용되는데 배포와 롤백의 부담을 최소화하고 관리포인트를 줄이는 목적입니다. 이 기능을 사용하여 배포 전략을 설정 할 수 있고 리버전을 통해 롤백을 가능하게 해줍니다.

배포 전략

쿠버네티스에서 사용 할 수 있는 무중단 배포는 3가지로 나눌 수 있습니다. 점전적으로 하나씩 Pod를 최신 버전으로 교체하는 롤링 배포 방식과 모든 신버전을 준비하고 한번에 교체하는 블루-그린 배포 방식, 그리고 최신 버전을 일부만 먼저 배포해 테스트를 진행 할 수 있는 카나리 방식입니다.

하나씩 배포 방식을 정리해보겠습니다.

1. 롤링 배포 (Rolling Deployment)

♻️ 새로운 버전 POD 로 순차적으로 교체하는 방법

롤링 배포는 사용 중인 인스턴스 내에서 새 버전을 점진적으로 교체하는 것으로 무중단 배포의 가장 기본적인 방식입니다. 순차적으로 새 버전을 가진 파드로 교체하는 방법으로, 새로운 ReplicaSets 을 생성하고 새로운 컨테이너로 이전 컨테이너를 교체합니다.

순차적으로 새로운 버전이 올라가며 리소스가 제한적인 인스턴스 환경에서도 사용 할 수 있는 무중단 배포 방식입니다. 다만 그 시간동안 v2 버전과 v1이 공존하다보니 API 설계를 잘못 한다면 문제가 발생 할 수 있습니다.

단계

1) 일부의 Pod v2를 생성합니다.
2) Pod v2가 정상적으로 실행되었다면 생성된 만큼의 Pod v1를 제거합니다.
3) 최종적으로 v1에 아무것도 남지 않을때까지 반복합니다.

2. 블루 - 그린 배포 (Blue-Green Deployment)

♻️ 동일한 사이즈의 서버 리소스를 준비하여 교체하는 방법

블루 - 그린 배포는 DownTime을 최소화하면서 한번에 모든 트래픽을 이동 시키는 방법입니다.
구 버전의 Pod는 Blue 신 버전의 Pod는 Green으로 칭하며 Green Pod가 모든 준비가 완료되었다면 이전 BluePod의 트래픽을 GreenPod로 전환하고 Podv1은 모두 종료시킵니다.

순차적으로 올리는 방식이 아니라 일괄로 변경하는 방식이다보니 모든 트래픽이 동일한 버전의 API를 볼 수 있는 장점이 있습니다. 다만 Green Pod를 준비하는 과정에서 그만한 리소스가 더 필요합니다.

단계

1) Pod v2 (Green Pod)를 리소스에 맞게 전부 실행합니다.
2) Pod v2 (Green Pod)가 모두 실행되었다 판단되면 Pod v1 (Blue Pod)의 트래픽을 Pod v2로 이전시킵니다.
3) Pod v2(Green Pod)에 모든 트래픽이 이전되었다면 Pod v1(Blue Pod)를 제거합니다.

3. 카나리 배포 (Canary Deployment)

♻️ 잠재적 문제 상황을 빠르게 찾아 낼 수 있는 방법

카나리 배포는 과거 광부들이 가스 노출을 점검하기 위해 카나리아라는 새를 사용하여 확인 했던것에 유례한 방법으로 동일한 환경을 복제하여 테스트를 진행했더라도 유저가 사용하는 환경에서는 에러가 발생 할 수 있기 때문에, 이러한 문제를 최소한으로 줄이기위해 고안된 방법입니다.

카나리 배포는 두가지를 활용 할 수 있습니다.

1) 첫번째 방법은 Pod v2를 새로 연결한 다음 가중치에 따라 적은양의 트래픽을 Pod v2로 흘려보내는 방식으로 무작위로 불특정 다수에게 테스트를 진행합니다.

2) 두번째 방법은 특정 Path 경로로만 v2로 접근 할 수 있는 방법으로 v1은 service/api 주소를 가지고 있고 v2는 service/v2/api로 설정하여 v2에 접속하는 사람의 트래픽으로 테스트를 진행한 다음, 이후 문제가 없다 판단되면 service/v2/api 를 service/api로 교체하는 방법이 있습니다.

단계

1) Pod v2를 새로 올린 다음, 적은량의 트래픽 조정하여 Pod v2로 보냅니다.
2) Pod v2가 정상적으로 작동되는 것이 확인된다면 Pod v2를 늘리고 Pod v1를 축소합니다.

마지막으로..

과거와 다르게 하루에 수십번, 많으면 수백번 등 많은 배포가 이루어지는 기업이 늘어나고 있습니다. 배포를 많이 한다는 것은 유저의 니즈를 적용시키기 쉽다는 것이고, 기능 검증이 더욱 빨라진다는 것을 의미합니다. 가상화를 쓰지 않고 운영이 될때는 무중단 배포에 많은 인적, 자원 리소스가 들었지만 지금은 쿠버네티스와 같이 자동화된 툴이 많은 지원을 하고 있습니다.

배포는 유저에게 공개되는 핵심적인 활동으로 배포 인프라는 매우 중요하게 관리 될 수밖에 없습니다. 다양한 가상화 도구 플랫폼이 생기며 무중단 배포가 당연시 되는 지금, 충분히 경쟁력 있는 서비스로 운영하기 위해서 만약 아직 무중단을 지원하지 않는다면, 한 번쯤 고려해보길 바랍니다.

profile
짧고 굵게 살아가는 백엔드 개발자

0개의 댓글