🔒 내부용 · 비배포 (포트폴리오에는 일반화 버전만 공개)
0한눈에
- 대상: Gathering → Master → Distribution 데이터 수집 파이프라인 전체.
- 호스트 흐름:
lab-gath → lab-master → lab-dist.
- 핵심 변경: 오픈소스 RAW 데이터 저장을 파일시스템 → 오브젝트 스토리지(SeaweedFS)로 마이그레이션.
- 핵심 효과: 재수집 때마다 1,000만~1억 건 외부 요청이 필요하던 구조 → RAW 보존·재파싱으로 재처리 시 외부 요청 0건 (설계 산정 예: 2일 → 5분).
- 근거 문서: Confluence [ISSU|DBPT] 기존 ETL 데이터 수집 플로우 문제점 · [ENHC|OBJ] 오브젝트 스토리지 구축 방안
1왜 재정립했나
레거시는 원테이크 수집이었다: API 호출 → 즉시 파싱 → DB 저장, RAW는 메모리에만 존재하고 버린다. 그 결과,
- 재수집·추가 수집 때마다 매번 1,000만~1억 건의 외부 API 요청이 필요했고, rate limit에 걸려 수집이 장기화.
- 파싱 버그·이상 데이터("왜 UNKNOWN이 들어갔지?")가 발견돼도 원본이 없어 원인 추적·재현 불가, 덮어쓰기 구조라 이력도 없음 — 유일한 해결책이 전체 재수집.
또한 수집(lab-gath)부터 마스터(lab-master), 배포(lab-dist)까지 단계별 처리·저장 방식이 제각각이라 흐름 파악과 운영 인계가 어려웠고, 오픈소스 RAW 데이터가 늘면서 파일시스템 저장은 용량·확장성 한계가 명확했다. → RAW 보존 구조 + 수집 플로우 표준화 + 확장 가능한 스토리지 기반이 필요.
2진행 순서
- 수집→마스터→배포 파이프라인 전 단계 재정의 (흐름·책임 명확화)
- RAW 보존 구조 설계 — Collector(수집)와 Worker(정제)를 상태 관리 DB로 분리,
processed 플래그 + FOR UPDATE SKIP LOCKED 대기열, version_id로 수정 이력 추적, Cache Hit/Miss 패턴
- 오픈소스 RAW 데이터 수집용 오브젝트 스토리지(SeaweedFS) 설계
- 파일시스템 → 오브젝트 스토리지 마이그레이션 전략·로드맵 수립
- 로드맵에 따른 단계적 마이그레이션 적용 (진행 중)
RAW 데이터 저장소 전환은 수집 단계(lab-gath)에 직접 영향을 주므로, 마이그레이션을 단계적으로 적용하고 로드맵 기준으로 진행.
3온보딩 포인트
- 파이프라인은 Gathering → Master → Distribution. 데이터는 항상 수집에서 배포 방향으로 흐른다.
- 오픈소스 RAW 데이터는 파일시스템이 아닌 오브젝트 스토리지(SeaweedFS)를 기준 저장소로 가져간다.
- 재처리는 재수집이 아니라 재파싱이다 — RAW가 보존되어 있으므로 외부 API를 다시 부르지 않는다 (요청 0건). 파싱 로직을 고치면 해당 기간 RAW만 다시 읽으면 된다.
- 이상 데이터를 만나면
version_id로 그 시점의 RAW 원본을 확인한다 — "API가 안 보낸 건지, 파싱 버그인지"를 원본으로 판별.
- 목표: 수집 플로우 표준화 + 확장 가능한 스토리지 기반 마련.
4공개(포트폴리오)와의 차이
공개 버전(human/portfolio/items/etl-flow-redesign.html)은 내부 호스트명(lab-gath, lab-master, lab-dist) 등 내부 식별자를 일반 용어(수집/마스터/배포)로 치환하고 문제·접근·임팩트 중심으로 일반화했다. 이 내부 문서는 본인 참고/온보딩용.
📦 데이터 플랫폼 재구축 시리즈 ① — ① ETL 재정립 · ② 오브젝트 스토리지