こんにちは、ミツカリCTOの塚本こと、つかびー(@tsukaby0) です。
以前、以下のような記事を書きました。
今まではE2EテストにDatadog Synthetic Browser Test(以下Datadog)を利用していましたが、チーム内で協議した結果、Playwrightに移行することになりました。
移行作業自体は他のメンバーが対応してくれたのでそこは関わっていないのですが、乗り換えた動機やPros/Consについてまとめてみようと思います。
なお、この記事で言うPlaywrightとはOSS、セルフホスティングの物を指します。Microsoft Playwright TestingなどのSaaSは含みません。
Datadogの採用理由
Datadogを選定した理由は以前の記事にも書いていますが概ね以下の通りです。
- コードベースでのE2Eは保守コストが高く、保守されない、テストが追加されない不安があった
- テスト実行環境を持ちたくなかった (SaaSで管理を楽にしたかった)
- ノーコードでテストを作成することで誰でもテストを作れる、編集できるようにしたかった
これらは確かに解消されたのかもしれませんが、運用していく中で課題がなかったわけではありません。
Datadogを運用する中で感じた課題
課題1. 高い
https://www.datadoghq.com/ja/pricing/?product=synthetic-monitoring#products
Datadogは1実行あたり$0.012です。 50テストケース * 100回/1日 * 20日 で計算した場合 100,000回 実行なので、 $1200/月 です( 150円/USD とすると、 180,000円 )。
実際に運用する場合は以下の費用もかかります。
https://www.datadoghq.com/ja/pricing/?product=continuous-testing#products
こちらの通り並列テストアドオンというのが1並列あたり $79/月 (11,850円/月) なので高いです。テストの長さに応じて6並列などで実行したくなります。その場合はアドオンが5つ必要なので、 79*5=$395/月 (59,250円/月) かかります。
当社の場合は、 50テストケース * 20回/1日 * 20日 程度の頻度だったと記憶しています。そのため、実行コストよりもこの並列アドオンコストがネックでした。
課題2. PRごとに実行できない
Datadogの場合、実行対象はインターネット上に公開されているサイトが対象となります。例えばHerokuのReview Appのような仕組みを用いてPRごとに環境を自動構築するような仕組みを作っている場合は良いですが、そうでない場合はPRごとにE2Eテストを実行できないことになります。
当社もそうでした。過去にReview Appは使っていましたが、現在は廃止しています。
当社の場合はPR Merge後にSTG環境に対してE2Eテストを実行していました。これはPRをMergeするためにE2Eを待たなくて良いというメリットはありますが、問題のあるPRをmasterに取り込む確率が増えてしまうというデメリットを持っています。また、STG環境に対するE2E実行はシーケンシャルになってしまいます。複数のPRが同時にMergeされた場合などは少しもどかしい時もありましたし、誰のPRでE2EがFailしたのか分かりづらいという問題もありました。
(PRごとに環境が立ち上がらなくても任意の操作でdev環境にデプロイしつつE2Eテストを実行する、みたいな仕組みもあり得ると思います。)
また、これは副次的な問題ですが、E2Eテストのトリガーに余計にコンピューティングコストがかかるという問題もありました。当社の場合はGitHub ActionsとDatadogのCLIを使ってE2Eテストを実行＆結果待ち、通知を行っていました。実行して結果を待つ間GitHub Actionsのrunnerを起動し続けておく必要があるのですが、これが無駄なコストだなと感じていました。
課題3. 負荷問題
前述の通りSTGをE2E環境としており、並列度を増やしていたため、E2Eテストが走り出すとSTGに大量のアクセスが発生します。その影響で一部の画面が500エラーになり、テストがFlakyになっているというような問題がありました。これはパフォーマンスチューニングの不足や、STGのリソース配分の問題など、複数の要因がありました。後日何日かかけて調整して安定化はしました。
(これはDatadogでもPlaywrightでも発生しうる問題ではあります。)
課題4. すぐに実行できない
Datadogのテスト実行体験が特段遅いというわけではないですが、Playwrightへの移行を終えた今となっては遅いと感じます。
Datadogではテストケースの編集を行うと少しラグがあってからテストがキューに積まれ、そして実行されます。これが少しもどかしいことがありました。
課題5. 実現できないテストがある、一部のFlakyなテストを解決できない
当社が調査した限りではドラッグアンドドロップはDatadogで実現できませんでした。
また、Flakyを解消できないテストが出てきてしまい、これらが発端となってPlaywrightを検討することになりました。
以前からDatadogをIaCするか？という話も出ていましたが、そうするとノーコードの意味が薄れますし、どうせIaC化するならPlaywrightのほうが良い選択であるとも思えます。
Datadog vs Playwright の Pros/Cons
前述のような課題があり、Playwrightへ移行しました。移行してみて感じたPros/Consなどをまとめてみようと思います。現状はPlaywrightのほうが当社にはあっていると思いますし、時代の流れ的にもPlaywrightを使う人が多そうですがDatadogも独自の強みがあると思っています。
DatadogのPros/Cons
- Pros
- Location選択機能があり、Asia/Tokyo以外の環境から接続させることができる
- ノーコードツールであるため、非エンジニア職でもテストを保守できる
- テストごとにダミーのメールアドレスを生成し、そのメアドに対してメールが送信されたかをチェックできる
- テスト結果に対してAPMの結果をリンクできるため、パフォーマンスチェックも同時にできる
- SaaSであるため、実行環境の構築が不要。導入が早い
- Cons
- 高い
- 実現できない操作、テストがある
- 生成AIを組み合わせられるPlaywrightと比較して保守コストが高い
- localhostを対象として簡単に実行できない
PlaywrightのPros/Cons
- Pros
- 安い
- localhostに対して実行できる。そのため、PRごとに実行できる
- local PC上ですばやく実行できる
- 生成AIとの相性が良い。大半のテストコードを生成・保守できる
- コードなのでDatadogより自由度が高い
- Cons
- 結果表示はDatadogより簡素
- 生成AIがあるとはいえ、非エンジニア職は保守できない
- メール周りのテストは一工夫必要であり、手間がかかる
どう使い分けるべきか？
- Playwrightを採用したほうが良いケース
- エンジニア職だけでE2Eテストを構築する場合
- コードが読み書きできるQAエンジニアがいる場合
- Datadogを採用したほうが良いケース
- E2Eというよりは監視目的のケース
- QAチームにコードが読み書きできないエンジニアがいる場合
- QAやリグレッションテストを非エンジニアが実施する場合
生成AIによってテストコードの作成や保守は楽になりました。ブラウザ操作のMCP等はありますが、今となってはおそらくDatadogのテストケースを修正するよりもPlaywrightのテストケース（コード）を修正する方が早いです。また、大量にテストケースを作成したり、同じような修正を加える場合は間違いなくPlaywrightの方が早いでしょう。
Flakyなテストケースが発生してしまう割合はどちらも変わらない印象です。今回Playwrightに乗り換えましたが、Flakyの問題は発生しています。ただ、Playwrightの方がlocalで実行できるのでデバッグしやすく、解決しやすいです。
Datadogが全くダメなのかというとそうでもないです。
例えばCIの一環としてのE2Eテスト目的ではなく、監視目的ではDatadogの方が良いと思います。例えば本番環境での問題発見を早めるために、本番環境に対して定期的にテストを行いたいケースです。Playwrightでもできないことはないですが、DatadogはSaaSですし、通知機能や定期実行機能を内蔵しているので素早く構築できそうです。このような構築を非エンジニアやQAエンジニアだけでできるという点はメリットかなと思います。
RUMとの統合
また、Datadogではテスト実行時にパフォーマンスチェックも同時にできます。これはReal User Monitoring(RUM)という製品を併用すると見れるようになります。
E2E実施時に見るべきかは少し疑問が残りますが、パフォーマンスに厳しい場合はこれは有益かなと思います(※スクショ以外にもトレースなどRUM、APMの情報を色々見れます)。
当社ではこの機能は活用しきれていませんでしたが、成熟したチームや大規模なチームにとってはこの機能は重宝されるかもしれません。
ロケーションを変えたテスト実行
Location機能はグローバルサービス展開をしているチームにとっては良いと思います。それぞれのリージョンごとにサーバーを立てている場合や、それぞれのリージョンでの性能が気になる場合は、この機能で簡単に実行できます。Playwrightでも実行環境を増やせば実現できますが、構築の手間はありますし、少なくともGitHub Actionsなどでは簡単には実現できません。
※対象を増やすほどテスト数は増えるのでコストが高くなります
メールのアサーション
メールのアサーションが簡単にできる点も良いです。Playwrightでも実現はできますが、多少の作り込みが必要です。
実際に当社ではフォームにDatadogのテンポラリメールアドレスを入れてメール送信し、正しい内容のメールが受け取れたか？というテストを過去に行っていました。
蛇足
こちらの記事では
DataDogでブラウザテストのシナリオを修正したい場合、操作を一からやり直すことになります。一方Autifyでは、シナリオの途中から編集することができます。
というように説明されていますが、これは不正確です。Datadogでも途中から操作を記録、編集することはできます。例えば合計10ステップある操作のうち、5〜7ステップだけを変更したい場合は、記録を始める前に手動で4の部分まで進めて、そこから記録を開始すれば5〜7だけ入れ替えるということができます。ステップはドラッグ&ドロップで順番を入れ替えることもできるため、編集コストはAIよりは高いものの、手動でやるとしてもそこまで高くはないと思います。
技術選定の難しさ
これは余談ですが、今回の移行で改めて技術選定における意思決定の難しさを実感しました。
技術選定は多次元のトレードオフを伴います。ビジネス要件との整合性、スケーラビリティ、セキュリティ、チームの習熟度、学習コスト、エコシステムの成熟度、コミュニティの活性度、保守性、ROI、経営・技術戦略から見た投資タイミングなど、考慮すべき要素は枚挙にいとまがありません。技術選定は最適解ではなく「現時点での最良の妥協点」を見出すことが求められるのかなと思っています。
Playwrightは2020年頃から存在しますが、爆発的に流行ったのは2024年頃からです。
私がDatadogの技術選定をしたのは2023年初頭です。当時、生成AIの台頭やPlaywrightのエコシステム成熟を予見し、先回りしてPlaywrightを採用すべきだったのか？という問いに対しては、答えはNoだと考えています。
2023年初頭時点では、生成AIによるコード生成はまだ今ほど洗練されていませんでしたし、Playwrightのコミュニティも現在ほど成熟していませんでした。当時の情報と制約の中では、ノーコードで保守性を担保できるDatadogは合理的な選択だったと思います。
この経験から、技術選定において「将来の不確実性」は避けられないことだと学びました。重要なのは完璧な予測ではなく、以下の2点だと考えています。
- 適応力の高いアーキテクチャ設計：特定ツールへのロックインを避け、移行コストを最小化する設計や選定を心がける
- 定期的な技術選定の見直し：一度決めたら終わりではなく、エコシステムの変化を継続的にキャッチアップし、ROIなどを再評価する
完璧な技術選定は無いと思うので、環境変化に柔軟に適応できるアーキテクチャや組織作りを意識し、最適解を見つけるのではなく、最良の妥協点を見つけることが必要だと考えています。
Playwrightに移行してから開発メンバーは良い感触を得ているようです。今回の記事はDatadog寄りの内容が多くなりましたが、今後はPlaywrightに対する知見も投稿していきたいです。
現在、ミツカリではITエンジニアを募集しています。興味のある方はぜひお気軽にご連絡ください！
