> [!abstract] 概要(arXiv abstract の日本語訳) > マイクロサービスシステムのテストには、多くの計画と問題解決が必要となる。マイクロサービスシステムの規模と構造が複雑になるほど、テストの困難度は増す。マイクロサービスコミュニティの支援と、テストおよびトラフィックシミュレーションの実験簡略化のため、我々は確立された 2 つの open-source マイクロサービスシステムを完全な機能テストカバレッジで包含するテストベンチマークを作成した。ベンチマーク設計を通じて、特定の課題を克服する方法と、マイクロサービステストにおける効果的な戦略の発見方法を実演することを目指した。さらにベンチマーク利用例として、サービス依存グラフ発見とトレーシングを用いたビジネスプロセス発見によりテスト全カバレッジを検証する最良アプローチを特定する事例研究を実施した。 ## 論文情報 - タイトル: Benchmarks for End-to-End Microservices Testing - 著者: [[Sheldon Smith]], [[Ethan Robinson]], [[Timmy Frederiksen]](Baylor University); [[Trae Stevens]], [[Tomas Cerny]](Baylor University); [[Miroslav Bures]](Czech Technical University, FEE); [[Davide Taibi]](University of Oulu, M3S Cloud Group) - 媒体: arXiv 2306.05895v1 [cs.SE], 2023-06-09 - 公開資産: Zenodo(case study テストベンチマーク、DOI 10.5281/zenodo.7877723) ## 概要 [[Train-Ticket]] と [[eShopOnContainers]] という 2 つの well-established open-source マイクロサービスシステムに対し、Selenium + JUnit/TestNG による functional regression テストと、Gatling による load testing を体系的に組み合わせたテストベンチマーク群を提案する。両ベンチマークは Zenodo で公開され、後続研究が同一テスト群を再利用できるようにする。本稿は、benchmark 構築途上で遭遇した課題と best practice(authentication token 再利用・form parameter 取り扱い・並列化など)を case study 形式でまとめる。 ## 問題設定 マイクロサービス研究コミュニティでは個別研究が独自テストで効果を主張するため、結果比較や再現が困難である。著者らは「2 つの確立された OSS マイクロサービスシステムに対する共通テストスイート」が欠けていると認識し、Train-Ticket と eShopOnContainers を選定して機能テスト + 負荷テストの双方を整備する。Train-Ticket は version 1.0.0(2022-08-09 リリース、Fudan University CodeWisdom Team 作成、47 microservices、Java Spring Boot/Spring Cloud + Node.js + Python + Go + MongoDB + MySQL)、eShopOnContainers は version 5.0.0(.NET Application Architecture 参照アプリ、C# 製、HTML + Angular 2 + mobile)。 ## 提案手法 ### 機能テスト(functional regression testing) - 各 microservice のユースケースを全列挙したスプレッドシートを作成 - 当初 Katalon Web Recorder を試したが冗長・非モジュラ性のため放棄、手書きの Selenium スクリプトに移行 - Chrome WebDriver でデバッグ、HTML Unit WebDriver(GUI なし)で高速化 - 実行 framework を JUnit から TestNG に移行して **parallelization** を実現(eShop は 25s → 6-7s) - テストはサービス単位でグループ化、個々の assertion をメトリック単位とする ### 負荷テスト(load testing) - [[Gatling]] 3.9.2 を使用 - 240 エンドポイントを Train-Ticket 全体で列挙し、41 サービスが endpoint を持つことを確認 - **認証 token は login 応答 body から `.check(jsonPath("$.token").saveAs("user_token"))` で抜き出して以降の request header に注入**(hard-code を避ける) - form parameter は 2 方式: `.formparam(name, value)`(少量)/ `.body(RawFileBody("login_form.json"))`(JSON で大量・動的) ### ベンチマーク 3 要素(Hamilton ガイドラインに準拠) 1. **Workload Specifications**: 100/500/1,000/2,500/5,000 ユーザで 30 秒間負荷 2. **Metric Specifications**: response time、800ms 超のリクエスト割合 3. **Measurement Specifications(SLA)**: 800ms 超の割合 < 20% を合格とする ## 新規性 - 単一システムのみを扱う既存ベンチマーク群と異なり、**Java/Spring 系の Train-Ticket と C#/.NET 系の eShopOnContainers** の 2 軸でテストスイートを提供 - 機能テストと負荷テストの両面を網羅し、両者の case study で best practice(parallelization・auth token 抽出・form parameter 表現)を実践的に提示 - Selenium scripts と Gatling scenarios をすべて Zenodo に公開し再現可能性を確保 ## 実験結果 ### Train-Ticket Booking(Table IV) | 同時ユーザ数 | 800ms 超 | 総 request | 800ms 超 % | |---|---|---|---| | 100 | 3 | 706 | 0.4% | | 500 | 259 | 3,530 | 7.3% | | 1,000 | 721 | 7,060 | 10.2% | | 2,500 | 3,813 | 17,650 | 21.6% | | 5,000 | 15,249 | 35,300 | 43.2% | → **1,000 ユーザで合格(< 20%)、2,500 で不合格**。 ### eShopOnContainers Checkout(Table V) | 同時ユーザ数 | 800ms 超 | 総 request | 800ms 超 % | |---|---|---|---| | 100 | 0 | 2,244 | 0.0% | | 500 | 52 | 11,253 | 0.5% | | 1,000 | 4,276 | 22,479 | 19.0% | | 2,500 | 35,952 | 56,343 | 63.8% | | 5,000 | 75,910 | 112,593 | 67.4% | → **1,000 ユーザは合格寄り、2,500 で大きく不合格**(majority が 800ms 超)。 両 system で **login シナリオが特に脆弱**。credentials validation のロジックが共通の bottleneck。 ## 考察 - **Train-Ticket の consign service** は deploy できず、テストは書いたが verify できなかった旨を明記 - 200 ms(理想)/1,000 ms(許容上限)の通説を踏まえ 800 ms threshold を採用 - benchmark の reproducibility が研究比較に必須 ## 強み / 弱点・課題 ### 強み - 2 つの well-known OSS マイクロサービスシステムを同一手法で扱い、機能 + 負荷の両軸を統一 - 全 artifact を Zenodo で公開、再現可能 - best practice(token 抽出・form parameter・parallelization)を実装込みで提示 ### 弱点・課題 - 評価対象は 2 system のみ、別ドメインでの一般化は未検証 - 負荷シナリオは 30 秒に限定、長期負荷下の挙動は対象外 - Train-Ticket consign service が deploy できず一部テストは未検証 - 評価サーバ(Ubuntu 1TB SSD・32GB・3.2GHz 6 cores)で測定した絶対値であり、別環境ではしきい値が変わる - 「800ms < 20%」は実用的だがやや恣意的、SLI/SLO 設計の体系([[エラーバジェット]])と接続されていない ## 関連リンク - データセット: Zenodo [10.5281/zenodo.7877723](https://zenodo.org/records/7877723) - 関連 source: [[@2019__ASPLOS__An Open-Source Benchmark Suite for Cloud and IoT Microservices]](DeathStarBench、別系統の MS benchmark) - 後続: [[@2024__MSR__A Dataset of Microservices-based Open-Source Projects]](同じく Cerny+Taibi 主導の OSS-MS 系統的 dataset)・[[@2026__SANER-C__TrainTicketTrace - A Multi-Fault Distributed Dataset for Microservice Fault Detection and Localization]](同じく Train-Ticket をベースに fault dataset を構築)