ソフトウェア自動化カンファレンススライドver完成版

Kubernetes対応マイクロサービスの テスト自動化： 実践的アプローチと課題解決法 株式会社ラクス 竹田 舜

自己紹介 ● 名前：竹田 舜 ● 株式会社ラクス 開発推進部 SRE課 ● 趣味：ライブ鑑賞 （ずっと真夜中でいいのに。を見に行くのが多い） ● X(旧Twitter)：https://x.com/TKDDDDDS ● Github：https://github.com/tkeshun

• https://x.com/TKDDDDDS
• https://github.com/tkeshun

今日話すこと E2Eテストの対象となったシステムの前提 E2Eテストを作った時にハマったところ 反省点と改善予定

今日話すこと E2Eテストの対象となったシステムの前提 E2Eテストを作った時にハマったところ 反省点と改善予定

なにをするサービスなのか？ サービスを契約した顧客用の 利用環境を作成 発行自動依頼 販売管理DB 環境発行を依頼 商材 商材 商材 商材 商材 商材 商材 発行 利用環境の自動作成する社内向けアプリケーション

アプリケーションの構成 K8s上 DB Batch 起動 API群 外部 システム BFF （仮） Batch 起動 メール 送信 同期 商材の環境発行・更新・削除を自動化 定期的に起動するサービスとそれらが利用するAPIで構成されたMSA ※実際のサービスと同等の図ではありません。ぼかしてます

E2Eテストで実現したいのは？ アプリケーションに対して サービス間連携がエラーなく動く 保証をする

テストで対応しないといけない要求 ● 複数の環境に対応 （ローカル、CI(Github Actions)、multipass, rancher desktop） ● ビルドのできることがチェックができる ● 同期→環境発行結果のメール送信確認までできる ● 外部システムはモックへ差し替え (データ同期対象のシステム、メールサーバー、その他依存API)

作成したテストの全体像 - コマンド コンテナ起動 コンテナのヘルスチェック アプリケーションのヘルスチェック 同期開始 DBのステータス確認 Goのコード （確認できるまで or リトライ許容回数までリト ライ） - メールの受信確認 所属部署の技術スタックとして Go がある。 試験的な試みでテスト管理を Goのコードでかいた

ここまで前提

今日話すこと E2Eテストの対象となったシステムの前提 E2Eテストを作った時にハマったところ（問題点） 反省点と改善予定

E2Eテスト実装時の問題点 ● 問題1 : テスト環境をどうするか？ ● 問題2 : Goのdocker 操作ライブラリが一部環境で使えない。 Compose Go SDKはDocker Desktopでしか使えない ● 問題３：バッチ処理を起点に非同期で動くので、結果がしばらく反 映されない（反映される時間が固定ではない）

E2Eテスト実装時の問題点 ● 問題1 : テスト環境をどうするか？ ● 問題2 : Goのdocker 操作ライブラリが一部環境で使えない。 Compose Go SDKはDocker Desktopでしか使えない ● 問題３：バッチ処理を起点に非同期で動くので、結果がしばらく反 映されない（反映される時間が固定ではない）

実行環境の候補と要求 要求 実行環境の候補 コンテナビルド可能 kind 検証環境 minikube docker compose マイクロ サービス連携検証が可能 複数の環境で実行可能 ● Github Actions ● multipass(docker ce) ● rancher desktop

どのテスト環境がいい？ minikube, kind 開発環境とは別に準備が 必要 検証環境 E2Eテスト用のコードを 混入させたくない docker compose 開発環境で使用

結論 ビルド、コンテナ起動・管理がまとめてできる 既存の開発環境であり、準備・実行コストが低い docker composeを採用

E2Eテスト実装時の問題点 ● 問題1 : テスト環境をどうするか？ ● 問題2 : Goのdocker 操作ライブラリが一部環境で使えない。 Compose Go SDKはDocker Desktopでしか使えない ● 問題３：バッチ処理を起点に非同期で動くので、結果がしばらく反 映されない（反映される時間が固定ではない）

Goからコンテナ操作をする際のハードル 前提：テスト実行管理をGoコードでやる試み 問題： Compose Go SDKはDocker Desktopしか使えない docker/cliはcompose関連がない&バージョンが不一致で使用不可

結論 絶対にGoだけで完結させたいほどの制約ではない 時間的なコストをかけないようにcompose up でサクッと解決

E2Eテスト実装時の問題点 ● 問題1 : テスト環境をどうするか？ ● 問題2 : Goのdocker 操作ライブラリが一部環境で使えない。 Compose Go SDKはDocker Desktopでしか使えない ● 問題３：バッチ処理を起点に非同期で動くので、結果がしばらく反 映されない（反映される時間が固定ではない）

結果確認が必要なのは？ APIアクセスが必要 BFFヘルスチェック DBのステータス確認 メール送信確認 バッチ起動かつ非同期なので、すぐには結果が反映されない

結論 単純ですが、 一番簡単にできて 効果あり！ リトライ回数を多めにとって 状態確認できるまで APIリクエストをリトライする

ここまでのまとめ ● docker composeがおすすめ 余計な学習コストなどがかからず他の人にも使ってもらいやすい ● 非同期処理は完了するまでリトライ 単純な仕組みで実現しやすい ● ヘルスチェックとdepends_onを活用しよう 起動順の制御や実行環境ごとの起動時間の差分を吸収できる

作ってみての反省点 以下反省点について話します！ ● composeファイルが２つある ● ヘルスチェックが一部Goコード内に記述 ● テストコードの起動がCLI

反省点① composeファイルが２つある ● ほぼ同じcomposeファイルが２つある 開発用：main.goを起動、並列起動数が１ テスト用：main.go→stub.goに差し替え、テスト用にコンテナを並列起 動 差分がほぼないがコンテナバージョンが変わった時に両方メンテする 必要がある 共通部分は同じファイルにしたい！

反省点① composeファイルが２つある 対処案：overrideを使用して解決する compose.yml 参考：https://docs.docker.jp/compose/extends.html 変えたい場 所だけ変 更可能 compose.override.y ml

• https://docs.docker.jp/compose/extends.html

反省点② （現状）テストコードの起動がCLI 現状 ①compose up app コンテナ ③🔄 コンテナ ヘルスチェック ② go run Goコード ● ● ● コンテナ起動とは別にコマンド起動が 必要 テストコード側からテスト環境の ヘルスチェックが必要 docker特有のコードが E2Eテストの コードに含まれてしまう

反省点②（対処案）テストコードの起動がCLI 対処案：改善の構想 ①compose up app コンテナ ② depends_on で起動を待つ ③ テストを キックする コンテナ起動 Goコード コンテナ ● ● ● compose upのみでテスト完了まで動く Goコード側にヘルスチェックコードが不要 全プラットフォーム共通の処理しか書かれ ない

比較 現状 ①compose up app コンテナ ③🔄 コンテナ ヘルスチェック ② go run Goコード ● ● ● 対処案：改善の構想 ①compose up app コンテナ ② depends_on で起動を待つ ③ テストを キックする コンテナ起動 Goコード コンテナ ● ● ● コンテナ起動とは別にコマンド起動が 必要 テストコード側からテスト環境の ヘルスチェックが必要 docker特有のコードが E2Eテストの コードに含まれてしまう compose upのみでテスト完了まで動く Goコード側にヘルスチェックコードが不要 全プラットフォーム共通の処理しか書かれ ない

まとめ 今日のポイント ● docker composeでE2Eテスト実行するのがおすすめ！ ● 非同期のサービス間連携の状態の把握は大変 →リトライしておけば状態の考慮を無視できる ● overrideを活用してcomposeファイルをスリムに保つ ● depends_on, healthを活用しよう→compose upでテスト完了まで放 置できる（予定）