간단히 말해서 카나리아 릴리스의 기본 아이디어는 소수의 사용자에게만 새 소프트웨어 버전을 제공하고 결과를 분석한 후 계속 진행할지 여부를 결정하는 것입니다. 결과가 기대와 일치하지 않으면 롤백하세요. 그렇다면 모든 사용자가 새 버전의 혜택을 누릴 때까지 노출되는 사용자 수를 늘리십시오.  이번 포스팅에서는 이 소개를 간략하게 설명하고, 분수를 정의하는 다양한 방법을 설명하고,  Apache APISIX로 실행하는 방법을 보여드리고 싶습니다.  카나리아 릴리스 소개  "카나리아"라는 용어는 석탄 채굴 산업에서 유래되었습니다. 채굴할 때 독성 가스를 방출하는 것은 드문 일이 아닙니다. 작고 밀폐된 공간에서는 빠른 죽음을 의미할 수 있습니다. 더 나쁜 것은 가스가 무취일 수 있기 때문에 광부들이 떠나기에는 너무 늦을 때까지 가스를 들이마실 것입니다. 일산화탄소는 탄광에서 흔히 발생하며 인간의 감각으로 감지할 수 없습니다.  이러한 이유로 광부들은 카나리아를 지하로 가지고 왔습니다. 카나리아가 갑자기 죽으면, 그런 가스 주머니가 뚫렸을 가능성이 높았고, 이제 그곳을 떠나야 할 때였습니다.  몇 년 전 우리는 새로운 소프트웨어 버전을 출시하기 위해 이러한 접근 방식을 도입했습니다. 비유는 다음과 같습니다. 채굴자는 버전을 배포하는 Ops 팀이고, 카나리아는 릴리스의 영향을 측정하는 모든 도구로 구성되며, 가스는 (중요한) 버그입니다.  가장 중요한 부분은 실패율, HTTP 상태 코드 등을 포함하여 릴리스의   것입니다. 이는 이 게시물의 범위를 벗어나지만, Canary 릴리스의 이점을 활용하려면 다시 한 번 강조하는 것이 중요합니다. 두 번째로 중요한 부분은 새 버전에 버그가 있는 경우 빠르게 롤백할 수 있는 기능입니다. 영향을 측정하고 이를 이전 버전과 비교해야 한다는  Canary 릴리스와 기능 플래그 비교  카나리아 릴리스가 새 코드 릴리스의 위험을 관리하는 유일한 방법은 아닙니다. 예를 들어 기능 플래그는 또 다른 인기 있는 방법입니다.  카나리아 접근 방식은 새 구성 요소 버전의 전체 기능 세트를 제공합니다.  기능 플래그는 구성요소도 배포하지만 전용 구성 매개변수를 사용하면 각 기능을 개별적으로 활성화 및 비활성화할 수 있습니다.  기능 플래그는 롤백에 대한 보다 민첩한 접근 방식(진정한 의미에서)을 나타냅니다. 기능 10개 중 하나에 버그가 있는 경우 새 버전을 배포 취소할 필요가 없습니다. 버그 기능만 비활성화하면 됩니다. 그러나 이 강력한 기능에는 타사 제품에 의존하든 직접 구현하든 상관없이 코드베이스가 더 복잡해집니다.  반면, 카나리아에서는 마음대로 배포 및 배포 취소가 가능하려면 성숙한 배포 파이프라인이 필요합니다.  카나리아 릴리스에 대한 접근 방식  카나리아 릴리스의 기본 아이디어는 일부 사용자만 새 버전에 액세스할 수 있도록 허용하는 것입니다. 대부분의 카나리아 정의는 "부분"을 사용자 비율로만 정의합니다. 그러나 더 많은 것이 있습니다.  첫 번째 단계는 검증된 사용자만 프로덕션 환경의 배포가 예상대로 작동하는지 확인할 수 있도록 허용하는 것입니다. 이 경우 특정 내부 사용자 집합(   : 테스터)만 새 버전으로 전달할 수 있습니다. 사람을 미리 알고 시스템이 사용자를 인증하는 경우 ID로 구성할 수 있습니다. 그렇지 않은 경우 일반적인 방법   : HTTP 헤더 -   으로 대체해야 합니다. 예 (예 X-Canary: Let-Me-Go-To-v2  불일치를 확인하려면 기존 시스템과 새 시스템을 모니터링해야 한다는 점을 기억하세요. 아무것도 표시되지 않으면 새 버전으로 전달되는 사용자 풀을 늘릴 수 있는 절호의 기회입니다. 나는 당신이 자신의 개밥을 먹는다고 가정합니다   팀원들은 자신이 개발 중인 소프트웨어를 사용합니다. 예를 들어 고급 자동차 전자상거래 사이트가 아닌 경우 이 섹션을 건너뛰어도 됩니다. .  위험을 제한하면서 사용자 비율을 확대하기 위해 이제 내부 사용자에게 새 버전을 무차별적으로 제공할 수 있습니다. 이를 위해 클라이언트 IP를 기반으로 새 버전으로 전달하도록 시스템을 구성할 수 있습니다. 사람들이 현장에서 작업할 당시에는 IP가 특정 범위에 있었기 때문에 쉬웠습니다. 사용자가 VPN을 통해 회사 네트워크에 액세스할 가능성이 높으므로 원격은 크게 변경되지 않습니다.  이 시점에서 다시 모니터링하고 비교하십시오.  전체 9야드  이 시점에서는 일부 또는 전체 내부 사용자에 대해 모든 것이 예상대로 작동해야 합니다. 그러나 어떤 계획도 적과의 접촉에서 살아남을 수 없듯이, 어떤 사용법도 생산 워크로드의 전체 다양성을 모방할 수 없습니다. 간단히 말해서, 일반 사용자가 새 버전에 액세스할 수 있도록 해야 하지만 지금까지 사용자 수를 점진적으로 늘린 것처럼 통제된 방식으로 작은 부분부터 시작하여 모니터링하고 모든 것이 괜찮으면 부분을 늘리십시오. .  Apache APISIX를 사용하여 수행하는 방법은 다음과 같습니다. Apache APISIX는 플러그인 기반 아키텍처를 제공하며 우리의 요구 사항을 충족하는 플러그인, 즉   플러그인을 제공합니다. traffic-split    플러그인을 사용하면 트래픽 부분을 다양한 업스트림 서비스로 동적으로 전달할 수 있습니다. traffic-split  이는 트래픽 분할을 위한 사용자 지정 규칙인   와 트래픽을 전달할 업스트림 집합인   구성하여 수행됩니다. match weighted_upstreams  --  트래픽 분할  각 버전마다 하나씩 몇 가지 기본 업스트림부터 시작하겠습니다.   upstreams: - id: v1 nodes: "v1:8080": 1 - id: v2 nodes: "v2:8080": 1    플러그인을 사용하여 대부분의 트래픽을 v1로 전달하고 일부를 v2로 전달할 수 있습니다. traffic-split   routes: - id: 1 uri: "*" #1 upstream_id: v1 plugins: traffic-split: rules: - weighted_upstreams: #2 - upstream_id: v2 #3 weight: 1 #3 - weight: 99 #3  포괄 경로 정의  트래픽 분할 방법을 구성합니다. 여기, 가중치  트래픽의 99%를 v1로 전달하고 1%를 v1로 전달합니다. 가중치는 서로 상대적입니다. 50/50을 달성하려면 가중치 1과 1, 3과 3, 50과 50 등을 설정할 수 있습니다.  다시 한번 말씀드리지만, 우리는 모든 것을 모니터링하고 결과가 예상한 대로인지 확인합니다. 그런 다음 v2로 전달되는 트래픽의 비율을 늘릴 수 있습니다.   : 예   routes: - id: 1 uri: "*" upstream_id: v1 plugins: traffic-split: rules: - weighted_upstreams: - upstream_id: v2 weight: 5 #1 - weight: 95 #1  v2에 대한 트래픽을 5%로 늘립니다.  Apache APISIX는 매초마다 위의 파일에 대한 변경 사항을 다시 로드합니다. 따라서 거의 실시간으로 트래픽을 분할합니다. 또는 Admin API를 사용하여 동일한 결과를 얻을 수도 있습니다.  더욱 통제된 릴리스  위에서는 내부 사용자에서 외부 사용자의 일부로 이동했습니다. 아마도 모든 내부 사용자에게 공개하는 것은 조직에서 너무 큰 위험이므로 더 많은 제어가 필요할 수 있습니다. 이 경우   플러그인을 추가로 구성할 수 있습니다. traffic-split   routes: - id: 1 uri: /* upstream_id: v1 plugins: traffic-split: rules: - match: - vars: [["http_X-Canary","~=","Let-Me-Go-To-v2"]] #1 - weighted_upstreams: - upstream_id: v2 weight: 5 - weight: 95    HTTP 헤더에 구성된 값이 있는 경우에만 트래픽을 분할합니다. X-Canary  다음 명령은 항상 v1으로 전달됩니다.   curl http://localhost:9080  다음 명령도 항상 v1으로 전달됩니다.   curl -H 'X-Canary: Let-Me-Go-To-v1' http://localhost:9080  다음 명령은 구성된 가중치(   : 95/5)에 따라 트래픽을 분할합니다. 예   curl -H 'X-Canary: Let-Me-Go-To-v2' http://localhost:9080  결론  이 게시물에서는 카나리아 릴리스와 Apache APISIX를 통해 카나리아 릴리스를 구성하는 방법을 설명했습니다. 우선순위가 다른 여러 경로로 시작하여   플러그인으로 이동할 수 있습니다. 후자는 더 복잡한 사용 사례를 허용하도록 추가로 구성할 수도 있습니다. traffic-split  이 게시물의 전체 소스 코드는   에서 찾을 수 있습니다. GitHub   더 나아가려면:   Apache APISIX 기반의 Canary 릴리스 솔루션 구현   Apache APISIX 인그레스를 사용하는 Kubernetes의 카나리아 릴리스   Flagger가 포함된 APISIX 수신 컨트롤러를 사용하여 원활한 Canary 릴리스  원래 2023년 12월 3일   에 게시되었습니다. A Java Geek

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

이 오디오는 이야기의 원래 언어로 제작되었습니다!

Apache APISIX를 사용하여 Canary 릴리스 구현

About Author

코멘트

태그 걸기

이 기사는 다음에서 발표되었습니다.

Related Stories

독특한 생태계를 강화하는 비트코인 UTXO 모델

성공적인 클라우드 마이그레이션을 위한 전체 가이드: 전략 및 모범 사례

볼츠만 뇌 이론에 대한 간략한 소개

Floki의 Valhalla가 인도 스리랑카 투어의 보조 후원자로 합류

독특한 생태계를 강화하는 비트코인 UTXO 모델

성공적인 클라우드 마이그레이션을 위한 전체 가이드: 전략 및 모범 사례

볼츠만 뇌 이론에 대한 간략한 소개

Floki의 Valhalla가 인도 스리랑카 투어의 보조 후원자로 합류

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps