EKS Blue/Green 배포 1부

안녕하세요. 여기어때컴퍼니 인프라개발팀에서 EKS(Elastic Kubernetes Service, AWS의 관리형 Kubernetes 서비스)를 담당하고 있는 젠슨입니다. 이전에 여기어때 EKS Update는? 이라는 주제로 인사를 드린 적이 있습니다.

여기어때컴퍼니에서는 최근 업데이트를 거쳐 Version 1.27의 EKS를 사용하고 있습니다. 오늘 제가 소개해 드릴 내용은 Version 1.27까지 오면서 EKS에추가되었던 많은 기능들 중 하나인 Blue/Green 배포입니다. 불행하게도 EKS에서는 기본설정만으로 Blue/Green이나 Canary 방식으로 배포를 할 수 없습니다. 그래서 이러한 방식을 적용하기 위해서는 별도의 설정이 필요한데, 이는 2부에서 다루도록 하겠습니다. 1부에서는 CI/CD에 대한 공부를 시작한 사회 초년생들을 위하여 Rolling, Blue/Green, Canary에 대한 개념을 다루도록 하겠습니다.

1. Rolling

Rolling 배포는 운영중인 Version 1.0의 POD에 Version 2.0의 신규 Application이 배포 되었을 때 Version 2.0의 POD 생성과 Version 1.0의 POD 종료가 동시에 진행되는 것을 의미합니다. 일반적으로 EKS는 Rolling 방식으로 배포를 진행합니다. 아래와 같은 형식입니다.

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%

아래와 같이 Version 1.0의 Application이 Client에게 제공되고 있다고 가정해 보겠습니다. Service 앞에 Ingress 등이 올 수도 있지만 쉬운 이해를 위해 생략하겠습니다. Client는 현재 Version 1.0의 Application을 경험하고 있을 것입니다.

Rolling — Version 1.0

만약 Version 2.0 Application을 배포하게 되고 Rolling 방식을 사용할 경우 아래와 같은 순서대로 진행될 것입니다.

Rolling — Version 2.0 Application Deploy(1)

Version 2.0의 Application이 배포되면 Deployment의 manifest에 선언되어 있는 maxSurge, maxUnavailable 수치에 맞춰서 신규 POD가 배포될 것입니다. 수치에 따라서 약간은 다를 수 있지만 보통 Version 2.0의 신규 POD가 배포되면 기존에 배포 되어 있던 Version 1.0의 POD 중 일부는 상태가 Terminating으로 변경될 것입니다.

Rolling — Version 2.0 Application Deploy(2)

조금 더 시간이 흐르면 Version 2.0의 POD는 liveness probe, readiness probe에 성공하는 시점부터 Ready 1/1 상태가 되고 서비스를 제공할 것이며 기존에 서비스를 하고 있던 Version 1.0 POD는 Terminated로 이미 삭제가 이루어 졌을 것입니다. 결국 동일한 방법을 한 번 더 수행하게 되고 최종적으로는 아래와 같이 Client가 Version 2.0의 Application을 제공받게 될 것입니다.

Rolling — Version 2.0 Application Deploy(3)

Rolling 배포 전략이 문제가 되는 것은 아니지만 그림 : Rolling — Version 2.0 Application Deploy(2)를 보시면 한가지 특이한 점을 발견할 수 있습니다. Client 시점으로 바라보았을 때 아주 잠시동안 Version1.0과 Version2.0의 Application을 모두 제공받게 됩니다. 즉, Rolling 배포 방식은 간단한 배포가 가능하지만 기존, 신규 Version의 Application이 공존하는 시간이 발생한다는 것을 알 수 있습니다.

이러한 배포 방식이 서비스를 제공하는데 문제가 없다면 해당 Application은 Rolling 방식을 사용해도 상관이 없지만 Version 공존 시간 때문에 문제가 발생할 수 있다면 Blue/Green 배포 방식을 사용해야 합니다.

2. Blue/Green

이제 Blue/Green의 배포 방식에 대해서 알아보도록 하겠습니다. 아래와 같이 Blue/Green은 Version 2.0의 Application이 배포될 경우 기존 운영 중이던 Version 1.0의 POD들이 계속해서 Client에게 서비스를 제공합니다. 하지만 EKS 내부에서는 Version 2.0의 POD가 생성되며 서비스 준비를 시작합니다.

Blue/Green — Version 2.0 Application Deploy(1)

배포가 완료되고 Version 2.0의 POD Status가 1/1 상태로 서비스를 제공할 준비가 완료되면 Version 1.0의 POD를 바라보던 Service가 Version 2.0의 POD를 바라보도록 한 번에 변경합니다.

Blue/Green — Version 2.0 Application Deploy(2)

이제 Client는 Version 2.0의 서비스를 제공 받게 됩니다. 두 개의 Version이 동시에 제공되는 상황이 발생하지 않습니다. Version 2.0의 Application이 제공되기 시작하면 EKS 내부에서는 원래 운영 중이던 Version 1.0의 POD를 삭제하기 시작합니다.

Blue/Green — Version 2.0 Application Deploy(3)

Version 1.0의 POD가 Terminated되면 결국 아래와 같이 Version 2.0의 POD 만 남게 됩니다.

Blue/Green — Version 2.0 Application Deploy(4)

3. Canary

Rolling과 Blue/Green은 위에서 보여드린 것과 같이 완전히 상반된 개념을 가지고 있습니다. 이 중간에 위치한 게 Canary 배포 방식입니다. Canary 배포 방식은 의도적으로 두 개의 Version을 공존 시키면서 신규 Version의 Application이 문제 없이 잘 동작하는지 확인하는 방식입니다.

아래 그림을 예시로 설명해 보겠습니다. 신규 배포가 발생하면 Version 2.0의 POD가 준비될 때 까지 Version 1.0의 POD가 서비스를 제공합니다.

Canary — Version 2.0 Application Deploy(1)

Client는 Version 1.0의 Application만 경험할 것입니다. 이어서 Version 2.0 POD가 Ready 1/1 상태가 되면 Client 중 일부는 Version 2.0의 Application을 경험하게 되며 기존 Version 1.0의 POD 중 일부는 삭제됩니다.

Canary — Version 2.0 Application Deploy(2)

이 상태가 Canary의 핵심입니다. Client 중 일부에게만 의도적으로 신규 버전을 경험하게 함으로써 Version 2.0에 문제가 없는지 조금씩 테스트 해 볼 수 있습니다. 현재 4개의 POD 중 1개의 POD 만, 즉 25% 적용된 상태이고 이 수치를 높여가면서 신규 Application이 문제 없는지 확인할 수 있습니다.

Canary — Version 2.0 Application Deploy(3)

100% 적용되면 Version 2.0의 POD로 모두 교체가 될 것입니다.

여기까지가 EKS에서 대표적으로 사용하는 Rolling, Blue/Green, Canary 배포 전략에 대한 개념입니다. 2부에서는 여기어때컴퍼니에서 사용하고 있는 Blue/Green 배포 전략을 실제로 적용하는 방법에 대해서 설명해 드리도록 하겠습니다.

감사합니다.