第12章クラウドネイティブアプリケーション開発

LINK TO LEARNING学びを広げるリンク

The article Microservices (https://openstax.org/r/76microservic) discusses the characteristics of a microservices architecture in contrast to a monolith architecture.

記事「Microservices」（https://openstax.org/r/76microservic）では、モノリシックアーキテクチャとの比較を通じて、マイクロサービスアーキテクチャの特徴を論じている。

Components vs. Servicesコンポーネントとサービス

Building applications using components is a desirable approach. In the case of monoliths, this is typically achieved by using libraries as components and compiling or linking them into a single program or process that accesses them using “in-process” function calls. In contrast, “services” in a microservices-centric application are “out-of-process” components that communicate with each other using a web service request, or a remote procedure call. Figure 12.8 illustrates how components are accessed in a monolithic architecture as compared to a microservices architecture.

英語のヒント

コンポーネントを使ってアプリケーションを構築することは、望ましい手法である。モノリスでは、通常、ライブラリをコンポーネントとして使い、それらを1つのプログラムやプロセスへコンパイルまたはリンクする。そのプログラムやプロセスは、「プロセス内」の関数呼び出しでコンポーネントにアクセスする。これに対し、マイクロサービス中心のアプリケーションにおける「サービス」は、「プロセス外」のコンポーネントであり、Webサービスの要求や遠隔手続き呼び出しで互いに通信する。図12.8は、モノリシックアーキテクチャとマイクロサービスアーキテクチャで、コンポーネントへのアクセス方法がどう異なるかを示している。

Figure 12.8 Components in a monolith architecture are accessed differently compared to components in a microservices architecture. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

図12.8 モノリシックアーキテクチャのコンポーネントへのアクセス方法は、マイクロサービスアーキテクチャのものとは異なる。（出典：Copyright Rice University, OpenStax、CC BY 4.0ライセンス）

As noted earlier, services used by microservices-centric applications are independently deployable so that changes to any service do not affect other services. This assumes services are well encapsulated and designed with minimally cohesive service boundaries. The use of web services calls and RPC makes this easier to achieve. A web service is a unit of software that is available as a resource over the Internet. A remote procedure call (RPC) is a request-response protocol used by a program to access services from other programs over a network. However, there are downsides to this approach. RPCs are more expensive than in-process calls, and thus remote APIs need to be coarser-grained (i.e., coarse-grained APIs expose more methods in their interfaces as opposed to fine-grained APIs).

英語のヒント

前述したように、マイクロサービス中心のアプリケーションが使うサービスは、独立して配置でき、どのサービスへの変更も、ほかのサービスに影響しない。これは、サービスが十分にカプセル化され、凝集を最小限にしたサービス境界を持つように設計されていることを前提とする。Webサービスの呼び出しとRPCを使うと、これを実現しやすくなる。Webサービスは、インターネット上でリソースとして利用できるソフトウェア単位である。遠隔手続き呼び出し（RPC）は、プログラムがネットワークを通じてほかのプログラムのサービスへアクセスするための、要求・応答プロトコルである。しかし、この手法には欠点もある。RPCは、プロセス内の呼び出しより負担が大きい。そのため、遠隔APIは、より粗い粒度にする必要がある。すなわち、粗粒度のAPIは、細粒度のAPIよりも多くのメソッドをインターフェースで公開する。

One challenge to using services is changing the allocation of responsibilities between components. This can be challenging especially if the service consists of multiple processes deployed together such as an application process and a datastore process that are only used by that service. Another challenge is that it may be difficult to get the components’ service boundaries right. In other words, the difficulty is to fit software into a component that can be used as a service. Services use APIs, thus any changes to the API must be coordinated with other components. API changes must be backward compatible so components that do not use the latest updated version of the API can still function. Finally, testing is also more complicated.

英語のヒント

サービスを使う際の課題の1つは、コンポーネント間の責任の割り当てを変えることである。特に、そのサービスでだけ使うアプリケーションプロセスとデータストアプロセスなど、複数のプロセスを一緒に配置してサービスを構成する場合には、難しいことがある。もう1つの課題は、コンポーネントのサービス境界を適切に定めることが難しい場合があることである。言い換えると、サービスとして使えるコンポーネントへソフトウェアを収めるのが難しい。サービスはAPIを使うため、APIの変更はほかのコンポーネントと調整しなければならない。APIの変更には後方互換性が必要であり、最新の更新版APIを使わないコンポーネントも、引き続き動作できなければならない。最後に、テストも複雑になる。

SOA vs. MicroservicesSOAとマイクロサービス

The microservices architecture is not the first architectural style to make use of self-contained components and implement individual business capabilities. The service-oriented architectural style, a well-established style of software design, commands the same approach. A service-oriented architecture (SOA) requires that conforming applications be structured as discrete, reusable, and interoperable services that communicate through an enterprise service bus (ESB) via message protocols such as SOAP,¹ ActiveMQ,² or Apache Thrift.³

英語のヒント

自己完結したコンポーネントを使い、個々の事業機能を実装するアーキテクチャスタイルは、マイクロサービスが最初ではない。確立したソフトウェア設計のスタイルであるサービス指向アーキテクチャも、同じ手法を求める。サービス指向アーキテクチャ（SOA）では、それに従うアプリケーションを、個別で、再利用でき、相互運用できるサービスとして構成する。それらはエンタープライズサービスバス（ESB）を通じて、SOAP¹、ActiveMQ²、Apache Thrift³などのメッセージプロトコルによって通信する。

An enterprise service bus (ESB) implements a bus-like communication system between interacting service providers and service consumers. The services, ESB, and messaging protocols collectively make up an SOA application. In Figure 12.9, the architecture shown on the left illustrates a typical SOA compared to the typical microservices architecture illustrated on the right. As is the case for services in a microservices architecture, SOA services can be updated independently. However, the ESB represents a single point of failure for the entire system.

英語のヒント

エンタープライズサービスバス（ESB）は、互いにやり取りするサービスの提供者と利用者の間に、バスに似た通信システムを実装する。サービス、ESB、メッセージプロトコルが一緒になって、SOAアプリケーションを構成する。図12.9の左側は典型的なSOA、右側は典型的なマイクロサービスアーキテクチャを示している。マイクロサービスアーキテクチャ内のサービスと同様、SOAのサービスも独立して更新できる。しかし、ESBはシステム全体にとっての単一障害点となる。

1 For information on the SOAP Messaging Protocol, see https://www.w3.org/TR/2007/REC-soap12-part1-20070427/ 2 For information on ActiveMQ, see https://activemq.apache.org/ 3 For information on Apache Thrift, see https://thrift.apache.org/

1 SOAP Messaging Protocolについては、https://www.w3.org/TR/2007/REC-soap12-part1-20070427/を参照。2 ActiveMQについては、https://activemq.apache.org/を参照。3 Apache Thriftについては、https://thrift.apache.org/を参照。

Figure 12.9 In an SOA, services communicate via an ESB compared to a microservices architecture where services typically communicate via REST protocols. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

図12.9 SOAではサービスがESBを介して通信するのに対し、マイクロサービスアーキテクチャでは、通常、RESTプロトコルで通信する。（出典：Copyright Rice University, OpenStax、CC BY 4.0ライセンス）

Different from services in an SOA, microservices usually communicate with each other statelessly using lightweight REST protocols implemented via HTTP. Furthermore, microservices can be implemented using different programming languages and frameworks because they can communicate through programming language-agnostic APIs. Advancements in containerization technologies make it possible to deploy, upgrade, scale, and restart microservices independently, better controlling their life cycles. In case a microservice fails, the rest of the application is unaffected. Thus, applications using microservices can be more fault tolerant because they do not rely on a single ESB as is the case for SOA applications.

英語のヒント

SOAのサービスとは異なり、マイクロサービスは通常、HTTPを通じて実装した軽量なRESTプロトコルを使い、状態を保持しない形で互いに通信する。また、プログラミング言語に依存しないAPIで通信できるため、異なる言語やフレームワークを使って実装できる。コンテナー化技術の進歩により、マイクロサービスを独立して配置・更新・拡張・再起動でき、ライフサイクルをより適切に管理できる。1つのサービスが故障しても、アプリケーションの残りは影響を受けない。SOAアプリケーションのように1つのESBへ依存しないため、マイクロサービスを使うアプリケーションは、より障害に強くなりうる。