マイクロサービスにおける軽快なE2Eテストを、ローカルとEC2のハイブリット構成で実現

はじめまして! これはディップ Advent Calendar 2023 の16日目の記事です。

目次

1. はじめに
2. なぜWindowsとMacを使うメンバーが混在したことで生産性が下がったのか？
3. 対象者
4. ざっくりとしたプロダクトのアーキテクチャ
5. 最初の構成の問題点
6. 解決策
7. 実際にハイブリット構成で運用してみたことによる所感
8. おわりに

はじめに

はじめまして、ディップ株式会社で開発エンジニアをさせていただいております。@sogenです。

この記事では、私のチームで実践したローカルとEC2のハイブリット構成のE2Eテスト環境の構築設計をご紹介します。

早速ですが、皆さんはどんなPCをお使いでしょうか？
主にPCにはWindowsとMacの2種類があるかと思います。

今回はこの2種類のPCを用いて開発したことにより、生産性が低下してしまったお話と、それを解決した手法の紹介をできればと考えています。

なぜWindowsとMacを使うメンバーが混在したことで生産性が下がったのか？

本プロダクトでは開発初期の段階では主にWindows PCの開発者だけで開発が進んでいたのですが、ある日Macを利用している開発者がアサインされることになりました。私です。

後ほど詳しく説明するのですが、開発を進めていくうちに、MacとWindowsのプログラム実行環境の違いによるMac端末特有の不具合がところどころ出てくるようになってきました。

当初はwindowsの端末に変えることを検討したのですが、後々Mac端末を使うメンバーも増えていくことが予想できる状況だったのでwindowsとMacユーザー両方が開発できるようなE2Eテスト環境にしていこうと思い、テスト環境の改善に取り組んでいく運びとなりました。

対象者

以下の人を対象者にしています。

• Windows,Macを使う人両方が開発チームに存在している人
• Apple製のCPUで立ち上がらないコンテナが存在し困っている人
• マイクロサービス構成のシステム開発をしているがE2Eテストの自動化に何かしら問題を抱えている人

ざっくりとしたプロダクトのアーキテクチャ

• 前提として、私の所属するチームで作っているプロダクトは複数のサービスが互いに通信し合い稼働しているマイクロサービス構成になっています。
• 開発の際には、Dockerコンテナを利用しており、複数コンテナをローカルで起動させています。
• E2Eテストではnewman/postmanのコンテナイメージを用いています。

• 最初の構成は以下のような形でした。(あくまで例として挙げているので実際の使用言語やDBとは多少異なっています)

これはローカル上で newman/postman のイメージコンテナがservice①コンテナに接続をして、あらかじめpostman用の定義ファイルに記述してあるテストケース全てを順に実行して期待値通りのレスポンスが返ってきているかを確認する構成になっています。

また、service①コンテナはサブモジュールコンテナ群(service②~⑦のイメージコンテナ)に接続する形のE2Eテストを行っています。(全てのコンテナはdocker-composeで起動され、そのままテストが実行される仕組み)

最初の構成の問題点

Mac本体で全てのコンテナを起動すると、実行が極端に遅くなる

Macに搭載されているM1/M2チップ(ARM64のCPUアーキテクチャ) による処理実行に適さないコンテナイメージを利用していました。(例えばSQL Serverのコンテナイメージなど)

そのため、コンテナ実行の際にRosetta2というエミュレーターを使う必要がありWindowsでの実行時間と比較して、時間がかかってしまう問題がありました。

また、LimaというMacOS上でLinuxの仮想環境を構築できるツールの採用を検討したのですが、Dockerを操作する際にGUIではなくCLI操作になってしまう点や、Limaを導入する際にリソースを割いてしまうこと、Docker DesktopユーザーにDocker DesktopをアンインストールさせてLimaの環境を立ててそこにDockerをインストールさせる手間があるといったデメリットがあるため採用を見送ることにしました。

解決策

結論

結論として以下の構成に変更することでE2Eテストを高速で実行することが可能になりました。EC2(AmazonLinux2)は運良く元々プロダクト開発の検証用に用意していただいていたものがあったのでそちらを利用することにしました。

ローカルマシン上で、newman/postmanのイメージコンテナとservice①コンテナを立ち上げ、postmanからはservice①コンテナへ接続、service①コンテナからはEC2のサブモジュール用コンテナ群へ接続する構成にしました。

本解決策を採用したことで得られたメリット・デメリット

本解決策を採用したことで得られたメリット・デメリットは以下の通りです。

メリット

1. ローカルで立ち上げるコンテナが減ったことでPCのリソースを節約できる。
2. Macに搭載されているM1/M2チップ(ARM64のCPUアーキテクチャ) による処理実行に適さないコンテナイメージをEC2に配置することで、サクサク快適な処理速度でコンテナ実行が可能になる。

デメリット

1. EC2インスタンスの料金が多少かかるため、予算がない場合は実現できない。(私のチームは元々存在する検証用EC2を用いたため追加のコストは無し)
2. EC2インスタンスのタイプによっては、postmanでローカル環境から高速で次々にリクエストが送られることによる負荷に耐えられなくなり、実行中ステータスのEC2インスタンスがクラッシュして再起動しなければいけなくなる。(EC2インスタンスのタイプによっては負荷に耐えられない)

実際にハイブリット構成で運用してみたことによる所感

1. Mac端末だけでなくWindows端末や低スペック端末を使っている開発者の開発体験が向上した

まず、このハイブリッド構成を設計、構築していくにあたって予想外だったことはWindows端末を利用している開発メンバーの開発体験が著しく向上したことです。

特にwindows端末で8GBのものを利用していた開発者の方からは、私の作成したハイブリッド構成のE2Eテスト環境を利用することによってPC本体のリソースを圧迫することなく開発を進められたと感想をいただきました。

その方によると、最初のE2Eテストの構成ではローカルで全てのコンテナがビルドし終わるまでに数十分かかっていたそうですが、私の今回設計構築したハイブリッド構成のE2Eテスト環境下では、すでにほとんどのサービスはEC2で実行されているためビルド時間は数十秒までに短縮 されたそうです。

テスト実行の時間も余裕あるリソース分配によりかなり短縮できるようになったそうです。

2. EC2のコストに対する費用対効果

費用対効果の件についてお話しします。ここまでお読みくださった皆様は気になっていると思いますが、今回ハイブリッドE2Eテスト環境を導入した検証用のEC2のサイズは「t3.large」で、こちらの記事の表によると大体79USD/月になります。1万円を超えてしまいますね。。
(ただし、検証用インスタンスは業務時間を超えると自動停止するように設定してあるため実際にかかる料金はもっと安いです。)

検証用に立てられたEC2インスタンスに今回のハイブリッド構成のE2Eテスト環境を導入したことにより従来の用途に加えてもっと意味のあるインスタンスになったのではないかと個人的には感じています。このハイブリッドE2Eテスト環境の導入によって得られた生産性の向上は1万円以上の価値があるのではないかと考えています。

おわりに

マイクロサービス構成における軽快なE2Eテスト環境を、ローカルとEC2のハイブリッド構成で実現したお話をさせていただきましたがいかがでしょうか？

今回のハイブリッド構成のE2Eテスト環境は元々「Mac端末でもストレスフリーでpostmanを実行したい！」という思いで設計構築しましたが、Windows端末や低スペックのPCにもポジティブな影響があったのは嬉しい誤算でした。

本E2Eテスト環境の設計構築は、実際の機能の開発とは別軸で私自身が主体となってテックリードの上司をはじめとする開発者メンバーに広く意見をいただきながら軌道修正を何度も繰り返しつつ進めていきました。私一人の力では今の形になっていなかったと思います。

もし、本記事に対してご質問がある方がいらっしゃれば気軽にお聞きいただけると幸いです〜。
それでは、最後までお読みいただきありがとうございました。

参考：AWS EC2の月額料金の一覧表を作ってみた