LabHub
배우기 러닝패스 코스

로그가 미래에서 왔다 — 시계가 만든 다섯 사건 · 한 번만 돌았어야 할 정산이 두 번 돌았다 · 퀴즈

퀴즈: 한 번만 돌았어야 할 정산이 두 번 돌았다

LabHub 에서 이어서 보기

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

  1. 정기 작업의 감시를 「총 실행 횟수」로만 하면 서머타임 사고를 못 잡는 이유는?

    1. 서머타임 기간에는 실행 기록이 다른 형식으로 쌓여 집계에서 빠지기 때문이다
    2. 건너뛴 한 번과 두 번 돈 한 번이 서로를 가려 총계가 기대치와 같아지기 때문이다
    3. 스케줄러가 놓친 실행을 나중에 몰아서 돌려 총계를 맞춰 주기 때문이다
    4. 총계는 하루 단위로만 세므로 새벽 시간대가 집계 창 밖으로 나가기 때문이다
  2. 쿠버네티스 CronJob 문서가 시간대를 UTC 로 고정한 뒤에도 Job 을 멱등하게 만들라고 요구하는 이유는?

    1. 컨트롤러가 일정마다 대략 한 번 Job 을 만들며 두 개가 생기거나 하나도 안 생길 수 있기 때문이다
    2. UTC 로 고정하면 서머타임 대신 윤초 때문에 중복이 생기기 때문이다
    3. 같은 네임스페이스의 다른 CronJob 이 같은 Job 을 다시 만들 수 있기 때문이다
    4. Job 이력 보관 한도를 넘으면 삭제된 Job 이 다시 생성되기 때문이다
  3. concurrencyPolicy 의 Forbid 가 하는 일은?

    1. 앞 실행을 새 실행으로 갈아 끼운다
    2. 앞 실행이 끝날 때까지 새 실행을 대기열에 넣어 두었다가 이어서 돌린다
    3. 앞 실행이 아직 안 끝났으면 이번 실행을 건너뛴다
    4. 같은 네임스페이스의 다른 CronJob 까지 동시 실행을 막는다
  4. 되풀이 작업의 멱등성을 위한 실행 열쇠로 적절한 것은?

    1. 작업 이름과 실행 아이디를 이어 붙인 문자열
    2. 작업 이름과 실제로 시작한 시각을 이어 붙인 문자열
    3. 실행할 때마다 새로 만드는 UUID
    4. 작업 이름과 처리 대상 기간을 이어 붙인 문자열
  5. 겹침 방지와 멱등성이 서로 다른 문제라는 것을 가장 잘 보여 주는 경우는?

    1. 앞 실행이 실패해 재시도가 곧바로 다시 도는 경우
    2. 서머타임 종료로 같은 기간이 한 시간 간격을 두고 두 번 도는 경우
    3. 노드 장애로 Job 의 파드가 다른 노드에서 다시 뜨는 경우
    4. startingDeadlineSeconds 를 넘겨 실행이 건너뛰어지는 경우
  6. CronJob 문서가 startingDeadlineSeconds 에 대해 따로 경고한 것은?

    1. 값을 0 으로 두면 모든 실행이 즉시 실패로 기록된다
    2. 이 값은 concurrencyPolicy 가 Forbid 일 때만 효력이 있다
    3. 10초보다 작게 두면 컨트롤러의 확인 주기 탓에 아예 스케줄되지 않을 수 있다
    4. 설정하지 않으면 기본값 100초가 적용되어 늦은 실행이 버려진다