DevOps : Blue-Green 배포, A/B Testing 그리고 Canary Releases

최근에 기술적으로 논의를 하는 자리에서 꼭 나오는 단어가 있다. 바로 "DevOps"이다. 이 단어의 개념를 논하는 대상이 인프라팀이나, 개발팀이냐에 따라 성격이 조금은 다르다.

그들과 탁자에 앉아서 대화할 때 DevOps에 대한 방향성은 항상 옳고 재미있는 길이라고 판단한다. 하지만 때로는 DevOps라는 단어 자체가 불편하게 느껴질 때도 있다. 우리나라 환경에서 개발팀과 인프라팀은 항상 Communication에 있어서 대립하며 그들간의 체계적인 R&R 정의가 매우 힘들다.

예를 들어 배포에 대한 Best practices, hot deployments, rollback 등에 대한 이야기를 팀과 이야기하고 있었는데 blue-green 배포에 대한 이야기를 꺼냈을때, 그들의 뜨거웠던 공기가 차갑게 식는 것을 느꼈다. 이렇듯 바라보는 시선에 따라 조금은 조심스러운 길인 것 같다.

Blue-Green 배포는 이미 Amazon에서 10년이 넘는 기간동안 이루어졌다. 그만큼 안정적이고 검증된 배포 프로세스이다. Blue-Green 배포는 silver bullet 즉 개발 life cycle을 빠르게 해주는 총알이 아니라 단지 Life cycle 관리에 유용한 프로세스이다. 그럼 A/B Testing은 어떨까? 아니면 Canary Releases는 어떨까?

정말 많은 #Microservices , #DevOps , #Cloud-Native 에서는 그들의 대한 논의가 이루어지지만, 내가 지금까지 바라본 개념을 정리하고 싶다.

Blue-Green Deployments

첫번째로, Martin Fowler의 Blue-Green Deployments에 대한 링크를 살펴볼 필요가 있다.( https://martinfowler.com/bliki/BlueGreenDeployment.html ) 이곳에서 전반적인 개념을 제공한다.

Blue-Green Deployments는 기본적으로 릴리즈와 관련된 모든 downtime을 줄이기 위한 Application Release 기술이다. 앱을 출시하기 전에 준비하는 매우 빠른 방법이며, 배포판의 Issue가 감지되었을 시 빠르게 Rollback을 할 수 있다.

시나리오를 설명해 보겠다. 먼저, 똑같은 환경을 지닌 인프라를 2 Set을 준비한다. 물론 Blue-Green을 활용하기 위해서는 현재 운영중인 인프라의 2배의 리소스가 필요하다.

이제 시나리오로 예를 들겠다. 

먼저, 현재 운영하고 있는 Application은 초록색(Green) 인프라에서 동작되고 있는 중이다. V2 개발이 끝난다면 기존 Big Bang upgrade 방식으로 초록색 인프라에 덮어 씌우는 것이 아닌, 비어있는 파란색(Blue) 인프라에 V2 배포를 한다.

그리고 파란색 인프라에서는 새로운 버전의 Unit Test, Smoke test 혹은 그밖의 테스트(OS, cache, CPU에 대한 부하 테스트를 포함)를 수행한다. 만약 모든 테스트가 끝난다면, 초록색 Application으로 트래픽을 보내주는 LB/Router/Proxy 등의 타겟을 파란색 인프라로 변경해준다.

그 이후에 신버전 릴리즈로 인한 실패 혹은 예외 등의 Issue가 발생하는지 모니터링 한다. 모든 Standby가 종료되면 기존의 초록색 인프라는 종료하고 다른 용도로 사용한다. 만약 Issue가 발생했다면, 신속하게 앞단의 LB/Router/Proxy의 타겟을 정상적인 초록색 Application으로 변경하는 Rollback 작업을 수행한다.

이론적으로는 완벽한 이 배포 방법에도 사실 고려해야 할 점이 여러가지 있다.

- 기존 초록색 Application에서 Long-term 트랜잭션이 수행되고 있었다면, 파란색으로 전환할 때 해당 트랜잭션이 제대로 수행되지 못한다. 물론 새로운 Request도 정상적으로 처리해야한다. 이 문제는 DB backend에서 처리해 주면 좋지만, 실상 그렇게 동작하는 경우는 거의 없다.

- 초록색 Application이 가지고 있던 Database Migration도 매우 큰 고려사항이다. Migration이 정상적으로 수행되었다고 해도, 만약 V2의 파란색 Application이 문제가 생겨 Rollback을 수행할 때에도 해당 DB 정보도 Rollback에 대한 고려가 되어야 한다.

- 위에서 언급했 듯 Blue, Green 두 세트의 인프라가 준비되어야 하고, 그만큼 두배의 Cost가 발생한다.

그 밖에도 여러가지 고려사항이 있지만, 그 것을 감안하더라도 기존 Dev-Stage-Product 배포 프로세스에 비해, 운영적으로 효율적인 프로세스가 아닐까 하는 생각이 든다.

A/B Testing

많은 사람들이 A/B Testing과 Blue-Green Deployment를 구분하지 못한다. 실제로 업무관련 협의를 진행할 때에도 이 두가지 용어를 혼돈하여 사용하는 경우를 많이 보았다.

간단히 말해 A/B Testing은 기능적으로 Upgrade된 적용이 아닌, 서로 다른 두가지 버전의 Application 중 유용성, 인기도, 눈에 띄는 정도 등과 같은 다양한 이유로 Application 기능을 테스트하는 방법이다. 일반적으로 App의 UI 부분과 관련된 Test가 많지만, backend는 이 두가지 Application을 모두 동작할 수 있도록 준비되어 있어야 한다.

이 방법은 Application-Level switch, Static Switch(Application), Traffic Manager 혹은 아래 설명된 Canary 릴리즈로 구현할 수 있다.

Blue-Green 배포와 A/B Testing의 차이점은 A/B Test는 단지 App의 기능을 측정하기 위한 도구로 사용된다는 것이고, Blue-Green 배포는 새로운 버전의 기능을 안전하게 Release하고, 예상대로 Rollback하는 것을 목표로 삼는다는 것이다.

Canary Releases

마지막으로, Canary 배포는 새로운 버전의 Application을 Production 환경으로 보내어 어떻게 동작하는지 모니터링 하는 도구로 사용될 수 있다. 예를 들어, 다른 Application과의 연계, CPU, MEM, DISK 사용량 등을 미리 검증할 수 있다.

새로운 버전의 앱을 프로덕션 환경에 보내어, LB에서 일부 세션이 그 곳에 물리도록 만든다. 만약 이상 동작을 한다면 바로 Canary를 철수시켜 정상적인 버전으로 새로운 세션을 맺게 만들어 준다.

이 Release를 이용하여 Full Release 전에 발생할 수 있는 여러가지 Issues를 검증할 수 있다.

Summary

위에서 말한 3가지 DevOps 배포, 테스트 방법은 기반 인프라나 Application 성격에 관계없이 전략을 수행할 수 있다. 하지만, 위에서 언급한 여러가지 고려사항들을 만족시키기 위해 Docker와 Kubernetes와 같은 기술로 도움을 받을 수 있다. 

그 두가지 기술이 구현된 Red Hat Openshift 라는 Platform을 통해 Blue-Green, Canary를 수행하는 영상을 아래에서 확인할 수 있다.

• Veer Muchandi demonstrates blue-green deployments on OpenShift v3
• James Rawlings demonstrates canary releases with full CI/CD built in with Fabric8v2