Pythonクローリング&スクレイピングの初版の詰まりどころ
Pythonクローリング&スクレイピングの初版(表紙の文字が青い本)は2017年に出版され、現在では動かなくなってしまったコードもあります。

そこで初版を手にしてくださった方のために、主な詰まりどころと対策をまとめておきます。初版のサポートページには細かな変更点も記載されているので、合わせてご確認ください。
2章(2.4以降) urllibで403 Forbiddenになる
問題
Webサイト側の変更により、2.4以降のコードを実行すると403 Forbiddenとなってしまいます。
対策
注釈やサポートページに記載があるように、 https://gihyo.jp/dp を http://sample.scraping-book.com/dp に置き換えて実行してください。
5.3 Excelファイルなどのデータ構造が変わっている&新しいpandasだと動かない
問題
公開されているExcelファイルなどの構造が当時から変更されており、そのままのコードでは意図した通りの結果が得られないところがあります。また、pandas 0.24以降では一部挙動が変わっており、途中で動かない部分があります。
対策
増補改訂版のサンプルコード の 5-3 を参照してください。
5.5.2 Amazon.co.jpへのログインができなくなっている
問題
Webサイト側の仕様が変わり、RoboBrowserでログインしようとするとCAPTCHAが表示されてしまいます。
対策
次の記事で、SeleniumとHeadless Chromeを使ってAmazon.co.jpの注文履歴を取得する方法を解説しているので、参考にしてください。
Headless Chromeの使い方については、次項目の対策を参照してください。
5.6 PhantomJSの開発が終了した
問題
PhantomJSは開発が終了したため、現在ではHeadless Chromeなどを使うことが推奨されています。macOSでは書籍に記載通りのコマンドでインストールできなくなっています。
対策
次の記事でPhantomJSの代わりにHeadless Chromeを使う方法を解説しているので、参考にしてください。
また、増補改訂版のサンプルコード の 5-6 も参照してください。
6章全般 Spiderで意図した通りにデータを抜き出せない
問題
Webサイト側の変更で、動かなくなっているコードがちらほらあります。
対策
増補改訂版のサンプルコード の 6-* を参照してください。
最後に
増補改訂版ではこれらの問題に対応済みで、解説も新しくなっています。初版にはなかった新しいトピックも追加されているので、よろしければ是非お買い求めください!
SeleniumとHeadless ChromeでAmazonの注文履歴を取得する
Pythonクローリング&スクレイピングの初版ではAmazonの注文履歴を取得するサンプルコードを掲載していました。増補改訂版の執筆の際、RoboBrowserのようなJavaScriptを扱えないクローラーではログインが難しくなっていたので、対象のサイトを変更しました。
せっかくなので、SeleniumとHeadless Chromeで書き直したコードを紹介します。
import os import logging from selenium.webdriver import Chrome, ChromeOptions, Remote from selenium.webdriver.common.keys import Keys from selenium.common.exceptions import NoSuchElementException logging.basicConfig(level=logging.INFO) # 認証の情報は環境変数から取得する。 AMAZON_EMAIL = os.environ['AMAZON_EMAIL'] AMAZON_PASSWORD = os.environ['AMAZON_PASSWORD'] options = ChromeOptions() # ヘッドレスモードを有効にするには、次の行のコメントアウトを解除する。 # options.headless = True driver = Chrome(options=options) # ChromeのWebDriverオブジェクトを作成する。 # Windows上の仮想マシンの場合は、前の行をコメントアウトして、 # 次の行のコメントアウトを解除する。Remote()の第1引数はゲストOSから見たホストOSのChromeDriverのURL。 # driver = Remote('http://10.0.2.2:4444', options=options) def main(): # 注文履歴のページを開く。 logging.info('Navigating...') driver.get('https://www.amazon.co.jp/gp/css/order-history') # サインインページにリダイレクトされていることを確認する。 assert 'Amazonログイン' in driver.title # name="signIn" というサインインフォームを埋める。 # フォームのname属性の値はブラウザーの開発者ツールで確認できる。 email_input = driver.find_element_by_name('email') email_input.send_keys(AMAZON_EMAIL) # name="email" という入力ボックスを埋める。 email_input.send_keys(Keys.RETURN) password_input = driver.find_element_by_name('password') password_input.send_keys(AMAZON_PASSWORD) # name="password" という入力ボックスを埋める。 # フォームを送信する。 logging.info('Signing in...') password_input.send_keys(Keys.RETURN) # ページャーをたどる。 while True: assert '注文履歴' in driver.title # 注文履歴画面が表示されていることを確認する。 print_order_history() # 注文履歴を表示する。 try: link_to_next = driver.find_element_by_link_text('次へ') # 「次へ」というテキストを持つリンクを取得する。 except NoSuchElementException: break # 「次へ」のリンクがない場合はループを抜けて終了する。 logging.info('Following link to next page...') link_to_next.click() # 「次へ」というリンクをたどる。 driver.quit() # ブラウザーを終了する。 def print_order_history(): """ 現在のページのすべての注文履歴を表示する。 """ # ページ内のすべての注文履歴について反復する。ブラウザーの開発者ツールでclass属性の値を確認できる。 for line_item in driver.find_elements_by_css_selector('.order-info'): order = {} # 注文の情報を格納するためのdict。 # 注文の情報のすべての列について反復する。 for column in line_item.find_elements_by_css_selector('.a-column'): try: label_element = column.find_element_by_css_selector('.label') value_element = column.find_element_by_css_selector('.value') label = label_element.text value = value_element.text order[label] = value # 注文の情報を格納する。 except NoSuchElementException: pass # ラベルと値がない列は無視する。 print(order['注文日'], order['合計']) # 注文の情報を表示する。 if __name__ == '__main__': main()
.envファイルに次のようにログイン情報を保存します。ファイルの取り扱いには気をつけてください。
AMAZON_EMAIL=<Amazon.co.jpのメールアドレス> AMAZON_PASSWORD=<Amazon.co.jpのパスワード>
次のように実行すると、日付と価格が表示されます。
$ forego run python selenium_amazon_order_history.py INFO:root:Navigating... INFO:root:Signing in... 2019年9月8日 ¥ 0 2019年8月12日 ¥ 2,236 2019年8月4日 ¥ 30,000 2019年7月29日 ¥ 648 2019年7月29日 ¥ 2,592 2019年7月29日 ¥ 648 2019年7月29日 ¥ 648 2019年7月29日 ¥ 648 2019年7月29日 ¥ 648 2019年7月28日 ¥ 648 INFO:root:Following link to next page... 2019年7月28日 ¥ 648 2019年7月28日 ¥ 648 2019年7月26日 ¥ 20,807 2019年7月25日 ¥ 0 2019年6月19日 ¥ 767 2019年6月3日 ¥ 10,092 2019年5月31日 ¥ 5,054 2019年4月15日 ¥ 2,500 2019年4月7日 ¥ 1,800
増補改訂版は好評発売中です。よろしくお願いします!
![Pythonクローリング&スクレイピング[増補改訂版] -データ収集・解析のための実践開発ガイド Pythonクローリング&スクレイピング[増補改訂版] -データ収集・解析のための実践開発ガイド](https://images-fe.ssl-images-amazon.com/images/I/41VimzqqXAL._SL160_.jpg)
Pythonクローリング&スクレイピング[増補改訂版] -データ収集・解析のための実践開発ガイド
- 作者: 加藤耕太
- 出版社/メーカー: 技術評論社
- 発売日: 2019/08/10
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
Pythonクローリング&スクレイピングの増補改訂版が出版されます
Pythonクローリング&スクレイピングはおかげさまでご好評いただき、この度、増補改訂版を出版する運びとなりました。紙版は本日8/10発売で、電子書籍版は既に発売中です。
![Pythonクローリング&スクレイピング[増補改訂版] -データ収集・解析のための実践開発ガイド Pythonクローリング&スクレイピング[増補改訂版] -データ収集・解析のための実践開発ガイド](https://images-fe.ssl-images-amazon.com/images/I/41VimzqqXAL._SL160_.jpg)
Pythonクローリング&スクレイピング[増補改訂版] -データ収集・解析のための実践開発ガイド
- 作者: 加藤耕太
- 出版社/メーカー: 技術評論社
- 発売日: 2019/08/10
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
クローリングやスクレイピングを扱う書籍は、対象として利用しているWebサイトの変化によって、サンプルコードが動かなくなってしまう宿命があります。初版を執筆した際は、なるべく考え方を伝えるようにすることで、たとえサンプルが動かなくなったとしても役立つ内容にすることを心がけました。
ですが、書いてあるコードがそのまま動くに越したことはありません。今回改訂の機会をいただいたことで、読者の皆様に学びやすい形でお届けできるのを嬉しく思います。
増補改訂版の主な変更点
初版で評価いただいた良い点は残しつつ、全体的に内容をアップデートしています。主な変更点は次のとおりです。
早めにサードパーティライブラリを使う構成に変更
初版では、2章で標準ライブラリのみを使い、3章からサードパーティライブラリを使う構成でした。増補改訂版では、主要なサードパーティライブラリであるRequestsとlxmlを2章から使うように変更しました。これによって、実践的な手法を素早く学べるようになりました。
最新のPython 3.7に対応
初版ではPython 3.4/3.5を使っていましたが、増補改訂版ではPython 3.7を使います。これによって、f-stringsやdictの並び順保持、asyncio.runなどの便利な機能を使えるようになりました。
また、サンプルコードでは積極的に型ヒントを使うようにしました。型ヒントは好みが分かれるかもしれませんが、関数の入出力がわかりやすくなることを重視してつけました。好みでない場合、型ヒントは省略しても問題なく動きます。
Headless Chromeやpyppeteerに対応
初版から2年ほどの間に、ヘッドレスブラウザー周りは大きな変化がありました。PhantomJSがメンテナンスされなくなり、ChromeやFirefoxがヘッドレスモードをサポートしました。増補改訂版でもHeadless Chromeを使うよう変更し、PuppeteerをPythonにポートしたpyppeteerも解説しました。
運用をアップデート
7章で扱う運用もいろいろとアップデートしました。
- Linux OSをUbuntu 14.04 → 18.04に変更し、systemdを前提とした解説に変更
- Scrapy Cloudの解説を追加
- クローリングとスクレイピングの分離ではキューとしてAmazon SQSを使用
- サーバーレスなクローラーの運用についても軽く解説
さいごに
今回、改訂の機会を得られたのは、初版を読んでくださった読者の皆様と、初版の出版に関わってくださった皆様のおかげです。改めてお礼申し上げます。また、増補改訂版のレビュアーの皆様には数多くの指摘をいただき、よりわかりやすく正確な内容へと洗練させることができました。本当にありがとうございました。
増補改訂版をよろしくお願いいたします。
![Pythonクローリング&スクレイピング[増補改訂版] -データ収集・解析のための実践開発ガイド Pythonクローリング&スクレイピング[増補改訂版] -データ収集・解析のための実践開発ガイド](https://images-fe.ssl-images-amazon.com/images/I/41VimzqqXAL._SL160_.jpg)
Pythonクローリング&スクレイピング[増補改訂版] -データ収集・解析のための実践開発ガイド
- 作者: 加藤耕太
- 出版社/メーカー: 技術評論社
- 発売日: 2019/08/10
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
【1万部突破】Pythonクローリング&スクレイピングの発売から約1年
先月ツイートしましたが、Pythonクローリング&スクレイピングは第5刷となり、累計発行部数が1万部を突破しました。
【1万部突破!】Pythonクローリング&スクレイピングの増刷(第5刷)が決まり、発売1年足らずで累計発行部数が1万部を突破しました!読者の皆様、書評を書いてくださった皆様、レビュワーをはじめとする関係者の皆様に改めてお礼申し上げます。今後ともよろしくお願いします。 https://t.co/jrJxo9iCuC
— かと (@orangain) 2017年11月10日
評価
1万部突破にあたって http://scraping-book.com/ を更新する際に、ブログでの書評をまとめたのですが、とても良い評価をいただけていて嬉しく思います。
Amazonのカスタマーレビューは13件も書いていただき、★4.3と高い水準が継続していて本当にありがたいです。
「Rubyによるクローラー開発技法」のヒットやデータサイエンスにおけるPython人気の高まりという良いタイミングで企画をいただけたことに加え、締め切り前にScrapyがPython 3に対応したのも幸運でした。
また、書籍が良い内容になるには、レビュアーとして参加いただいた皆様の協力も不可欠でした。関係者の皆様にお礼を申し上げます。
振り返りの意味も込めて、この1年での本書を取り巻く状況の変化のうち、主なものを述べていきます。
クロール対象のサイトの変化
クローラー本の宿命ですが、クロール対象のサイトの変化により、書籍で掲載しているサンプルのコードが動かなくなってしまうことがあります。
把握している範囲の変更は、以下のサポートページに補足情報として掲載しています。
サポートページ:Pythonクローリング&スクレイピング ―データ収集・解析のための実践開発ガイド―:|技術評論社
gihyo.jpでCDNが導入されたことで、2章で使っているurllibのUser-Agentに対して403を返すようになってしまったのは結構初期段階なので辛いですが、代わりにサンプルサイトをご利用ください。
今のところ把握している範囲では、サイトが消えてなくなったりはしていないので、まだマシだとは思っています。
PhantomJSのメンテナー引退
書籍ではJavaScriptを使ったページへの対応として、PhantomJSを使っていましたが、今後はChromeやFirefoxのヘッドレスモードが主流になりそうです。
以下の記事は、PhantomJSの代わりにHeadless Chromeを使って本書のサンプルコードを動かしてみたものです。
SPAの採用が進むにつれてJavaScriptを使ったページへの対応は重要になっていくので、もっとページを割いても良かったかなと思います。
AWS LambdaのPython 3対応
発売当時のAWS LambdaはPython 3系に対応していなかったこともあり、クローラーの運用としてLambdaは紹介しませんでしたが、2017年4月にLambdaがPython 3に対応しました。
Lambdaを使えばサーバー管理が不要になるので、可能な場合には積極的に使っていきたいサービスです。以下の記事ではLambdaに加えてAWS Fargateを使い、EC2を管理せずにクローラーを運用できることを示しています。
その他
他にも書籍ではページ数の都合で書けなかったことを補足的に記事にしておきました。
今後ともよろしくお願いいたします。
AWS FargateとLambdaでサーバーレスなクローラー運用
これはWebスクレイピング Advent Calendar 2017の7日目の記事です。こんな感じでAWS FargateとAWS Lambdaを使ってサーバーレス(EC2レス)なクローラーを作ります。

この記事はFargateでのクローリング処理にフォーカスしており、クロールしたHTMLをS3に保存するところまでを主に解説します。Lambdaの方はおまけ程度の扱いで、スクレイピングしたデータの扱い(データベースへの格納など)はスコープ外です。
長くなったので目次です。
背景
クローラーを稼働させるのにサーバー管理をしたくないという思いがあります。かと言ってScrapinghubのようなSaaSは、ロケーション・実装の自由度やサービス継続性の面から採用しづらいこともあります。
サーバーレスと言えばLambdaが代表格です。Lambdaでクローラーを作ろうとする取り組みは過去にもあります。
ただ、クローラー*1の処理のうち、スクレイピング処理はいいとしても、クローリング処理はあまりLambda向きのワークロードではないと考えています。
クロール対象のサーバー負荷軽減のためにクロール間隔を空けることを考えると、Lambdaのスケーラビリティはあまりメリットになりません。Lambdaをn秒間隔で呼び出してくれるような仕組みはない*2ので、クロール間隔を空けるためにはLambdaの実行中にSleepする必要があります。
LambdaはCPUを使っていなくても関数の実行時間で料金が決まるので、Sleepしている間やWebページのダウンロードを待っている間も課金対象です。このクローラーの性質は、まさに以下の記事に書かれているLambdaに不向きなアプリケーションの性質に合致します。
- 1: Lambda functionの実行時間のうち、ネットワークI/O時間が支配的である
- 2: Lambda functionの実行終了を同期的に待たなければならない
- 3: 複数のレコードをLambda functionの引数に渡すことができない*3
コスト効率の悪いLambdaアプリケーションの性質に関する考察 - ゆううきブログ
さらに、Scrapyのような1プロセス内での非同期実行を前提とした開発効率の良いフレームワークがある中、細切れのLambda関数を書いていくのはダルいという思いもあります。
AWS Fargateの登場
そんなわけで2017年11月にこのAdvent Calendarに登録した時はクローリング処理をサーバーレス(EC2レス)で実行するためにAWS Batchを使うことを考えていました。
しかし先日のAWS re:Invent 2017でAWS Fargateが颯爽と登場したので、早速試してみます。AWS FargateはDockerクラスターを構築するサービスであるAmazon ECSにおいて、EC2を管理することなくクラスターを使えるサービス(クラスターの一形態)です。
クローラーの場合、FargateにしたところでLambdaのコストモデルの問題が解消するわけではありませんが、プロセスの実行が長時間に渡ることを前提としたScrapyのようなフレームワークを使いやすいというメリットがあります。
LambdaでもFargateでも、クロール対象サイトを複数にして同時にクロールすればネットワークI/Oを多重化できます。ですが、サイトごとのクロール間隔の調整はそれなりに面倒な処理なので、Fargateを使うことで既存のフレームワークで提供されている仕組みに乗っかれるのはメリットです。
クローラーの構成
冒頭の構成図を再掲します。

Scrapyはクローリングしながらスクレイピングするアーキテクチャですが、以前も書いたように、これはあまり良いアーキテクチャではないように思います。そこで、クローリングとスクレイピングを分離し、Scrapyではクローリングのみを行い、HTMLを丸ごとAmazon S3に保存します。
S3を間に挟むとスクレイピングに失敗したときや追加の情報を取得したくなったときでも、相手のサーバーに負荷を与えずにやり直しできて安心です*4。実運用ではS3のライフサイクルポリシーを使って1ヶ月後にオブジェクトを消すなどすると、再実行可能性とデータ量の抑制を両立できます。
やってみる
クローリング処理はPython 3.6とScrapyで作成します。途中でPython 2系では動作しないライブラリを使います。
これから作成するScrapyのSpiderのソースコードは以下の場所に置いてあります。
以下は前提とします。
- AWSのアカウントを持っていること
- 適当なS3バケットを持っていること
- ローカル開発環境において、そのS3バケットへの書き込み権限とAmazon ECRへの書き込み権限を持つユーザーでAWS CLIを設定済みであること
- ローカル開発環境ではPython 3の仮想環境内で作業していること
1. ScrapyのプロジェクトでSpiderを作る
まずはローカル開発環境でScrapyのSpiderを作ります。この記事では、Pythonクローリング&スクレイピングのサンプルファイルの中にある、6.7節の食べログのSpiderを改変して使います。
DOWNLOAD_DELAYなどの設定は適切にしておきましょう。
2. Scrapy S3 Pipelineをインストールする
Scrapyでクローリングのみを行い、HTMLを丸ごとS3に保存するのはよくあるパターンなので、Scrapy S3 Pipelineというライブラリにしてみました。これをインストールします。
(venv) $ pip install scrapy-s3pipeline
Scrapy S3 Pipelineはスクレイピングして得られたItemをJSONLines形式でS3に保存するItem Pipelineです。Scrapyの通常のFeed ExportsもS3への保存に対応していますが、S3ではファイルへの追記ができない都合上、Spiderの実行が終わってから大きな1つのファイルをS3に保存します。一方Scrapy S3 Pipelineは、アイテムをチャンクごと(デフォルトで100アイテムごと)に区切ってS3に保存します。これによって、S3のイベント通知を受けてLambdaでスクレイピングする構成を取りやすくなります。
また、Gzip圧縮をサポートしているのも特徴です。同じようなHTMLが複数含まれるファイルは圧縮率が高くなるので、スクレイピング再実行のためにHTMLを残しておきたい場合には効果的です。
3. Scrapy S3 Pipelineをプロジェクトに追加する
プロジェクトのsettings.pyに以下の設定を追加します。S3PIPELINE_URLのバケット名 (scraping-bookの部分) はご自身の所有するS3バケットに変更してください。
ITEM_PIPELINES = {
's3pipeline.S3Pipeline': 100,
}
S3PIPELINE_URL = 's3://scraping-book/{name}/{time}/items.{chunk:07d}.jl.gz'
なおS3PIPELINE_URL内の変数は以下のように置き換えられます。
{name}: Spider名{time}: Spiderの開始時刻{chunk}: チャンクに含まれるアイテムの開始番号(0, 100, 200, ...)。上記ではFormat Stringを使ってゼロパディングしている。
Spiderのコールバックメソッドではスクレイピング処理を行わず、単にs3pipeline.Pageオブジェクトをyieldするのみとします。Pageクラスはurl, body, crawled_atの3つのフィールドを持ち、Page.from_response(response)とするだけでこれらの値が埋められます。
# ... from s3pipeline import Page # ... class TabelogSpider(CrawlSpider): # ... def parse(self, response): yield Page.from_response(response)
ここまでできたら以下のコマンドを実行し、問題なくクローラーが動作していればOKです。
(venv) $ scrapy crawl tabelog
正常に動作していれば以下のようにS3にオブジェクトが作成されるはずです。

4. ScrapyのプロジェクトをDockerizeする
作成したSpiderをDockerコンテナ内で実行できるようにします。
以下の内容でDockerfileを作成します。
FROM python:3.6.3 WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt COPY . . CMD ["scrapy", "crawl", "tabelog"]
.dockerignoreファイルも作成しておきます。
venv/ .scrapy/ .git/
以下のコマンドで、Dockerイメージをビルドして実行できればOKです。
$ docker build -t serverless-crawler . $ docker run --rm -it serverless-crawler
通常Dockerコンテナ内ではAWSのクレデンシャルを取得できないので、botocore.exceptions.NoCredentialsError: Unable to locate credentials などのエラーが発生するはずです。Fargateでの実行時にはIAM Roleで取得できるようになるので特に問題ありません。Ctrl-Cを2回押してSpiderの実行を終了しておきます。
5. Amazon ECRにリポジトリを作成する
さて、ここからはAWSのマネジメントコンソールで作業します。2017年12月時点ではAWS Fargateは北部バージニアリージョン(us-east-1)のみに対応しているので、以降の手順ではすべて北部バージニアリージョンを使います。
Amazon ECSの管理画面の「リポジトリ」から serverless-crawler という名前のリポジトリを作ります。
6. DockerイメージをAmazon ECRにpushする
リポジトリ作成時に手順が表示されるはずですが、以下のようにログインして先ほどビルドしたDockerイメージをAmazon ECRにpushします。
ログイン:
$ $(aws ecr get-login --no-include-email --region us-east-1) Login Succeeded
タグ付けとプッシュ(<AWS ID>はご自身のIDに置き換えてください):
$ docker tag serverless-crawler:latest <AWS ID>.dkr.ecr.us-east-1.amazonaws.com/serverless-crawler:latest $ docker push <AWS ID>.dkr.ecr.us-east-1.amazonaws.com/serverless-crawler:latest

7. IAM Roleを作成する
ECSのタスクからS3にPUTできるよう、EC2 Container Service Task (ecs-tasks.amazonaws.com) をTrusted EntityとするIAM Roleを作成しておきます。 ecsTaskServerlessCrawler という名前のロールを作りました。
本来はポリシーを書いて必要最低限の権限のみを割り当てるべきですが、手抜きしてAWS管理ポリシーAmazonS3FullAccessを割り当てました。
8. ECSクラスターを作成する
ここからいよいよAmazon ECSの管理画面での作業です。「クラスター」→「クラスターの作成」から、Networking Only (Powered by AWS Fargate) のクラスターを作成します。defaultという名前にしました。
「Getting Started with Amazon Elastic Container Service (Amazon ECS) using Fargate」というウィザードもありますが、今回は使いません。このウィザードを使うとECSのサービスも一緒に作成されますが、バッチ処理のように実行完了したら終了したいタスクはクラスターとタスク定義だけあれば良く、サービスは不要なためです。

9. ECSタスク定義を作成する
「タスク定義」→「新しいタスク定義の作成」から、実行するタスクの雛形であるタスク定義を作成します。
- ステップ 1: Select launch type compatibility
- Launch Type Conmpatibility: Fargate
- ステップ 2: Configure task and container definitions
- タスク定義名:
serverless-crawler - タスクロール:
ecsTaskServerlessCrawler(7で作成したもの) - Task execution role:
ecsTaskExecutionRole(初回に自動作成されるはず) - Task memory (GB): 0.5GB
- Task CPU (vCPU): 0.25 vCPU
- コンテナ定義
- コンテナ名:
serverless-crawler - イメージ:
<AWS ID>.dkr.ecr.us-east-1.amazonaws.com/serverless-crawler:latest(6でpushしたもの) - メモリ制限: ソフト制限 128MB
- ※環境変数など必要なものがあればここで追加する
- コンテナ名:
- タスク定義名:
10. タスクを実行する
クラスターdefaultの「タスク」→「新しいタスクの実行」か、タスク定義serverless-crawlerの「アクション」→「タスクの実行」からタスクを実行します。
Launch typeでFARGATEを選択し、適切なVPCとサブネットを選択して実行します。この時点でタスクのロールやコンテナの環境変数などを上書きすることも可能です。

実行開始して1分ほど待つとRUNNING状態になり、ログを確認できるようになります。 ただ、ECSの管理画面に表示されるログは見づらいので、CloudWatch Logsで見たほうがわかりやすいです。
5分ほどでSpiderの実行は終了し、S3にアイテムが生成されているのが確認できます。
おまけ: Lambda関数を作成する
スクレイピング処理は、こんな感じのLambda関数(Python 3.6)を作成し、S3へのオブジェクトの作成をトリガーとして呼び出されるようにします。Lambdaに関しては世の中に多くの情報があるのでここでは詳しく解説しませんが、以下の点には気をつけてください。
- サードパーティライブラリ(この例ではlxmlとcssselect)は一緒にパッケージングする。
- S3からファイルを取得できるようIAM Roleを設定する。
- 同じファイルへのイベントが複数来ることがあるので、処理がべき等になるようにする。
- LambdaをVPC内で実行する場合はLambdaからS3にアクセスできるようVPCエンドポイントを作るなどする。
import io import json import gzip import boto3 import lxml.html def lambda_handler(event, context): """ Lambdaから呼び出されるエントリーポイント """ for record in event['Records']: bucket_name = record['s3']['bucket']['name'] object_key = record['s3']['object']['key'] process_object(bucket_name, object_key) def process_object(bucket_name, object_key): """ 1つのS3オブジェクトを処理する。 """ s3 = boto3.client('s3') for page in read_pages(s3, bucket_name, object_key): scrape_from_page(page) def read_pages(s3, bucket_name, object_key): """ S3オブジェクトからページをyieldするジェネレーター """ use_gzip = object_key.endswith('.gz') bio = io.BytesIO() s3.download_fileobj(bucket_name, object_key, bio) bio.seek(0) f = gzip.GzipFile(mode='rb', fileobj=bio) if use_gzip else bio for line in f: page = json.loads(line) yield page def scrape_from_page(page): """ 1つのページからlxmlなどを使ってスクレイピングする。 """ root = lxml.html.fromstring(page['body']) restaurant = { 'url': page['url'], 'name': root.cssselect('.display-name').text_content().strip(), } # スクレイピングしたデータのDBへの保存などを行う
まとめ
AWS Fargateを使って、EC2の管理をすることなくDocker化されたバッチ処理(クローラー)を実行できました。バッチ処理に合わせてクラスタを起動・終了しなくてもクラスタ実行時間のみが課金対象となるので楽です。Lambdaのような制限も少なく、既存の処理も移行しやすそうです。
タスクの起動に時間がかかるのはやや気になりますが、ある程度長時間実行するクローラーであれば影響は少ないでしょう。今回はDebianベースのDockerイメージを使ったので、Alpineベースのイメージにするなど、イメージサイズを減らすことで改善するかもしれません。
他にもやり残した点として、クローラーのグレースフルな停止があります。ScrapyのクローラーをDocker化するとコンテナの停止時(マネジメントコンソールからECSのタスクを停止した時)にSIGTERMが送られて一瞬で終了してしまうので、SIGINTによるグレースフルなクローラーの停止に対応させたいです。
Pythonクローリング&スクレイピングはおかげさまで1万部を超えるヒットとなりました。出版当時の2016年12月はLambdaのPython 3対応もなかった時代で、7章の運用ではオーソドックスにEC2内のCronでプロセスを実行していましたが、Fargateの登場によってEC2なしで運用できるようになりました。Fargateが東京リージョンに来るのを楽しみにしています。
ElementTreeやlxmlで名前空間を含むXMLの要素を取得する
PythonでElementTreeやlxmlを使って名前空間つきのXMLから要素を取得しようとしても、思い通りに取得できないことがあります。これはよくあるハマりどころですが、あまりまとまった情報がないのでまとめておきます。
Python 3.6.0で検証しました。
目次:
解決したい問題
まず前提としてXMLの名前空間について確認した後、解決したい問題について述べます。
前提知識: XMLの名前空間
1つのXML文書に複数の語彙を混ぜた場合、タグ名などが衝突してしまう可能性があるので、それらの意味を明確にするのが名前空間です。
XMLの名前空間はURI(ここではhttp://www.w3.org/2005/Atom)で表され、XML文書内では名前空間に属する要素や属性を接頭辞(ここではatom:)をつけて表します。
<atom:feed xmlns:atom="http://www.w3.org/2005/Atom"> ... <atom:title>orangain flavor</atom:title> ... </atom:feed>
xmlns属性でデフォルト名前空間として指定した名前空間は接頭辞が不要になるので、以下のようにも書けます。
<feed xmlns="http://www.w3.org/2005/Atom"> ... <title>orangain flavor</title> ... </feed>
当ブログのAtomのソースもこのような形になっています。
参考: XML名前空間の簡単な説明
問題: 名前空間を含むXMLから意図した要素を取得できない
さて、このようなXML文書のtitle要素を取得しようとして、以下のように書いても要素が取得できません。
from urllib.request import urlopen from xml.etree import ElementTree f = urlopen('http://orangain.hatenablog.com/feed') xml = f.read() root = ElementTree.fromstring(xml) title = root.find('./title') # title要素を取得するつもりがNoneとなる print(title) # None
以降では、この問題への対応方法を見ていきます。(RSSやAtomなどのフィードに限って言えば、feedparserのようなライブラリを使えば生のXMLを意識する必要はありませんが、ここでは名前空間を持つXMLの一例としてAtomを取り上げます。)
対応方法
基本的な対応方針としては以下の2つを行います。
注意点は、デフォルト名前空間であっても必ず適当な接頭辞をつけなくてはいけないということです。「名前空間なし」と「デフォルト名前空間」は完全に別のものと認識されます。
ElementTree(標準ライブラリ)の場合
ElementTreeのfind()やfindall()では以下のようになります。
from urllib.request import urlopen from xml.etree import ElementTree f = urlopen('http://orangain.hatenablog.com/feed') xml = f.read() root = ElementTree.fromstring(xml) title = root.find('./atom:title', {'atom': 'http://www.w3.org/2005/Atom'}) # 第2引数に名前空間のマッピングを指定 print(title) # <Element '{http://www.w3.org/2005/Atom}title' at 0x108e545e8>
ちなみに以下のようにXPath内に直接名前空間のURIを書くこともできます。これはElementTreeのAPIで使用できる特殊な書式であり、有効なXPathではないため、後述するlxmlのxpath()では使用できません。(そもそもElementTreeではXPathのサブセットのみ使用できます。)
title = root.find('./{http://www.w3.org/2005/Atom}title') # 名前空間のURIをXPathに含める
lxml(サードパーティライブラリ)の場合
lxml 3.8.0で検証しました。
lxmlのxpath()では以下のようになります。なおnamespacesはキーワード引数でしか指定できません。
from urllib.request import urlopen from lxml import etree f = urlopen('http://orangain.hatenablog.com/feed') xml = f.read() root = etree.fromstring(xml) title = root.xpath('./atom:title', namespaces={'atom': 'http://www.w3.org/2005/Atom'})[0] print(title) # <Element {http://www.w3.org/2005/Atom}title at 0x108ab8e08>
(lxmlにもElementTree互換のfind()などがあり、ElementTreeの場合と同様の書き方ができます。が、lxmlで敢えてXPathのサブセットしか使えないこれらのAPIを使うメリットは少ないでしょう。詳しくはあとで触れます。)
XPathにデフォルト名前空間を指定したい
さて、名前空間を指定すれば取得できるのはわかりましたが、XPathに名前空間を含めるのは正直面倒です。XMLではデフォルト名前空間によって簡潔に書けるようになっていますが、XPathでも同様にできないのでしょうか。
結論から言えばXPath 1.0ではできません。XPath 1.0の仕様として、名前空間を指定しない要素は常に「名前空間なし」の要素を意味し、デフォルト名前空間のようなものを指定することはできません。lxmlのFAQにもこの旨が書かれています。
XPath 2.0以降ではデフォルト名前空間を指定できるようになっているようですが、XPath 2.0以降は1.0から大きく変わってXQueryという仕様のサブセットになっています。世の中の実装も多くはXPath 1.0のままであり、lxmlで使われているlibxml2でもXPath 2.0をサポートする予定はないそうです。
参考: objective c - Does libxml2 support XPath 2.0 or not? - Stack Overflow
諦めてXPathに名前空間を含めましょう、ということなのですが、微妙な感じの対処法を2つ紹介しておきます。
実はlxmlのfind()やfindall()ではデフォルト名前空間を指定できる
実はlxmlのfind()やfindall()はElementTreeのそれから拡張されており、デフォルト名前空間を指定できます。名前空間マッピングでキーをNoneにすると、それがデフォルト名前空間として使用されます。
title = root.find('./title', {None: 'http://www.w3.org/2005/Atom'})
さらに、lxmlではroot.nsmapでドキュメントの名前空間マッピングを取得できるため、以下のように書けます。
title = root.find('./title', root.nsmap)
また、lxmlでは名前空間のURIにワイルドカードを指定できるので、以下のようにも書けます。
title = root.find('./{*}title')
これらの書き方だと名前空間のURIを意識しなくてよいので嬉しいですが、ElementTreeからの拡張についてドキュメント化されていないこと、lxmlでfind()を使うメリットが少ないことから、微妙な感じです。
よく使うであろうxpath()では、名前空間マッピングのキーをNoneにするとエラーになるので注意が必要です。
名前空間の宣言を消してしまう(雑)
非常に雑ですが、XMLの文字列から名前空間の宣言を消してしまうという方法もあります。以下のようにデフォルト名前空間の宣言を消せば、名前空間を気にせずに要素を取得できるというわけです。
from urllib.request import urlopen from xml.etree import ElementTree import re f = urlopen('http://orangain.hatenablog.com/feed') xml = f.read() root = ElementTree.fromstring(re.sub(rb'xmlns=".*?"', b'', xml, count=1)) title = root.find('./title') print(title) # <Element 'title' at 0x108308598>
書き捨てのスクリプトであれば、これで十分な場合もあるでしょう。誤って意図しない箇所を置換してしまう可能性もあるので、自己責任でどうぞ。
デフォルト名前空間だけでなく、他の名前空間もある場合は、すべての名前空間を消す必要があります。正規表現では厳しくなってくるので、一度パースしてから書き換えるのが無難です。詳しくは以下のページを参考にしてください。
ちなみにこのページにも「XMLの文字列を正規表現で書き換えるなんてとんでもない!」というコメントがあります。
まとめ
名前空間を含むXMLに対してXPathを使用する際は、面倒ですが名前空間を1つ1つ指定しましょう。
Pythonクローリング&スクレイピングでElementTreeを扱った箇所では、シンプルさを優先して名前空間のついたAtomの代わりに名前空間のないRSS 2.0からデータを取得しました。よくあるハマりどころなので、名前空間のついたXMLを扱う方法もどこかに書いておけばよかったなと思い、記事にしました。
参考
- lxmlでXMLパースしたらnamespaceではまった - YAMAGUCHI::weblog
- Pythonで名前空間付きのXMLを操作する(ElementTree) - Qiita
- RSS1.0を検索する際の名前空間の指定 - stogの日記
- lxmlでXMLをパースする - ふたこもり
- Issue 18304: ElementTree – provide a way to ignore namespace in tags and searches - Python tracker
- python - lxml etree xmlparser remove unwanted namespace - Stack Overflow
神戸Pythonの会でクローリングとスクレイピングについて話した
だいぶ日が経ってしまいましたが、神戸Pythonの会でクローリング・スクレイピングについて2回話してきました。
1回目はRequestsとBeautiful Soupを使った基本的なスクレイピングについて、2回目はHeadless Chromeを使ったスクレイピングについて話してきました。
資料は概要的なもので、これだけ読んでもあまり役立たないですが、以下のリンク先にあります。
演習問題もやりました。こちらのほうがメインです。
感想など
神戸Pythonの会は去年から始まったコミュニティで、しばしば参加させてもらってます。登壇者との距離が近くて質問しやすく、演習問題などでコードを書く時間を多く取っているのが好みです。
参加者の皆さんは研究や業務など、様々な目的でクローリング・スクレイピングに興味を持たれていました。終了後に感想を伺うとPythonのライブラリの便利さに驚いたといった声や、やりたかったことができそうという声があり、少しは役立ったかなと思います。
参加者の中にはPythonクローリング&スクレイピングを購入してくださった方も多く、とてもありがたかったです。2回目には書籍を読んでから私のTwitterアカウントを知り、Twitterでの告知を見て参加してくださった方も居て、なんとも感激でした。
ちなみにPythonクローリング&スクレイピングは先日また増刷され、半年余りで第4刷になりました。編集者さんからは「新人著者にしてはかなりのヒット」というお言葉をいただき、注目の集まる題材でタイミング良くオファーを頂いたことの幸運を噛みしめるとともに、お世話になった関係者・読者の皆様に改めて感謝しております。今後ともよろしくお願いします。