배포 전략(Deployment Strategies)
Micro-Frontend(이하 MFE)를 도입하기전 배포 전략을 어떻게 세울지 고민해 보았다. MFE는 본질적으로는 독립적으로 배포되어야 하고 전체 코드베이스에 영향을 주지 않고 코드의 일부만 배포하게 된다.
뭐 일단 나중에야 그렇게 되겠지만, 지금 당장 우리의 애플리케이션은 프로덕션 환경에서 이미 실행중이며, 이럴때는 어떻게 진행되면 좋을까. 여러가지 배포 전략을 살펴보며 개념을 익혀보자.
빅뱅 릴리스(Big Bang Releases)
여러분은 우리 비즈니스의 복잡성을 이해하지 못해요 - 빅뱅 옹호자 -
빅뱅 릴리스는 프로젝트에 너무 많은 위험을 가져다 주지만, 특히 폭포수(waterfall) 모델에서 많이 사용되던 방식이다. 빅뱅 릴리스란 간단하게 말해 완전하게 기능을 갖는 것을 목표로 일부 코드에 대해 몇 달 동안 작업하는 경우이다. 그리고 이 릴리스를 통해 우리는 우리의 고객이 멋진 새로운 기능을 잘 사용하며 잘 적응해 줄 것이라고 믿는다.
하지만 이러한 빅뱅 릴리스는 그 릴리스 범위에 대한 가정을 테스트하지 않고 범위를 엄격하게 정의하고 실행하게 된다. 실제 테스트는 이미 그 릴리스를 위한 상당한 투자가 이루어진 이후에나 가능하게 된다.
과연 모든 세부 사항을 정말 모두 고려할 수 있었을까, 완제품을 확신할 수 있는가
또한 빅뱅 릴리스는 일반적으로 어떤 특정 기능의 완전한(100%) 추가를 목표로 하므로 미치치 못하는 높은 기대치를 설정하게 한다. 오랜 시간이 소요되며 상당한 투자가 발생했기 때문이다. 당연히 기본 사항을 변경하는 것은 매우 힘들게 된다. 이미 모든 작업은 가정된 기능과 기능을 지원하도록 설계되었으며, 변경시 비용이 급증하면서 변경이 어렵거나 큰 비용의 증가 및 릴리스 기간이 미뤄지는 경우가 발생할 것이다. (때로는 이 릴리스에 관련된 사람이 집을 못가고 계속 야근을 하며 변경사항에 대응하게 된다.)
빅뱅 릴리스는 규모가 커지면 커질수록 모든 계란을 한 바구니에 담는 것과 동일하다. 큰 위험이 따르며, 문제가 생겨서 깨진 계란이 생겼더라도 다시 처음으로 돌아가긴 힘들다
문제는 여기가 끝나지 않는다. 만약 해당 기능이 기다린 유저의 기대에 부응하지 못하거나 높은 실적(트래픽 증가, 매출 증가, 회원수 증가 등)으로 이루어지지 못한다면 다 같이 고생한 팀은 팀대로 인정받지 못하고, 반대로 기다렸던 사용자들도 실망을 안고 우리의 애플리케이션을 떠나갈 수도 있다. 또한 중간에 트랜드가 바뀌는 경우 경쟁사를 따라가지 못하거나 트랜드에 뒤쳐진 것을 큰 공을 들여 개발하게되는 것일 수도 있다.
그래서 우리는 빅뱅 릴리스보다는 사용자에게 작은 범위의 유용한 기능(기능, 프로모션, 변화 등)을 제공하고 발견 사항을 기반으로 더 많은 릴리스와 실제 문제를 해결, 가정 검증에 중점을 두어야 한다. 세상은 우리의 생각보다 더 빠르게 변화하며, 유일하게 지속 가능한 접근 방식은 작게 시작하여 생각을 테스트하고 반복을 통해 최적의 솔루션을 향해 점진적으로 진행하는 것이다.
빅뱅보단 소규모 출시를 하자
문득 궁금해 졌다. 빅뱅 릴리스는 항상 옳지 못한가?
당연히 아니다. 모든 것에는 은총알은 없든 ‘모든’이라는 단어를 대체할 수는 없다. 하지만 대부분의 경우 웹은 변화가 빠르고 사용자(소비자)들의 요구사항과 성향이 빠르게 변하기 때문에 빅뱅보단 소규모 릴리스가 더 적합한 것이다.
반면 제품 개발/연구가 필요한 부분이라면 조금 다를 수 있다. 예를 들어 애플의 아이폰이나 삼성의 갤럭시 휴대폰을 보자. 기존보다 더 높은, 더 좋은 기능과 품질을 타켓으로 제품을 만들어야하고 더 나은, 더 최신의 디자인을 선보여야 한다. 이는 연구와 개발이 필요하다. 이런 경우는 빅뱅 릴리스를 통해 출시 일정을 보다 명확하게 잡고 각 부서에서는 그 일정에 맞춰 마케팅, 영업 전략, 사업 전략을 세우고 더 많은 시간을 할애할 수 있다.
또한 이렇게 개발한 고도화된 기술의 제품은 경쟁 제품들이 이 제품을 따라잡기까지 시간이 걸리기 때문에 경쟁 우위를 확보할 수도 있으며, 일정 기간 꾸준한 수익을 가져다 줄 수 있다.
다시 본론으로
다시 본론으로 돌아와서, 이러한 빅뱅 릴리스는 MFE에는 적합하지 않다. 대신 소규모 사용자 그룹에게 새로운 버전의 MFE를 릴리스할 것이며, 이를 위한 몇가지 배포 전략에 대해 살펴보자.
Blue-Green Deployment
블루-그린 배포(Blue-Green Deployment)는 마지막 테스트 환경이 나머지 플랫폼에 대해 실제 실행 중인 프로덕션 환경에서 테스트의 마지막 단계를 수행해야 한다는 가정으로부터 시작된다. 애플리케이션 또는 마이크로 서비스의 이전 버전에 있떤 사용장 트래픽을 이전 버전과 거의 동일한 새 버전으로 점진적으로 이전하는 애플리케이션 릴리스 모델이며, blue와 green이라는 두 개의 동일한 프로덕션 환경을 실행하여 가동 중지 시간과 위험을 줄이는 기술이다. 새 버전을 배포한 후 프로덕션 환경에서 테스트의 모든 이점을 얻으면서 사용자를 새 버전으로 리다이렉션하지 않고 프로덕션에서 새 코드를 테스트 할 수 있다.
그리고 모든 테스트가 통과되면 트래픽의 100%를 MFE의 새 버전으로 리다이렉션할 준비가 되며, 이 전략은 사용자에게 영향을 주지 않고 모든 테스트를 수행할 수 있기 때문에 새로운 MFE를 배포할 위험을 줄여준다.
이전 버전을 blue 환경, 새 버전을 green 환경으로 부르며, 프로덕션 트래픽이 블루에서 그린으로 완전히 이전되면, 블루를 롤백에 대비하여 남겨두면 된다. 이 기술을 배포로 인한 다운타임을 제거할 수 있으며, 새 버전에서 예상치 못한 일이 발생할 수 있으므로 blue를 바로 폐기하지 말고 롤백해야 하는 경우가 발생했을때 바로 blue로 전환하여 마지막 버전으로 롤백할 수 있다.
참고로 데이터베이스 마이그레이션과 같이 시간이 많이 걸리는 작업에 대한 유지 관리 기간 동안 정적 유지 관리 페이지를 표시하도록 경로 매핑 패턴을 조정할 수 있으며, 블루-그린 배포로 인해 업데이터 중 그린 데이터베이스와 블루 데이터베이스 간에 불일치가 발생할 수 있으므로, 데이터 무결성을 위해 단일 데이터베이스를 구성한다.
Canary Releases
카나리아 릴리스(Canary Releases)에서는 모든 테스트를 통과한 후 모든 트래픽을 새 버전으로 전환하지 않으며, 대신 새로운 MFE 버전으로 트래픽을 점차 완화한다. 오류율 증가 또는 사용자 참여 감소와 같이 새로운 프론트엔드를 소비하는 라이브 트래픽의 메트릭을 모니터링하면서 그에 따라 트래픽을 늘리거나 줄일 수 있다.
Blue-Green Deployment / Canary Releases
두 방식 모두 트래픽을 형성하거나 트래픽을 한 버전에서 다른 버전으로 전환하는 라우터가 필요하다. 라우터는 선택한 아키텍처에 따라 클라이언트측, 서버측, 에지측에서 처리될 수 있다.
- 클라이언트측 라우팅: 정적 JSON 또는 백엔드 API를 통해 전달된 애플리케이션 쉘 구성
- 에지측 라우팅: 엣지에서 실행되는 로직(e.g. AWS Lambda@Edge)
- 서버측 라우팅: 애플리케이션 서버 로직, API 게이트웨이, 로드 밸런서
Strangler Pattern
교살자 패턴(Strangler Pattern)은 기존 웹 애플리케이션이 있고 MFE를 도입할때 유용하게 사용할 수 있다. 물론 MFE를 도입할때 전체 애플리케이션이 MFE로 전부 다시 작성될 때가지 기다릴 수도 있겠지만, 현실에선 교살자 패턴이 더 적절한 경우가 많다.
교살자 패턴이란 완전히 새로운 애플리케이션이 준비될 때까지 기다리는 대신 애플리케이션의 일부를 릴리스하여 비즈니스와 사용자를 위한 증분 가치(Incremental value)를 생성한다는 아이디어에서 비롯된다. MFE를 구축하고 레거시 애플리케이션과 같이 유지하며 애플리케이션의 새로운 부분을 개발할 때마다 전체 레거시 애플리케이션이 MFE 플랫폼으로 완전히 대체될 때까지 레거시 애플리케이션의 다른 부분을 대체한다. 애플리케이션 영역이 아직 MFE에 대한 준비가 되지 않는 경우 라우터는 사용자를 레거시 플랫폼으로 리다이렉션 시킨다.
도살자 패턴을 사용하면 회사가 부담없이 감수할 수 있는 위험을 탐색한 다음 이를 분석한 후 올바른 구현을 설계할 수 있다.