bug(scheduler): 자동 일일 수집이 2026-04-22 부터 equity/crypto 100% 실패 #81

New issue

Open

opened 2026-05-26 02:28:33 +09:00 by xhh · 1 comment

xhh commented

2026-05-26 02:28:33 +09:00

Owner

증상

equity_prices 테이블의 50개 심볼 + crypto_prices 의 BTC-USD 가 2026-04-21 에서 max_date 정지. 2026-05-26 기준 lag 35일.
/api/collect/history?days=60 으로 보면 매일 KST 09:00 에 자동 실행은 되고 있으나, equity/crypto 부분이 매일 success=0 / failed=100.
collection_logs 의 실패 행은 모두 error_message="데이터 없음", started_at 이 KST 09:03 ± 2초.
FRED 는 일부만 실패 (success=24~29 / failed=1~14), 발표 주기 영향 가능성이라 별 이슈로 보임.

진단 (NAS 로컬, 2026-05-26 02시 KST)

외부 라이브러리·코드·환경 모두 정상으로 동작 확인:

yfinance.Ticker('SPY').history(period='5d') → 5 rows (5/18~5/22)
obb.equity.price.historical('SPY', provider='yfinance') → 250 rows
OpenBBCollector().fetch_equity_historical('SPY') → 250 rows
POST /api/collect/single?symbols=SPY  → collection_logs records_count=23 (4/22~5/22)

즉 컨테이너 안에서 같은 함수를 새로 호출하면 정상. 자동 스케줄 path (subprocess → scripts/collect_daily.py → collect_single_symbol → fetch_equity_historical) 와 동일 코드인데 실행 결과만 다름.

가설

yfinance cookie/cache 오염. 운영 컨테이너 안 /home/app/.cache/py-yfinance/cookies.db mtime 이 최근 컨테이너 재시작 시각과 일치. 아래 사실 종합:

yfinance 가 응답 실패 시 어떤 stale 값을 cookies.db 또는 ticker tz cache(tkr-tz.db)에 남길 수 있고, 같은 컨테이너에서 이후 매 호출이 그 stale 결과를 그대로 받음.
컨테이너 재시작 = 새 cookie → fresh 응답. 우리가 5/25 17:21 에 API/streamlit 을 리빌드+recreate 한 직후부터 직접 호출이 250 rows 정상이 됨.
그 이전엔 컨테이너가 "Up 10 days" 였고, 4/22 부터 매일 실패. 컨테이너 부팅 직후 한 번도 정상으로 안 돌고 멈춤 또는 그 사이 어떤 이벤트로 cache 가 오염됐을 가능성.

다만 yfinance 코드를 직접 까보지는 않았으니 단정은 아님. 다른 가설 (rate-limit 누적, OpenBB provider 캐시 오염, Yahoo 의 시간대별 응답 차이 등) 가능성 열어둠.

검증 계획

내일 (2026-05-27) KST 09:00 자동 실행 결과:
- 정상 수집 → 가설 강화 ("컨테이너 fresh state"). 다만 N일 후 재발 여부 모니터.
- 다시 실패 → 가설 폐기. OpenBB provider 또는 다른 캐싱 레이어 의심.
collection_logs 에서 4/21 (마지막 정상일) 과 4/22 (첫 실패일) 사이 컨테이너 재시작 / 환경 변화 흔적 확인 (이미지 mtime, docker inspect started 등).

가능한 영구 fix 후보

A. 매 수집 job 시작 시 ~/.cache/py-yfinance/cookies.db 삭제 (가장 단순).
B. yfinance Ticker 객체를 매 호출마다 새로 생성 + 명시적으로 session.cookies.clear().
C. APScheduler job 을 subprocess 대신 in-process 로 바꾸고 retry-with-cache-bust 로직 추가.
D. OpenBB 의 yfinance provider 외 fallback provider 추가 (polygon free tier 등).

임시 조치

2026-05-26 02시 KST 에 수동 백필 트리거 진행 중 (51개 equity+crypto 심볼, 4/22~5/22 약 23 영업일). 결과는 댓글로 추가.

영향

macro-report:liquidity 스킬이 5/25 에 equity price data lag 를 data_gap 으로 자동 보고했던 그 현상.
다른 다운스트림 스킬·대시보드가 stale 데이터로 잘못된 판단을 했을 가능성 있음 (영향 평가 별도).

## 증상 - `equity_prices` 테이블의 50개 심볼 + `crypto_prices` 의 BTC-USD 가 **2026-04-21** 에서 max_date 정지. 2026-05-26 기준 lag 35일. - `/api/collect/history?days=60` 으로 보면 매일 KST 09:00 에 자동 실행은 되고 있으나, equity/crypto 부분이 매일 `success=0 / failed=100`. - `collection_logs` 의 실패 행은 모두 `error_message="데이터 없음"`, started_at 이 KST 09:03 ± 2초. - FRED 는 일부만 실패 (`success=24~29 / failed=1~14`), 발표 주기 영향 가능성이라 별 이슈로 보임. ## 진단 (NAS 로컬, 2026-05-26 02시 KST) 외부 라이브러리·코드·환경 모두 정상으로 동작 확인: ``` yfinance.Ticker('SPY').history(period='5d') → 5 rows (5/18~5/22) obb.equity.price.historical('SPY', provider='yfinance') → 250 rows OpenBBCollector().fetch_equity_historical('SPY') → 250 rows POST /api/collect/single?symbols=SPY → collection_logs records_count=23 (4/22~5/22) ``` 즉 **컨테이너 안에서 같은 함수를 새로 호출하면 정상**. 자동 스케줄 path (subprocess → scripts/collect_daily.py → collect_single_symbol → fetch_equity_historical) 와 동일 코드인데 실행 결과만 다름. ## 가설 **yfinance cookie/cache 오염**. 운영 컨테이너 안 `/home/app/.cache/py-yfinance/cookies.db` mtime 이 최근 컨테이너 재시작 시각과 일치. 아래 사실 종합: - yfinance 가 응답 실패 시 어떤 stale 값을 cookies.db 또는 ticker tz cache(`tkr-tz.db`)에 남길 수 있고, 같은 컨테이너에서 이후 매 호출이 그 stale 결과를 그대로 받음. - 컨테이너 재시작 = 새 cookie → fresh 응답. 우리가 5/25 17:21 에 API/streamlit 을 리빌드+recreate 한 직후부터 직접 호출이 250 rows 정상이 됨. - 그 이전엔 컨테이너가 "Up 10 days" 였고, 4/22 부터 매일 실패. 컨테이너 부팅 직후 한 번도 정상으로 안 돌고 멈춤 또는 그 사이 어떤 이벤트로 cache 가 오염됐을 가능성. 다만 yfinance 코드를 직접 까보지는 않았으니 단정은 아님. 다른 가설 (rate-limit 누적, OpenBB provider 캐시 오염, Yahoo 의 시간대별 응답 차이 등) 가능성 열어둠. ## 검증 계획 1. **내일 (2026-05-27) KST 09:00 자동 실행 결과**: - 정상 수집 → 가설 강화 ("컨테이너 fresh state"). 다만 N일 후 재발 여부 모니터. - 다시 실패 → 가설 폐기. OpenBB provider 또는 다른 캐싱 레이어 의심. 2. `collection_logs` 에서 4/21 (마지막 정상일) 과 4/22 (첫 실패일) 사이 컨테이너 재시작 / 환경 변화 흔적 확인 (이미지 mtime, `docker inspect` started 등). ## 가능한 영구 fix 후보 - A. 매 수집 job 시작 시 `~/.cache/py-yfinance/cookies.db` 삭제 (가장 단순). - B. yfinance Ticker 객체를 매 호출마다 새로 생성 + 명시적으로 `session.cookies.clear()`. - C. APScheduler job 을 subprocess 대신 in-process 로 바꾸고 retry-with-cache-bust 로직 추가. - D. OpenBB 의 yfinance provider 외 fallback provider 추가 (polygon free tier 등). ## 임시 조치 2026-05-26 02시 KST 에 수동 백필 트리거 진행 중 (51개 equity+crypto 심볼, 4/22~5/22 약 23 영업일). 결과는 댓글로 추가. ## 영향 - macro-report:liquidity 스킬이 5/25 에 `equity price data lag` 를 data_gap 으로 자동 보고했던 그 현상. - 다른 다운스트림 스킬·대시보드가 stale 데이터로 잘못된 판단을 했을 가능성 있음 (영향 평가 별도).

xhh added the

bug

collector

infra

labels

2026-05-26 02:28:33 +09:00

xhh commented

2026-05-26 02:31:53 +09:00

Author

Owner

임시 백필 결과 (2026-05-26 02시 KST)

51개 심볼 일괄 POST /api/collect/single 트리거. 50건 success / 1건 fail (1분 소요).

equity_prices: 49개 lag 1d 정상화, DX-Y.NYB (Dollar Index) 만 실패 — yfinance 가 이 특이 티커에서 빈 응답 반환. 별도 추적 필요.
crypto_prices: BTC-USD lag 1d 정상화.

동반 closes 대상

이 이슈와 직접 매칭되는 data_gap 항목:

id=12 equity price data lag (macro-report:liquidity 가 5/25 자동 보고). 이 이슈가 자동 수집 정상화로 종결되면 PR/머지 커밋 디스크립션에 다음 라인을 포함해 함께 정리할 것:

Closes #81
Also resolve data_gap #12 via: 
  curl -X PATCH http://localhost:8000/api/meta/data-gaps/12 \
    -H "X-API-Key: $FDP_REPORTER_API_KEY" \
    -H "Content-Type: application/json" \
    -d '{"resolved": true, "resolved_note": "#81 자동 수집 정상화로 해결"}'

나머지 5/25 등록 liquidity 갭 6건(id=7,8,9,10,11,13)은 이 이슈와 별개 — 신규 심볼 추가(B 그룹: 9/10/13) 또는 신규 수집기(C 그룹: 7/8/11) 작업으로 별도 추적.

다음 검증

2026-05-27 KST 09:00 자동 실행 결과가 정상이면 "컨테이너 재기동 후 fresh state" 가설 강화. 일정 기간 모니터 후 stable 하면 close.
실패 재발 시 cookie/cache bust 패치 (가설 fix A) 도입.

## 임시 백필 결과 (2026-05-26 02시 KST) 51개 심볼 일괄 `POST /api/collect/single` 트리거. **50건 success / 1건 fail** (1분 소요). - equity_prices: 49개 lag 1d 정상화, **DX-Y.NYB** (Dollar Index) 만 실패 — yfinance 가 이 특이 티커에서 빈 응답 반환. 별도 추적 필요. - crypto_prices: BTC-USD lag 1d 정상화. ## 동반 closes 대상 이 이슈와 직접 매칭되는 `data_gap` 항목: - **id=12 `equity price data lag`** (`macro-report:liquidity` 가 5/25 자동 보고). 이 이슈가 자동 수집 정상화로 종결되면 PR/머지 커밋 디스크립션에 다음 라인을 포함해 함께 정리할 것: ``` Closes #81 Also resolve data_gap #12 via: curl -X PATCH http://localhost:8000/api/meta/data-gaps/12 \ -H "X-API-Key: $FDP_REPORTER_API_KEY" \ -H "Content-Type: application/json" \ -d '{"resolved": true, "resolved_note": "#81 자동 수집 정상화로 해결"}' ``` 나머지 5/25 등록 liquidity 갭 6건(`id=7,8,9,10,11,13`)은 이 이슈와 별개 — 신규 심볼 추가(B 그룹: 9/10/13) 또는 신규 수집기(C 그룹: 7/8/11) 작업으로 별도 추적. ## 다음 검증 - **2026-05-27 KST 09:00** 자동 실행 결과가 정상이면 "컨테이너 재기동 후 fresh state" 가설 강화. 일정 기간 모니터 후 stable 하면 close. - 실패 재발 시 cookie/cache bust 패치 (가설 fix A) 도입.