부재 감지기의 grace_hours 임계값을 실측으로 정하려면 신호가 최장 몇 시간까지 안 올 수 있는지를 알아야 했다. 이벤트가 쌓이는 DynamoDB job_events 를 Scan 으로 전수로 훑어 5천여 건을 얻었다.
Table of contents
Open Table of contents
원인 — 창을 정한 만료 설정
가장 오래된 것과 가장 최근 것의 시간 범위가 48시간 언저리로 딱 떨어졌다. 테이블 설정을 보니 ttl 속성에 48시간 만료가 걸려 있었다. AWS 공식 문서대로 DynamoDB 는 만료된 항목을 만료 시각 뒤 며칠 안에 지운다. 경계가 정확히 48시간은 아니지만 그 언저리에서 잘리는 것은 같다.
남아 있는 데이터의 범위가 48시간인 것은 그것이 전부여서가 아니라 그보다 오래된 것이 지워졌기 때문이다. 48시간보다 긴 간격은 있었더라도 앞쪽이 사라져서 이 스캔으로는 보이지 않는다.
판단 기준 — 구조적 불가와 표본 제한
여기서 한 번 더 갈랐다. 영영 못 재는 것인지 이번 스캔으로 못 재는 것인지다.
48시간 창 안에서 일어난 장기 실행은 완전히 보인다. Scan 을 매일 돌려 S3 에 누적하면 더 긴 창을 만들 수 있으므로 표본 기간 제한이지 구조적 관측 불가가 아니었다. 구조적 불가면 다른 데이터 소스를 찾아야 하고 표본 제한이면 더 모으면 된다. 이 구분이 다음 행동을 정한다.
조치 — 우회 대신 명시
두 가지 방법이 있었는데 CloudWatch Logs 같은 다른 데서 어떻게든 뽑아 보는 것과 한계를 그대로 적는 것이다. 뒤쪽을 골랐다. 이유는 다른 소스는 같은 이벤트를 같은 기준으로 담고 있다는 보장이 없어서다. 대신 임계값을 이번에 확정하지 못하는 것을 감수했다. 적은 내용은 ttl 때문에 표본 기간이 제한되고 그보다 긴 간격은 이번 Scan 으로 확정할 수 없으며 누적하면 닫을 수 있다는 것이다.
한계를 적는 것도 결과이고 우회해서 부정확한 값을 내는 것보다 낫다. 읽는 쪽이 그 숫자를 어디까지 믿을지를 알 수 있게 된다.
주의 — 반증도 확증도 아닌 상태
같은 조사에서 다른 것이 나왔다. 실행 소요가 길어 유예 시간을 잠식한다는 작업 전제가 있었는데 특정 대상의 이벤트 다섯 건을 실측하니 started_at 과 finished_at 의 차이가 1초 이내였다.
전제가 정반대로 반증된 것처럼 보였지만 그 다섯 건을 다시 보니 processed_count 가 전부 0인 무주문 실행이었다. 부하가 있는 실행의 소요는 관측하지 않았다. 실행이 항상 빠르다고 일반화할 수 없다. 전제가 이 표본에서 확인되지 않았지만 이 표본은 부하 있는 실행의 표본이 아니므로 반증도 확증도 아니라고 적었다.
근거가 없으면 안 바꾼다
그래서 두 가지를 정했다. 실행 소요를 이유로 grace_hours 를 조정할 근거가 없으므로 임계값은 안 바꾼다.
지금 아는 한계를 알려진 공백으로 문서화하고 나중에 제대로 된 표본이 모이면 다시 본다. 무엇을 모아야 하는지도 적었는데 더 조사가 필요하다가 아니라 processed_count > 0 인 부하 실행 표본이 필요하다고 쓰면 다음 사람이 할 일이 정해진다.
표본에서 이상한 것도 하나 발견했다. 다섯 건 중 하나가 예정된 cron 시각이 아닌 때에 실행돼 있었다. 수동 실행인지 재시도인지 밀린 것인지 알 수 없었다. 이번 조사와 별개라 파지 않고 기록만 남겼다.
정리
ttl보존 기간이 관측 창을 제한하므로 남아 있는 범위가 전부가 아니다- 영영 못 재는 것과 이번 스캔으로 못 재는 것을 구분한다
- 우회하지 말고 표본 기간 제한으로 명시한다
- 한계를 적는 것도 결과다
- 실측이 전제를 반증해도 표본이 대표성 없으면 확증도 아니다
- 반증도 확증도 아닌 상태를 그대로 적는다
- 바꿀 근거가 없으면 안 바꾸고 알려진 공백으로 문서화한다
- 더 조사가 필요하다가 아니라 이런 표본이 필요하다고 적는다