대기업들처럼 웹 스크레이핑(Web Scraping)을 하고 싶다면 (2021)

 (incolumitas.com)
7P by GN⁺ | ★ favorite | 댓글 1개
  • AWS Lambda와 Headless Chrome만으로도 Google SERP를 주당 수백만 개 수집할 수 있었지만, 강하게 보호된 사이트 앞에서는 클라우드 기반 봇 구조가 쉽게 한계에 부딪힘
  • Lambda 재호출과 여러 리전을 활용하면 16개 리전 기준 약 16 * 250 = 4000개의 공개 IP를 동시에 쓸 수 있었고, 이는 느슨한 대상에는 충분했음
  • DataDome, Akamai, Imperva 같은 안티봇 업체는 브라우저 설정 불일치, 자동화 흔적, 지문 정보를 추적하며, 실제 난제는 탐지 자체보다 오탐률을 낮추는 것에 가까움
  • 더 덜 탐지되는 구조로 Docker나 클라우드 서버 대신 실제 Android 기기와 모바일 IP를 쓰는 방식을 제안하며, 4G/5G/LTE IP는 대도시의 많은 정상 사용자가 공유해 차단이 어려움
  • 실제 기기 농장은 기기 구매, 도시별 공간 임대, 현장 유지보수, 하드웨어 장애를 감수해야 하고, Android 에뮬레이터도 에뮬레이션 탐지 위험이 남아 있음

AWS Lambda로 만든 대량 스크레이핑 구조

  • 과거 스크레이핑 서비스 운영 당시 Google SERP를 주당 최대 수백만 개 수집했지만, Brightdata, Packetstream, Oxylabs 같은 프록시 제공업체는 쓰지 않았음
    • 같은 프록시 대역폭을 공유하는 다른 고객을 신뢰하기 어렵다고 봄
    • 공개 정보에 대한 비 DoS 스크레이핑은 괜찮지만, 광고 사기, 소셜 미디어 스팸, 자동 SQL injection, XSS 같은 웹 공격과는 선을 그음
    • 프록시 서비스 비용도 부담으로 작용했음
  • 실제 구성은 AWS Lambda에 Headless Chrome을 넣고, puppeteer-extra와 chrome-aws-lambda로 300초 동안 브라우저를 실행하는 함수였음
  • Google은 자체 검색엔진에 대해 봇 차단을 강하게 하지 않고 주로 IP 기준 속도 제한을 적용하므로, Google SERP만 보면 curl로도 가능했을 수 있다고 봄
  • Lambda에서는 함수 호출 3번 뒤 새 공개 IP를 얻고, 1000개 함수를 동시에 호출하면 약 250개 공개 IP에 도달했다고 함
    • 16개 리전을 쓰면 동시에 약 4000개의 공개 IP를 사용할 수 있었다고 계산함
    • 공유 데이터센터 IP였지만 Google SERP를 주당 수백만 개 수집하기에는 충분했음
  • Google Cloud Platform도 시도했으나, Google은 AWS 트래픽보다 자사 클라우드 인프라 트래픽을 더 강하게 차단했음
  • 이 경험은 2019년과 2020년 기준이며, 이후 상황은 바뀌었을 수 있음

클라우드 봇이 막히는 이유

탐지되기 쉬운 경제적 구조

  • 대량 스크레이핑을 하려는 봇 개발자는 브라우저를 Docker 컨테이너에 넣고 Docker Swarm이나 Kubernetes로 오케스트레이션하는 경우가 많음
  • 이런 봇은 Hetzner, AWS, DigitalOcean 같은 클라우드 제공업체에서 호스팅되는 일이 잦음
  • 이 구조는 인간 사용자의 환경과 크게 다름
    • 정상 사용자가 Hetzner VPS의 Docker 컨테이너 안에서 Instagram을 탐색하는 상황은 자연스럽지 않음
  • 성공적인 스크레이핑 규칙으로 두 가지를 제시함
    • 두 번째로 중요한 규칙: 브라우저 설정에 대해 거짓말하지 말 것
    • 가장 중요한 규칙: 들키지 않을 때만 브라우저 설정에 대해 거짓말할 것

실제 Android 기기 농장

  • 난독화된 안티봇 지문 채취 라이브러리를 역공학하기 어렵기 때문에, 실제 기기를 스크레이핑에 쓰는 접근을 제안함
  • 가정한 구조는 저가 Android 기기 500대를 사고, 지문 다양성을 위해 5개 제조사 정도에서 기기를 섞는 방식임
    • 저가 Android 기기는 대당 58달러부터 시작함
    • 한 번에 100대를 사면 큰 할인을 받을 수 있다고 봄
  • 각 기기에 저렴한 데이터 요금제를 붙이고, DeviceFarmer/stf로 제어함
  • London, Paris, Boston, Frankfurt, Los Angeles 같은 5개 주요 도시에 각각 100대씩 배치하고, 모바일 셀룰러 안테나가 가까운 저렴한 저장 공간을 임대하는 구상임
  • 기기에는 가벼운 Android Go를 설치하고 불필요한 요소를 제거한 뒤 전원에 연결함
  • 5분마다 비행기 모드를 켰다 끄면 4G Carrier Grade NAT를 통해 새 IP를 받을 수 있음
  • 모바일 IP 주소는 대도시에서 최대 수십만 명의 정상 사용자가 공유하므로 실질적으로 차단하기 어려움
    • 예시로 Instagram이 일부 스팸 사용자를 이유로 LA의 20만 명을 차단하지는 않을 것이라고 봄
    • CGN에서 IPv4 주소가 차단되면 전체 가입자 기반에 영향이 갈 수 있다는 Ofcom 문서를 인용함
  • IPv6는 주소 공간이 너무 넓어 대부분의 안티봇 업체가 IPv6 주소에 IP 평판을 거의 또는 전혀 부여하지 않는다고 봄

실제 기기 구조의 탐지 포인트와 운영 부담

  • 실제 기기를 바닥에 하루 종일 놓아두면 회전이나 움직임이 없는 상태가 지속되므로, deviceorientation과 devicemotion JavaScript 이벤트를 커널 수준에서 스푸핑해야 함
    • 웹사이트는 Android의 회전과 속도 데이터에 권한 요청 없이 접근할 수 있음
  • 이 문제를 제외하면 해당 구조를 봇 탐지 시스템이 어떻게 차단할 수 있을지 명확하지 않다고 봄
  • 운영 부담은 작지 않음
    • Android 기기 500대를 구매해야 함
    • 주요 도시에 저장 공간을 임대해야 하며 비용이 듦
    • 5개 도시에서 기기 농장 문제를 고칠 사람이 필요함
    • 하드웨어를 다뤄야 하며 지속적으로 문제가 생길 수 있음
  • 이런 구조는 큰 프로젝트가 되며, 유지보수에 수천 달러가 들 수 있다고 봄

Android 에뮬레이터라는 대안

  • 실제 Android 기기 대신 Android 에뮬레이터를 쓰는 편이 더 낫다고 봄
  • 비용은 줄일 수 있지만, 안티봇 업체가 에뮬레이션 환경을 찾아낼 수 있음
  • 가능한 탐지 방식은 여러 가지임
    • 브라우저 기반 red pill로 브라우저가 에뮬레이션 환경에서 실행 중임을 드러낼 수 있음
    • 브라우저 기반 포트 스캔으로 에뮬레이트된 Android 기기에서만 실행되는 포트나 adb 같은 서비스를 찾을 수 있음
    • Google이 모바일 기기 전체에 광고 ID를 설정할 수 있으며, 이 ID가 없거나 항상 같으면 의심 신호가 될 수 있음
    • Social Media Login Detection으로 Gmail이나 YouTube 계정 로그인 여부를 확인할 수 있고, Android에서 Google 계정 로그인이 없으면 의심 대상이 될 수 있음
    • 그 밖에도 에뮬레이트된 Android 기기 탐지 기술이 많이 있을 수 있음
  • Android 에뮬레이터는 불완전할 가능성이 높고, 그 불완전성이 모바일 브라우저의 방대한 JavaScript API를 통해 드러날 수 있음
  • 그래도 에뮬레이션 접근을 선호하며, 강력한 서버 몇 대에 4G 동글을 연결하는 구성을 제안함
  • proxidize.com은 4G 모바일 프록시를 제공하지만, 프록시는 그 자체로 탐지 가능하므로 Android 에뮬레이터에서 4G 동글을 직접 쓰고 싶다고 함
  • 최종 구조는 지역별 스크레이핑 스테이션 형태임
    • 한 지리적 위치에 4G 동글 50개가 연결된 강력한 스크레이핑 서버 1대를 설치함
    • 각 서버에서 50~100개의 에뮬레이트된 Android 기기를 실행함
    • 이런 스테이션을 5개 주요 도시에 배치함
    • 간단한 명령·제어 서버가 5개 스크레이핑 스테이션을 오케스트레이션함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들
  • 웹 스크래핑 분야에서 일하는 변호사로서 이런 스레드를 보면 늘 웃음이 남. 지금 우리가 기술 분야의 독점 기업으로 보는 거의 모든 회사나 그 계열사는 사업을 키우는 과정에서 스크래핑을 활용했고, 이제는 같은 회사들이 스타트업과 경쟁사의 데이터 스크래핑을 금지함
    그 데이터도 법적으로 인식 가능한 의미에서 실제로 “그들의” 데이터가 아닌 경우가 대부분임. 그래서 웹 스크래핑의 윤리도, 관련 법적 쟁점도 그렇게 단순하지 않음. 지난가을 이에 대해 쓴 글이 여기서도 관심을 받았음: https://news.ycombinator.com/item?id=37264676
    • Facebook과 신원 정보도 비슷함. 기억이 맞다면 Facebook은 초기에 Google 주소록을 활용해 성장했지만, 누군가가 Facebook 소셜 그래프 데이터를 장기 저장해 자기 울타리 밖에서 쓰려 하면 공격적으로 막음
      결국 자신들이 성장에 썼던 수법은 남들이 못 쓰게 막는 셈임
    • 웹 스크래핑의 윤리는 오히려 아주 간단해 보임. “당신은 내 HTTP 요청에 원하는 대로 응답할 수 있고, 나는 그 응답을 원하는 대로 해석할 수 있다”는 정도면 충분함
      인간의 의사소통이 시작된 이래 대화는 늘 이런 방식 아니었나 싶음. 반면 법적 쟁점은 기성 사업자를 국가 폭력의 위협으로 보호하기 위해 짜낸 천처럼 보이고, 별로 새롭지도 않으며 한심하지만 예측 가능한 부류임. 더 넓게는 이걸 지식재산권 문제로 포장하고 예술가와 창작자 보호에 붙이려는 시도도 논리적으로 매우 어색해서 눈살이 찌푸려짐
  • 예전에 전문 웹 스크래퍼였고 지금도 업계 흐름은 계속 따라가고 있음. 요즘은 웹 스크래핑 자체로 돈을 버는 게 아니라, 웹 스크래퍼에게 서비스를 팔아서 돈을 범
    웹 스크래핑 SaaS와 관련 서비스가 많고, 주거용 프록시 제공업체도 수십 곳 있음. 대부분의 봇 방지 메커니즘이 너무 빠르게 진화해서, 전통적인 소프트웨어 엔지니어링 역할 안에서도 봇 방지 우회 기술만 전담해 꽤 괜찮은 수입을 올릴 수 있음. 이런 변화 속도 때문에 웹 스크래핑을 직업으로 삼는 것보다 웹 스크래핑 회사에서 일하는 편이 더 안정적임. 스크래퍼는 프로젝트 단위로 돈을 받아 장기적으로 불안정하고, 고급 스크래핑에는 주거용 프록시와 서버 임대 같은 운영 투자가 필요하며, 저가 일감은 보수가 매우 낮음. Brightdata가 웹 스크래핑 컨퍼런스를 여는 것만 봐도 대규모 스크래핑 서비스 판매가 얼마나 수익성 있는지 알 수 있음
    • 스크래핑이나 대규모 봇 네트워크 운영에는 주거용 프록시가 필수라고 오래 생각해 왔지만 직접 써 본 적은 없어 실제 규모에서 어떻게 쓰이는지는 확인하지 못했음
      이런 용도로 보안이 취약한 IoT 기기나 악성코드에 감염된 소비자 하드웨어가 흔히 쓰이는지 궁금함. ISP와 협력해 주거용 IP를 확보하는 방식은 수익성이 있거나 가능할 것 같지 않아서, 주거용 프록시 서비스라면 꽤 은밀한 방식밖에 없어 보임
    • 일반적으로 스크래핑에 가장 가까운 컨퍼런스가 있다면 추천받고 싶음. 아는 한 스크래핑 전용 컨퍼런스나 강한 커뮤니티가 거의 없어서, 배우고 실력을 키우고 싶음
    • Upwork에서 수년 동안 스크래퍼를 작성해 왔는데, 프로젝트 기반 일에 지쳤고 스크래핑 SaaS에서 일하거나 직접 시작하고 싶음. 조언이 궁금함
    • 처음엔 이게 이렇게 쉬운 줄 모르고 코드를 오픈소스로 공개했음. GitHub는 Akamai 같은 곳이 DMCA를 빨리 보낼 것 같아서 피했고, 관할권 차이를 이용해 중국판 GitHub 비슷한 Gitee에 올렸음
      이 분야 배경은 없었지만, 회사들이 자랑해 놓은 내용을 맞춰 보면 어렵지 않았고 스포츠 베팅을 자동화하는 실용적 목적도 있었음. 실제 본업도 그쪽에 가까웠고, 20대 후반에 프로그래밍을 빠르게 배우는 데 도움이 됨. 그런데 거의 즉시 중국의 스니커 봇 운영자들과, 영어가 모국어가 아닌 듯한 특이한 영어를 쓰는 사람들에게 요청이 쏟아졌음. 법적 위협 때문이 아니라 고객지원 일이나 남 밑에서 일하고 싶지 않아서 코드를 내렸고, 요청 대부분이 “네가 일하면 수익은 나누자”는 식이라 누가 그런 제안을 받아들이는지 믿기 어려웠음. 인터넷은 영원하니 Cyberfed-Akamai 0.8~2.3을 흉내 내던 코드 일부는 아직 떠돌 가능성이 있음. 중간 20대에 프로그래밍을 배워 3년 안에 올린 코드가 통했다면, 그런 제품에 비싼 돈을 받는 사이버보안 회사들은 부끄러워해야 한다고 봄. 고등학교 2학년 이후 수학도 안 했고, ADHD 때문에 영상도 글도 오래 못 봐서 GitHub와 비슷한 서비스에서 베껴가며 작동할 때까지 배운 게 전부였음. 이 업계에는 아마 뱀기름 같은 솔루션이 많이 팔리고 있을 것 같음
    • 업계 흐름은 어떻게 계속 따라가고 있는지 궁금함
  • 이 문제에 대해 마음이 복잡함. 봇 방지 기술은 보안 연구에서 점점 큰 고통점이 되고 있고, 이 분야에서 일하다 보니 그런 시스템을 상대해야 함
    위협 행위자들이 Cloudflare 같은 서비스를 써서 악성 페이로드 접근을 막음. 브랜드 사칭이나 자격 증명 피싱을 찾고 탐지하려는 고객에게는 큰 문제인데, Cloudflare는 전혀 도움이 되지 않고 그냥 신경 쓰지 않음
    • 동의함. 위협 행위자들이 무료 Cloudflare 계정을 만들고, 생성된 지 2시간 된 도메인의 피싱 사이트를 200억 달러짜리 회사가 뒷받침하는 보호막 뒤에 숨길 수 있게 되면서 탐지를 피하는 일이 너무 쉬워졌음
      Akamai 뒤에서는 피싱을 거의 못 보는 게 재미있음. 우리도 이 분야에서 일하므로 앞으로도 이런 위협을 탐지할 수 있어야 하는 이해관계가 있음
    • 결국 이 문제를 풀기 위해 어떤 형태의 소액 결제 메커니즘에 도달하게 될 것 같음
  • “부적응자”와 “정상인”이라는 표현은 이상함. 이런 일을 하는 이유는 지루한 회사용 React 웹사이트를 스무 번째 만드는 것보다 훨씬 흥미롭고 재미있기 때문임
    실제 현실의 문제를 풀고 뭔가를 하는 새로운 방법을 찾아야 해서 재미있음. 익스플로잇 개발도 마찬가지임. 이런 사람들은 부적응자가 아니라, 자신이 열정적인 일을 하는 정상적인 사람들임. “내가 싫어하는 일을 하는 사람은 부적응자”라는 사고방식이야말로 완전히 이상함
    • 그 문단 전체는 농담임. 끝에 작은 윙크가 붙어 있는 이유가 그거임
  • 봇 방지 기술은 보안 위협이자 프라이버시 위협처럼도 보임. 가상 머신을 쓰면 사이트 접근을 막거나, 포트 스캔을 하거나, 여러 형태의 지문 채취를 하기 때문임
    • 새 방문자에게 CPU 연산을 쓰게 하는 알고리즘 과제 방식이 더 좋음
      절차가 명확하고, 프라이버시 위험이나 이상한 꼼수도 없으며, 실패하더라도 사람이 적어도 보고 신고할 수 있는 방식으로 실패함. 알 수 없는 장애처럼 보이는 것보다 낫음
  • 당시에도 논의됐음: Scrape like the big boys - https://news.ycombinator.com/item?id=29117022 - 2021년 11월, 댓글 189개
  • “모든 웹사이트가 권한 요청 없이 Android의 회전 및 속도 데이터에 접근할 수 있다”고? 이건 정말 말도 안 됨
  • 흥미로움. 지금 낮은 빈도의 스크래핑이 필요한 프로젝트를 만들고 있음
    거부되는 경우를 어떻게 처리할지 고민 중이었는데, 저렴한 Android 기기 한 대가 빈틈을 메워 줄 수도 있겠음
답변달기