Quiz: Deployment Strategy

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

• 새 버전이 완전히 뜨기를 기다리려고
• 트래픽을 천천히 옮기려고
• 전환 후에도 구버전 Pod 을 잠시 남겨 즉시 롤백할 수 있게 하려고
• DB 마이그레이션이 끝나기를 기다리려고

카나리 단계 정의에서 setWeight 와 analysis 의 순서가 중요한 이유는?

• analysis 가 먼저여야 롤백이 빨라지기 때문
• setWeight 가 먼저 실행돼 카나리에 트래픽이 흐른 뒤에 analysis 가 시작돼야 실제 트래픽 기반 지표가 모이기 때문
• 순서는 상관없고 선언만 되어 있으면 되기 때문
• setWeight 가 analysis 결과를 인자로 받기 때문

카나리 분석이 계속 Inconclusive 로 끝난다. 가장 흔한 원인과 대응은?

• 임계값이 너무 느슨한 것이다 — 임계값을 더 엄격하게 올려 잡는다
• 쿼리가 틀렸다 — analysis 를 제거한다
• 카나리 트래픽이 너무 적어 쿼리가 NaN 을 반환한다 — 기본값을 주거나 analysis 앞에 pause 를 둬 표본을 모은다
• Pod 이 부족하다 — replicas 를 줄인다

결제나 인증처럼 한 건의 오류도 비용이 큰 서비스에 더 맞는 전략은?

• 카나리 — 1% 단위로 정밀하게 노출할 수 있으니까
• 롤링 업데이트 — 리소스를 아낄 수 있으니까
• 재생성(recreate) — 가장 단순하니까
• 블루-그린 — 문제가 보이면 트래픽을 통째로 즉시 되돌릴 수 있으니까

Expand-Contract 3단계 중 단순한 코드 롤백만으로는 되돌릴 수 없는 단계는?

• Expand
• Migrate
• Contract
• 세 단계 모두 안전하다

롤링·블루그린 배포에서 스키마 변경을 한 릴리스에 몰아 넣으면 왜 깨지나?

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