AWS 서버리스 데이터 파이프라인

문제

회사의 가격 예측 작업에는 폭넓고 최신인 시장 데이터가 필요했습니다. 목표는 회사가 취급하는 7개 차량 브랜드 전체에서 하루 약 500만 건의 매물이었습니다.

파이프라인은 안정적이어야 했고, 예산 안에서 운영되어야 했으며, 읽기 속도를 제한하는 데이터 소스에도 대응해야 했습니다.

아키텍처

1. 스케줄 EventBridge가 각 수집 주기를 시작합니다. 작은 Lambda가 그날의 수집 대상을 초기화합니다.
2. 큐 SQS가 작업을 보관하며, 데이터베이스를 큐로 쓰던 이전 설계를 대체했습니다. 실패한 메시지는 데드레터 큐로 이동합니다.
3. 워커 Docker 이미지로 패키징한 Lambda 함수가 페이지를 병렬로 가져와 파싱합니다.
4. 저장 매물은 RDS PostgreSQL에 저장되며, 커넥션 풀링에는 RDS Proxy를 사용합니다. 쓰기는 점진적이고 원자적입니다.
5. 알림 CloudWatch 지표와 알람, 그리고 SNS를 통한 알림.

• 재시도와 복구안전한 대상 선점, 재시도, 멈춘 작업 복구, DLQ 재처리
• 모니터링 Lambda데이터베이스 상태를 CloudWatch에 보고하는 읽기 전용 작업
• 상태 점검어떤 OS에서도 실행되는 AWS CLI 스크립트

무너지지 않고 속도를 늦추는 설계

요청 속도를 제한하는 데이터 소스는 결국 제동을 겁니다. 파이프라인은 이를 전제로 설계했습니다.

• 서킷 브레이커. 페이지가 차단되기 시작하면 워커는 더 세게 재시도하는 대신 잠시 멈춥니다. 공유 쿨다운 상태는 PostgreSQL에 저장됩니다.
• 적응형 속도 제한. 요청 간격에 지터를 두고, 소스가 제동을 걸면 자동으로 속도를 줄이며, 쿨다운 후에는 워커를 점진적으로 늘립니다.
• 안전한 동시성. 워커는 대상을 안전하게 선점하고, 재시도하며, 멈춘 작업을 복구합니다. 그래서 많은 워커가 충돌 없이 병렬로 실행됩니다.

관측성과 운영

• 중요한 것에 대한 알람. 오케스트레이터가 멈추거나, 워커가 실패하거나, Lambda가 워커 실행을 제한(스로틀링)하거나, 큐가 밀리거나 메시지가 오래 대기하거나, 페이지가 차단되거나, 데이터베이스 쓰기가 실패하거나, 일일 매물 수가 떨어지면 CloudWatch가 저에게 알립니다.
• 상태 점검. AWS CLI 스크립트로 어떤 컴퓨터에서든 파이프라인 상태를 점검하고, 작은 읽기 전용 Lambda가 데이터베이스 상태를 CloudWatch에 보냅니다.
• 문서화된 절차. Lambda를 제한하거나 중지하고 큐를 비우는 방법을 적어 두어, 폭주하는 작업이 비용을 키우지 못하게 합니다.

시니어 리뷰 후 안정성 강화

시니어 엔지니어가 파이프라인을 리뷰했고, 저는 그 리뷰를 바탕으로 파이프라인을 강화했습니다.

• 모든 데이터베이스 쿼리에 타임아웃이 있고, 모든 쓰기는 원자적입니다.
• 워커는 허용 목록에 있는 URL만 가져오고, 너무 큰 응답은 거부합니다.
• 의심스럽게 비어 있는 페이지는 바로 실패로 처리하고, 각 실패는 맥락과 함께 기록합니다.
• 자주 실행되는 경로에서 비용이 큰 COUNT(*)를 제거하고, 인덱스 유지 관리 도구를 추가했습니다.
• ECR 이미지와 CloudWatch 로그의 보존 정책으로 저장 비용을 낮게 유지합니다.

결과

• 500만/일목표치. 가장 작은 RDS 인스턴스로 테스트에서 달성
• 약 5,000/일프로덕션에서 데이터 소스의 제한이 허용한 속도
• 매일프로덕션에서의 수집, 저장, 알림
• 7개 브랜드회사의 가격 분석을 위한 수집 범위

배운 점: 파이프라인은 하루 500만 건의 매물을 처리할 수 있었지만, 데이터 소스는 그렇지 못했습니다. 소스가 속도 제한을 강화하자 지속 가능한 속도는 하루 약 5,000건으로 떨어졌고, 이것이 평소 운영 수준이 되었습니다. 이 규모에서는 인프라가 아니라 데이터 소스가 한계를 정하므로, 소스가 제동을 걸면 스스로 속도를 줄이는 백오프를 처음부터 설계에 넣어야 합니다.

이 페이지에는 회사 코드, 내부 데이터, 비공개 URL을 싣지 않았고, 데이터 소스의 이름도 밝히지 않았습니다.