🧩 BE

개별 기사 데이터 분석 조회수 오차 이슈 (2)

Assigned To
Date
2026/02/20
Status
Done
Type
Issue
Server
Infra
Table of contents

Issue Point

결국 30일치를 한번에 가져와서 분석하는건 ga4 quota 상 불가능하다는 결론.
기사 발행 후 7일이 지나면 DB의 view_count가 동결됨. GA4에는 조회수가 계속 쌓이지만, DB에 반영할 트리거가 없었음.

Detail

기존에 희래님이 만들어두신 get_donga_view_count lambda가 존재함. 이 코드는 오늘 기준 7일치 데이터를 조회해서 가져오는 코드인데, 해당 코드에 대한 트리거가 존재하지 않아 get_, save_ donga_view_count 코드 둘 다 놀고 있는 상황. 해당 코드 활용해서 트리거만 만들고 파라미터 수정해서 조회수 수집 파이프라인 활성화 해보면 될 것 같음.

Task

1.
DB 쿼리 메서드 생성 (기간별 기사 select)
a.
특정 날짜에 생성된 기사 목록 조회
b.
특정 날짜에 생성된 기사 ID 목록 조회
c.
발행일 기준 기간 내 기사 ID 목록 조회
2.
SQS 메시지 딜레이 전송 로직 추가 (0~900초 min값 잡아놓음)
3.
청크 분할 후 SQS 전송 트리거 로직 추가
4.
빌드용 Dockerfile 생성
5.
CI/CD 스크립트 작성
6.
AWS ECR 리포지토리 donga-etl/trigger_view_count_update 생성
7.
1차 배포 (ECR 이미지 생성용)
8.
AWS Lambda 생성 및 ECR 연결
9.
2차 배포 (Lambda 코드 배포용)
10.
EventBridge 추가 - cron(0 20 * * ? *) (매일 오전 5시에 실행)
11.
Lambda 수동 Test 및 GA4 quota 모니터링

Result

1차 Test 결과

connect timeout error 발생 → rds 연결을 위한 내부 VPC 연결 때문인 것으로 파악 → query 호출용 lambda와 트리거 및 전송용 lambda 분리
query 호출용 : get-articles-view-count
트리거 및 전송용 : trigger-view-count-update

2차 Test 결과

trigger에서 get-articles-view-count로 모든 청크 전송 → DB에서 ID값 조회해와서 전송 → get-donga-view-count에서 ga와 연결해서 조회수 update (SQS 1개씩 처리) → save-donga-view-count에서 DB에 조회수 업데이트 수행
위의 과정이 오류없이 잘 돌아감. 모니터링 2회정도 더 해보고 EventBridge 활성화 시켜보면 될 것 같음.
다음주에 출근하면 trigger lambda에 {} 넣어서 test 한 번 더 해보고 get-donga-view-count , save-donga-view-count , get-donga-analytics 까지 로그 확인해보기.
2차 모니터링 결과 429에러 발생. 현재 배치 1개당 토큰 2000개 정도를 소비함. 때문에 58개 청크의 SQS중 1개만 가져와서 처리하는데도 429에러 발생. 이 부분 해결해야함.
시도해볼 방법
1.
날짜 구간을 3개로 분할(8~14, 15~22, 23~30)하여 EventBridge 페이로드를 분리
시간 (KST): 05:00 cron (UTC): cron(0 20 * * ? *) 이벤트 페이로드: {"days_start": 30, "days_end": 23}
시간 (KST): 08:00 cron (UTC): cron(0 23 * * ? *) 이벤트 페이로드: {"days_start": 22, "days_end": 15}
시간 (KST): 11:00 cron (UTC): cron(0 2 * * ? *) 이벤트 페이로드: {"days_start": 14, "days_end": 8}
2.
현재 get_donga_view_count 코드에서 google_analytics/core 에서 metrics + metadata를 모두 가져옴. view_count만 가져오면 되는 부분인데, metadata까지 가져와버리니까 호출 횟수가 2배가 돼서 불필요한 토큰 소비 발생
→ metadata 가져오는 로직은 삭제. 배치로 metrics만 가져오도록 수정.
3.
batch_run_reports가 내부적으로 5개의 쿼리를 별도 리포트(ga4의 RunReportRequest)로 요청중. 내부적으로 5개의 쿼리를 각각 실행해서 토큰이 5배로 듦.
→ 5개 기사를 1개 리포트로 합쳐서 조회. InListsFilter로 여러 content_id를 한 번에 필터링하고, dimension으로 그룹핑.
a.
현재 : batch_run_reports(5개 리포트)
b.
개선 : run_report(1개 리포트, content_id IN […])

New Task

위의 1, 2, 3번 적용
5AM에 모니터링 수행. 에러 터질 시 eventbridge 비활성화

3차 Test 결과

기존 로그
개선 로그
→ 동일 토큰으로 한 번에 5개 기사 ⇒ 100개 기사 수집이 가능하도록 개선 (처리 속도 약 20배 증가)
기존 7일치 데이터 수집 기준 18~22개 청크로 나눠서 수집 수행. → SQS 50%(10개) 처리 후 에러 나던 부분 현재 429 에러 없이 30분 내로 100% 처리가능.