로그가 미래에서 왔다 — 시계가 만든 다섯 사건 · 한 번만 돌았어야 할 정산이 두 번 돌았다 · 퀴즈
퀴즈: 한 번만 돌았어야 할 정산이 두 번 돌았다
문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
정기 작업의 감시를 「총 실행 횟수」로만 하면 서머타임 사고를 못 잡는 이유는?
- 서머타임 기간에는 실행 기록이 다른 형식으로 쌓여 집계에서 빠지기 때문이다
- 건너뛴 한 번과 두 번 돈 한 번이 서로를 가려 총계가 기대치와 같아지기 때문이다
- 스케줄러가 놓친 실행을 나중에 몰아서 돌려 총계를 맞춰 주기 때문이다
- 총계는 하루 단위로만 세므로 새벽 시간대가 집계 창 밖으로 나가기 때문이다
쿠버네티스 CronJob 문서가 시간대를 UTC 로 고정한 뒤에도 Job 을 멱등하게 만들라고 요구하는 이유는?
- 컨트롤러가 일정마다 대략 한 번 Job 을 만들며 두 개가 생기거나 하나도 안 생길 수 있기 때문이다
- UTC 로 고정하면 서머타임 대신 윤초 때문에 중복이 생기기 때문이다
- 같은 네임스페이스의 다른 CronJob 이 같은 Job 을 다시 만들 수 있기 때문이다
- Job 이력 보관 한도를 넘으면 삭제된 Job 이 다시 생성되기 때문이다
concurrencyPolicy 의 Forbid 가 하는 일은?
- 앞 실행을 새 실행으로 갈아 끼운다
- 앞 실행이 끝날 때까지 새 실행을 대기열에 넣어 두었다가 이어서 돌린다
- 앞 실행이 아직 안 끝났으면 이번 실행을 건너뛴다
- 같은 네임스페이스의 다른 CronJob 까지 동시 실행을 막는다
되풀이 작업의 멱등성을 위한 실행 열쇠로 적절한 것은?
- 작업 이름과 실행 아이디를 이어 붙인 문자열
- 작업 이름과 실제로 시작한 시각을 이어 붙인 문자열
- 실행할 때마다 새로 만드는 UUID
- 작업 이름과 처리 대상 기간을 이어 붙인 문자열
겹침 방지와 멱등성이 서로 다른 문제라는 것을 가장 잘 보여 주는 경우는?
- 앞 실행이 실패해 재시도가 곧바로 다시 도는 경우
- 서머타임 종료로 같은 기간이 한 시간 간격을 두고 두 번 도는 경우
- 노드 장애로 Job 의 파드가 다른 노드에서 다시 뜨는 경우
- startingDeadlineSeconds 를 넘겨 실행이 건너뛰어지는 경우
CronJob 문서가 startingDeadlineSeconds 에 대해 따로 경고한 것은?
- 값을 0 으로 두면 모든 실행이 즉시 실패로 기록된다
- 이 값은 concurrencyPolicy 가 Forbid 일 때만 효력이 있다
- 10초보다 작게 두면 컨트롤러의 확인 주기 탓에 아예 스케줄되지 않을 수 있다
- 설정하지 않으면 기본값 100초가 적용되어 늦은 실행이 버려진다