오늘 배운 것

웹 크롤링을 위한 사전지식

Server & Client Architecture

• Client : 서버에 데이터를 요청하는 서비스 사용자 또는 사용자의 디바이스
• Server : 요청에 따라 데이터를 전송

URL 구조

• 예시 : http://news.naver.com:80/main/read.nhn?mode=LSD&mid=shm&sid1=105&oid=001&aid=0009847211#da_727145
  • http:// : 프로토콜
    프로토콜 : 데이터를 주고 받을 때 데이터가 어떤 형태로 되어있는지 정한 규칙
  • news.naver.com : 도메인
    도메인을 바탕으로 DNS서버에 접근하면, DNS 서버가 127.0.0.1 과 같은 IP주소로 변환하여 해당 주소의 서버로 접근한다.
  • :80 : 포트
    한 서버에 여러 서비스를 제공하는 경우가 많아, 포트를 통해 어떤 서비스에 접근하는지 구분한다. 웹서비스의 경우 주로 80번, 443번을 사용하며 url에서 생략이 가능하다.
  • /main/ : path
    서버도 로컬 컴퓨터처럼 디렉토리와 파일이 트리처럼 저장되어 있는데, 여기서 path가 디렉토리 역할을 한다.
  • read.nhn : file
    main 디렉토리에 있는 read.nhn파일을 말한다. 여기서 확장자는 nhn이지만 실제로는 HTML 파일로 작성되어 있을 가능성이 높다.
  • ?mode=LSD&... : query
    Client에서 Server에 GET 형식으로 데이터를 보낼 때 사용하는 쿼리스트링이다.
  • #da_727145 : fragment
    동일한 웹페이지 내에서 특정 위치를 지정하는 역할을 한다.
    웹크롤링에서는 잘 사용되지 않는다.

GET & POST

웹서버에 요청하는 두가지 방식이다

• get : URL에 데이터를 포함하여 전송
  • 데이터가 노출되므로 민감한 데이터를 전송하면 안된다
  • 길이 제한이 있다 (브라우저에 따라 상이)
• post : URL을 body에 담아 전송

OSI 7계층 (필요한 개념만 간단하게)

• 통신 과정을 7단계의 계층으로 나눈 것이다.
• 우리가 원하는 데이터는 1Byte라도, 프로토콜 종류, ip주소, 전기적 신호 전송 방식 등 다양한 정보를 담아서 보내야하기 때문에 훨씬 더 많은 데이터를 사용해야 한다.
  • 이렇게 추가적으로 붙는 것을 payload라고 하며, 더 하위계층일수록 payload가 증가한다.
  • 가능한 적은 요청으로 한번에 많은 정보를 받는 것이 자원 절약의 핵심이다.

Cookie & Session & Cache

• Cookie

  • 보조기억장치(또는 브라우저)에 저장되는 데이터
  • 브라우저 당 최대 300개, 도메인 당 최대 20개까지 저장이 가능하다.
  • 쿠키 하나의 크기는 4KByte이다.
  • 맞춤형 광고, 사용자 맞춤 서비스 등에 사용된다.

• Session

  • Server에 저장되는 데이터
  • 동일 브라우저로 동일 서버(도메인)을 방문할 경우 만료되기 전까지 항상 동일한 Session ID를 갖는다.
  • Session ID와 쿠키를 이용해 자동 로그인 기능 등을 사용할 수 있다.

• Cache

  • Client나 Server의 메모리에 저장하여 빠르게 데이터를 가져올 수 있는 저장소
  • 동일 데이터를 반복 요청할 경우 Server까지 요청하지 않더라도 저장된 캐시를 바로 꺼내오는 등 속도가 매우 빨라진다.
  • 브라우저를 종료하면 사라진다.

Status Code

데이터를 주고 받은 결과를 나타내는 코드

• 2XX (sucess) : 요청과 응답이 성공적으로 이루어짐
• 3XX (redirection) : 서버까지 요청이 가지 않고 캐시 등 저장된 데이터를 이용해 처리 함
  • 2XX와 동일하게 요청이 성공적으로 수행되었다는 의미이다
• 4XX (req error) : 클라이언트에서 잘못된 요청을 보냄
  • 유효하지 않은 도메인 접근, 접근이 금지된 서버에 요청 등이 있다.
• 5XX (server error) : 요청 처리 중 서버 쪽에서 에러가 발생하는 등 응답이 되지 않음

정적 페이지 & 동적 페이지

• 정적 페이지 : 이벤트에 의한 화면 변경이 없는 페이지로, 다른 화면을 보기 위해서는 URL이 변경되어야 한다.
  • HTML 파일을 통해 데이터 전송이 이루어지므로, HTML 문자열을 파싱해야한다.
• 동적 페이지 : 이벤트를 통해 서버에서 필요한 데이터를 받아와 화면을 변경하는 페이지
  • URL 변경 없이 추가적인 데이터를 불러오는 등 변동이 가능함
  • JSON(드물게 XML)을 이용하므로 주로 JSON을 파싱해야한다.

selenium

• 크롤링 방지 기술이 적용되어 GET, POST 등 request를 통한 접근이 아예 불가능 할 경우, 실제 브라우저를 직접 열어서 파이썬 코드로 컨트롤하며 데이터를 받아 올 수 있다.
• 속도가 느리다는 단점이 있다. (json > html > selenium)

웹 크롤링 실습

흐름

1. 크롤링을 위한 url 획득
2. requests를 보내어 문자열 취득
3. 문자열을 파싱하여 JSON으로 변환
4. JSON을 딕셔너리 또는 리스트로 변환
5. DataFrame으로 변환하여 데이터화

실습 중 새로 배운 내용

• header

  • 파이썬을 통해 requests를 보내면, 전송되는 요청의 headers 정보에 python이라는 것이 표시된다.
  • 크롤링은 트래픽에 부담을 주므로 이러한 경우 대부분의 웹사이트에서 블록한다.
  • 이 경우, 직접 header를 지정하고, 정상적인(?) 유저인 것처럼 요청을 보내야 한다.
    

• 함수화

  • 크롤링 과정 코드를 함수화하면 손쉽게 반복작업을 할 수 있다.

• 크롤링 후 데이터 전처리 및 시각화

  • 데이터를 받아오면 끝이 아니라 분석을 위한 적절한 데이터 전처리가 중요하다.
  • 전처리 후 시각화 및 탐색적 데이터 분석을 통해 인사이트를 도출 할 수 있어야 한다.

크롤링의 위험성

• 대부분의 웹페이지는 크롤링 정책을 갖고 있다. (url/robots.txt에 접근하면 볼 수 있다)
• 크롤링 정책의 법적 강제성은 없지만, 과도한 크롤링으로 서버에 영향을 주거나 지적재산권 침해, 개인정보 관련 등의 사유로 처벌을 받을 수 있으니 유의하여 크롤링을 진행해야 한다.
  

API 실습

API는 데이터를 가지고 있는 업체에서 데이터를 쉽게 가져갈 수 있도록 제공하는 서비스이다.
제공자가 직접 제공하므로, 크롤링에 비해 훨씬 안전하고 데이터 획득이 쉽다.

코멘트

• 잠깐 버그가 나거나 진도를 놓치면 따라잡기 어려울 정도로 정신없는 수업이었다.

• 하지만 그만큼 재밌는 주제였고, 신나게 따라할 수 있었다.

• 최대한 실습 코드를 보지 않고 복습을 진행하였는데, 다행히 진도를 놓치지 않은 것 같다 다행이다.

• 중간중간 주어지는 강사님의 꿀팁도 큰 도움이 되었다. 이 중에서 추가로 공부하고 싶은 것은 이번 주말에 따로 정리해서 TIL을 작성할 것이다.