マイクロサービス

ソフトウェア工学において、マイクロサービスアーキテクチャとは、アプリケーションを、軽量プロトコルを介して通信する、疎結合で粒度の細かいサービスの集合として配置するアーキテクチャパターンである。マイクロサービスベースのアーキテクチャにより、チームはサービスを独立して開発および展開し、コードの相互依存性を減らし、コードベース内で可読性とモジュール性を高めることができる。これは、コードベース内のいくつかの依存関係を減らし、開発者が限られた制約内でサービスを進化させ、追加の複雑さを減らすことによって実現される。^[1]その結果、組織は急速な成長とスケーラビリティを備えたソフトウェアを開発できるだけでなく、既製のサービスをより簡単に実装することができる。これらの利点には、コードベース内で分離構造を維持する必要があるというコストが伴い、つまり、その初期実装はモノリシックコードベースの場合よりも複雑になる。^{[2]インターフェースは慎重に設計し、}APIとして扱う必要がある。

マイクロサービスはドメイン駆動設計における境界付けられたコンテキストに類似している。^[3]

意味

マイクロサービスには単一の定義はありません。業界では時間の経過とともにコンセンサスが形成されてきました。よく引用される定義特性には次のようなものがあります。

マイクロサービスアーキテクチャにおけるサービスは、多くの場合、HTTPなどの技術に依存しないプロトコルを使用してネットワーク経由で通信し、目的を達成するプロセスです。^[4]^[5]^[6]
サービスはビジネス能力を中心に編成されています^{[説明が必要]}。^[7]
サービスは、最適なものに応じて、さまざまなプログラミング言語、データベース、ハードウェアおよびソフトウェア環境を使用して実装できます。^[8]
サービスは規模が小さく、メッセージングが可能で、コンテキストによって境界が定められ、自律的に開発され、独立して展開可能であり、^[9]^[8]分散化されており、自動化されたプロセスで構築およびリリースされます。^[9]
マイクロサービスは、柔軟で独立して展開可能なソフトウェアシステムを構築するために使用されるサービス指向アーキテクチャの実装アプローチの特殊化です。^[7]

マイクロサービスは、モノリシックアプリケーション内のレイヤーではありません (たとえば、Web コントローラーやフロントエンドのバックエンドなど)。^[10]むしろ、明確なインターフェイスを備えた自己完結型のビジネス機能であり、独自の内部コンポーネントを通じて階層化アーキテクチャを実装できます。戦略的な観点から見ると、マイクロサービスアーキテクチャは基本的に「1 つのことを行い、それをうまく行う」というUnix 哲学に従います。 ^[11] Martin Fowler は、マイクロサービスベースのアーキテクチャを次の特性を持つものとして説明しています。^[4]

継続的デリバリーソフトウェア開発プロセスに適しています。^[12]アプリケーションの小さな部分を変更する場合は、1つまたは少数のサービスのみを再構築して再デプロイする必要があります。^[13]
きめ細かいインターフェース（独立して展開可能なサービス）、ビジネス主導開発（例：ドメイン駆動設計）などの原則に従います。^[14]

使用法

マイクロサービスアーキテクチャは、クラウドネイティブアプリケーション、サーバーレスコンピューティング、軽量コンテナーデプロイメントを使用するアプリケーションに採用されるのが一般的です。Fowler によると、サービスの数が多い (モノリシックアプリケーションの実装と比較した場合) ため、このようなアプリケーションを効果的に開発、保守、運用するには、分散型の継続的デリバリーと総合的なサービス監視を備えた DevOps が必要です。^[15]このアプローチに従うことの結果 (および根拠) は、個々のマイクロサービスを個別にスケーリングできることです。モノリシックアプローチでは、3 つの機能をサポートするアプリケーションは、これらの機能の 1 つだけにリソース制約がある場合でも、全体をスケーリングする必要があります。^[16]マイクロサービスでは、リソース制約のある機能をサポートするマイクロサービスだけをスケールアウトする必要があるため、リソースとコストの最適化のメリットが得られます。^[17]

2020年2月、クラウドマイクロサービス市場調査レポートでは、世界のマイクロサービスアーキテクチャ市場規模は2019年から2026年にかけて年平均成長率21.37%で増加し、2026年までに31億ドルに達すると予測されています。 ^[18]

歴史

1999年、ソフトウェア開発者のピーター・ロジャーズはヒューレット・パッカード研究所でデクスター研究プロジェクトに取り組んでいた。このプロジェクトの目的は、コードの脆弱性を軽減し、大規模で複雑なソフトウェアシステムを変更に対して堅牢にすることだった。 ^[19]最終的にこの研究の道は、 REST が特別なサブセットである汎用コンピューティング抽象化であるリソース指向コンピューティング(ROC) の開発につながった。2005年、Web Services Edge カンファレンスでのプレゼンテーションで、ロジャーズは「RESTサービス」を主張し、「ソフトウェアコンポーネントはマイクロ Web サービスです...マイクロサービスはUnix のようなパイプラインを使用して構成されます(Web と Unix の出会い = 真の疎結合)。サービスはサービスを呼び出すことができます (+ 複数言語ランタイム)。複雑なサービスアセンブリは、単純なURIインターフェイスの背後に抽象化されます。あらゆる粒度のあらゆるサービスを公開できます。」と述べた。彼は、適切に設計されたマイクロサービスプラットフォームが「WebおよびRESTサービスの基本的なアーキテクチャ原理をUnixのようなスケジューリングとパイプラインと組み合わせて適用し、サービス指向アーキテクチャに根本的な柔軟性と改善されたシンプルさを提供する」方法について説明しました。^[20]

また、2005 年にAlistair Cockburn は、マイクロサービスとともに使用されるソフトウェア設計パターンである六角形アーキテクチャについて書いています。このパターンは、マイクロサービスを他のサービスから完全に独立して展開および実行するために必要な補助サービスからビジネスロジックをレイヤーで分離するため、マイクロサービスの設計が可能になります。

サービスの粒度

マイクロサービスアーキテクチャを定義する上で重要なステップは、個々のマイクロサービスがどの程度の大きさであるべきかを判断することです。正しい答えはビジネスや組織の状況によって異なるため、これに対するコンセンサスやリトマス試験はありません。^[21]たとえば、Amazon はサービス指向アーキテクチャを使用しており、サービスが 3 ～ 10 人のエンジニアのチームと 1 対 1 でマッピングされることがよくあります。^[22]

適切なサービス粒度を見つけるために、アーキテクトはプログラマーと継続的にコンポーネント設計を繰り返す必要があります。アーキテクトは、ユーザーの要件、責任、アーキテクチャの特性（非機能要件とも呼ばれます）を考慮する必要があります。^[3]

ソフトウェアアーキテクチャのコンテキストでは、特定のバックエンドシステムの呼び出しや特定の計算の実行など、単一のタスク専用のサービスは、アトミックサービスと呼ばれます。出力を統合するためにアトミックサービスを呼び出すサービスは、複合サービスと呼ばれます。

サービスを小さくしすぎるのは悪い習慣と考えられています。実行時のオーバーヘッドと運用の複雑さがアプローチの利点を圧倒する可能性があるためです。サービスが細分化されすぎると、機能をライブラリとしてパッケージ化したり、他のマイクロサービスに統合したりするなど、代替アプローチを検討する必要があります。^[7]

システム構築の対象となるドメインをモデル化する際にドメイン駆動設計が採用されている場合、マイクロサービスは集合体のように小さくなることも、境界付けられたコンテキストのように大きくなることもあります。 ^[23]

マイクロサービスの粒度に関する議論には、さまざまな範囲があります。一方の端には、責任がそれほど多くない貧弱なサービスがあり、もう一方の端には、システムの大きなモジュールであるモジュラーモノリスがあります。

利点

アプリケーションをさまざまな小さなサービスに分解することの利点は数多くあります。

モジュール性：これにより、アプリケーションの理解、開発、テストが容易になり、アーキテクチャの劣化に対する耐性が高まります。^[8]この利点は、モノリシックアーキテクチャの複雑さと比較して議論されることがよくあります。^[24]

スケーラビリティ：マイクロサービスは互いに独立して実装および展開されるため、独立したプロセス内で実行されるため、独立して監視および拡張することができます。^[25]

異種システムとレガシーシステムの統合：マイクロサービスは、既存のモノリシックソフトウェアアプリケーションを近代化するための実行可能な手段と考えられています。^[26]^[27] 既存のソフトウェアの一部をマイクロサービスに置き換えることに成功した、または置き換えを進めている企業がいくつかあるという経験報告があります。^{[28]レガシーアプリケーションの}ソフトウェア近代化のプロセスは、増分アプローチを使用して行われます。^[29]
分散開発：小規模な自律的なチームがそれぞれのサービスを独立して開発、展開、拡張できるようにすることで、開発を並列化します。 ^{[30]また、継続的な}リファクタリングを通じて個々のサービスのアーキテクチャを構築することもできます。^{[31]マイクロサービスベースのアーキテクチャは}、継続的な統合、継続的な配信、展開を促進します。 ^[32]

批判と懸念

マイクロサービスアプローチは、次のようないくつかの問題で批判の対象となっています。

サービスは情報の障壁を形成する。^[33]
ネットワークを介したサービス間呼び出しは、モノリシックなサービスプロセス内のプロセス内呼び出しよりも、ネットワーク遅延とメッセージ処理時間の点でコストが高くなります。^[4]
テストと展開はより複雑です。^[34]^[35]
サービス間で責任を移すことはより困難です。^[8]異なるチーム間のコミュニケーション、別の言語での機能性の書き換え、または別のインフラストラクチャへの適合が必要になる場合があります。^[4]ただし、マイクロサービスはアプリケーションの他の部分とは独立してデプロイできますが、モノリスで作業するチームは同期して一緒にデプロイする必要があります。^[29]
サービスのサイズを主要な構造化メカニズムと見なすと、サービスが多すぎることになりかねませんが、内部モジュール化の代替案の方がよりシンプルな設計につながる可能性があります。 ^[36]これには、アプリケーションの全体的なアーキテクチャとコンポーネント間の相互依存性を理解する必要があります。^[37]
2段階コミットはマイクロサービスベースのアーキテクチャではアンチパターンとみなされており、トランザクション内のすべての参加者の結合が緊密になります。しかし、この技術が欠如しているため、データの一貫性を維持するために、すべてのトランザクション参加者が実装しなければならない厄介な問題が生じます。^[38]
多くのサービスの開発とサポートは、異なるツールや技術で構築されている場合、より困難になります。これは、エンジニアがプロジェクト間を頻繁に移動する場合に特に問題になります。^[39]
マイクロサービスで一般的に使用されるプロトコル（HTTP）は、一般向けのサービス向けに設計されているため、信頼性が求められることが多い内部マイクロサービスの動作には適していません。^[40]
マイクロサービスに特有のものではないが、分解手法では機能分解がよく使用されるが、これは要件の変更に対応できず、サービスの複雑さが増すことになる。^[40]
マイクロサービスの概念そのものが誤解を招きます。なぜなら、マイクロサービスにはサービスしか存在しないからです。サービスがいつマイクロサービスとして開始され、いつ終了するかについての明確な定義はありません。^[40]
データ集約。稼働中のシステムを完全に把握するには、マイクロサービスリポジトリからデータセットを抽出し、単一のスキーマに集約する必要があります。たとえば、単一のマイクロサービスリポジトリでは不可能な運用レポートを作成できるようになります。

複雑さ

このアーキテクチャでは、レイテンシ、メッセージ形式の設計、^[41] バックアップ/可用性/一貫性 (BAC)、^[42] 負荷分散、フォールトトレランス^[35]など、追加の複雑さと対処すべき新しい問題が生じます。これらすべての問題に大規模に対処する必要があります。モノリシックアプリケーションの複雑さは、マイクロサービスのセットとして再実装しても消えることはありません。複雑さの一部は運用上の複雑さに変換されます。^[43]複雑さが現れるその他の場所としては、ネットワークトラフィックの増加があり、パフォーマンスの低下につながります。また、任意の数のマイクロサービスで構成されるアプリケーションでは、それぞれのエコシステムにアクセスするためのインターフェイスポイントの数が多くなり、アーキテクチャの複雑さが増します。^[44]このような追加の複雑さの影響を軽減するために、さまざまな組織化原則 (アプリケーション状態のエンジンとしてのハイパーメディア(HATEOAS)、 Swagger経由でキャプチャされたインターフェイスとデータモデルのドキュメントなど) が適用されています。

課題

マイクロサービスは、分散コンピューティングの誤解の影響を受けやすく、一連の誤解がソフトウェアの開発と展開に重大な問題を引き起こす可能性があります。^[3]

ベストプラクティス

O'Reillyによれば、各マイクロサービスは独自のアーキテクチャ特性（非機能要件とも呼ばれる）を持つべきであり、アーキテクトは分散システム全体に対して均一な特性を定義すべきではない。^[3]

レイテンシは、中央値や平均レイテンシでは外れ値を見逃してしまう可能性があるため、誤解を招く恐れがあるため、「99パーセンタイル」で測定されることが多い。^[45]^{[ページが必要]}^[46]

テクノロジー

コンピュータマイクロサービスは、さまざまなプログラミング言語で実装でき、さまざまなインフラストラクチャを使用する可能性があります。したがって、最も重要な技術の選択は、マイクロサービスが互いに通信する方法（同期、非同期、UI統合）と通信に使用されるプロトコル（RESTful HTTP、メッセージング、GraphQL ...）です。従来のシステムでは、プログラミング言語などのほとんどの技術の選択がシステム全体に影響を与えます。したがって、技術を選択するアプローチはまったく異なります。^[47]

Eclipse Foundationはマイクロサービス開発の仕様であるEclipse MicroProfileを公開した。^[48]^[49]

サービスメッシュ

サービスメッシュでは、各サービスインスタンスは、サービスプロキシ、サイドカープロキシ、またはサイドカーと呼ばれるリバースプロキシサーバーのインスタンスとペアになっています。サービスインスタンスとサイドカープロキシはコンテナーを共有し、コンテナーはKubernetes、Nomad、Docker Swarm、DC/OSなどのコンテナーオーケストレーションツールによって管理されます。サービスプロキシは他のサービスインスタンスとの通信を担当し、サービス (インスタンス) の検出、負荷分散、認証と承認、安全な通信などの機能をサポートできます。

サービスメッシュでは、サービスインスタンスとそのサイドカープロキシがデータプレーンを構成します。データプレーンには、データ管理だけでなく、リクエストの処理と応答も含まれます。サービスメッシュには、サイドカープロキシを介してサービス間のやり取りを管理するためのコントロールプレーンも含まれます。^{[引用が必要]}

プラットフォームの比較

マイクロサービスアーキテクチャの実装は非常に困難です。マイクロサービスアーキテクチャには、対処しなければならない多くの懸念事項があります (以下の表を参照)。Netflixは、社内アプリケーションをサポートするためにマイクロサービスフレームワークを開発し、そのフレームワークの多くの部分をオープンソース化しました^[50]。これらのツールの多くはSpring Frameworkによって普及しており、Spring Cloud ^[51]プロジェクトの傘下で Spring ベースのツールとして再実装されています。以下の表は、Kubernetesエコシステムの実装機能と Spring Cloud の世界の同等の機能の比較を示しています^[52] 。Spring Cloud エコシステムの注目すべき点の 1 つは、Kubernetes が多言語ランタイムプラットフォームであるのに対し、これらはすべて Java ベースのテクノロジであることです。

参照

参考文献

^ 「マイクロサービスアーキテクチャ: 各部分の合計以上のもの?」IONOS Digitalguide。2020年 3 月 2 日。2022 年 3 月 29 日閲覧。
^ Fowler, Martin (2002).エンタープライズアプリケーションアーキテクチャのパターン. Addison-Wesley Professional. ISBN 978-0321127426。
^ abcd ソフトウェアアーキテクチャの基礎：エンジニアリングアプローチ。オライリーメディア。2020年。ISBN 978-1492043454。
^ abcd Martin Fowler. 「マイクロサービス」。2018年2月14日時点のオリジナルよりアーカイブ。
^ ニューマン、サム (2015-02-20)。マイクロサービスの構築。オライリーメディア。ISBN 978-1491950357。
^ Wolff, Eberhard (2016-10-12).マイクロサービス: 柔軟なソフトウェアアーキテクチャ. Addison-Wesley. ISBN 978-0134602417。
^ abc Pautasso, Cesare (2017). 「マイクロサービスの実践、パート1：現実の確認とサービス設計」. IEEEソフトウェア. 34 (1): 91–98. doi :10.1109/MS.2017.24. S2CID 5635705.
^ abcd Chen, Lianping (2018)。マイクロサービス: 継続的デリバリーと DevOps のためのアーキテクチャ。IEEE 国際ソフトウェアアーキテクチャ会議 (ICSA 2018)。IEEE。
^ ab Nadareishvili, I.、Mitra, R.、McLarty, M.、Amundsen, M.、『マイクロサービスアーキテクチャ：原則、実践、文化の整合』、O'Reilly 2016
^ 「フロントエンドパターンのためのバックエンド」。Microsoft Azure クラウドデザインパターン。Microsoft。
^ Lucas Krause.マイクロサービス: パターンとアプリケーション. ASIN B00VJ3NP4A.
^ Ford, N; Richards, M; Sadalage, P; Dehghani, Z. 「ソフトウェアアーキテクチャ：ハード部分」。Thoughtworks 。 2023年1月20日閲覧。
^ 「マイクロサービスアーキテクチャの CI/CD」、Azure Architecture Center、Microsoft。2018年 1 月 9 日閲覧。
^ ジョスティス、N. (2007)。 SOA の実践。セバストポル、カリフォルニア州、米国: オライリー。ISBN 978-0-596-52955-0。
^ Martin Fowler (2014年8月28日). 「マイクロサービスの前提条件」。2023年10月3日時点のオリジナルよりアーカイブ。
^ Richardson, Chris (2018 年 11 月)。マイクロサービスパターン。Manning Publications。1.4.1スケールキューブとマイクロサービス。ISBN 9781617294549。
^ Mendonca, Nabor C.; Jamshidi, Pooyan; Garlan, David; Pahl, Claus (2019-10-16). 「自己適応型マイクロサービスシステムの開発：課題と方向性」. IEEE ソフトウェア. 38 (2): 70–79. arXiv : 1910.07660 . doi :10.1109/MS.2019.2955937. S2CID 204744007.
^ 調査、検証済み市場。「クラウドマイクロサービス市場 2020 年の動向、市場シェア、業界規模、機会、分析、2026 年までの予測 – Instant Tech Market News」。2020年 2 月 18 日閲覧。
^ Russell, Perry; Rodgers, Peter; Sellman, Royston (2004). 「XML アプリケーションプラットフォームのアーキテクチャと設計」. HP テクニカルレポート. p. 62. 2015 年8 月 20 日閲覧。
^ Rodgers, Peter (2005 年 2 月 15 日)。「NetKernel でのサービス指向開発 - システムの複雑さを軽減するパターン、プロセス、製品」。CloudComputingExpo。SYS -CON Media。2018 年 5 月 20 日時点のオリジナルよりアーカイブ。2015 年8 月 19 日閲覧。
^ O. Zimmermann、マイクロサービス API パターンによるドメイン固有のサービス分解、Microservices 2019、https://www.conf-micro.services/2019/slides//keynotes/Zimmerman.pdf
^ 「Amazon SOA 指令」 2011 年 10 月 13 日。
^ Vaughn, Vernon (2016).ドメイン駆動設計の要約。Addison -Wesley Professional。ISBN 978-0-13-443442-1。
^ Yousif, Mazin (2016). 「マイクロサービス」. IEEE クラウドコンピューティング. 3 (5): 4–5. doi :10.1109/MCC.2016.101.
^ Dragoni, Nicola; Lanese, Ivan; Larsen, Stephan Thordal; Mazzara, Manuel; Mustafin, Ruslan; Safina, Larisa (2017). 「マイクロサービス: アプリケーションをスケールさせる方法」( PDF ) .システム情報学の展望. コンピュータサイエンスの講義ノート。第 10742 巻。pp. 95–104。arXiv : 1702.07149。Bibcode : 2017arXiv170207149D。doi :10.1007/ 978-3-319-74313-4_8。ISBN 978-3-319-74312-7.S2CID 1643730 。
^ ニューマン、サム (2015)。マイクロサービスの構築。オライリー。ISBN 978-1491950357。
^ Wolff, Eberhard (2016).マイクロサービス: 柔軟なソフトウェアアーキテクチャ. Addison Wesley. ISBN 978-0134602417。
^ Knoche, Holger; Hasselbring, Wilhelm (2019). 「マイクロサービス導入の推進要因と障壁 - ドイツの専門家を 対象とした調査」。エンタープライズモデリングと情報システムアーキテクチャ。14 : 1 :1–35–1:1–35。doi :10.18417/emisa.14.1。
^ ab Taibi, Davide; Lenarduzzi, Valentina; Pahl, Claus; Janes, Andrea (2017). 「アジャイルソフトウェア開発におけるマイクロサービス: ワークショップに基づく問題、利点、欠点の研究」。XP2017科学ワークショップの議事録。doi :10.1145/3120459.3120483。S2CID 28134110 。
^ Richardson, Chris. 「マイクロサービスアーキテクチャパターン」. microservices.io . 2017 年 3 月 19 日閲覧。
^ Chen, Lianping; Ali Babar, Muhammad (2014)。「アジャイルソフトウェア開発における継続的リファクタリングによるアーキテクチャの出現の証拠に基づく理解に向けて」。Proceedings Working IEEE/IFIP Conference on Software Architecture 2014 WICSA 2014。第 11 回 Working IEEE/IFIP Conference on Software Architecture(WICSA 2014)。IEEE。doi : 10.1109 /WICSA.2014.45。
^ Balalaie, Armin; Heydarnoori, Abbas; Jamshidi, Pooyan (2016 年 5 月)。「マイクロサービスアーキテクチャが DevOps を実現する: クラウドネイティブアーキテクチャへの移行」( PDF)。IEEEソフトウェア。33 (3): 42–52。doi : 10.1109 /ms.2016.64。hdl :10044/1 / 40557。ISSN 0740-7459。S2CID 18802650 。
^ Stenberg, Jan (2014 年 8 月 11 日)。「マイクロサービスでの失敗の経験」
^ Calandra, Mariano (2021 年 4 月 7 日)。「マイクロサービスの場合、ユニットテストだけでは不十分な理由」
^ ab 「Spring と Cloud Foundry を使用した PaaS 向けマイクロサービスの開発」。
^ Tilkov, Stefan (2014 年 11 月 17 日)。「マイクロサービスはどの程度小さくすべきか?」Innoq。2017年1 月 4 日閲覧。
^ Lanza, Michele; Ducasse, Stéphane (2002). 「ソフトウェアの視覚化とソフトウェアメトリクスの組み合わせを使用したソフトウェアの進化の理解」(PDF)。LMO 2002 (Langages et Modèles à Objets) の議事録: 135–149。2021年 2 月 27 日のオリジナル(PDF)からアーカイブ。
^ Richardson, Chris (2018 年 11 月)。「第 4 章 saga によるトランザクションの管理」。マイクロサービスパターン。Manning Publications。ISBN 978-1-61729454-9。
^ Devoxx (2017年8月30日). 「マイクロサービスで大失敗するための10のヒント by David Schmitz」. YouTube . 2021年4月22日時点のオリジナルよりアーカイブ。
^ abc Löwy, Juval (2019). Righting Software 第1版. Addison-Wesley Professional. pp. 73–75. ISBN 978-0136524038。
^ Pautasso, Cesare (2017). 「マイクロサービスの実践、パート2：サービス統合と持続可能性」. IEEEソフトウェア. 34 (2): 97–104. doi :10.1109/MS.2017.56. S2CID 30256045.
^ Pautasso, Cesare (2018). 「マイクロサービスのための一貫した災害復旧：BAC定理」. IEEE Cloud Computing . 5 (1): 49–59. doi :10.1109/MCC.2018.011791714. S2CID 4560021.
^ Fowler, Martin . 「マイクロサービスのトレードオフ」
^ 「BRASS ビルディングリソース適応型ソフトウェアシステム」。米国政府。DARPA。2015 年 4 月 7 日。「しかし、システムコンポーネントへのアクセスや、クライアントとアプリケーション間のインターフェイスは、非公式に文書化されたアプリケーションプログラミングインターフェイス(API)、特異な外部関数インターフェイス、複雑で理解しにくいモデル定義、アドホックデータ形式など、多くの場合は無関係な多数のメカニズムを介して仲介されます。これらのメカニズムでは通常、コンポーネント自体のセマンティクスが部分的にしか理解されず、不完全です。このような複雑さがあるため、アプリケーションが対話するエコシステムの予想される動作について多くの仮定を組み込むのも不思議ではありません。」
^ Vitillo, Roberto (2021).分散システムを理解する: 大規模分散アプリケーションについてすべての開発者が知っておくべきこと。Roberto Vitillo。ISBN 978-1838430207。
^ Bhargav, Nikhil (2024-03-18). 「P99レイテンシーとは?」baeldung.com . 2024-06-08に取得。平均値と中央値は外れ値を隠してしまうことが多い
^ Wolff, Eberhard (2018-04-15). マイクロサービス - 実践ガイド. CreateSpace Independent Publishing Platform. ISBN 978-1717075901。
^ Swart, Stephanie (2016 年 12 月 14 日). 「Eclipse MicroProfile」. projects.eclipse.org .
^ “MicroProfile”. MicroProfile . 2021年4月11日閲覧。
^ Netflix OSS、Git Hub
^ 雲、春
^ 「マイクロサービス向け Spring Cloud と Kubernetes の比較」、開発者、Red Hat、2016 年 12 月 9 日
^ Somashekar, Gagan; Gandhi, Anshul (2021-04-26). 「マイクロサービスの最適な構成に向けて」。機械学習とシステムに関する第 1 回ワークショップの議事録。EuroMLSys '21。オンライン、英国: Association for Computing Machinery。pp. 7–14。doi : 10.1145 /3437984.3458828。
^ Istio サービスメッシュを使用したマイクロサービスの管理、Kubernetes、2017 年 5 月
^ Kubernetes パッケージマネージャー、Helm

さらに読む

「マイクロサービスに関する特別テーマ号」。IEEEソフトウェア。35 （3）。2018年5月～6月。
I. Nadareishvili 他著『マイクロサービスアーキテクチャ - 原則、実践、文化の整合』O'Reilly、2016 年、 ISBN 978-1-491-95979-4
S. Newman、マイクロサービスの構築 - 細粒度システムの設計、O'Reilly、2015年ISBN 978-1491950357
Wijesuriya, Viraj Brian (2016-08-29)マイクロサービスアーキテクチャ、講義ノート- コロンボ大学コンピューティングスクール、スリランカ
Christudas Binildas (2019 年 6 月 27 日)。『実践的なマイクロサービスアーキテクチャパターン: Spring Boot と Spring Cloud を使用したイベントベースの Java マイクロサービス』。Apress。ISBN 978-1484245002。

[1] 「マイクロサービスアーキテクチャ: 各部分の合計以上のもの?」IONOS Digitalguide。2020年 3 月 2 日。2022 年 3 月 29 日閲覧。

[2] Fowler, Martin (2002).エンタープライズアプリケーションアーキテクチャのパターン. Addison-Wesley Professional. ISBN 978-0321127426。

[:0-3] ソフトウェアアーキテクチャの基礎：エンジニアリングアプローチ。オライリーメディア。2020年。ISBN 978-1492043454。

[martinfowler-4] Martin Fowler. 「マイクロサービス」。2018年2月14日時点のオリジナルよりアーカイブ。

[5] ニューマン、サム (2015-02-20)。マイクロサービスの構築。オライリーメディア。ISBN 978-1491950357。

[6] Wolff, Eberhard (2016-10-12).マイクロサービス: 柔軟なソフトウェアアーキテクチャ. Addison-Wesley. ISBN 978-0134602417。

[ieeeswi2-7] Pautasso, Cesare (2017). 「マイクロサービスの実践、パート1：現実の確認とサービス設計」. IEEEソフトウェア. 34 (1): 91–98. doi :10.1109/MS.2017.24. S2CID 5635705.

[Micro_Chen-8] Chen, Lianping (2018)。マイクロサービス: 継続的デリバリーと DevOps のためのアーキテクチャ。IEEE 国際ソフトウェアアーキテクチャ会議 (ICSA 2018)。IEEE。

[NMMA16-9] Nadareishvili, I.、Mitra, R.、McLarty, M.、Amundsen, M.、『マイクロサービスアーキテクチャ：原則、実践、文化の整合』、O'Reilly 2016

[10] 「フロントエンドパターンのためのバックエンド」。Microsoft Azure クラウドデザインパターン。Microsoft。

[11] Lucas Krause.マイクロサービス: パターンとアプリケーション. ASIN B00VJ3NP4A.

[12] Ford, N; Richards, M; Sadalage, P; Dehghani, Z. 「ソフトウェアアーキテクチャ：ハード部分」。Thoughtworks 。 2023年1月20日閲覧。

[13] 「マイクロサービスアーキテクチャの CI/CD」、Azure Architecture Center、Microsoft。2018年 1 月 9 日閲覧。

[14] ジョスティス、N. (2007)。 SOA の実践。セバストポル、カリフォルニア州、米国: オライリー。ISBN 978-0-596-52955-0。

[15] Martin Fowler (2014年8月28日). 「マイクロサービスの前提条件」。2023年10月3日時点のオリジナルよりアーカイブ。

[16] Richardson, Chris (2018 年 11 月)。マイクロサービスパターン。Manning Publications。1.4.1スケールキューブとマイクロサービス。ISBN 9781617294549。

[17] Mendonca, Nabor C.; Jamshidi, Pooyan; Garlan, David; Pahl, Claus (2019-10-16). 「自己適応型マイクロサービスシステムの開発：課題と方向性」. IEEE ソフトウェア. 38 (2): 70–79. arXiv : 1910.07660 . doi :10.1109/MS.2019.2955937. S2CID 204744007.

[18] 調査、検証済み市場。「クラウドマイクロサービス市場 2020 年の動向、市場シェア、業界規模、機会、分析、2026 年までの予測 – Instant Tech Market News」。2020年 2 月 18 日閲覧。

[19] Russell, Perry; Rodgers, Peter; Sellman, Royston (2004). 「XML アプリケーションプラットフォームのアーキテクチャと設計」. HP テクニカルレポート. p. 62. 2015 年8 月 20 日閲覧。

[cloudcomputingexpo-20] Rodgers, Peter (2005 年 2 月 15 日)。「NetKernel でのサービス指向開発 - システムの複雑さを軽減するパターン、プロセス、製品」。CloudComputingExpo。SYS -CON Media。2018 年 5 月 20 日時点のオリジナルよりアーカイブ。2015 年8 月 19 日閲覧。

[21] O. Zimmermann、マイクロサービス API パターンによるドメイン固有のサービス分解、Microservices 2019、https://www.conf-micro.services/2019/slides//keynotes/Zimmerman.pdf

[22] 「Amazon SOA 指令」 2011 年 10 月 13 日。

[23] Vaughn, Vernon (2016).ドメイン駆動設計の要約。Addison -Wesley Professional。ISBN 978-0-13-443442-1。

[24] Yousif, Mazin (2016). 「マイクロサービス」. IEEE クラウドコンピューティング. 3 (5): 4–5. doi :10.1109/MCC.2016.101.

[25] Dragoni, Nicola; Lanese, Ivan; Larsen, Stephan Thordal; Mazzara, Manuel; Mustafin, Ruslan; Safina, Larisa (2017). 「マイクロサービス: アプリケーションをスケールさせる方法」( PDF ) .システム情報学の展望. コンピュータサイエンスの講義ノート。第 10742 巻。pp. 95–104。arXiv : 1702.07149。Bibcode : 2017arXiv170207149D。doi :10.1007/ 978-3-319-74313-4_8。ISBN 978-3-319-74312-7.S2CID 1643730 。

[26] ニューマン、サム (2015)。マイクロサービスの構築。オライリー。ISBN 978-1491950357。

[27] Wolff, Eberhard (2016).マイクロサービス: 柔軟なソフトウェアアーキテクチャ. Addison Wesley. ISBN 978-0134602417。

[28] ^ Knoche, Holger; Hasselbring, Wilhelm (2019). 「マイクロサービス導入の推進要因と障壁 - ドイツの専門家を 対象とした調査」。エンタープライズモデリングと情報システムアーキテクチャ。14 : 1 :1–35–1:1–35。doi :10.18417/emisa.14.1。

[researchgate.net-29] Taibi, Davide; Lenarduzzi, Valentina; Pahl, Claus; Janes, Andrea (2017). 「アジャイルソフトウェア開発におけるマイクロサービス: ワークショップに基づく問題、利点、欠点の研究」。XP2017科学ワークショップの議事録。doi :10.1145/3120459.3120483。S2CID 28134110 。

[30] Richardson, Chris. 「マイクロサービスアーキテクチャパターン」. microservices.io . 2017 年 3 月 19 日閲覧。

[Ach_Chen-31] Chen, Lianping; Ali Babar, Muhammad (2014)。「アジャイルソフトウェア開発における継続的リファクタリングによるアーキテクチャの出現の証拠に基づく理解に向けて」。Proceedings Working IEEE/IFIP Conference on Software Architecture 2014 WICSA 2014。第 11 回 Working IEEE/IFIP Conference on Software Architecture(WICSA 2014)。IEEE。doi : 10.1109 /WICSA.2014.45。

[32] Balalaie, Armin; Heydarnoori, Abbas; Jamshidi, Pooyan (2016 年 5 月)。「マイクロサービスアーキテクチャが DevOps を実現する: クラウドネイティブアーキテクチャへの移行」( PDF)。IEEEソフトウェア。33 (3): 42–52。doi : 10.1109 /ms.2016.64。hdl :10044/1 / 40557。ISSN 0740-7459。S2CID 18802650 。

[infoq-1-33] Stenberg, Jan (2014 年 8 月 11 日)。「マイクロサービスでの失敗の経験」

[cdct-34] Calandra, Mariano (2021 年 4 月 7 日)。「マイクロサービスの場合、ユニットテストだけでは不十分な理由」

[infoqbook-35] 「Spring と Cloud Foundry を使用した PaaS 向けマイクロサービスの開発」。

[36] Tilkov, Stefan (2014 年 11 月 17 日)。「マイクロサービスはどの程度小さくすべきか?」Innoq。2017年1 月 4 日閲覧。

[37] Lanza, Michele; Ducasse, Stéphane (2002). 「ソフトウェアの視覚化とソフトウェアメトリクスの組み合わせを使用したソフトウェアの進化の理解」(PDF)。LMO 2002 (Langages et Modèles à Objets) の議事録: 135–149。2021年 2 月 27 日のオリジナル(PDF)からアーカイブ。

[38] Richardson, Chris (2018 年 11 月)。「第 4 章 saga によるトランザクションの管理」。マイクロサービスパターン。Manning Publications。ISBN 978-1-61729454-9。

[39] Devoxx (2017年8月30日). 「マイクロサービスで大失敗するための10のヒント by David Schmitz」. YouTube . 2021年4月22日時点のオリジナルよりアーカイブ。

[Löwy_2019_73–75-40] Löwy, Juval (2019). Righting Software 第1版. Addison-Wesley Professional. pp. 73–75. ISBN 978-0136524038。

[ieeeswmsip2-41] Pautasso, Cesare (2017). 「マイクロサービスの実践、パート2：サービス統合と持続可能性」. IEEEソフトウェア. 34 (2): 97–104. doi :10.1109/MS.2017.56. S2CID 30256045.

[ieeeccbac-42] Pautasso, Cesare (2018). 「マイクロサービスのための一貫した災害復旧：BAC定理」. IEEE Cloud Computing . 5 (1): 49–59. doi :10.1109/MCC.2018.011791714. S2CID 4560021.

[43] Fowler, Martin . 「マイクロサービスのトレードオフ」

[44] 「BRASS ビルディングリソース適応型ソフトウェアシステム」。米国政府。DARPA。2015 年 4 月 7 日。「しかし、システムコンポーネントへのアクセスや、クライアントとアプリケーション間のインターフェイスは、非公式に文書化されたアプリケーションプログラミングインターフェイス(API)、特異な外部関数インターフェイス、複雑で理解しにくいモデル定義、アドホックデータ形式など、多くの場合は無関係な多数のメカニズムを介して仲介されます。これらのメカニズムでは通常、コンポーネント自体のセマンティクスが部分的にしか理解されず、不完全です。このような複雑さがあるため、アプリケーションが対話するエコシステムの予想される動作について多くの仮定を組み込むのも不思議ではありません。」

[45] Vitillo, Roberto (2021).分散システムを理解する: 大規模分散アプリケーションについてすべての開発者が知っておくべきこと。Roberto Vitillo。ISBN 978-1838430207。

[46] Bhargav, Nikhil (2024-03-18). 「P99レイテンシーとは?」baeldung.com . 2024-06-08に取得。平均値と中央値は外れ値を隠してしまうことが多い

[47] Wolff, Eberhard (2018-04-15). マイクロサービス - 実践ガイド. CreateSpace Independent Publishing Platform. ISBN 978-1717075901。

[48] Swart, Stephanie (2016 年 12 月 14 日). 「Eclipse MicroProfile」. projects.eclipse.org .

[49] “MicroProfile”. MicroProfile . 2021年4月11日閲覧。

[50] Netflix OSS、Git Hub

[51] 雲、春

[52] 「マイクロサービス向け Spring Cloud と Kubernetes の比較」、開発者、Red Hat、2016 年 12 月 9 日

[53] Somashekar, Gagan; Gandhi, Anshul (2021-04-26). 「マイクロサービスの最適な構成に向けて」。機械学習とシステムに関する第 1 回ワークショップの議事録。EuroMLSys '21。オンライン、英国: Association for Computing Machinery。pp. 7–14。doi : 10.1145 /3437984.3458828。

[54] Istio サービスメッシュを使用したマイクロサービスの管理、Kubernetes、2017 年 5 月

[55] Kubernetes パッケージマネージャー、Helm