분산처리가 되는 파이썬 수집 시스템을(웹 데이터수집 : 크롤 )

인터넷에 존재하는 유용한정보와, 실제 프로젝트진행한 경험을 바탕으로

요약을 해 보았습니다.

공통 파이썬 모듈

로컬에서 동시성 처리

우선 파이썬 내부에서 1노드에서 동시성처리를 위해(여러개의 요청을 동시에처리)

다음과 같은 선택가능합니다.

다음과 같은 장단점이 있습니다. 스레드모델은 공유접근에 대한 문제를  스레드 모델로

풀어야하기때문에 어려워질수 있습니다. 코르틴은 복잡한 진행/완료 처리를 하다보면

콜백헬에 빠질수 있습니다.  액터모델은 액터자체로 원격처리 가능한 메시지처리

기반이기때문에 순수한 로컬에서만 사용한다면 쓸데없이 어려워질수 있습니다.  

실행계획

리눅스에서 일반작동코드를 데몬화 해주는 pm2를 통해 윈도우 서비스처럼 구동시킬것입니다.

pm2는 파이썬 스크립트뿐만아니라, node.js / 도커실행등도 지원하는 마이크로서비스를 위해

리눅스에서 편리하게 데몬화 시킬수 있는 녀석입니다.

아마존이나/애져에 실행하고 싶으면 클라우드서비스가 제공하는 API를 사용하면되겠으나

여기서는 직접 서버를 준비하고 구동하는 설치형으로 진행하겠습니다. 

https://www.npmjs.com/package/pm2

만약,  크롤모듈중 닷넷 코어를 사용해 c#코드를 리눅스에 실행계획이 있다고 하면

pm2와 유사한 스펙인

https://topshelf.readthedocs.io/en/latest/configuration/quickstart.html

이것을 이용하면 되겠습니다.  과거에는 개발자가 서비스혹은 데몬에 올리는 프로그램을 직접

개발하여 컨트롤 하였지만, 지금은 간단하게 이용가능한 모듈들이 많이 있습니다.

수집모듈

수집 방식은 3가지로 분류 할수 있습니다.  우선 요청시, 일반적으로 API를 통해 JSON결과값을 수집하여

분석해야할시 Request만으로 충분합니다. 이방식이 가장 간편하고 성능이 빠릅니다. 여기서 성능이라하면

상대 편 응답속도가 일정하다라고 가정을 한것입니다.

Request로만으로 모든 정보를 획득할수 있다면 이방식만 사용합니다. 하지만 대부분 그렇지 않은경우가 많으며

두번째, 대부분의 웹정보는 착하게 API형태로 정보제공을 하지 않는경우가 많거나, Html의 태그가 아주 복잡하게 구성되어 있어서

태그분석 헬에 빠질수 있습니다. 그경우 지저분한 html tag를 이쁘게 데이터로 만들어주는 BeautifulSoup을 이용합니다.

이것역시 Request와 조합이 되어야하며, 추가적인 html분석이 필요하기 때문에 성능이슈는 약간 증가하였습니다.

세번째, 요즘 대부분의 웹페이지는 요청한번에 페이지에대한 모든정보를 주는게 아닌, 내부 Ajax처리를 통해

화면 갱신을 합니다. 그러면 Request+BeauifulSop조합만으로는 Ajax에의해 최종 갱신된 UI정보 추출이 불가합니다.

이때 브라우져 엔진을 사용하며, 수집타이밍을 사용자 UX에 맞게끔 트리거 작동을 시킬수 있습니다.

예를 들면, 로딩 DIV태그가 사라지고 1초뒤(이때가 정보를 수집할 데이터가 모두왔다고 트리거정의) 수집을해라

이러한게 가능합니다. 이것의 성능이 제일느리지만 , QA수준의 테스트툴에 사용되는 모듈이기때문에 어쨋건

수집방식의 타이밍이 가장 직관 적입니다.


단일수집 노드에 극단적인 스케일업을 해서,  수집성능을 최고로 올리는것은 권장 되지 않습니다.

단일지점 네트워크 트래픽 문제, 블락문제등 여러가지 문제가 있기때문입니다. 

Request량을 최대한 안정적인 범위내에 조절가능한 수준으로만 해놓습니다.



 그럼이제 1노드에대한 수집처리를 어떻게할지 선택지가 풍부 해졌으니, 이것을 어떻게 분산처리를 할것인가?

에대해 고민을 해보겠습니다. Type A/B로 구분하였습니다.  어떻게 조합하고, 자신의 서비스에 더 적합한지

차이이지 조합에따라 여러가지 Type구성이 가능합니다.


Type A


DB Read/Write는 아주 일반적이고 선택가능하기 때문에 언급을 하지 않겠습니다. 

크롤량이 많고 크롤해야할 노드가 많이 늘어난다고 가정해봅시다. 크롤이 모두 DB커넥션을 맺게되고

대량의 처리결과를 DB에 한꺼번에 푸시하게된다면 서비스 DB는 힘들어 할것입니다. 

그래서 크롤은 분산 메시지 시스템인 Kafka에게만 연결시키고 ( 실제는 클러스터처리를위해 주키퍼에 연결됨  )

안정적으로 StoreDB에 공급을 할것입니다.


KAFKA 아키텍쳐 : http://epicdevs.com/17

사용되는 모듈 : http://kafka-python.readthedocs.io/en/master/apidoc/KafkaProducer.html#

활용사례 : http://www.ciokorea.com/news/27214

내부정리 자료: kafka with akka


Kafka에대한 소개는 논외로 하겠습니다.(인터넷에 자료 많으며 대용량데이터 중간 장치로 많이 사용됨)


Type B


SparkStream(API)와 고성능 분석처리까지 할수 있는 Spark를  사용하여 KAFKA와 DB사용을 단일화 하였습니다.

Spark을 기본으로 설치하면( 클러스터구성은 약간의 설정및 노력이필요) 위와같은 패키지가 기본적으로 

포함되어 설치가됩니다. Kafka를 안정적인 중간 전송 모듈로 상호운영을 해도 되지만 여기서의 핵심가치는

대량의 데이터를 스트리밍으로 빠르게 저장하고 / 그것을 어떻게 분산컴퓨팅을 이용하여 간결한 코드로 분석할것인가에대한

중요한 솔류션을 한방에 제공해준다란것입니다. 

더 자세한 설명은 링크로


사용모듈 : https://www.datacamp.com/community/tutorials/apache-spark-python

이용사례 : http://engineering.vcnc.co.kr/2015/05/data-analysis-with-spark/

내부정리자료 : spark on centos

크롤을 통한 연구 과제

초기 크롤은 단순하게 Request하여 분석하여 저장하는것이였으나  

크롤을 통해 동시성데이터처리 / 대용량데이터처리/ 대용량데이터 분석등의 솔류션을 살펴보았습니다.

요즘은  대용량 트래픽처리을 어떻게 받아줄것이냐?,대용량으로 저장된 데이터를 어떻게 빠르게 분석할것이냐?

에 확장이되고.. 더 나아가 기계학습을 시키기위한 준비단계로 사용이되고 있습니다.

크롤이 단순한 수집기술을 넘어, 서비스보다 더 많은 스트림처리를 하고 더 복잡한 분산 처리능력을 사용하고 있습니다.

그런 의미에서 완전한 크롤링 서비스를 한셋트를 만드는것은 대용량 분산처리 개발경험에 도움이 될것으로 생각이됩니다.


또한 위에서 언급한 수집모듈및 저장솔류션은 그 어떠한것으로 대체가가능합니다.  예를들면 나노시스템을 위해서

파이썬을 선택을 했다고하면,  닷넷 코어 모듈로 작성하는게 파이썬보다 훨씬 가벼울수있으며 대체가능합니다.

메시지 처리를 위해 Kafka외에 ActiveMQ/RabbitMQ등 익숙한것을 선택할수도 있습니다.

또한 단일 기술을 사용해서 모두 구현하는 옵션도 있습니다. ( https://github.com/psmon/psmonSearch )




  • No labels
Write a comment…