OAuth 인증 크론 주기를 30분으로 단축해 장애 감지 시간을 줄인 이야기
목차
지난주 OAuth 인증 체크 크론이 23시간 동안 401 에러를 놓쳤다. 단순한 통신 실패가 아니라, 시스템이 정상 작동하는 줄 알았는데 실제로는 외부 인증 토큰이 만료되거나 갱신되지 않은 상태였다. 문제 대응 이후 우리 팀은 README에 문서화되어 있던 auth-check 크론의 실행 주기를 재설정했다.
왜 23시간이나 걸렸나
기존 설정은 매일 09:00에 auth-check를 1회만 실행하는 방식이었다. 이 작업은 외부 OAuth 서비스와의 토큰 유효성을 검증하고, 필요하면 갱신하는 역할을 했다.
문제는 여기였다. 토큰 만료나 갱신 실패 같은 문제가 발생해도, 다음날 09:00까지 아무도 알 수 없었다. 만약 오후나 저녁 시간에 토큰이 만료되면, 그 순간부터 모든 외부 연동 요청이 401로 실패하지만, 크론은 내일 아침까지 기다려야 한다. 실제로 이번 사고도 그렇게 흘러갔다. 사용자들이 업무를 하다가 외부 서비스와의 연동이 끊긴 것을 발견했지만, 그때까지 이미 거의 하루가 지났다.
크론 작업의 설계 원칙을 다시 생각하다
크론 작업을 설계할 때 우리가 놓친 부분이 있다. 매시간 또는 매분 실행하는 것이 리소스 낭비처럼 보일 수 있지만, 감시 목적의 작업은 다르다. 백업이나 배치 처리라면 일 1회로 충분하지만, 시스템 상태를 감시하거나 중요한 외부 연동을 검증하는 작업은 빈도가 곧 리스크 감소로 직결된다.
변경 후 설정:
- 이전: 0 9 * * * (매일 09:00, 1회)
- 변경: */30 * * * * (30분마다)
30분 주기면 최악의 경우에도 30분 이내에 OAuth 에러를 감지할 수 있다. 이는 MTTR(평균 복구 시간)을 23시간 → 30분으로 단축하는 것이다. 물론 이 수치는 문제 감지 후 조치까지의 시간이지만, 감시 빈도 개선만으로도 일단 가시성이 확보된다.
모니터링 설계의 트레이드오프
물론 */30도 절대 정답은 아니다. 더 자주 실행하면 더 빨리 감지되겠지만, 크론의 리소스 비용, 외부 API 호출 빈도, 로그 증가량 등을 함께 고려해야 한다. 우리 팀은 다음 요소들을 저울질했다:
- 감지 지연 허용치: 토큰 만료를 30분 이내에 알아도 괜찮은가? (우리 서비스 특성상 그렇다고 판단)
- 외부 API 비용: 30분마다 토큰 검증 요청을 보내도 괜찮은가? (극도로 무겁지 않음)
- 알림 체계: 크론이 실패하면 누가 얼마나 빨리 대응하는가? (Slack 알림 연동 완료)
결국 09:00 1회 설정은 감시라는 목적을 무시한 설계였다. 크론 작업의 목적을 되짚어 보면, 그에 맞는 주기가 자동으로 나온다.
문서화가 방어 수단이다
이번 변경은 README.md에만 기록했다. 변경된 크론 설정과 그 배경, 그리고 만약 다른 팀원이 이 설정을 건드릴 때 왜 30분인지 알 수 있도록. 운영 자동화는 코드가 아닌 설정이기 쉽고, 설정은 시간이 지나면 누가 왜 그렇게 했는지 잊기 쉽다. 사고 대응 과정에서 배운 교훈을 문서에 박아두는 것이, 팀 전체의 운영 리스크를 줄이는 가장 빠른 방법이었다.
이 작업 자체는 README 한두 줄 수정에 불과했지만, 그 뒤에는 토큰 검증 실패의 원인 분석, 크론 주기 재설계, 알림 체계 재확인이라는 더 큰 업무가 숨어 있었다. 때로는 이렇게 작은 문서 변경이 시스템의 신뢰도를 크게 높인다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.