E2Eテストを最大63%高速化！AWS上での並列実行でCI/CDのボトルネックを解消した事例
はじめに
こんにちは。株式会社ココナラ QAグループの鈴木（まるちゃん）です。
皆さんの開発チームでは、E2Eテストがリリースフローのボトルネックになっていませんか？品質向上のために導入したはずの自動テストが、実行時間の長さから開発サイクルの足かせとなってしまうのは、多くのチームが直面する課題です。
ココナラでも、2023年にAppiumで構築したモバイルアプリのE2Eテストがリリース遅延の原因となり、開発チームから「テストが遅い」という声が上がるようになりました。
本記事では、この課題を解決するために、私たちがどのようにAWS EC2上でE2Eテストの並列実行環境を構築し、テスト時間を最大63%削減したか、そのアプローチと結果について詳しくご紹介します。
E2Eテスト導入の背景と、実行時間の課題
ココナラでは、2023年前半に本番環境での障害流出率が上昇傾向にありました。この課題への対策として、特に重要となるユーザー体験の核（CUJ: Critical User Journey）に対するE2EテストをWebとモバイルアプリに導入しました。
そして2023年9月には、リリース前にE2Eテストを実行することが必須となりました。
この取り組みは非常に効果的で、これまでに通算30件以上の本番障害を未然に防ぐという大きな成果を上げています。
しかし、このE2Eテスト運用が定着するにつれ、 「E2Eテストの実行時間が長すぎる」 という新たな問題がCI/CDパイプラインのボトルネックとして浮上してきたのです。
ボトルネックはモバイルアプリのE2Eテスト（実行時間120分）
開発チームのリリースを妨げていたのは、特にモバイルアプリのE2Eテストでした。当時のテスト実行時間は以下の通りです。
| 実行タイプ | モバイルアプリ | Web |
|---|---|---|
| 全件実行 | 120min | 18min |
| 最小限実行 | 25min | 6min |
| 最小限＋α実行 | 30min | 10min |
モバイルアプリの改修時には、すべてのテストケースを実行する「全件実行」が必要で、これに2時間もかかっていました。
この状況に、ココナラの高速な開発サイクルが追い打ちをかけます。
長いテスト時間とこれらの制約が組み合わさることで、リリース待ちの「渋滞」が頻発。E2Eテストが、開発のスピードを著しく低下させる要因となってしまっていたのです。
解決策：Jestの並列実行とAWS EC2インスタンスの最適化
このテスト実行時間という課題を解決するために、我々はE2Eテストの並列実行による高速化を決断しました。
並列化環境を構築するにあたり、以下の3つの観点を重視しました。
アーキテクチャ改善：OS制約に応じたインスタンスの使い分け
これらの観点を踏まえ、私たちはiOSとAndroidで異なるアプローチをとることにしました。
iOS: Macインスタンスのスケールアウト
before
after
iOSはMacOSでしか実行できないという絶対的な制約があります。そのため、並列数を増やすには単純に実行マシン（EC2 Macインスタンス）の台数を増やすしかありません。
そこで、mac2.metal インスタンスを1台から2台に増設し、並列数を2から4へ倍増させるスケールアウト戦略をとりました。
かつJestの shared を利用してテスト実行を半分にし、それぞれのEC2にテスト実行のリクエストをする仕組みに変更しました。
Android: 高性能なLinuxインスタンスへのスケールアップ
before
after
一方、AndroidのテストはMacOSで実行する必要はありません。ここがコストとパフォーマンスを両立させる最大のポイントでした。
これまでiOSと同じ mac2.metal で実行していましたが、これをはるかにコストが安く、メモリ性能が高いLinuxベースの c5.metal インスタンスへ移行することにしました。
これにより、コストを抑えながらメモリを16GiBから192GiBへと大幅に増強し、並列数をJestのmaxworkersを利用して2から10へと一気に引き上げるスケールアップが実現できました。
改善結果：テスト時間を最大63%削減し、コストも最適化
このアーキテクチャ変更の結果は、以下の表の通りです。
| iOS(変更前) | iOS(変更後) | Android(変更前) | Android(変更後) | |
|---|---|---|---|---|
| OS | Mac | Mac | Mac | Linux |
| インスタンスタイプ | mac2.metal | mac2.metal | mac2.metal | c5.metal |
| インスタンス数 | 1台 | 2台 | 1台 | 1台 |
| メモリ | 16GiB | 16GiB | 16GiB | 192GiB |
| 並列数 | 2端末 | 4端末 | 2端末 | 10端末 |
| 年間コスト | ¥565,344 | ¥1,130,688 | ¥565,344 | ¥356,602 |
そして、肝心のテスト実行時間は劇的に短縮されました。
| 実行タイプ | 移行前 | 移行後(Android) | 移行後(iOS) |
|---|---|---|---|
| 全件実行 | 120min | 45min (-63%) | 60min (-50%) |
| 最小限実行 | 25min | 12min (-52%) | 16min (-36%) |
| 最小限＋α実行 | 30min | 15min (-50%) | 19min (-36%) |
最大の懸念だったモバイルアプリの全件実行時間は、iOSで半分の60分に、Androidでは45分へと大幅に短縮され、リリース渋滞は無事に緩和されました🎉
おわりに
本記事では、E2Eテストの実行時間がCI/CDのボトルネックとなる課題に対し、並列実行によって解決した事例をご紹介しました。
今回の改善の核心は、「モバイルアプリのE2Eテストにおいて、iOSとAndroidの実行環境をOS制約に基づいて分離し、それぞれに最適なAWS EC2インスタンスを選択した」という点にあります。特に、Androidを安価で高性能なLinuxインスタンス (c5.metal) に移行したことが、コストを抑えつつ高い効果を生む鍵となりました。
この記事を通して、「E2Eテストが遅い」という問題に対して「テストの並列化」や「実行環境の最適化」といった解決策があるという気づきを一つでも提供できていれば幸いです。
最後までお読みいただき、ありがとうございました。
ココナラではエンジニアを絶賛募集中です。
少しでも興味を持たれた方がいましたら、ぜひ下記の採用ページをご覧ください。
- 採用情報
- カジュアル面談をご希望の方
Discussion