상황
위 글에 이어 추가로 과소진이 발생한 이슈.
간단히 설명하자면 통계값을 업데이트 할 때 전날 늦은 시간에 돌았던 select 쿼리가 다음날 완성되면서 하루 전 날 값이 엎어쳐지는 이슈였다. 이를 해결하기 위해서 시간값을 세션 변수에 담아두고 업데이트 시점에 이 날짜가 동일한지(하루 지나지 않았는지) 확인해주는 작업을 해주었었다.
이렇게 잘 해결되었으나 또 추가로 전날 값이 엎어쳐지는 이슈가 있었다. 도대체 문제가 무엇인가?
원인
이제 본격적으로 이 글의 타이틀이 Airflow와 연동 되어 있는 이유가 나온다.
우리가 사용하는 Airflow의 버전은 1.10.12이다.
이 버전대의 Airflow에는 execute date라는 개념이 있다(지금은 없어졌다.)
가령 n시간 별로 도는 배치에서 집계해줘야 하는 작업은 주로 (현재 시간-n 시간) ~ 현재시간 까지일 것이다.
그것을 위해 execute date라는 개념이 있었다. 참고로 이 개념이 등장했을 때 해당 버전대의 airflow Issue 항목중 그것이 직관적이지 않다는 지적도 나왔던 것으로 보인다.
우리는 날짜값을 쿼리에서 발생시킨 값으로 판정하는 것이 아니라 Python Operator로 이 execute date의 값을 넣어주고 있었다. 즉, 시작 시점이 아닌, job이 스케줄 queue에 들어간 시점을 사용하고 있었기 때문에 연산 오류가 발생한 것이다.
Execute date를 제대로 이해하지 못하고 사용하고 있었던 것이다.
원인을 찾은 방법
1. 비즈니스 로직 검토
먼저 로직상의 결함을 검토하기 위해 30건 이상의 테스트 케이스를 작성했다. 과소진이 발생하는 경우의 수를 찾아내보고자 했던 것이다. 그러나 이를 연산하는 로직에서 결함을 찾지 못하였다
2. RDB 백업 파일으로 이상 현상 확인
RDB의 유실을 대비해서 매일 특정 시간에 규모가 작은 테이블은 스냅샷을 떠두고, 규모가 큰 테이블은 증분 백업을 해두고 있다.
문제가 발생한 테이블에서, 문제가 발생한 과소진 케이스의 레코드 필드를 모두 찾아보았고, 이상 현상을 확인하였다. 확인 결과 예산 소진 검증 로직에 사용되는 사용 가능 예산과 비례하는 특정 값이 과도하게 높은것을 확인하였다.
정상적인 루트로는 해당 값이 절대 높아선 안되었고, 해당 테이블의 history 테이블(사용자 트리거 이력만 저장한다)을 검증해본 결과 사용자의 조작으로 인한것은 아닌듯 보였다. 따라서 문제는 배치이거나, 배치에 사용되는 파라미터 값으로 문제의 범위를 소거하였으며 해당 방향성을 가지고 execute date의 문제임을 찾아냈다.
해결 방안
쿼리에서 사용하는 date 판정을 Python Operator로 넘겨주는 것이 아니라, 쿼리단에서 now() 와 같은 함수를 사용하여 발생시킴
'트러블 슈팅 > 인프라' 카테고리의 다른 글
(Kafka) Kafka Streams에서 Repartition Topic을 Consume하지 못하는 장애(feat: kafkaAdminCli) (0) | 2024.06.16 |
---|---|
(Kafka) Kafka Streams에서 Repartition Topic을 Consume하지 못하는 장애 (feat: Metric으로 Lag값 추출) (0) | 2024.05.18 |
(Kafka) 유효하지 않은 레코드가 토픽에 들어와 카프카 어플리케이션 장애가 났을 때 (2) | 2024.05.08 |
(Airflow) 배치 날짜값 오차로 인한 통계값 오류가 발생한 이슈 1 (2) | 2024.04.28 |
(ES) Kibana Index Pattern이 생성되지 않는 버그 (1) | 2024.04.27 |