--workersで実行時間を縮める
テストが安定して通るようになったところで、本題の並列実行に進みます。
計測の前提を揃える
今回のサンプルは、5つのプロジェクトに対してデスクトップ向け8本とモバイル向け2本のテストを組み合わせ、合計44件になりました。この44件を、ローカルとクラウドそれぞれでワーカー数を変えながら計測します。ワーカー数はコマンドラインの--workersで指定します。
筆者の環境（12コアのMac、クラウド側はEast Asiaリージョン）で計測した結果は次の通りです。
| 実行環境 | ワーカー数 | 所要時間 |
|---|---|---|
| ローカル | 1 | 14.8秒 |
| ローカル | 4 | 8.6秒 |
| ローカル | 8 | 10.5秒 |
| クラウド（Linux） | 4 | 約72秒 |
| クラウド（Linux） | 10 | 約60秒 |
| クラウド（Linux） | 20 | 27.4秒 |
クラウド実行はワーカー数を20まで増やしても27.4秒で、ローカルの8.6秒に届いていません。
理由は、テスト1本あたりの実行時間が0.2〜0.5秒と非常に短いことにあります。この規模では、リモートのブラウザへ接続する往復のオーバーヘッドが処理時間を上回り、クラウドの並列性が活きません。逆に言えば、クラウド実行が効いてくるのは、テスト1本が数秒以上かかる、あるいは件数が数百規模になり、ローカルのCPUでは並列度を稼げなくなってからです。前回述べた「テスト件数が多いほど恩恵が大きい」という性質が、数字として表れた形です。
ただし、クラウド側はワーカー数を4から20へ増やすと明確に短縮しており、並列度を上げる余地が十分残っていることは読み取れます。
増やしても速くならない点がある
一方でローカル実行の結果に注目すると、ワーカー数を4から8へ増やすことでかえって遅くなっています。
ポイントは、前回説明した本サービスの構造です。クラウドへオフロードされるのはブラウザの起動と描画であり、テストを制御するワーカープロセス自体は手元のマシンで動き続けます。ワーカーを増やせばクライアント側のCPUとメモリを消費するため、ある点を超えると別プロセスとリソースの奪い合いが起きてしまい、結果的に実行時間が遅くなる可能性が生じます。
他にもテスト全体の完了時間には、次の要因が影響します。
- クライアントマシンのCPU・メモリ（ワーカーを増やすほど消費する）
- テストコードの複雑さ（1本が重いほど並列化の効果は大きくなる）
- リモートブラウザまでのレイテンシ（リージョンが遠いほど不利）
- 対象アプリの負荷耐性（並列度に応じてアプリにも負荷がかかる）
ワーカー数の上限はワークスペースあたり100ですが、上限まで上げることが最適とは限らないのは表が示す通りです。まずローカルで2ワーカー以上を指定して正しく通ることを確認し、クラウドへ移してからワーカー数を振って計測する、という順序で最適値を探していくべきです。
リージョンアフィニティを確認する
実行時間に影響する要因のうち、レイテンシに直接効くのがブラウザのホスト先リージョンです。
Playwright Workspacesには「リージョンアフィニティ」という仕組みがあり、既定では、クライアントマシンにもっとも近いAzureリージョンのブラウザが使われます。テスト結果はいったんそのリージョンで収集され、ワークスペースのリージョンへ転送されます。開発者が国内から実行しても、CIエージェントが海外にあっても、それぞれに近いブラウザが割り当てられるわけです。
この設定は、Azureポータルの「設定」セクションにある「リージョン管理」から確認・変更できます。
既定の設定を無効にすると、クライアントの位置にかかわらず、ワークスペースを作成したリージョンのブラウザが常に使われます。テスト結果の保存先を特定のリージョンに固定したい場合はこちらを選びます。ただし特別な事情がなければ、既定のまま利用するのが無難です。
まとめ
今回は、projectsによるブラウザマトリクスの設計から、モバイルエミュレーションの追加、並列化で顕在化したテストの脆さの修正、--workersによる並列実行の実測までを行いました。
次回は最終回として、テスト結果ダッシュボードとTrace Viewerによる失敗分析、そしてGitHub ActionsへのE2Eテストの組み込みを取り上げ、継続的にテストを回す運用基盤の作り方を紹介する予定です。
