LabHub

CI/CD 파이프라인 · 배포 전략: 블루그린과 카나리 · 퀴즈

퀴즈: 배포 전략

LabHub 에서 이어서 보기

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

  1. 블루그린에서 `scaleDownDelaySeconds` 를 300~600초로 두는 이유는?

    1. 새 버전이 완전히 뜨기를 기다리려고
    2. 트래픽을 천천히 옮기려고
    3. 전환 후에도 구버전 Pod 을 잠시 남겨 즉시 롤백할 수 있게 하려고
    4. DB 마이그레이션이 끝나기를 기다리려고
  2. 카나리 단계 정의에서 `setWeight` 와 `analysis` 의 순서가 중요한 이유는?

    1. analysis 가 먼저여야 롤백이 빨라지기 때문
    2. setWeight 가 먼저 실행돼 카나리에 트래픽이 흐른 뒤에 analysis 가 시작돼야 실제 트래픽 기반 지표가 모이기 때문
    3. 순서는 상관없고 선언만 되어 있으면 되기 때문
    4. setWeight 가 analysis 결과를 인자로 받기 때문
  3. 카나리 분석이 계속 Inconclusive 로 끝난다. 가장 흔한 원인과 대응은?

    1. 임계값이 너무 느슨한 것이다 — 임계값을 더 엄격하게 올려 잡는다
    2. 쿼리가 틀렸다 — analysis 를 제거한다
    3. 카나리 트래픽이 너무 적어 쿼리가 NaN 을 반환한다 — 기본값을 주거나 analysis 앞에 pause 를 둬 표본을 모은다
    4. Pod 이 부족하다 — replicas 를 줄인다
  4. 결제나 인증처럼 한 건의 오류도 비용이 큰 서비스에 더 맞는 전략은?

    1. 카나리 — 1% 단위로 정밀하게 노출할 수 있으니까
    2. 롤링 업데이트 — 리소스를 아낄 수 있으니까
    3. 재생성(recreate) — 가장 단순하니까
    4. 블루-그린 — 문제가 보이면 트래픽을 통째로 즉시 되돌릴 수 있으니까
  5. Expand-Contract 3단계 중 단순한 코드 롤백만으로는 되돌릴 수 없는 단계는?

    1. Expand
    2. Migrate
    3. Contract
    4. 세 단계 모두 안전하다
  6. 롤링·블루그린 배포에서 스키마 변경을 한 릴리스에 몰아 넣으면 왜 깨지나?

    1. 마이그레이션 자체가 느려져 배포 전체가 뒤로 밀리고 타임아웃이 나기 때문이다
    2. DB 커넥션 풀이 부족해지기 때문
    3. 신·구 코드가 동시에 떠 있는 구간이 반드시 있어서, 스키마를 먼저 바꾸면 구버전 코드가 깨지고 코드를 먼저 바꾸면 없는 스키마를 참조해 깨지기 때문
    4. 롤백이 느려질 뿐 기능적 문제는 없기 때문