API Gateway를 활용한 API 릴리스 전략
December 22, 2022
배포와 릴리스를 적절히 분리한 후, 다음 단계는 기능의 점진적인 릴리스를 제어할 메커니즘을 선택하는 것입니다. 프로덕션에서 위험을 줄일 수 있는 릴리스 전략을 선택하는 것이 중요합니다. 왜냐하면 릴리스 전에 API의 새 버전을 얼마나 많이 테스트하더라도, 실제 테스트는 고객 앞에 내놓았을 때 이루어지기 때문입니다.
이 위험을 줄이기 위해 소량의 트래픽으로 테스트나 실험을 수행하고 결과를 검증할 수 있습니다. 결과가 성공적이면 모든 트래픽에 대한 릴리스가 트리거됩니다. 특정 전략은 다른 시나리오보다 더 적합하며, 추가 서비스와 인프라의 다양한 수준을 요구합니다. 이 글에서는 오늘날 API Gateway를 사용하는 3가지 인기 있는 API 릴리스 전략을 탐구해 보겠습니다.
API 배포에서 API 게이트웨이를 사용하는 이유
API 기반 아키텍처로 전환하는 이점 중 하나는 서비스에 대한 새로운 변경 사항을 빠르게 반복하고 배포할 수 있다는 것입니다. 또한, 아키텍처의 현대화된 부분에 대해 API Gateway를 통해 트래픽 및 라우팅 개념을 확립할 수 있습니다. API Gateway는 동일한 게이트웨이 뒤에 여러 배포된 API를 가질 수 있도록 하는 단계를 제공하며, 다운타임 없이 제자리 업데이트가 가능합니다. API Gateway를 사용하면 인증, 속도 제한, 관찰 가능성 (API의 중요한 메트릭), 다중 API 버전 관리 및 단계적 배포 관리 (개발, 테스트, 스테이징, 프로덕션과 같은 여러 단계에서 API 배포)와 같은 서비스의 다양한 API 관리 기능을 활용할 수 있습니다.
오픈 소스 API Gateway (Apache APISIX 및 Traefik), 서비스 메시 (Istio 및 Linkerd) 솔루션은 트래픽 분할 및 Canary 릴리스 및 Blue-Green 배포와 같은 기능을 구현할 수 있습니다. Canary 테스트를 통해 사용자 기반의 일부만 선택하여 API의 새 릴리스를 심층적으로 검토할 수 있습니다. 다음 섹션에서 Canary 릴리스에 대해 다루겠습니다.
Canary 릴리스
Canary 릴리스는 API의 새 버전을 도입하고 소량의 트래픽을 Canary로 흐르게 합니다. API 게이트웨에서 트래픽 분할을 통해 대상 서비스의 한 버전에서 다른 버전으로 트래픽을 점진적으로 이동하거나 마이그레이션할 수 있습니다. 예를 들어, 서비스의 새 버전 v1.1을 원래 버전 v1.0과 함께 배포할 수 있습니다. 트래픽 이동을 통해 처음에는 사용자 트래픽의 일부, 예를 들어 1%만 v1.1로 라우팅한 다음, 시간이 지남에 따라 모든 트래픽을 새 서비스로 이동시킬 수 있습니다.
이를 통해 새 서비스를 모니터링하고, 기술적 문제(예: 지연 시간 증가 또는 오류율)와 원하는 비즈니스 영향(예: 고객 전환율 또는 평균 쇼핑 체크아웃 값과 같은 주요 성과 지표 증가)을 확인할 수 있습니다. 트래픽 분할을 통해 A/B 또는 다변량 테스트를 실행할 수 있습니다. 예를 들어, 대상 서비스의 v1.0과 v1.1 간에 트래픽을 50/50으로 분할하고 특정 기간 동안 어느 버전이 더 나은 성능을 보이는지 확인할 수 있습니다. Apache APISIX Ingress Controller의 트래픽 분할 기능에 대해 더 알아보세요.
적절한 경우, Canary 릴리스는 Canary에 노출되는 트래픽 비율이 매우 제어되기 때문에 훌륭한 옵션입니다. 단점은 시스템에 문제를 신속하게 식별하고 필요한 경우 롤백할 수 있는 좋은 모니터링이 있어야 한다는 것입니다(이것은 자동화될 수 있습니다). 이 가이드는 Apache APISIX와 Flagger를 사용하여 Canary 릴리스 솔루션을 빠르게 구현하는 방법을 보여줍니다.
트래픽 미러링
트래픽 분할을 사용하여 실험을 실행하는 것 외에도, 트래픽 미러링을 사용하여 트래픽을 복사하거나 복제하고 이를 추가 위치 또는 일련의 위치로 보낼 수 있습니다. 트래픽 미러링에서는 복제된 요청의 결과가 호출 서비스나 최종 사용자에게 반환되지 않는 경우가 많습니다. 대신, 응답은 정확성을 위해 대역 외에서 평가되며, 리팩토링된 서비스와 기존 서비스에서 생성된 결과를 비교하거나, 새 서비스 버전이 요청을 처리할 때 응답 지연 시간이나 필요한 CPU와 같은 운영 속성을 관찰합니다.
트래픽 미러링을 사용하면 사용자에게 새 릴리스에 대해 알리지 않고도 내부적으로 필요한 효과를 관찰할 수 있는 "다크 릴리스" 서비스를 구현할 수 있습니다.
시스템의 가장자리에서 트래픽 미러링을 구현하는 것은 최근 몇 년 동안 점점 더 인기를 얻고 있습니다. APISIX는 클라이언트 요청을 미러링하기 위해 proxy-mirror 플러그인을 제공합니다. 이 플러그인은 실제 온라인 트래픽을 미러링 서비스로 복제하고, 온라인 서비스를 중단하지 않고도 온라인 트래픽이나 요청 내용을 특정 분석할 수 있습니다.
Blue-Green
_Blue-green_은 일반적으로 라우터, 게이트웨이 또는 로드 밸런서를 사용하는 아키텍처의 한 지점에서 구현되며, 그 뒤에는 완전한 blue 환경과 green 환경이 있습니다. 현재 blue 환경은 현재 라이브 환경을 나타내고, green 환경은 스택의 다음 버전을 나타냅니다. green 환경은 라이브 트래픽으로 전환하기 전에 검사되며, 전환 시 트래픽은 blue에서 green으로 전환됩니다. blue 환경은 이제 "꺼짐" 상태이지만 문제가 발견되면 빠르게 롤백할 수 있습니다. 다음 변경 사항은 green에서 blue로 진행되며, 첫 번째 릴리스부터 진동합니다.
Blue-green은 단순성 때문에 잘 작동하며, 결합된 서비스에 대한 더 나은 배포 옵션 중 하나입니다. 또한 지속적인 서비스를 관리하기가 더 쉽지만, 롤백 시에도 주의해야 합니다. 또한 현재 활성 환경과 병렬로 실행할 수 있도록 리소스의 두 배가 필요합니다.
Argo Rollouts를 사용한 트래픽 관리
앞서 논의한 전략은 많은 가치를 추가하지만, 롤아웃 자체는 수동으로 관리하고 싶지 않은 작업입니다. 이때 Argo Rollouts와 같은 도구가 논의된 문제를 실제로 보여주는 데 유용합니다.
Argo를 사용하면 API의 새 Canary를 롤아웃하기 위해 취할 수 있는 전략을 나타내는 Rollout CRD (Custom Resource Definition)를 정의할 수 있습니다. CRD를 통해 Argo는 Kubernetes API를 확장하여 롤아웃 동작을 지원할 수 있습니다. CRD는 Kubernetes에서 인기 있는 패턴이며, 사용자가 하나의 API와 상호 작용하면서 다양한 기능을 지원할 수 있도록 합니다.
Apache APISIX와 Apache APISIX Ingress Controller를 사용하여 Argo Rollouts와 함께 트래픽 관리를 할 수 있습니다. 이 가이드는 ApisixRoute를 Argo Rollouts와 통합하여 가중치 기반 라운드 로빈 로드 밸런서로 사용하는 방법을 보여줍니다.
요약
점진적 전달 접근 방식의 부상과 이전의 지속적 전달 내에서의 고급 요구 사항으로 인해, 서비스(및 해당 API)의 배포와 릴리스를 분리할 수 있는 능력은 강력한 기술입니다. Canary 릴리스 서비스를 수행하고 API Gateway의 트래픽 분할 및 미러링 기능을 활용할 수 있는 능력은 잘못된 릴리스의 위험을 완화하고 고객의 요구 사항을 더 효과적으로 이해하는 데 있어 비즈니스에 경쟁 우위를 제공할 수 있습니다.