LabHub

Istio 서비스 메시 · 카나리와 트래픽 분할 · 퀴즈

퀴즈: 카나리와 트래픽 분할

LabHub 에서 이어서 보기

문항 7개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

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

    1. 파드 개수와 트래픽 비율이 분리되어, 배포 없이 가중치만 되돌릴 수 있다
    2. 프록시가 응답 코드를 보고 판단하므로 readiness 프로브를 두지 않아도 된다
    3. 새 이미지를 빌드하지 않고도 가중치만으로 새 버전 코드를 띄울 수 있다
    4. 같은 개수의 파드를 롤링 업데이트보다 훨씬 빠른 속도로 교체해 준다
  2. 가중치를 90:10 으로 두었는데 실제 관측된 비율이 88:12 였습니다. 옳은 판단은?

    1. 가중치가 프록시에 절반만 반영된 상태이므로 다시 적용해 동기화해야 한다
    2. 일관 해시가 켜져 있어 특정 사용자 키가 v2 쪽으로 몰린 결과다
    3. 가중치 합이 100 을 넘어 초과분이 뒤쪽 대상에 더해진 결과다
    4. 요청마다 난수를 뽑는 확률적 분할이므로 표본이 적으면 정상적인 편차다
  3. 트래픽 미러링에 대한 설명으로 옳은 것은?

    1. 미러로 보내는 비율도 `weight` 합에 포함되어 100 을 맞춰야 한다
    2. 미러 대상이 원본보다 먼저 응답하면 그 응답이 사용자에게 전달된다
    3. 미러 요청의 응답은 버려지지만 DB 쓰기 같은 부작용은 실제로 일어난다
    4. 미러 대상이 5xx 를 내면 원본 요청도 같은 오류로 함께 실패한다
  4. 가중치 카나리 중 사용자들이 화면마다 다른 버전을 본다는 불만이 들어왔습니다. 해결책은?

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

    1. 경고 이벤트만 남긴 채 적힌 비율 그대로 적용되어 트래픽이 그대로 흐른다
    2. 검증에서 거부되므로 '한쪽만 바꾸고 다른 쪽을 잊는' 사고가 구조적으로 막힌다
    3. 가장 큰 가중치를 가진 대상이 모자란 몫을 흡수해 전부 받아 간다
    4. 모자란 몫이 배열의 첫 번째 대상에 자동으로 더해져 100 이 맞춰진다
  6. DestinationRule 의 subset 라벨에 해당하는 파드가 하나도 없는 상태에서 그 subset 에 10% 를 배분하면?

    1. 엔드포인트가 없는 subset 은 건너뛰고 남은 subset 으로 요청이 넘어간다
    2. 그 10% 가 건강한 업스트림 없음(UH) 으로 503 이 된다
    3. 라벨에 맞는 파드가 없다는 검증 오류가 나면서 적용 자체가 거부된다
    4. 그 10% 의 요청은 큐에 쌓인 채 맞는 파드가 뜰 때까지 대기한다
  7. 카나리 계획에 롤백 항목을 반드시 넣어야 하는 이유로 가장 적절한 것은?

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