WebスクレイピングにAmazon CloudWatch Synthetics CanaryとBedrockを利用する

はじめに

Webサイトのスクリーンショット取得及び、Webスクレイピングを実行する必要があったのですが、下記2つの課題を、CloudWatch Synthetics CanaryとBedrockを利用する事で、ある程度解決してみました。

  • 自前でPuppeteer/Selenium実行環境の作成/メンテナンス実施がしんどい
  • コンテンツ変更があった際のセレクタ変更対応を行う事がしんどい

スクレイピングの禁止Webサイトについて

サービス利用規約により、自動化された手段、データ収集の禁止が含まれているWebサイトもあるため、利用規約をご確認下さい。

目次

概要

構成図に起こす程でもありませんが、下記のような構成となっております。

CloudWatch Synthetics Canaryとは

CloudWatch Synthetics Canaryとは、実際のユーザーの動きを模倣したスクリプトを定期的に実行する事が可能な、いわゆる合成モニタリングを実施する事が可能なツールとなっています。

CloudWatch ユーザガイド 合成モニタリング
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html

Canary の動画デモ が非常に分かりやすい内容となっております。
Webページの差分検知機能等もあり、とても便利です。

合成モニタリングとは

予防的な問題検知、ユーザーエクスペリエンスの保証という観点で、重要な監視と考えています。

リアルユーザモニタリング(RUM) vs 合成モニタリング: 顧客体験を改善するにはどうしたらいいか
https://newrelic.com/jp/blog/how-to-relic/synthetic-versus-real-user-monitoring

手順

Synthetics Canaryの作成

案内にある通り、AWS Synthetics Canary Recorder Chrome プラグインをインストールし、対象のURLを開きます。

プラグインにてUI操作をスクリプト化

プラグインから、レコードを開始した後
ブラウザ操作を行う事で、行った操作がスクリプト化されます。

スクリプトを編集しCanaryに設定

Canaryを作成するとLambdaが作成される事を確認できます。

スクリプトの実行結果を確認

スクリプトの実行結果を確認(詳細)

失敗時の実行結果を、各ステップでスクリーンショット付きで確認する事ができます。
これがとても便利です。

作成されたファイルの確認

標準設定ですと、synthetics.executeStep の 各ステップでスクリーンショットを取得してくれ、har ファイル等も一緒に作成してくれるため、そこそこの容量となります。

作成したスクリプト (抜粋) 

スクリーンショット解析Lambdaの作成

Synthetics Canary 実行結果保存バケットに下記のような条件で、解析Lambdaを起動するように設定

スクリプト (抜粋)

手抜き仕様で、処理されるのが単一ファイルのみなので注意

Tips

Synthetics Recorder利用に際して

レコードする際には、プライベートブラウザにて実施する等で、Cookieがない状態からUI操作を行う必要があるWebサイトがあります(Cookie受け入れ許可ダイアログ等)

idが動的に生成されるWebサイト

idが動的に生成されるWebサイトが多いため、name 属性で指定してあげる等

WebページにSyntheticsからアクセスすると Forbidden 等が返却される

国内IP利用 + UserAgent 設定でクリア出来るパターンが多かったです。
自分のuserAgent 確認 console.log(window.navigator.userAgent)

Canaryの設定で気を付ける事

  • 実行時間制限が標準のタイムアウト時間だと長いため必要に応じて調整する
  • データ保持期間が標準だと1ヶ月等なので、必要に応じて調整する

不要ファイルの作成防止

スクリプトの先頭で下記のような設定をする事で、作成ファイルを絞る事ができました。

スクリーンショットの大きさ

生成AIにスクリーンショット画像を渡す際に、大きすぎる画像だと良い結果が得られないケースがありました。
適切に領域を切って渡してあげる等工夫が必要と思いました。

まとめ

本来の使い方とは少し毛色が異なりますが
自前でLambda Layerを作成/管理する事に比べ、工数の削減を実現できました。

失敗時のデバッグも行いやすいと感じており、とても良いサービスと感じました。
(本記事のスクリプト例とは異なりますが、自分の契約しているサービスがAPIを提供してくれていないため、日に1回動かしております。MFAが強制で有効になると困るなぁとは思っておりますが :sweat_smile:)

一方で、本来の使い方に近いものですと、Synthetics Canary の実態はLambdaのため
StepFunctionsでSynthetics Canary Lambdaを複数起動させて負荷テストを実施するという下記ブログについて良い利用法だなと感じましたので、機会があれば検討してみたいと思います。

参考

Puppeteer を使用した Node.js Canary スクリプト用のライブラリ関数

https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_Library_Nodejs.html

Amazon CloudWatch Synthetics を使用して負荷テストと合成モニタリング

https://aws.amazon.com/jp/blogs/mt/reduce-code-duplication-in-load-testing-and-synthetic-monitoring-using-amazon-cloudwatch-synthetics/

S3 Image Analysis

Analyzing images in S3 with Claude 3 and AWS Lambda
https://github.com/aws-samples/s3-image-analysis-lambda-claude3/blob/main/README_en.md

投稿者プロフィール

takashi
Japan AWS Ambassadors 2023, 2024
開発会社での ASP型WEBサービス企画 / 開発 / サーバ運用 を経て
2010年よりスカイアーチネットワークスに在籍しております

機械化/効率化/システム構築を軸に人に喜んで頂ける物作りが大好きです。

ABOUTこの記事をかいた人

Japan AWS Ambassadors 2023, 2024 開発会社での ASP型WEBサービス企画 / 開発 / サーバ運用 を経て 2010年よりスカイアーチネットワークスに在籍しております 機械化/効率化/システム構築を軸に人に喜んで頂ける物作りが大好きです。