---
title: E2E テストワークフローの高速化のためにやったこと
tags: 
author: [kofuk](https://convert.docswell.com/user/kofuk)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/57G3NY1DJL.jpg?width=480
description: E2E テストワークフローの高速化のためにやったこと by kofuk
published: October 02, 24
canonical: https://convert.docswell.com/s/kofuk/Z4VYNJ-2024-10-02-232724
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/57G3NY1DJL.jpg)

E2E テストワークフローの
高速化のためにやったこと
2024.10.02
サイボウズ株式会社 福田航生
1


# Page. 2

![Page Image](https://bcdn.docswell.com/page/4EQ5QMDXJP.jpg)

自己とチームの紹介
福田 航生
• X (Twitter): @man_2_fork
• Garoon という大規模向けグループウェア製品
の開発をやっています
右側が本人です（嘘）
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/KJ49NVZ271.jpg)

背景
• Garoon 開発チームでは、Four Keys に基づいてリリースを改善してきた
• Four Keys とは DORA が提唱しているソフトウェアデリバリーのパフォーマンスを示すメトリクス
• デプロイ頻度、変更のリードタイム、変更障害率、障害からの復旧時間
• 改善が功を奏し、リリースプロセスは軽量になった
• デプロイ頻度が 8 倍に増加
• 変更のリードタイムが 1/10 に短縮
• 障害変更率が 1/8 に低下
• サービス復元時間が 1/8 に短縮
詳細はこちら: Four Keysに基づくリリースプロセス改善とその成果
https://speakerdeck.com/ak1210/release-process-improvement-based-on-the-four-keys-and-itsresults
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/LE1K53RKJG.jpg)

リリースプロセスは軽量になったけれど……
E2E テストが通らなくて
一生リリースできないよ……
E2E テストワークフローの改善を進めていくことに……
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/GEWD5P1PJ2.jpg)

E2E テストが通らない理由
• CI で実行している E2E テストワークフローが不安定
• 不具合が検出されているわけではない
• 不安定要因は以下の 2 つに集約される
• テスト実行環境が不安定
• テスト自体が不安定（flaky test）
• これまでにも、いろんな対策を行ってきた
• レートリミット回避
• キャッシュの改善
• ワークフローのタイムアウト設定
• 何度か失敗するのは許容することにし、ジョブを自動で再実行
詳細はこちら: E2Eテストワークフローを高速化・安定化させる取り組み
https://www.docswell.com/s/r4mimu/ZXYR73-2024-05-16-184345
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/47ZGNKP6E3.jpg)

テスト実行環境が不安定
• Amazon ECS に構築した環境でテストを走らせている
• Garoon が systemd を使用しているため、privileged: true なコンテナで立ち上げる必要があった
• ECS on EC2 を使用する必要がある
• EC2 インスタンスの不調が不安定要因になっていた
• ECS に service を立てて、GitHub Actions から見えるようになるのを待っていた
• テストの並列実行のためにたくさん環境を立てる必要があり、都度サービスや ALB を立てていていた
• AWS 上に複数のリソースを作っていて、複雑
• 消すのも大変
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/YJ6Y8QML7V.jpg)

テスト実行環境が不安定問題の対処 1: privileged コンテナをやめる
• 本物の systemd のかわりに docker-systemctl-replacement という OSS を使うようにした
• systemd っぽい振る舞いをする Python スクリプト
• systemd の辛みが消えるかわりにこのスクリプトの辛みが生える
懸念もあったが、小さいスクリプトのためデバッグも比較的容易と
判断
• 本家では動かない機能を使っていたため、フォークを使用
• systemd を使わなくなったため、特権コンテナが必要なくなった
https://github.com/pakutoma/docker-systemctlreplacement
• もともとは CI ではなく、開発用の Docker イメージのために導入したもの
• ローカルの開発環境もシンプルになり、みんなハッピーに
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/GJ5G9RZMJ4.jpg)

テスト実行環境が不安定問題の対処 2: ECS の service をやめる
• mirage-ecs という OSS でデプロイを行うようにした
• ECS でコンテナを立ち上げて、それにリバースプロキシしてくれる
• API が生えていて、HTTP でリクエストを送ればタスクの
起動や停止ができる
• 一定期間使ってないインスタンスは勝手に落としてくれる
• まるで蜃気楼のようだ……（？）
• CI でケアするリソースが ECS のタスク定義だけになった
https://github.com/acidlemon/mirage-ecs
• ALB が 1 個で済むので、コスト的にも嬉しい！
• （特定の条件で panic するバグがあったので PR 送ったんですが、ちゃんと対応してもらえて助かりまし
た）
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/LE3RYP9975.jpg)

テストが不安定
• 不安定なケースを特定して修正する活動は行っている
• でもけっこう大変
• ある程度は失敗を許容しつつ、再実行を素早く行えるようにする
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/8EDY5LG8EG.jpg)

テストが不安定な問題の対処 1: ワークフローの自動リトライ
• E2E テストのワークフローが失敗した場合も、3 回までは再実行を許容する
• 環境要因の失敗があるので、デプロイからやり直してもらうのが手っ取り早い
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/V7P6G23WJ8.jpg)

テストが不安定な問題の対処 2: 失敗したケースのみを再実行
• ワークフローを再実行する際、既に成功したテストケースを実行しない
• 通ったケースも再実行すると遅くなるし、不安定なテストが複数含まれている場合に無限リトライ編になる
• 通ったテストケースのリストを S3 に保存しておき、再実行の際は失敗したケースだけを実行する
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/2JV36D49EQ.jpg)

まとめ &amp; これから
• テスト実行環境の改善と、テスト自体の不安定性の影響を小さくする活動をした
• でも、E2E テストが不安定な問題はまだまだ残っているのが現実……
• 快適な開発環境の維持には継続的な活動が必要
• テスト自体も良くして、開発の高速化と開発者体験向上していきたいですね！
ま、前よりはだいぶ楽になったかな～
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/5EG3NY147L.jpg)

©️ Cybozu, Inc.
13


