さて、前回の記事の通り、puppeteerはWindowsサーバー上ではなくFaaS上で動かしたいです。
nodejsプログラムの作成(puppetter) - Qiita
いろいろ3大FaaSを比較した結果、Google Cloud Functionsで動かしました。
- Azure Function
- Headless Chromeがそもそも動かない環境ぽいので断念
- AWS Lambda
- Lambda上で @serverless-chrome/lambda を使わねばならず、めんどくさそう
- Google Cloud Functions
- 公式にPuppeteerをサポートしており、puppetterに組み込まれているchrominiumをそのまま使える。普通にPC上で動かすために書いたコードと、Cloud Functions上で動かすためのコードがそこまで変わらない。
やり方は、以下のサイトを見れば簡単にできました。
Cloud Functions with Puppeteer + Google Apps Script でスクレイピングサーバーをサクッと作る - Qiita
特筆すべきことは…
- Memory allocatedは2GBにした
- ケチって256MBとかだとpuppeteerが起動できずエラーとなったため
- SourceCodeはInlineEditerに
- 今回はコード量も少なかったので直接書いた
- コード量が多いものをFaaSで実行すべきか、という議論は後述
- Function to Executeはちゃんと設定しましょう
Google Cloud Functionsの特徴
HTTPSトリガーしか存在しないこと。
Azure FuctionならHTTPSトリガーに加えてタイマートリガーやら、ストレージキュートリガーなどありますが、Google Cloud FunctionsはHTTPSをたたいてやらないと起動しません。よって、上記の参考にした記事ではGoogle Apps Scriptを使ってHTTPSをたたいていますが、これはそれぞれ使い慣れたツールでよいので、私はAzureのiPaaSであるLogicAppsを使いました。
Logic App Service | Microsoft Azure
- Google Cloud FunctionsをたたくとJSONで値を返すようにする。
- その状態で、LogicAppsでGoogle Cloud Functionsをたたき、戻り値のJSONを料理する
ご参考まで。
FaaS利用の考え方
HTTPSトリガーしか存在しないGCFを利用して改めて思ったことですが、FaaSはあくまでパーツの集まりとして、それらを利用(実行)するロジックは他で作成するのがいいのでは、という話です。
GCFはまだいいですが、AWS Lambdaなどは、ローカル実行時とFaaSでの実行時でコードが結構変わってしまって、長いコードだとローカル実行 → FaaS実行で差異が出そうでヤな感じ。単機能のパーツとして実装すればデバッグもしやすい。
私自身も「取得した情報をDBに投入する」というGCFの作成を進めていましたが、これでも
- 情報を取得する
- DBに投入する
の2機能がセットになっているので、前述のLogic Appsで「GCFをたたく→DBに投入する」の2パーツを接続するような形としました。(余談ですがDBに投入する機能はLogic Appsの組み込みを使った。こういうのができるのがiPaaSのいい所)