maengsanha/instacrawler

Now on optimizing: Change parsing method and Pipelining

maengsanha opened this issue · 1 comments

maengsanha commented

최적화 작업 중 - 당분 간은 인스타그램 크롤러 서버 이용 불가

​ init과 next의 작업이 거의 동일해지므로 Crawl이라는 하나의 함수로 통일 가능해보임

​ 긴 문자열을 2번 Split하는 과정이 생략되므로 코드 복잡도와 처리 시간 양면에서 이득을 볼 수 있음

  • 2. 고루틴 간 통신 - 파이프라인 패턴

    기존의 방법 - sync 패키지와 indexing으로 write 시 병렬 처리의 race condition 해결

    이 때 고루틴 간 소통이 원활하지 않을 가능성이 있고 코드가 복잡해짐.

​ 새로운 방법 - 채널을 통한 파이프라인 패턴 구현

​ 고루틴 간 소통 문제를 해결하고 race condition도 해결하며 코드도 단순해짐

  • 3. 404 Error 발생

    1, 2 번 작업 후 테스트 후 추가적으로 논의

maengsanha commented

✅ Conflict Fixed

  1. Resolved Latency

​ 👉🏻 Pagination Caching

  • /api/v1/crawl 의 Request, Response에 end_cursor 값을 포함시켜 캐싱
  • 크롤링 갯수의 한계와 크롤링 지연 시간을 동시에 해결
  • 모바일 FE에서 스크롤이 최대까지 내려가면 모바일 BE가 업데이트된 end_cursor 값을 포함하여 다시 검색 서버에 요청, 해당 pagination부터 다시 크롤링 수행
  • end_cursor 값이 비어있을 때 has_next_page가 true라면 크롤링 시작이고, false라면 마지막 pagination까지 크롤링한 것이므로 중단
  1. Resolved 404 Error (Page Not Found)

​ 👉🏻 Pagination Caching

  • end_cursor 값을 캐싱함으로써 어디까지 크롤링했는지 알 수 있으므로 status code가 200이나 429가 아닐 경우 해당 pagination부터 다시 크롤링을 수행, 404 에러가 발생해도 성공할 때까지 시도할 수 있음
  • 404 에러가 아주 자주 발생하는 건 아니므로 최대 재시도 횟수를 3번 정도로 제한하고, 그 이상 실패하면 인스타그램의 난독화 매커니즘 발동 시간에 물린 것으로 판단, 처음부터 다시 크롤링 시도
  1. Optimized Code

​ 👉🏻 OOP → FP

  • Crawler 구조체를 삭제하고 Closure를 활용, CrawlerGenerator 정의
  • CrawlerGenerator에 Crawler가 저장하던 필드를 bound시키고 CrawlGenerator에 의해 생성된 함수 리터럴을 사용함으로써 Crawl 함수가 Code 영역에서 차지하는 메모리를 절약 가능
  • 함수 리터럴을 사용하므로 meta.Search 함수도 단순해짐