Tech勉強会レポート -Selenium+AWS LambdaでWebスクレイピング実行/Next.js 15を使ってみて感じたこと-

katsuya saitou

Pocket

こんにちは、エンジニアの斉藤です。

2024年11月29日に、アシアル社内イベントの1dayオフィスで開催した、Tech勉強会のアフターレポートです。
アシアルでは定期的にTech勉強会を開催しており、社員同士で技術に関する知見や意見を交換しています。

アシアルの1dayオフィスに関する取り組みは以下の記事を参照ください。
1dayオフィスの開催レポート｜アシアルnote

今回は二人の発表者がそれぞれ以下の話題で発表しました。

Selenium+AWS LambdaでWebスクレイピング実行
Next.js 15を使ってみて感じたこと

Selenium+AWS LambdaでWebスクレイピング実行

まずは一人目の発表者から、Seleniumを使って、スクレイピングをしてみたという事例を紹介していました。
私自身、SeleniumというツールはE2Rテストなどに利用する感覚でいましたので、このアイデアは面白いなと思いました。

システムの概要は以下とのことです。

作成するシステム
- ECサイトを定期的にWebスクレイピングし、最新商品を通知する
使用技術
- Python(Selenium, Beautifulsoup4, boto3)
- Docker
- AWS Lambda
- Amazon SNS

そして、以下のような流れで進めていたとのことです。

スクレイピング対象のスクレイピング可否（利用規約やrobots.txt ）の確認
SNSトピックの作成
Python+Dockerfileコーディング
ビルドしたDockerイメージをECRにpush
Lambda関数の作成・テスト
EventBridgeを用いたトリガー設定

特にスクレイピング可否の確認は大切な点ですね。
世の中に公開されているサイトに対して、スクレイピングをしても良いのかどうかに関しても調査したとのことで、技術が社会に与える影響を考慮するのは当たり前だけど大事な点だな、と思いました。

仕組みとしては、以下のような内容とのことでした。

EventBridgeでタイミングを見て、Lambdaを実行
Lambdaがdocker越しにpythonを実行
python内でSeleniumを実行
python内でAmazon SNSに連携
Amazon SNSが通知

Seleniumが動くということは、ブラウザがどこかに存在するということですが、Selenium Managerというプロダクトを利用することで、ブラウザが自動的にダウンロードされる仕組みのようです。
私が以前Seleniumを触った時にはそのような機能はありませんでしたが、やはりどんどんWebテクノロジーは進化しますね。
また、通知関連の実装は面倒なイメージがありますが、Amazon SNSを使えば実装できてしまうのは、さすがAWSですね。

発表された方は勉強のためにAWSを触ってみる、そうすることで得られるものがある、という理由から今回のアプリを構築されているようでした。作っていく中で、その環境の課題や苦労された点を話されていまして、やはり作ってみることでしか分からないことが学べますね。
（ブラウザとSeleniumドライバーのバージョン不整合でエラー、ECRとLambdaの連携など、つまづく点があったそうです）

この発表は、自分にとって新しい技術を触れてみる、経験をして分かった課題を乗り越える、というエンジニアとしての成長を楽しんでいることが伝わる内容でした。

Next.js 15を使ってみて感じたこと

続いて、二人目からはNext.js 15を使ってみての知見を共有という内容で発表がありました。
特に、RSC(React Server Components)を業務で利用した例の紹介をしていました。

以下のような内容を含む発表でした。

Server Component (SC)
Client Component (CC)
SC/CCの使い分け
Sever Action

Server ComponentとはReactのコンポーネントの中に、サーバー側のロジックを記述する仕組みだそうです。これは新しい開発者体験ができそうですね！
今までのReactでは、クリックする、ブラウザAPIを実行するなどクライアントサイドのコードを書いていると思いますが、この仕組みではDB接続などサーバーサイドのコードをReactの中で書くそうなので、また新しい書き心地になりそうです。

では「WEB APIはどうなるのか」といった疑問も湧いてきますが、 Server Action という仕様でサーバーサイドのコードを手続的に記述し、そちらをServer Componentから呼び出すとのことです。
APIエンドポイントを意識しないで済む分、インターフェイスの取り決めといった従来の設計が変わりそうですね。

この話の中で、特に聞いていて面白かったのは、「フロントエンドとサーバーサイドの役割が曖昧になりそう」という点です。
というのも「Reactのコンポーネント内で、DB接続するようなコードが書けるので、従来のようなAPIエンドポイントを意識することがなくなるのでは」という未来を感じたためです。

他にも「Client Component内でServer Componentを使いたい場合はどうすれば良いのか」「複数のServer Componentで認証認可など共通処理をさせたい場合はどうすれば良いのか」などを伝えていました。
このあたりはインターネット上もノウハウが蓄積されている途中という状況なようで、デファクトスタンダードな方法が定まっているというわけではないとのことです。

この発表では、発表者が新しい技術に触れてみながらも「一般的な考慮要素、要求が実現できるのか」「今までのやり方と比較するとこうなりそうだ」など、技術に振り回されず慎重に取り組んでいる姿を垣間見ることができました。