컴포넌트 인기도 기반 차등 수집
오픈소스 라이브러리의 커뮤니티 활성도·유지보수 상태를 수집하고, 인기도 점수에 따라 갱신 주기를 차등화해 한정된 크롤링 자원을 인기도 순으로 배분
기간2022
소속래브라도랩스(LabradorLabs)
역할데이터 엔지니어 · 수집 모듈/전략 설계·구현
GitHub GraphQL APIGitLab GraphQL APIPythonCrawlerScoring
0작업자의 메모
오픈소스 생태계 전체를 같은 주기로 수집하면 중요한 컴포넌트와 거의 쓰이지 않는 컴포넌트가 같은 비용을 먹습니다. 수집 자원이 한정돼 있어, 우선순위를 활성도 지표 데이터로 정했습니다.
Stars나 commits 같은 지표를 갱신 주기를 조정하는 운영 신호로 썼습니다. 점수 산정 자체만큼, 점수를 수집 정책에 연결하는 쪽을 신경 썼습니다.
1배경
라이브러리/컴포넌트를 선택할 때는 버전 정보에 더해 커뮤니티 활성도·유지보수 상태 같은 질적 정보가 필요합니다. 이런 신호는 소스 저장소에 흩어져 있어 외부 API로 수집·정량화할 필요가 있었습니다.
- Stars·Forks·Commits·기여자 수 등은 라이브러리의 활성도와 신뢰도를 가늠하는 핵심 지표
- 수집 대상 컴포넌트는 많은데 크롤링 자원은 한정 → 모든 컴포넌트를 같은 주기로 갱신하는 방식은 비효율
2접근
① 수집GitHub·GitLab GraphQL API로 활성도 지표 수집
→
② 점수화중요도·인기도를 점수로 산출
→
③ 차등 스케줄점수 높은 컴포넌트일수록 자주 갱신
→
④ 최신성한정 자원으로 핵심 데이터 최신 유지
인기도 점수로 우선순위를 매겨 갱신 주기를 차등화했습니다. 크롤링 자원은 점수가 높은 컴포넌트에 먼저 배분했습니다.
3아키텍처
점수가 높은 컴포넌트는 짧은 주기로, 낮은 컴포넌트는 긴 주기로 재수집되도록 스케줄러가 큐를 구성합니다.
4결과
지표 4종 수집 — Stars·Forks·Commits·기여자 수를 GitHub·GitLab GraphQL API로 정량화
수집 정책 전환 — 전 컴포넌트 동일 주기에서 점수 기반 차등 주기로 바꿔 한정된 크롤링 자원을 재배분
갱신 우선순위 — 점수가 높은 컴포넌트일수록 짧은 주기로 재수집되도록 큐를 구성
5역할
데이터 엔지니어로서 수집 모듈 개발, 인기도 점수화, 차등 수집 전략 수립·적용을 직접 맡았습니다. 외부 GraphQL API로 활성도 지표를 모으는 수집기를 만들었고, 차등 수집 정책은 팀 리뷰를 거쳐 적용했습니다. 점수가 높은 컴포넌트는 짧은 주기로, 낮은 컴포넌트는 긴 주기로 재수집 큐에 배치했습니다.
🕷 라이브러리 크롤러 시리즈 ② — ① 멀티 언어 크롤러 구축 · ③ 누락 점검·Python 전환