크롤링 IP 제한, 이렇게 뚫었다! 나만의 해결 여정

1. 문제 정의

처음 뉴스 데이터를 크롤링할 때, 하나의 고정된 IP로 다수의 요청을 보냈더니 IP 제한에 걸려 원하는 데이터를 안정적으로 수집하지 못하는 상황에 직면했습니다. 이를 해결하기 위해 처음에는 두 가지 방법을 시도했습니다.

2. 시도된 해결 방법

2.1 프록시 서버 사용

• 시도 배경: 크롤링 트래픽을 분산하기 위해 프록시 서버 IP를 활용하려 했습니다.
• 문제점:
  • 비용 부담: 신뢰할 만한 프록시 IP 제공 서비스는 가격이 비쌌습니다.
  • 신뢰성 문제: 불안정한 프록시로 인해 데이터 수집의 안정성이 낮아졌습니다.

2.2 네이버 API 활용

• 장점: 네이버에서 제공하는 공식 API를 사용하면 안정적으로 데이터를 수집할 수 있었습니다.
• 단점:
  • 날짜 제한: 특정 날짜 이후의 뉴스 데이터는 제공되지 않아 완전한 데이터 수집이 불가능했습니다.
  • API 호출 제한: 특정 횟수 이후로는 요청이 불가능했습니다.

처음에는 2.2의 방법을 활용했는데 시간이 지나갈 수록 데이터가 적은 것은 치명적이라고 생각이 들었습니다. 따라서 이를 해결하기 위해서 더 좋은 방법을 고민해야만 했습니다.

여담으로 API의 호출 제한의 경우 회피할 수 있는 방법이 존제하기 때문에 그렇게 큰 문제는 아니었습니다.

---

3. 서버리스 기반 크롤링 아키텍처 도입

기존 방식의 한계를 극복하기 위해 AWS의 서버리스 솔루션을 활용한 새로운 아키텍처를 설계했습니다. 카프카 연동 작업 중 람다(Lambda)를 활용한 아이디어가 떠올랐고, 크롤링 제한을 회피할 수 있는 방안을 구체화했습니다.

3.1 아키텍처 옵션

① API Gateway + Lambda

• 장점: 요청과 응답이 동기식으로 처리되므로 구현이 간단하고 실시간 처리가 가능합니다.
• 단점: 대량 트래픽이 발생할 경우 성능 문제가 있을 수 있으며, 메시지 유실 방지에 대한 추가 처리가 필요합니다.

② SQS(SNS) + Lambda 조합

• 장점:
  • 대량 트래픽 처리에 최적화: SQS가 메시지를 큐에 저장하므로 트래픽 피크 상황에서도 유실 없이 안정적인 처리 가능.
  • 비동기 방식: Lambda가 메시지를 비동기로 처리하여 확장성이 높습니다.
• 선택 이유:
  • 대량 트래픽 처리와 안정성이 중요했기 때문에 SNS 대신 SQS를 선택했습니다.
  • 메시지 유실 위험성을 줄이고, 효율적인 비동기 처리가 가능했습니다.

4. 최종 아키텍처

• AWS SQS: 크롤링 요청 메시지를 큐에 저장.
• AWS Lambda: 큐에서 메시지를 읽어와 비동기로 처리.
• Lambda 함수 역할:
  1. 네이버 API 호출 또는 크롤링 실행.
  2. 데이터를 가공 및 저장.
• 결과:
  • 대량 트래픽 처리 시에도 안정적이고 유실 없는 데이터 수집 환경 구축.

5. 결론

이번 프로젝트를 통해 프록시 IP 사용 → 네이버 API → 서버리스 아키텍처로 전환하면서 크롤링 문제를 효과적으로 해결할 수 있었습니다. 특히 SQS + Lambda 조합은 비용 효율적이고, 안정성과 확장성을 동시에 확보할 수 있는 훌륭한 선택이었습니다.

 

최종 결과

아래는 서버리스 아키텍처를 활용하여, 기존에는 403 Forbidden 오류로 막혔을 상황도 성공적으로 해결한 상황입니다: