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

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

Various tools and/or frameworks can help automate testing in a microservices testing (https://openstax.org/r/76microtest) such as Selenium automation testing.

Seleniumによる自動テストなど、さまざまなツールやフレームワークが、マイクロサービスのテストの自動化（https://openstax.org/r/76microtest）に役立つ。

Logging Microservices

マイクロサービスのログ記録

Microservices are distributed systems and therefore traditional logging is ineffective when determining which microservices failed. As more microservices are added, the complexity of logging microservices activities grows exponentially and becomes more difficult to manage. In particular, logging aggregation is needed to track errors that might span across several microservices, as shown in Figure 12.10.

英語のヒント

マイクロサービスは分散システムであるため、どのサービスが故障したかを判断する際、従来のログ記録は効果的ではない。サービスが増えるほど、活動をログへ記録する複雑さは指数関数的に増え、管理も難しくなる。特に、図12.10のように、複数のサービスにまたがる可能性のあるエラーを追跡するには、ログの集約が必要である。

Figure 12.10 A microservices architecture is configured to use log aggregation and distributed tracing, which are typically used in a microservices-based distributed system. Log aggregation refers to storing various levels of warning and errors for a combined set of microservices. Distributed tracing helps interrelate information logged by multiple services so it can be followed as a single thread. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

図12.10 マイクロサービスを基にした分散システムで一般的に使われる、ログ集約と分散トレーシングを使うよう設定したアーキテクチャ。ログ集約は、複数のサービスをまとめて、さまざまなレベルの警告やエラーを保存することである。分散トレーシングは、複数のサービスが記録した情報を関連付け、1本の流れとしてたどれるようにする。（出典：Copyright Rice University, OpenStax、CC BY 4.0ライセンス）

Debugging Microservices

マイクロサービスのデバッグ

Remote debugging through a local integrated development environment will not work across several microservices. An IDE provides developers access to resources (e.g., source code editor, build automation tools, debuggers) to design, develop, debug, and test programs. Debugging a microservices-based application is challenging because errors are not propagated in a useful manner. In addition, logging formats can also differ across microservices. Debugging requires tracing through various error messages and status codes across the network, which is inefficient and makes it difficult to acquire the required information to debug the errors. Currently, there is no easy solution to debugging such applications effectively; however, tools (e.g., Helios,⁵ Rookout,⁶ Lightrun,⁷ ) do exist today to address this problem.

英語のヒント

ローカルの統合開発環境を通じた遠隔デバッグは、複数のマイクロサービスにまたがっては機能しない。IDEは、ソースコードエディター、ビルド自動化ツール、デバッガーなど、プログラムを設計・開発・デバッグ・テストするための資源へのアクセスを、開発者に提供する。マイクロサービス型のアプリケーションのデバッグは、エラーが役立つ形で伝播しないため難しい。また、ログの形式もサービスごとに異なる場合がある。デバッグでは、ネットワーク全体にわたるさまざまなエラーメッセージや状態コードを追跡しなければならない。これは非効率であり、エラーのデバッグに必要な情報を集めにくくする。現在、このようなアプリケーションを効果的にデバッグする簡単な方法はない。しかし、この問題に対処するツール、たとえばHelios⁵、Rookout⁶、Lightrun⁷は存在する。

Deployment of Microservices

マイクロサービスの配置

A monolithic application’s deployment may seem less complex because it is limited to a single deployment unit. In contrast, a microservices-based application is more complex to deploy because the interconnections between the microservices are more visible. In addition, there are more deployable units and the dependencies between them require more complex configurations. This increase in the number of deployable units imposes an order in which microservices need to be deployed. It also requires more investment in automation to practically manage them and help ensure that the whole microservices-based application is resilient and limits the risks of failovers.

英語のヒント

モノリシックアプリケーションの配置は、配置する単位が1つだけなので、あまり複雑に見えないかもしれない。対照的に、マイクロサービス型のアプリケーションは、サービス同士の接続がより明らかになるため、配置が複雑である。また、配置できる単位の数が多く、それらの依存関係によって設定も複雑になる。配置単位が増えることで、サービスを配置する順序も定めなければならなくなる。実際に管理を行い、マイクロサービス型アプリケーション全体が回復力を備え、フェイルオーバーの危険を抑えられるようにするためにも、自動化へより多く投資する必要がある。

5 For information about Helios, see https://snyk.io/blog/welcoming-helios-to-snyk/ 6 For information about Rookout, see https://www.rookout.com/ 7 For information about Lightrun, see https://lightrun.com/

5 Heliosについては、https://snyk.io/blog/welcoming-helios-to-snyk/を参照。6 Rookoutについては、https://www.rookout.com/を参照。7 Lightrunについては、https://lightrun.com/を参照。

Monitoring Microservices

マイクロサービスの監視

Because of the interdependencies between microservices, any downtime of a microservice resulting from updates or failures can cause cascading failures to other microservices. Monitoring a microservices-based application is challenging because it requires knowledge of the performance and availability of API calls for all the microservices in the application. In addition to monitoring the containers hosting the microservices, it is crucial to have a centralized view of the entire microservices-based application. This holistic view helps pinpoint any potential issues and ensures effective problem identification.

英語のヒント

マイクロサービスは互いに依存しているため、更新や故障によって1つのサービスが停止すると、ほかのサービスへ連鎖的な障害を引き起こす場合がある。アプリケーション内のすべてのサービスについて、API呼び出しの性能と可用性を知る必要があるため、マイクロサービス型アプリケーションの監視は難しい。サービスを動かしているコンテナーを監視するだけでなく、マイクロサービス型アプリケーション全体を一元的に把握することが重要である。この全体像によって、潜在的な問題を正確に突き止め、効果的に問題を特定できる。

Cloud-Native Application Architectureクラウドネイティブアプリケーションのアーキテクチャ

A cloud-native application takes advantage of cloud computing frameworks to implement a collection of loosely coupled microservices in the cloud. The cloud-native application architecture makes it possible to efficiently allocate resources to individual microservices that the cloud-native application uses. An example of a cloud-native application architecture is illustrated in Figure 12.11.

クラウドネイティブアプリケーションは、クラウドコンピューティングのフレームワークを活用し、クラウド内に疎結合のマイクロサービスの集合を実装する。このアーキテクチャによって、アプリケーションが使う個々のサービスへ、効率よく資源を割り当てられる。図12.11に、そのアーキテクチャの一例を示す。

Figure 12.11 A cloud-native application architecture includes the cloud-native application and the cloud computing platform it leverages. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

図12.11 クラウドネイティブアプリケーションのアーキテクチャには、アプリケーション自体と、それが活用するクラウドコンピューティングのプラットフォームが含まれる。（出典：Copyright Rice University, OpenStax、CC BY 4.0ライセンス）

The cloud infrastructure, shown in Figure 12.11, is provided by a cloud computing platform. The cloud computing platform also provides a scheduling and orchestration service to manage the containers that the cloud-native application microservices are deployed in. Microservices used in a cloud-native application typically run in different locations within a cloud platform, which enables the application to scale out horizontally. Therefore, cloud-native applications must be designed with redundancy in mind. This allows the application to withstand equipment failures.

英語のヒント

図12.11のクラウド基盤は、クラウドコンピューティングのプラットフォームが提供する。このプラットフォームは、クラウドネイティブアプリケーションのマイクロサービスを配置するコンテナーを管理するために、スケジューリングとオーケストレーションのサービスも提供する。クラウドネイティブアプリケーションで使うマイクロサービスは、通常、クラウドのプラットフォーム内の異なる場所で動作するため、アプリケーションを水平方向へ拡張できる。そのため、冗長性を考慮して設計しなければならない。これにより、機器の故障に耐えられるようになる。

Finally, the cloud-native application and runtime environment is where the cloud-native application operates. A cloud-native architecture leverages a commoditized microservices architecture. In this architecture, business capabilities are implemented as cloud-managed microservices, which makes the cloud-native application more reliable and scalable.

英語のヒント

最後に、クラウドネイティブアプリケーションとその実行環境は、アプリケーションが動作する場所である。クラウドネイティブアーキテクチャは、汎用化されたマイクロサービスアーキテクチャを活用する。ここでは、事業機能をクラウドが管理するマイクロサービスとして実装し、アプリケーションの信頼性とスケーラビリティを高める。

Cloud-native applications should be designed to include standardized logging and support events that can be associated with a standard logging catalog. Scaling and managing multiple microservices require core services such as load balancing, service discovery, and routing, which are all managed by the scheduling and orchestration layer. In summary, designing cloud-native applications to leverage the services of a cloud computing framework makes it possible to add and support new business capabilities more quickly.

英語のヒント

クラウドネイティブアプリケーションは、標準化されたログ記録を含み、標準のログカタログへ対応付けられるイベントを支えるよう設計すべきである。複数のマイクロサービスを拡張・管理するには、負荷分散、サービスディスカバリー、ルーティングなどの中核サービスが必要であり、それらはすべてスケジューリングとオーケストレーションの層が管理する。まとめると、クラウドコンピューティングのフレームワークが提供するサービスを活用するように設計すれば、新しい事業機能をより素早く追加し、支えられる。