2017年7月21日にGoalistの4Fで行われた勉強会の資料です。 この資料は２番目に発表した盛次経王の資料です。

1. Lambdaでクローリング
2017/07/21
サーバレスアーキテクチャを勉強する会
株式会社ゴーリスト 盛次経王

2. 自己紹介
• 盛次 経王（モリツグ ツネオ）
• 株式会社ゴーリスト所属
• クローラからフロントまで手広く色々
やってます
• フロントではAngular、サーバサイド
ではJavaが多いです
• 今日はスプラトゥーン2の発売日です

3. ゴーリストについて

4. ゴーリストについて
この辺を担当したり関わったりしてます

5. Redshift
HRogチャートのサーバレス構成
OZで蓄積した求人データをエリア、職種、給与などで検索、集計できる
Redshiftには2億4千万件(カラム数53) のテーブルがある
LambdaAPI Gateway
S3

6. HRogチャートでみるメリットデメリット
知ったように喋っていますが、実はHRogチャートはフロント
側の実装担当だったので裏側はそこまで詳しくないです。
なので、担当者に聞いてきました。

7. HRogチャートでみるメリットデメリット
メリット
Lambda、RedshiftともにAWSの東京リージョンなので、クエリ結果が
返ってくるのが早い（と思う。計測したわけではないです。)
↑Lambdaの代わりにEC2を使っても同じだとは思うので、アプリケー
ションサーバーとDBをAWSで統一するメリットと言う感じですが。
デメリット
Lambda と API Gatewayを使っているので、Redshiftに重いクエリ(一つ
のテーブルから仕事内容、応募内容などの長い文字列を含む20列くらい分
の求人案件レコードを200件取ってくるみたいなクエリ)を投げるとAPI
Gatewayのレスポンス時間制限(30秒)に引っかかりレスポンスが返せない
場合がある。

8. 要約すると...

9. HRogチャートでみるメリットデメリット
メリット
統一感
デメリット
API Gatewayの30秒制限つらい

10. RedshiftやAPI Gatewayがボトルネック
Lambdaは何も悪くない
Redshiftの同時接続数の上限は動的には増やせない

11. HRogチャートはサーバレスでちゃんと動いている
Lambdaはもっと可能性を秘めているのではないか？

12. Lambdaのコスト
512MBで100時間使った場合
100 × 3600 × 0.000000834 × 10 ＝ 3.0024 ($)
(無料枠は512MBでは800,000秒=約222時間)
EC2のt2.micro(メモリ1.0GB)を100時間使った場合
100 × 0.016 = 1.6 ($) (無料枠は720時間)
．．．単純なコスト比較にはあまり意味が無い
Lambdaは「使った分だけ課金」なのでEC2インスタン
スが遊んでいる時間が長ければ圧勝しそう

13. Lambdaをクローラに使ってみる
• EC2で動いているクローラの一部をLambdaに変更する
• デイリーで50,000件(200,000リクエスト)ぐらいの民泊系サイト
• EC2インスタンス80台で同時取得
• クローラに厳しめで応答が遅くなったり、IP制限される
• インスタンスを停止してIPを変えて対応している
• クローラは Java + Selenium WebDriver + PhantomJS

14. Lambdaに変更した処理
• URLリストクロール(検索の結果ページなどを集める）
• URLリストのスクレイプ（取得したHTMLからURLを抜き出す）
• 50,000件の各URLを80台でクロール
• クローリングが終わったら各インスタンスでスクレイプ
ここだけLambdaにした

15. Lambdaでクローリングするための構成
Lambda S3
Website
DynamoDB
EC2
proxy & controller
invoke
・
・
・
crawl
check
update
update
save
EC2
ec2-rebooter
reboot

16. 1. PhantomJSをLambda上で動くようにする
2. IP問題を解決する(IP制限をかわしたい)
3. VPC内のLambdaからS3やDynamoDBに接続する
※今回はLambdaをインターネット上ではなくVPC内に置く
Lambdaでクローリングできるまで
PhantomJSはGUI環境がなくてもうごく
ヘッドレスブラウザ
Lambdaにはfontなどは一切入っていないの
でほとんどの言語が文字化けする

17. PhantomJSをLambdaで動くようにする
詳細はゴーリストの技術ブログに書きました…
http://developers.goalist.co.jp/entry/2017/06/23/120000
ポイントは大体以下
• Lambdaにデプロイしたzipやjarは /var/task 以下に展開される
• /var/task/lib はLD_LIBRARY_PATHに指定されている
• chmodは使えないので実行権限は事前に与えておく
• phantomJSのログファイルの場所を /tmp 以下に変更する

18. 1. LambdaFunctionをわければ違うインスタンス(IP)になる？
IP問題を解決する(IP制限をかわしたい)
同じLambdaインスタンスが使われる。
同時リクエストが一定数を超えてオートスケーリングすると変わる。
2. LambdaFunctionを複数用意してVPCをわければ何とかなる？
使っていい金額とリマップの頻度次第ではこれでいける。
VPC毎のNAT Gatewayに指定するElasticIPをリマップすればいい。
リマップは月間100回までは無料、それ以降は1回0.1$。
仕方ないので今回はt2.nanoを80個たててproxyサーバとした
．．．サーバレス？いいえLambdaです。

19. VPC内のLambdaからS3やDynamoDBに接続する
VPC内のLambdaからS3やDynamoDBに接続するには
1. NAT Gatewayを使ってインターネットアクセス
2. VPCエンドポイントを作ってアクセス
2017/07/21現在でS3はVPCエンドポイントに対応している、
DynamoDBはパブリックプレビュー
3. EC2インスタンスをproxyにしてインターネットアクセス

20. • 金額自体は１日３０ドル前後でsmallを80台で動かしたと
きと大差なし。元のインスタンスが諸事情によりsmallであ
ることを考慮すると値段は高くなっている気がする(ぇ
• クローリングにかかる時間は元がマルチスレッドでは無
かったので同時実行数の分だけ短縮された。今回は同時実
行数３で８～１０時間⇒２～３時間ぐらい
結果どうだったのか その1

21. • Webアプリと違ってバッチ処理のようなインスタンスが
遊んでいる時間が無く、マシンパワーをしっかり使い切
るような場合はコスト面ではEC2の方が有利。
• マルチスレッドでも出来ることをLambdaに置き換えた
だけな気もするが、複数サイトになった場合にスレッド
数に上限がない（性能も劣化しない）ことを考えると意
味があるように思う。強いインスタンス立てたりインス
タンスの上限緩和申請出さなくて良いし。。。
結果どうだったのか その2

22. • 最大時間が5分の縛りがあるので処理を小分けにすること
が必要とされる場面もある。また、クロールしたファイ
ルの取り扱いがEC2に比べるといちいち面倒。
DynamoDBに突っ込んでもいいが、S3に置く方が安い。
• 開発時のデバッグが辛い場合があったり、ログも
CloudWatchだけでは無理ゲーなのでS3にエクスポート
して解析したり一手間かかる。
結果どうだったのか その3

23. なんだかあと一歩な結果でしたが
これは私のサーバレス力が不足しているだけです
Lambdaには可能性しか感じません

24. 以上です
ご清聴ありがとうございました