# Benchmarking Microservice Systems for Software Engineering Research > [!abstract] 概要 > マイクロサービスは産業界で普及し重要であるにもかかわらず、マイクロサービスに関する研究は限られている。その一因は、産業用マイクロサービスシステムの特性を反映したベンチマークシステムが無いことである。この欠落を埋めるため、我々は文献とオープンソースシステムを調査し、既存のベンチマークシステムと産業用マイクロサービスシステムとの差を特定する。この差の分析結果に基づき、マイクロサービスアーキテクチャの中規模ベンチマークシステムを開発して公開する。 ## 論文情報 - タイトル: Benchmarking Microservice Systems for Software Engineering Research - 著者: Xiang Zhou, Xin Peng, Tao Xie, Jun Sun, Chenjie Xu, Chao Ji, Wenyun Zhao([[Fudan University]]、Shanghai Key Laboratory of Data Science、University of Illinois at Urbana-Champaign、Singapore University of Technology and Design) - 媒体: ICSE 2018 Companion(40th International Conference on Software Engineering: Companion Proceedings、2018-05-27〜06-03、ヨーテボリ)。2 ページのショートペーパー - DOI: 10.1145/3183440.3194991 - リポジトリ: `microcosmx/train_ticket`(のちの `FudanSELab/train-ticket`)。ベンチマーク実体は [[Train-Ticket]] ## 概要 マイクロサービス研究が進まない原因を、産業システムに似たオープンなベンチマークの不在に求める。文献とオープンソースを調べて既存ベンチマークの不足点を 4 つに整理し、それを埋める 24 マイクロサービスの鉄道チケット予約システム TrainTicket を公開する。 ## 問題設定 産業のマイクロサービスシステムの大半は非公開で、研究は数個のマイクロサービスからなる非公開の小さなシステムに頼っている。先行研究(Francesco ら)が調べた範囲でも、オープンソースのベンチマークは 1 件で、マイクロサービスは 5 個にとどまる。マイクロサービスの開発・運用に関する研究を支えるには、産業システムの特性を持つ公開ベンチマークが要る。 ## 提案手法 ### 既存ベンチマークの調査 - 文献: ACM Digital Library・IEEE Xplore・Web of Science・Scopus で検索語 `microservi* OR micro-servi* OR micro servi*` をタイトル・要旨・キーワードに適用し、論文で説明されたシステムが公開されているかを手で確認した。公開されていたのは 5 件で、いずれも GitHub 上のオープンソースだった。 - オープンソース: GitHub と BitBucket で `micro` と `service` を検索し、上位 100 件ずつを手で調べた。モノリスに Docker デプロイなど一部の技術だけを使う案件が多く、インフラ系(開発ツール・運用フレームワーク)と 5 個未満の案件は除外した。数える対象はビジネス機能を実装するマイクロサービスで、サービスレジストリ・ディスカバリ・ロードバランスなどのインフラ用は含めない。 表1(Table 1) オンラインで入手できるベンチマークシステム(#S はマイクロサービス数、Sync は同期呼び出し、Async は非同期 REST 呼び出し、Queue はメッセージキュー) | 名称 | #S | 相互作用モード | |---|---|---| | Acme Air | 5 | Sync | | Music Store | 6 | Sync, Async | | Spring Cloud Demo Apps | 6 | Sync | | Bifrost Microservices Sample Application | 5 | Sync, Async | | Socks Shop | 8 | Sync, Queue | | Staffjoy | 9 | Sync, Queue | | NServiceBus | 8 | Queue | ### 産業システムとの差 4 点 - 相互作用モードの不足: 各システムが使うのは 1〜2 モードだけで、非同期通信や同期との混在に起因する問題を再現できない。 - 規模と複雑さの不足: マイクロサービス数が少なく呼び出しチェーンも短い。複雑な相互作用でだけ現れる問題を扱えない。 - 設計原則の適用不足: ビジネス能力ごとのモジュール化、1 チームで開発・配備・運用できる大きさといった原則を十分に守っていない。 - テストの不足: 単体テストと結合テストが乏しく、テスト・デバッグ研究の土台になりにくい。 ### TrainTicket - 題材は鉄道チケット予約。都市間の便の照会、乗客と座席クラスの選択、予約、支払い、メール通知、出発前後の変更を備える。 - ビジネスロジックのマイクロサービスは 24 個(インフラ用を除く)。マイクロサービス間の依存関係に従い 5 層に分ける(図1)。最下層は他に依存せず、上位層は下位層に依存し、同一層内の依存もある。 - 高速列車用と普通列車用で予約・注文・検索のマイクロサービス群を分けた。利用者数に応じて Docker インスタンス数を変える柔軟な配備ができる。 - 同期呼び出し・非同期呼び出し・メッセージキューを全て使う。 - Spring Boot で開発し、Java と Node.js で実装した。 ![[_attachments/2018__ICSE__Benchmarking-Microservice-Systems-for-Software-Engineering-Research/fig1-trainticket-architecture.png]] 図1(Figure 1) TrainTicket のアーキテクチャ。ゲートウェイの下に、サービスディスカバリ・サービスレジストリ・ロードバランス(左端のインフラ枠)を置き、ticket reserve や high-speed ticket reserve から order・notify・basic info・config・station などの下位サービスへ 5 層で依存する。データベースは省略されている。 ## 新規性 - 公開ベンチマークの不足を、論文と GitHub / BitBucket の二経路での体系的調査で定量的に示した点。 - 既存ベンチマークの 5〜9 個に対し、ビジネスマイクロサービス 24 個・5 層・3 種の通信モードを備えた中規模ベンチマークを公開した点。 ## 実験設定 実験はない。調査は文献 4 データベースと 2 つのオープンソースプラットフォームの上位 100 件で、実装規模とテスト数を報告するにとどまる。 ## 実験結果 - 入手可能な既存ベンチマークは 7 件で、ビジネスマイクロサービス数は最大 9(Staffjoy)。広く使われる Acme Air は 5 個である。 - TrainTicket の実装は 61,136 行。単体テスト 37 件と結合テスト 14 件があり、テストコードは 5,218 行。すべて公開リポジトリにある。 ## 考察 - 本文は、研究上の用途として開発・運用支援を挙げ、キーワードにトレーシング・可視化・デバッグ・障害診断を置く。後続の障害箇所特定・根本原因分析研究で TrainTicket が共通基盤になった経緯は [[Train-Ticket]] を参照。 - 24 という個数はインフラ用を除いたビジネスマイクロサービスだけの数で、後年の文献が挙げる 41・47・64 とは数え方が異なる(詳細は [[Train-Ticket]])。 ## 強み / 弱点・課題 - 強み: 調査の手順(検索語・除外基準・数え方)が明示され、TrainTicket の設計動機が既存ベンチマークの 4 つの不足に 1 対 1 で対応する。 - 弱点: 2 ページのため、TrainTicket が産業システムに近いという主張の実証(通信パターンや障害の再現性、産業システムとの比較)がない。「現実的」とする根拠は規模と構造の記述にとどまる。 - 弱点: 調査は 2017 年 8 月ごろの時点で、上位 100 件の手作業選別に依存し、再現手順の詳細は本文にない。