【ITニュース解説】Best Way to Run Puppeteer Online: Solutions Compared

ウェブサイトの自動操作は、現代のITシステム開発において非常に重要な技術である。特に「Puppeteer（ピュパティア）」は、Googleが開発した人気のあるツールで、ウェブブラウザをプログラムで操作できる。これは、まるで人間がマウスやキーボードを使ってウェブサイトを操作するのと同じような動きを、コードで自動的に実行できるというものだ。例えば、ウェブサイトのスクリーンショットを撮ったり、ウェブページから特定の情報を集める「スクレイピング」を行ったり、自動でウェブサイトの動作をテストしたり、PDFファイルを生成したりと、多岐にわたる複雑な要求に応えることができる。

しかし、これらのPuppeteerを使った処理は、多くの場面でオンラインで実行する必要がある。例えば、ソフトウェア開発の自動化プロセスであるCI/CDパイプラインの中で、自動テストとしてPuppeteerを呼び出したり、ウェブサイトが正常に動いているかを定期的にチェックしたり、インターネット上の大量の情報を自動で収集する「ウェブクローラー」を分散して動かしたりする場合などだ。

ここで問題になるのが、その実行環境である。Puppeteerのタスクは、多くの場合、短時間で終了し、常に動いているわけではない。もし、これを通常のサーバー（例えばDigitalOceanのような仮想サーバー）に配置すると、Puppeteerが動いていない時間でもサーバーは稼働し続け、その分だけ費用が発生してしまう。これは、コスト効率が非常に悪い。

この問題を解決する理想的な方法は、「サーバーレス」と呼ばれるモデルを利用することである。サーバーレスサービスは、実際にコードが実行された時間や回数に応じて料金が発生するため、使わない時間には費用がかからず、多くのシナリオで大幅なコスト削減につながる。つまり、必要な時にだけ起動して処理を行い、終わったらすぐに停止する、という柔軟な運用が可能になるのだ。

現在、サーバーレスでPuppeteerを実行できるプラットフォームは限られており、主に「Leapcell（リープセル）」、「AWS Lambda（エーダブリューエス ラムダ）」、そして「Cloudflare Browser Rendering（クラウドフレア ブラウザ レンダリング）」の三つが挙げられる。これから、これらのプラットフォームを比較しながら、システムエンジニアを目指す初心者がPuppeteerをオンラインで動かす方法と、それぞれの良い点、注意すべき点を見ていこう。

比較のために、共通のタスクとして「指定されたURLのウェブページのスクリーンショットを撮り、その画像を返す」という、Puppeteerでよく行われる処理を例に挙げる。このタスクは、ウェブページにアクセスし、スクリーンショットを撮影し、結果として画像を返すという三つのステップで構成される。

まず、「Leapcell」について解説する。Leapcellは、比較的新しいプラットフォームで、Node.jsアプリケーションをサーバーレスでデプロイするのに適している。LeapcellでのPuppeteerの利用は、比較的直感的だ。提供されるコード例では、HTTPリクエストを受け付ける「Hono（ホノ）」というフレームワークを使ってウェブアプリケーションを作成し、その中でPuppeteerを起動してスクリーンショットを撮影する処理を実行している。Leapcellの大きな利点は、開発環境と本番環境（クラウド上）がほぼ同じであるという点だ。これは、普段Node.jsを開発するのと同じ感覚でローカルで動作確認やデバッグ（プログラムの誤りを探して修正する作業）ができ、そのままクラウドにデプロイしても同じように動くことを意味する。公式のPuppeteerライブラリをそのまま使える点も魅力的である。ただし、HTTPリクエストを処理するためのハンドラ（リクエストに応じて適切な処理を行う部分）を自分で記述する必要があり、初心者にとっては初期設定が少し複雑に感じられるかもしれない。

次に、「AWS Lambda」について見ていこう。AWS Lambdaは、Amazonが提供する非常に広く使われているサーバーレス実行環境だ。しかし、LambdaでPuppeteerを動かす際には特有の課題がある。Lambdaの関数には、デプロイできるパッケージのサイズが250MBという制限がある。通常のPuppeteerライブラリには、ブラウザ本体（Chromium）が含まれており、これが単体で250MBを超える場合があるため、そのままではLambdaのサイズ制限に引っかかってしまうのだ。このため、AWS LambdaでPuppeteerを使う場合、通常は「puppeteer-core」という、ブラウザ本体を含まないPuppeteerの軽量版と、「chrome-aws-lambda」のようなサードパーティが提供する軽量化されたChromiumの組み合わせを使うことになる。これにより、サイズ制限をクリアしつつ、ブラウザの自動操作が可能になる。コード自体は、Lambdaの関数としてシンプルに記述できるというメリットがあるが、サードパーティ製のライブラリに依存するということは、セキュリティや将来のアップデートの安定性といった点で潜在的なリスクを抱えることにもなる。また、ローカルでのデバッグ環境を構築するには、本番環境と異なる特殊な設定が必要になるため、やや複雑になりがちだ。デプロイも、必要なライブラリやコードをZIPファイルにまとめてアップロードしたり、「Lambda Layers」という機能を使って共通のライブラリを管理したりと、手間がかかる場合がある。

最後に、「Cloudflare Browser Rendering」について説明する。Cloudflare Browser Renderingは、Cloudflareが提供する比較的新しいサーバーレスのPuppeteerソリューションである。これもAWS Lambdaと同様に、公式のPuppeteerライブラリではなく、Cloudflareが独自に提供するPuppeteerライブラリを使用する。Cloudflareが提供するライブラリは、サードパーティ製に比べてセキュリティ面で信頼できる可能性が高いが、アップデートのサイクルが遅いという欠点がある。例えば、数ヶ月間も更新がない時期があったとされており、最新のブラウザ機能やセキュリティ修正に迅速に対応できない可能性がある。Cloudflare Browser Renderingには、他にもいくつかの制限がある。このサービスは「Worker Pro」という有料プランのユーザーのみが利用でき、さらに、1分間に作成できるブラウザの数や、同時に実行できるブラウザの数に上限が設けられている。そのため、大規模な利用や柔軟な運用を考えている場合には、これらの制約が足かせとなる可能性がある。ローカルでのデバッグ環境の構築も、AWS Lambdaと同様に複雑な設定が必要になる。しかし、デプロイ自体は、Cloudflareの管理画面上で直接コードを記述して保存するだけで実行できるため、比較的シンプルだ。

まとめると、Leapcellはローカルでの開発とデバッグが容易で、公式のPuppeteerライブラリをそのまま使えるという大きな利点がある。一方、AWS Lambdaはサードパーティの軽量版ブラウザに依存する必要があり、デバッグやデプロイが複雑になる点が課題だ。Cloudflare Browser RenderingもCloudflare独自のライブラリに依存し、アップデートの遅さや利用制限がネックとなる。それぞれのプラットフォームには一長一短があるが、総合的に見ると、Puppeteerを使ったプロジェクトをオンラインで展開しようと考えているシステムエンジニアの初心者にとって、Leapcellは非常に優れた選択肢と言えるだろう。開発のしやすさ、環境の一貫性、そして公式ライブラリのサポートが、学習コストを抑え、スムーズな開発体験を提供してくれるはずだ。