탄력적인 ‘마이크로서비스’를 위한 배포 전략 4가지

마이크로서비스 배포에서 리스크를 테스트하고 완화할 수 있는 클라우드 네이티브 라우팅 방식들을 살펴본다. 

전통적인 아키텍처와 비교할 때 ‘마이크로서비스’로 앱을 구축하면 더 빠른 속도와 민첩성을 얻을 수 있다. 그러나 코드 변경은 여전히 위험을 초래한다. 코드 품질 문제가 발견되지 않거나 혹은 해결되지 않는다면 잠재적으로 실패 가능성을 안게 되는 셈이기 때문이다. 
 

이러한 위험을 완화하려면 적절한 클라우드 네이티브 라우팅 전략을 실행해야 한다. 이를 통해 위험이 있는지 쉽게 테스트할 수 있는 것은 물론 애플리케이션을 프로덕션 환경에 배포될 준비가 됐는지도 확인할 수 있다.  

다음의 네 가지 배포 전략은 라우팅 기술로 새 서비스와 기능의 안전한 도입, 기능 테스트, 반복적 개선, 취약점 식별 및 제거 등을 수행한다. 즉 마이크로서비스로 애플리케이션을 개발 및 배포하는 과정에서 발생할 수 있는 위험을 줄여주는 가상의 도구상자와도 같다. 각 도구의 유사점과 차이점을 이해한다면 이들을 최대한 활용하는 데 더욱더 도움이 될 것이다. 

1. 카나리 배포(Canary deployments)
카나리 배포는 과거 석탄 광산에서 유독가스를 미리 감지하고자 카나리아 새를 날려 보냈던 것에서 이름을 따왔다. 이름에서 알 수 있듯 이는 위험을 최소화하면서 실제 프로덕션 배포를 테스트할 방법이다. 

다시 말해, 카나리 배포는 들어오는 요청에서 일부분(예를 들면 1%)에만 새로운 기능이나 서비스를 테스트해보는 RC 버전이다. 테스트 결과를 검토한 후 진행이 원활하면 전체 서버와 노드로 배포를 서서히 늘려간다. 만약 원활하지 않다면? 카나리 배포를 바로 철수시키고 문제가 발생한 코드를 검토하거나 오류를 수정할 수 있다. 

또한 카나리 배포는 인바운드 사용자 트래픽 처리를 담당하는 엣지 라우팅과 통합해 실행할 수도 있다. 예를 들면 쿠버네티스 환경에서 인그레스 컨트롤러 구성을 통해 일부 트래픽 요청을 안정적으로 카나리 배포에 할당할 수 있다. 

이 방식으로 트래픽을 라우팅하면 정식 출시에 앞서 신규 서비스를 검증할 수 있다. 만약 문제가 발생했다면 이를 해결한 후에 다시 한번 카나리 배포 테스트를 진행하면 된다. 

2. A/B 테스팅(A/B testing)
A/B 테스팅은 카나리 배포와 유사하지만 한 가지 중요한 차이점이 있다. 카나리 배포가 버그와 병목현상 식별에 초점을 맞춘다면, A/B 테스팅은 신규 애플리케이션 기능에 관한 사용자 반응을 측정하는 데 초점을 맞춘다. 해당 기능에 대한 사용자 호응, 주목도, 작동 여부 등을 확인할 수 있다.  

A/B 테스팅은 소프트웨어 라우팅으로 서로 다른 트래픽 세그먼트를 가진 특정 기능을 활성화하고 테스트한다. 제한된 트래픽 혹은 그룹에 새로운 기능을 노출시키는 것이다. A 라우팅 세그먼트와 B 라우팅 세그먼트는 트래픽을 서로 다른 소프트웨어 빌드 혹은 서로 다른 구성이지만 동일한 소프트웨어 빌드를 사용하는 서비스 인스턴스로 전송할 수 있다. 

3. 블루-그린 배포(Blue-green deployments)
블루-그린 배포는 두 가지 프로덕션 환경을 나란히 운영한다. 여기서 블루는 현재 안정적으로 운영하는 환경이고, 그린은 새로운 버전을 테스트하기 위한 환경이다. 

이 배포 방식은 업데이트된 소프트웨어 버전을 쉽게 반복해서 릴리즈할 수 있도록 해준다. 데브옵스 팀이라면 해당 방식으로 CI/CD 파이프라인을 사용한 신규 버전 출시를 자동화할 수 있다.

블루-그린 전략으로 개발자들은 현재 프로덕션 트래픽을 처리하는 기존 인스턴스와 새로운 서비스 버전을 함께 배포한다. CI/CD 파이프라인은 자동화된 스모크 테스트를 진행하도록 설정돼야 한다. 이를 통해 새 버전의 핵심 기능이 성공적인지 검증할 수 있다. 

새로운 서비스가 마지막 테스트를 통과하고 나면 트래픽 경로를 자동으로 안전하게 다시 돌릴 수 있다. 소프트웨어 라우팅을 사용해 블루에서 그린으로 트래픽 전환을 원활하게 관리하는 것이다. 이에 못지않게 중요한 점은 출시 직전에 치명적인 문제가 발생하는 경우 배포를 블루 버전으로 되돌리는 것도 간단하다는 것이다.

4. 트래픽 섀도잉(Traffic shadowing)
트래픽 섀도잉은 블루-그린 배포와 비슷하지만 ‘그린’ 환경 검증을 위한 종합적인 테스트 대신 라우팅 기술을 통해 들어오는 모든 프로덕션 트래픽을 복제한 다음 아직 공개되지 않은 별도 테스트 배포로 미러링한다는 점에서 차이가 있다. 따라서 트래픽 섀도잉을 통해 실제 트래픽을 기준으로 새 버전을 배포했을 때 무슨 일이 일어날지 정확하게 파악할 수 있다. 

또한 트래픽 섀도잉을 통한 테스트는 실제 프로덕션에 아무런 영향을 미치지 않는다. 실례로 개발자들은 일부 테스트 서비스 요청을 복제한 후 통합 테스트 및 성능 벤치마킹을 (직접 또는 자동화 CI/CD 파이프라인의 프레임워크 내에서) 수행할 수 있다.

엔터프라이즈 개발자들은 새 애플리케이션 코드가 특정 요건을 충족하는지 확인하고자 다양한 테스트 방식을 이미 활용하고 있다. 예를 들면 단위 및 기능 테스트는 여전히 코드가 통과해야 할 필수적인 측정값이다. 그러나 마이크로서비스 기반 아키텍처의 특성상 엔드투엔드 통합 테스트는 매우 중요하다. 

마이크로서비스 아키텍처에 내재된 상호의존성 및 인터페이스 변동의 위험을 고려하면 종합적인 테스트는 가치가 있지만 결국 프로덕션 환경 내 서비스 간의 모든 상호작용을 정확히 나타내기는 부족할 것이다. 

중요한 것은 ‘목표’
서로 다르면서도 비슷한 이 모든 라우팅 방식은 마이크로서비스 기반 애플리케이션의 결함을 찾고 완화하며 테스트하는 작업에 도움을 준다. 이는 특히 엔드투엔드 CI/CD 파이프라인의 일부로 배포될 때 버그, 성능 문제, 보안 취약점을 해결하는 강력한 도구이기도 하다. 

어떤 것이 가장 적합할지는 직면한 문제에 따라 다를 것이다. 예를 들어 대대적인 UI 점검을 해야 한다면 A/B 테스팅이 적합하다. 블루-그린 배포는 새로운 기능이 기존 데이터 저장소 성능에 어떤 영향을 미치는지 확인할 때 유용하다. 

여러 방식을 조합해 최대의 효과를 얻을 수 있기도 하다. 하지만 각 방식이 기존 개발 모델과 얼마나 잘 통합될지 고려하는 것이 중요하다. 가령 개별 기능의 카나리 배포는 전체 버전의 블루-그린 배포보다 애자일 개발 방식에 더욱 적합할 수 있다. 또한 트래픽 섀도잉은 애플리케이션 성능 사전 배포에 뛰어난 가시성을 제공할 수 있는 반면, 컴퓨팅 자원 측면에서 구현이 어렵고 시간 및 비용이 많이 소모될 수 있다. 

그러나 이러한 라우팅 방식들은 소프트웨어 개발 과정의 매우 중요한 부분이 될 것이다. 전통적인 단일 애플리케이션에서 마이크로서비스 기반의 클라우드 네이티브 시스템으로 옮겨가는 추세이기 때문이다. 이들을 적절히 사용하되 각 방식의 장점을 염두에 둔다면 프로젝트의 무결성과 성공을 보장하는 것은 물론 더욱더 자신감 있게 프로덕션 단계로 전환할 수 있을 것이다. ciokr@idg.co.kr