クイズ: カナリアとトラフィック分割

메시의 가중치 분할이 롤링 업데이트보다 나은 점으로 가장 정확한 것은?

• 파드 개수와 트래픽 비율이 분리되어, 배포 없이 가중치만 되돌릴 수 있다
• 프록시가 응답 코드를 보고 판단하므로 readiness 프로브를 두지 않아도 된다
• 새 이미지를 빌드하지 않고도 가중치만으로 새 버전 코드를 띄울 수 있다
• 같은 개수의 파드를 롤링 업데이트보다 훨씬 빠른 속도로 교체해 준다

가중치를 90:10 으로 두었는데 실제 관측된 비율이 88:12 였습니다. 옳은 판단은?

• 가중치가 프록시에 절반만 반영된 상태이므로 다시 적용해 동기화해야 한다
• 일관 해시가 켜져 있어 특정 사용자 키가 v2 쪽으로 몰린 결과다
• 가중치 합이 100 을 넘어 초과분이 뒤쪽 대상에 더해진 결과다
• 요청마다 난수를 뽑는 확률적 분할이므로 표본이 적으면 정상적인 편차다

트래픽 미러링에 대한 설명으로 옳은 것은?

• 미러로 보내는 비율도 weight 합에 포함되어 100 을 맞춰야 한다
• 미러 대상이 원본보다 먼저 응답하면 그 응답이 사용자에게 전달된다
• 미러 요청의 응답은 버려지지만 DB 쓰기 같은 부작용은 실제로 일어난다
• 미러 대상이 5xx 를 내면 원본 요청도 같은 오류로 함께 실패한다

가중치 카나리 중 사용자들이 화면마다 다른 버전을 본다는 불만이 들어왔습니다. 해결책은?

• VirtualService 에 재시도를 추가해 다른 버전으로 간 요청을 원래 버전으로 되돌린다
• DestinationRule 의 로드밸런서를 일관 해시로 바꾸고 사용자 식별 헤더를 키로 쓴다
• 가중치 분할을 트래픽 미러링으로 바꿔 새 버전에는 복제된 요청만 흘려보낸다
• 가중치를 100/0 으로 되돌려 카나리를 접고 다음 배포 창까지 미룬다

VirtualService 의 가중치 합이 100 이 아니면 어떻게 되나요?

• 경고 이벤트만 남긴 채 적힌 비율 그대로 적용되어 트래픽이 그대로 흐른다
• 검증에서 거부되므로 '한쪽만 바꾸고 다른 쪽을 잊는' 사고가 구조적으로 막힌다
• 가장 큰 가중치를 가진 대상이 모자란 몫을 흡수해 전부 받아 간다
• 모자란 몫이 배열의 첫 번째 대상에 자동으로 더해져 100 이 맞춰진다

DestinationRule 의 subset 라벨에 해당하는 파드가 하나도 없는 상태에서 그 subset 에 10% 를 배분하면?

• 엔드포인트가 없는 subset 은 건너뛰고 남은 subset 으로 요청이 넘어간다
• 그 10% 가 건강한 업스트림 없음(UH) 으로 503 이 된다
• 라벨에 맞는 파드가 없다는 검증 오류가 나면서 적용 자체가 거부된다
• 그 10% 의 요청은 큐에 쌓인 채 맞는 파드가 뜰 때까지 대기한다

카나리 계획에 롤백 항목을 반드시 넣어야 하는 이유로 가장 적절한 것은?

• 가중치를 100 으로 올리는 순간 이전 버전 파드가 자동으로 삭제되기 때문
• 변경 관리 감사에서 롤백 절차 문서를 필수 제출 항목으로 요구하기 때문
• 나쁜 지표를 보고도 되돌리기를 망설이는 판단 편향을 미리 제거하기 위해
• 롤백 경로를 적어 두지 않으면 가중치를 단계적으로 올릴 수 없기 때문