第12章クラウドネイティブアプリケーション開発
12.1 Introduction to Cloud-Native Applications12.1 クラウドネイティブアプリケーション入門
Learning Objectives学習目標
By the end of this section, you will be able to:
この節を終えると、次のことができるようになる。
• Analyze the differences between monolithic and microservices architectures
• モノリシックアーキテクチャとマイクロサービスアーキテクチャの違いを分析する。
• Understand the architecture of cloud-native applications
• クラウドネイティブアプリケーションのアーキテクチャを理解する。
• Learn the features of cloud-native applications
• クラウドネイティブアプリケーションの特徴を学ぶ。
• Relate to the benefits of cloud-native applications
• クラウドネイティブアプリケーションの利点を理解する。
• Understand best practices and tools used to develop cloud-native applications
• クラウドネイティブアプリケーションの開発に使う優れた実践方法とツールを理解する。
• Apply the tools used in cloud-native application development
• クラウドネイティブアプリケーション開発のツールを活用する。
• Envision the road ahead for cloud-native applications
英語のヒント
• クラウドネイティブアプリケーションの今後を思い描く。
Cloud computing makes it possible for organizations to offer solutions in the cloud and use cloud services to streamline development and deployment. As organizations look to the cloud to solve today’s business problems, they may opt to create, deploy, and manage cloud-based or cloud-native applications. As noted earlier, cloud-native development relies on four key principles that help with designing applications for the cloud, as illustrated in Figure 12.2.
英語のヒント
クラウドコンピューティングによって、組織はクラウド上で解決策を提供し、クラウドサービスを使って開発と配置を効率化できる。今日の業務上の問題の解決をクラウドに求める組織は、クラウドベース、またはクラウドネイティブのアプリケーションを作成・配置・管理することを選ぶ場合がある。前述したように、クラウドネイティブな開発は、クラウド向けの設計を助ける4つの重要な原則に基づく。図12.2に、その原則を示す。
attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license · CC BY 4.0 · Source出典
Figure 12.2 The four key principles of cloud-native development are microservices, containerization, continuous delivery, and DevOps. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)
図12.2 クラウドネイティブ開発の4つの重要な原則は、マイクロサービス、コンテナー化、継続的デリバリー、DevOpsである。（出典：Copyright Rice University, OpenStax、CC BY 4.0ライセンス）
In a nutshell, a cloud-native application uses a microservices architecture that takes full advantage of the benefits of the cloud such as scalability and on-demand services. Cloud-based applications are adaptations of legacy applications, or monoliths, migrated to a cloud provider. They are designed to leverage cloud platforms to facilitate the interoperation of local and cloud components. Although cloud-based applications do leverage cloud platforms to some degree, they are generally deployed as a single monolithic component, which makes them inflexible as full-stack upgrades are likely necessary and require downtime.
英語のヒント
簡単に言えば、クラウドネイティブアプリケーションは、スケーラビリティや必要に応じて使えるサービスなど、クラウドの利点を最大限に活用するマイクロサービスアーキテクチャを使う。クラウドベースのアプリケーションは、クラウド事業者へ移行するために、従来のアプリケーション、すなわちモノリスを適応させたものである。クラウドのプラットフォームを活用し、ローカルとクラウドのコンポーネントを連携しやすくするよう設計されている。クラウドベースのアプリケーションも、クラウドのプラットフォームをある程度は活用する。しかし、通常は1つのモノリシックなコンポーネントとして配置するため、柔軟性に欠ける。スタック全体の更新が必要になる可能性が高く、そのためには停止時間を要するからである。
Different from cloud-based applications, cloud-native applications leverage microservices architectures that structure applications as coordinated collections of small, independent services that are self-contained and are deployed in software containers managed by a container orchestrator.
英語のヒント
クラウドベースのアプリケーションとは異なり、クラウドネイティブアプリケーションは、マイクロサービスアーキテクチャを活用する。これによって、アプリケーションを、連携する小さな独立サービスの集合として構成する。各サービスは自己完結しており、コンテナーオーケストレーターが管理するソフトウェアコンテナーに配置される。
Both cloud-based and cloud-native applications can run on public, private, or hybrid cloud infrastructures. A hybrid cloud combines private, public clouds, and bare metal or virtual environments. What distinguishes cloud-native applications from cloud-based applications is the fact that they take full advantage of inherent characteristics of the cloud, such as resource pooling, on-demand self-managed services, automation, scalability, and rapid elasticity, to name a few.
英語のヒント
クラウドベースのアプリケーションも、クラウドネイティブアプリケーションも、パブリック、プライベート、ハイブリッドのいずれのクラウド基盤でも動作できる。ハイブリッドクラウドは、プライベートクラウド、パブリッククラウド、物理マシンそのもの、または仮想環境を組み合わせる。クラウドネイティブアプリケーションがクラウドベースのものと異なるのは、クラウド本来の特徴を最大限に活用する点である。例をいくつか挙げると、資源のプール化、必要に応じて自分で管理するサービス、自動化、スケーラビリティ、迅速な弾力的拡張などである。
Monolithic vs. Microservices Architectureモノリシックアーキテクチャとマイクロサービスアーキテクチャ
A monolithic architecture consists of software units that are united through a single codebase. In a monolithic architecture, all the different components of the application, including the user interface, business logic, and data access layer are tightly integrated and deployed as a single software unit. Mainframe applications or legacy e-commerce websites were based on monolithic architectures.
英語のヒント
モノリシックアーキテクチャは、1つのコードベースを通じて統合されたソフトウェア単位からなる。利用者インターフェース、ビジネスロジック、データアクセス層など、アプリケーションの異なる構成要素がすべて密接に統合され、1つのソフトウェア単位として配置される。メインフレームのアプリケーションや、従来の電子商取引サイトは、このアーキテクチャを基にしていた。
A microservice is a self-contained software unit that typically implements a single business capability. Because microservices are independent and loosely coupled, changes to an individual microservice can be deployed separately and do not require updating the entire application. This in turn streamlines the application development and minimizes downtime.
英語のヒント
マイクロサービスは、通常、1つの事業機能を実装する、自己完結したソフトウェア単位である。マイクロサービスは互いに独立し、疎結合であるため、個々のサービスの変更を別々に配置でき、アプリケーション全体を更新する必要はない。その結果、開発を効率化し、停止時間を最小限にできる。
Monolithic architectures typically consist of a user interface, business logic, and data access layers that are tightly coupled and generally dependent on one another to operate properly. An application that conforms to a monolithic architecture (also called a monolith) implements all the business capabilities together, and data is shared across all these capabilities. Monoliths are typically easier to develop and deploy, but they may become difficult to manage and scale over time. The basic difference between a traditional monolithic architecture and a microservices architecture is illustrated in Figure 12.3.
英語のヒント
モノリシックアーキテクチャは一般に、利用者インターフェース、ビジネスロジック、データアクセスの各層からなる。それらは密結合であり、正常に動作するため、通常は互いに依存している。モノリシックアーキテクチャに従うアプリケーションは、モノリスとも呼ばれ、すべての事業機能を一体として実装し、それら全体でデータを共有する。モノリスは、通常、開発と配置が容易だが、時間がたつと管理や規模の拡張が難しくなる場合がある。図12.3は、従来のモノリシックアーキテクチャと、マイクロサービスアーキテクチャの基本的な違いを示している。
attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license · CC BY 4.0 · Source出典
Figure 12.3 Monolithic architectures consist of highly dependent components and do not scale well compared to microservices architectures with self-contained components that are more easily scalable. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)
図12.3 モノリシックアーキテクチャは、依存度の高いコンポーネントからなり、自己完結したコンポーネントを持つマイクロサービスアーキテクチャに比べて、規模を拡張しにくい。後者のコンポーネントは、より容易に規模を拡張できる。（出典：Copyright Rice University, OpenStax、CC BY 4.0ライセンス）
As an example of a monolith, consider an application that provides a catalog of products that can be ordered online. An application designed using a monolith architecture is shown in Figure 12.4. The application includes a user interface. The business logic layer includes various components such as an inventory system for the product catalog, a basket service to order products, a payment system to purchase the products, and a reporting system that generates reports on sales and customer interests. A component is a software unit that encapsulates a set of related functions and data through a well-defined interface and specified dependencies. A single database is typically used as part of the data access layer for the entire application.
英語のヒント
モノリスの例として、オンラインで注文できる商品のカタログを提供するアプリケーションを考えよう。図12.4は、モノリシックアーキテクチャで設計したアプリケーションを示している。アプリケーションには、利用者インターフェースがある。ビジネスロジック層には、商品カタログの在庫管理システム、商品を注文する買い物かごサービス、商品を購入する決済システム、売上と顧客の関心についての報告を生成するシステムなど、さまざまなコンポーネントが含まれる。コンポーネントは、明確に定義されたインターフェースと指定された依存関係によって、関連する機能とデータをカプセル化するソフトウェア単位である。データアクセス層では、通常、アプリケーション全体で1つのデータベースを使う。
attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license · CC BY 4.0 · Source出典
Figure 12.4 An application is designed using a monolithic architecture. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)
図12.4 モノリシックアーキテクチャを使って設計したアプリケーション。（出典：Copyright Rice University, OpenStax、CC BY 4.0ライセンス）
These are highly dependent software components that use shared libraries. Any changes to one component require understanding what other components need from these shared libraries. Such changes can cause dependencies between components to break over time. The various components are also programming language and framework dependent. New components need to be implemented in the same programming language or use the same framework as the existing components.
英語のヒント
これらは、共有ライブラリを使う、相互依存の強いソフトウェアコンポーネントである。1つのコンポーネントを変更するにも、ほかのコンポーネントが共有ライブラリの何を必要としているか、理解しなければならない。このような変更は、時間がたつにつれて、コンポーネント間の依存関係を壊す場合がある。また、各コンポーネントは、プログラミング言語とフレームワークに依存する。新しいコンポーネントは、既存のものと同じプログラミング言語で実装するか、同じフレームワークを使う必要がある。
Other challenges with monoliths are managing growth and ensuring scalability. Over time, as new functionality is added to meet the needs of end users, the monolith grows and becomes more difficult to manage. Deploying the monolith then becomes challenging as it requires more effort to stabilize it and get it to run smoothly. Scaling a monolith also becomes more difficult over time. For example, during a holiday season with a rapid increase in sales, the payment system component may require additional capabilities to support a sudden increase in transactions. To add the necessary capabilities to just the payment system component, the entire monolith application needs to be duplicated. The problem with this is that deploying a second instance of the entire application and making it available to end users may take a lot of time. Before this gets done, the holiday season may have ended already and the version of the application that was available was only able to support a limited number of transactions. The second instance of the application is useless at this point despite the effort it took to deploy it. A scaled version of the monolith application is shown in Figure 12.5.
英語のヒント
モノリスの別の課題は、成長を管理し、スケーラビリティを確保することである。最終利用者の必要を満たす新機能が加わるにつれて、モノリスは大きくなり、管理が難しくなる。安定化させ、滑らかに動かすための労力が増えるため、配置も難しくなる。規模の拡張も、時間とともに難しくなる。たとえば、休暇シーズンに売上が急増すると、急に増えた取引を支えるため、決済システムのコンポーネントに処理能力を追加する必要が生じる場合がある。決済システムのコンポーネントだけに必要な能力を加えるためにも、モノリスのアプリケーション全体を複製しなければならない。問題は、アプリケーション全体の2つ目のインスタンスを配置し、最終利用者が使えるようにするまでに、長い時間がかかるかもしれないことである。それが終わる前に休暇シーズンが終わり、それまで使えた版では、限られた数の取引にしか対応できなかったということもある。この時点では、配置に労力を費やしたにもかかわらず、2つ目のインスタンスは役に立たない。図12.5は、規模を拡張したモノリスのアプリケーションを示している。
attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license · CC BY 4.0 · Source出典
Figure 12.5 An application that was designed to use a monolithic architecture is scaled to handle an increase in use. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)
図12.5 モノリシックアーキテクチャで設計したアプリケーションを、利用の増加に対応するために拡張している。（出典：Copyright Rice University, OpenStax、CC BY 4.0ライセンス）
In contrast, microservices architectures consist of small loosely coupled services that run independently and connect via a network. Applications that conform to a microservices architecture include a collection of modular components that run independently and provide a well-defined API to facilitate communication with other services. Instead of using a shared database across all business capabilities, each microservice that implements a single business capability contains its own datastore, the type of which depends on the type of data needed.
英語のヒント
これに対し、マイクロサービスアーキテクチャは、独立して動作し、ネットワークでつながる、小さな疎結合のサービスからなる。このアーキテクチャに従うアプリケーションは、独立して動作するモジュール化されたコンポーネントの集合を含み、ほかのサービスとの通信を容易にする、明確に定義されたAPIを提供する。すべての事業機能でデータベースを共有する代わりに、1つの事業機能を実装する各マイクロサービスが、独自のデータストアを持つ。データストアの種類は、必要なデータの種類によって決まる。
If the sample monolith application discussed earlier is implemented using a microservices architecture, each one of its components (i.e., the inventory system, basket service, payment system, and reporting system) becomes an individual microservice. These microservices each run in separate containers and communicate via APIs. An application designed using a microservices architecture is shown in Figure 12.6.
前に述べたモノリスの例をマイクロサービスアーキテクチャで実装すると、在庫管理システム、買い物かごサービス、決済システム、報告システムという各コンポーネントが、それぞれ独立したマイクロサービスになる。各サービスは別々のコンテナーで動作し、APIを通じて通信する。図12.6は、マイクロサービスアーキテクチャで設計したアプリケーションを示している。
attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license · CC BY 4.0 · Source出典
Figure 12.6 An application designed using a microservices architecture. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)
図12.6 マイクロサービスアーキテクチャで設計したアプリケーション。（出典：Copyright Rice University, OpenStax、CC BY 4.0ライセンス）
Components in a microservices architecture are independent of each other. Individual microservices can be changed without affecting the other microservices. If a microservice fails, the rest of the application is not affected.
マイクロサービスアーキテクチャのコンポーネントは、互いに独立している。個々のマイクロサービスは、ほかのサービスに影響を与えずに変更できる。1つのマイクロサービスが故障しても、アプリケーションの残りの部分は影響を受けない。
Microservices are also programming language and framework independent. New microservices can use different programming languages or frameworks. For example, a team responsible for the inventory system can use a programming language or framework that is different from the ones used to implement the payment system. It is also easier to grow or scale a microservices-based architecture.
マイクロサービスは、プログラミング言語とフレームワークにも依存しない。新しいサービスでは、異なる言語やフレームワークを使える。たとえば、在庫管理システムの担当チームは、決済システムの実装に使ったものとは異なる言語やフレームワークを使える。マイクロサービスを基にしたアーキテクチャは、機能を増やしたり、規模を拡張したりすることも容易である。
Additional functionality can be added to individual microservices independently from the other microservices. This allows teams to iterate faster to bring value to end users. Microservices can also scale independently, as shown in Figure 12.7. During a holiday season with a rapid increase in sales, additional capabilities can be added to the payment system microservice quickly without affecting the other microservices. These additional capabilities can be scaled down as needed when sales decline after the holiday season ends.
英語のヒント
個々のマイクロサービスには、ほかのサービスと独立して機能を追加できる。これにより、チームは素早く反復し、最終利用者に価値を届けられる。図12.7のように、各サービスの規模も独立して拡張できる。休暇シーズンに売上が急増した場合、ほかのマイクロサービスに影響を与えず、決済システムのサービスへ処理能力を素早く追加できる。休暇シーズンが終わって売上が減れば、この追加した能力は必要に応じて縮小できる。
attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license · CC BY 4.0 · Source出典
Figure 12.7 An application that was designed to use a microservices architecture is scaled to handle an increase in use. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)
図12.7 マイクロサービスアーキテクチャで設計したアプリケーションを、利用の増加に対応するために拡張している。（出典：Copyright Rice University, OpenStax、CC BY 4.0ライセンス）
In summary, a monolith bundles all the capabilities together in a highly dependent way and requires them to use the same programming language and framework. Monoliths are more difficult to grow and scale because they require that the entire application be deployed as a second instance. In contrast, a microservices-centric application places individual capabilities in separate microservices that are deployed via containers and communicate via APIs. Individual capabilities are programming language and framework independent. They are easier to grow and scale independently.
英語のヒント
まとめると、モノリスはすべての機能を強く依存する形で一体にし、同じプログラミング言語とフレームワークを使うことを求める。機能を増やしたり規模を拡張したりすることは、より難しい。アプリケーション全体を、2つ目のインスタンスとして配置する必要があるからである。これに対し、マイクロサービス中心のアプリケーションは、個々の機能を別々のサービスに置き、コンテナーによって配置し、APIを通じて通信する。個々の機能は、プログラミング言語とフレームワークに依存しない。独立して機能を増やしたり、規模を拡張したりしやすい。