[AWS] Code Deploy를 사용하기 전에 꼭 알아야할 것 (feat. Loosely Coupled)

Intro

오늘은 Code Deploy를 왜 써야하고, 언제 써야하고, 어떻게 써야하는지에 대해서 이야기 해보고자 합니다. Code Deploy는 AWS에서 운영을 하고 있다면 거의 피할 수 없는 서비스이기 때문에 AWS를 사용하는 담당자 분들은 반드시 잘 알아야하는 서비스 입니다.

Code Deploy가 뭔가요?

Code Deploy는 단어 그대로 코드를 배포해주는 서비스 입니다. AWS 상에서 CI/CD를 가능하게 해주는 Code시리즈 Code Commit, Code Build, Code Deploy 중 하나로 이 시리즈를 하나의 파이프라인으로 만들어주는 Code pipeline 서비스로 묶을 수도 있습니다.

Code Deploy는 왜 사용해야 하나요?

기존에 대부분의 개발자들은 젠킨스라는 빌드배포 오픈소스 솔루션을 사용했을 겁니다. (요새는 github action도 많이 사용하더군요) 그러면 왜 Code Deploy를 사용해야할까요? 그 가장 큰 이유는 2가지가 있습니다.

• 첫째, 기존 방식에서는 AWS의 Autoscaling 기능을 사용할때 유동적인 IP에 대응이 힘들다
• 둘째, 기존 방식에서는 AWS의 ELB에서 유입되는 트래픽 제어가 힘들다

Code Deploy는 언제 사용해야 하나요?

위에서 설명드린 2가지의 경우가 해당 되지 않는 다면 기존 방식 그대로 소스 배포를 하면 됩니다. 하지만 그렇지 않다면 Code Deploy를 사용할 수 밖에 없습니다.

Code Deploy으로 배포할 수 있는 대상은 3가지로 EC2, Autoscaling Group, On-premise Server 입니다. 이 중에 Autoscaling Group을 대상으로 설정하게되면 Autoscaling Group에 Life Cycle Hook이 등록이 되고 서버가 Scale Out될때 Code Deploy의 배포가 자동으로 일어나게 됩니다.

Autoscaling Group에 Life Cycle Hook 이란?

LCH(Life Cycle Hook)은 Autoscaling 정책에 의해서 Scale in/out 될때 특정 작업을 수행할 수 있도록 해주는 기능입니다.

Autoscaling Group은 Scale out 발생시 대상 EC2인스턴스의 상태를 확인하고 사용할 수 있는 상태인지 체크를 하고 사용할 수 있는 상태로 만드는데요. 여기서 중요한점은 LCH가 설정이 되어 있을 경우 인스턴스가 사용할 수 있는 상태가 되었어도 LCH의 작업이 모두 완료가 된 뒤에 EC2인스턴스의 상태를 체크하여 Healthy 상태로 확인한다는 점입니다.

정리해보면 Code Deploy의 대상이 AutoScaling Group이면 자동으로 LCH가 등록이 되고, Scale Out이 발생되었을 때 LCH에 의해서 자동배포가 완료가 된 다음에 EC2의 health Check를 한다는 점입니다. 따라서 소스코드 배포가 완료가 안됐는데 Client가 접근하면 어쩌지? 하는 걱정을 하지 않아도 된다는 이야기 입니다.

그러면 만약에 LCH가 2개 이상일 경우에는 어떻게 동작할까요?

Autoscaling Group에 LCH가 2개 이상 일 경우 즉, 2개 이상의 Code Deploy의 대상이 동일한 Autoscaling Group 일경우 인데요. 이때는 LCH의 순서 보장이 안되며 2개의 배포가 동시에(parallel) 하게 동작합니다.

또한 2개의 LCH가 모두 동작하고 난뒤에 EC2의 heath check를 하게 됩니다.

Code Deploy로 트래픽 제어는 어떻게 하나요?

Code Deploy로 트래픽 제어를 하기위해서 가장 중요한 것이 하나 있습니다. Code Deploy로 제어할 수 있는 Target Group은 1:1 매핑으로 여러개의 Target Group을 할당할 수 없습니다.

따라서 ALB의 Target Group들은 대상이 같으면 안됩니다. 이 말은 아래 그림처럼 하나의 대상(EC2 또는 Autoscaling Group)에서 여러개의 포트를 사용하게 하면 안된다는 이야기 입니다.

그림1

왜냐하면 Code Deploy가 배포시 트래픽 제어를 할때 ALB target Group 대상에서 제외(Dranning) 시킨다음배포가 완료 되면 다시 대상으로 할당하는 작업을 자동으로 해주게 되는데요. Application이 Loosely coupled 하게 나누어져 있지 않다면 배포시 Application을 재시작할때 다른 포트로 유입되고 있는 트래픽의 유실이 발생할 수 있기 때문입니다.

이러한 상황을 피하기 위해서는 2가지 케이스가 있는데요. 그림으로 보면 이해가 빠를 것 같습니다.

• 첫째, Application을 Loosely coupled 하게 나눈다.
  그림2
  

  

• 둘째, ALB의 Target Group대상을 두개로 나눈다.
  그림3
  

  

번외로 세번째 방법이 있습니다만 별로 추천해드리고 싶지는 않습니다. 그래도 어떤 방법인지 대략 설명드리면. Code Deploy에 의해서 실행되는 스크립트에 다른 Target Group에 트래픽 제어를 위한 스크립트를 넣어두는 겁니다. Target에서 제외하고 배포가 완료되면 다시 할당하는 스크립트를 말이죠.
(스크립트로 관리하게되면 서비스의 안정성을 보장할 수 없기 때문에 가급적 사용하지 않는 것이 좋습니다)

Code Deploy를 사용 한다는 것은..

결론적으로 Code Deploy를 사용하기 위해서는 Application 또는 EC2가 Loosely Coupled 하게 설계가 되어있어야 한다는 것입니다. 클라우드, 가상화 그리고 Micro Service Architecture에서 가장 중요한 핵심 포인트가 Loosely Coupled 이고 이를 위해서는 반드시 Application을 분리하고 이에 따라서 소스코드의 분리 그 다음 인프라 레벨에서의 분리가 같이 이루어져야 합니다.

Application이 분리되지 않고 VM단위로 인프라 레벨에서만 나누어져 있다면 클라우드를 사용할 이유가 없는 것이고, Autoscaling, Code Deploy, ELB와 같은 서비스도 활용하기가 매우 어려워진다는 것을 확인해야 합니다.