1. (Requests + BS) VS 셀레니움

selenium.png

Requests로 데이터를 긁어오고 BS로 파싱하는것만으로도 웬만한 사이트의 정보는 크롤링이 가능하다.

하지만 해당 방식은 브라우저단에서 사이트에 접근하여 데이터를 받아오는것이 아니라, 단순히 사이트에 Http 통신을 보내 배포하고있는 웹 Html문서를 받아오기만 하는 것이기 때문에 브라우저에서 사용자의 입력에따라 동적으로 반응하며 정보가 랜더링되는 부분에 대한 크롤링에는 한계가 존재한다.

또한 특정 사이트들은 크롤링 해가는것을 막기 위해서 브라우저단에서 사이트에 접근하는 통신(Requests 모듈을 이용한 통신같은 경우)이 아닌 경우에는 해당접속요청을 차단하기도 한다.
(물론 조작된 헤더정보와 쿠키값을 담아서 적절하게 넘겨주면 웬만해선 Requests로도 접속차단을 뚫을 수도 있겠지만 아무튼 번거롭다)

위와 같은 상황에서의 크롤링에는 셀레니움 모듈을 이용할 수 있다. 셀레니움은 웹드라이버를 이용하여 웹브라우저를 원하는 방향으로 조작할 수 있다. 즉 크롤링을 하고자하는 주소로 브라우저를 실제로 동작시켜 접근하고 원하는 데이터를 가져오는 것이다. 실제로 브라우저 하나가 켜져있는 것이기 때문에, Requests 모듈을 이용하는 것보다 속도도 느리고 자원을 더 먹긴하지만 사이트에서 더 안정성있게 자료를 긁어올 수 있다.


Requsts 모듈을 이용해서 통신한 기록

파이썬 request.png

Selenium 모듈을 이용해서 통신한 기록

셀레니움.png

수동으로 브라우저를 이용해서 통신한 기록

실제 브라우저 접속.png

3가지 버전의 통신기록을 살펴보면, Requests 모듈을 이용 시 요청 헤더의 정보가 많이 생략돼 있음을 볼 수 있다. 하지만 셀레니움과 수동으로 실제 브라우저를 이용하여 사이트에 접근한 경우는 두 통신기록의 주요 내용이 완전 같다.

웹드라이버로 구동시킨 크롬 브라우저 사진첨부

자동화 소프트웨어.png

2. 재고사이트는 셀레니움? Requests?

현재 서비스하고 있는 재고사이트는 오로지 Requests 모듈만을 이용해서 데이터를 받아온다. 셀레니움을 이용해서 데이터를 가져왔을 때와 Requests를 이용해서 데이터를 가져왔을 때, 두 방식의 속도차이를 비교해보니 눈에 띌 정도로 큰 차이가 발생했었다. 셀레니움을 이용했을때 대략 4~5초 정도 더 느렸다. 셀레니움은 브라우저가 켜지고 사이트에 접근하는것까지 너무 많은 시간을 잡아먹는다. 웹 서비스의 쾌적함을 고려해봤을때 아무래도 못써먹겠다 라는 생각이 들었다.

하지만 데이터를 전부 Requests 모듈을 이용해서 가져오기에는 또 문제가 존재했다.
우리 사이트는 네이버 Book 검색 포탈에서 데이터를 가져오는데, 포탈에서 일부 책들에 대한 Http 접근이 올바르게 이루어지지 않았다. 어떤 책은 잘가져오는데, 어떤 책들은 못가져온다. 쉽사리 이유를 찾을 수 없었다.

3. Requests 크롤링 오류해결 과정

원인을 찾아내기위해 요청을 보낼때 User-Agent 정보를 헤더에 담아보기도하고, 쿠키값도 담아보기도하며 이런저런 트러블 슈팅을 해봤다.

그 결과 알아낸 정보는,

1. 접근이 거부되는 책들은 오디오북이 존재하는 책.

2. 오디오북이 존재하는 책의 링크에 접근하는 경우 리다이렉션(302)이 일어난다.

3. 리다이렉션이 일어난 주소에 접근시 상태코드 500(서버오류)를 받으며 정보를 받아오는데 실패한다.

오디오북이 존재하는 책들은 해당 html에 특정 스크립트가 작동하고 있는 것으로 추정하고 따라서 리다이렉션이 일어나는 것까지는 납득이가도 왜 리다이렉션된 링크에 올바르게 접근할 수 없는지가 의문이었다.
(리다이렉션은 또다른 주소로 새롭게 이동하는 것이 아니라, 완전히 동일한 주소로의 재이동이었는데 HTML 랜더링 갱신? 정도로 추측하고 있다)

우선 결론부터 말하자면 결국 해당 문제는 해결했다. 오디오북 주소에 브라우저로 수동으로 접근하면서 패킷정보를 확인하고, 해당 패킷에서 발견된 모든 요청헤더를 담아 보내봤더니 정상적으로 접근이 가능해지더라..
(정확하게는 요청 헤더정보에 Accept-Lagauage가 존재하지 않으면, 상태코드 500를 받게된다)

가장 우선적으로 확인했었야하는 접근법이었는데, 이상한것만 찾아보다 뺑뺑 돌고서 이렇게 정답을 찾으니 뭔가 .. 허무하면서도 ... 그래도 기뻤다 ㅎㅎㅎ

문제점에 봉착해서 문제를 해결하는데 시간을 많이 소모하긴했지만, 그래도 덕분에 여러정보를 다시한번 공부해보게 된 좋은계기 였었다.
(쿠키/세션, GET/POST 통신, Http 프로토콜 특성 등등. 이 항목에 대해서는 다른문서에서 추가적으로 기술할 예정 --> 링크 https://velog.io/@dlsghl92)

여담이지만 이 문제에 대한 해결은 사실 나보다는 같이 작업한 지인 분의 도움이 컸다. 오디오북이 존재하는 책들만 접근이 거부되고 있다는 그 쉽게 알아차리기 힘든 미묘한 정보를 알아차린 것부터가 다시금 생각해봐도 놀랍다. 통찰력이라구 해야하나.. ㅋㅋㅋ


관련사진첨부

123123.png

213123.png