マイクロサービス・アーキテクチャについて学習

最新のアプリケーションは、個別に構築されたいくつかのサービスを構成することによって構築されます。これにより、問題の修正と新機能導入のための俊敏性と市場投入までの期間が短縮されます。

このパラダイムはマイクロサービス・アーキテクチャと呼ばれますが、完全なアプリケーション用にまとめられるサービスの数は、数百(マイクロサービス)または10(マクロサービス)です。モジュラーモノリスと呼ばれるモジュラーモノリスにも新しい用語が使用されており、スプリングモジュリスがその例です。

多くの組織にはすでにマイクロサービス・アーキテクチャがありますが、マイクロサービスのデプロイメントには複雑さが伴い、デプロイメントの成功はほとんどの組織で引き続き進行中です。このソリューション・プレイブックは、Oracle Databaseを使用したクラウド・インフラストラクチャ、コンテナ、KubernetesおよびBackend as a Serviceプラットフォームとともに、人気のあるSpring Bootプラットフォームを使用して、最新のマイクロサービスの構築と導入を簡素化しようとします。

多言語、簡単にスケーラブル、メンテナンスとデプロイが容易、高可用性、および障害を最小限に抑えるアプリケーションを設計する場合は、マイクロサービス・アーキテクチャを使用してクラウド・アプリケーションを設計およびデプロイします。マイクロサービス・アーキテクチャでは、各マイクロサービスは単純なタスクを所有し、REST APIリクエストなどの軽量通信メカニズムを使用してクライアントまたはその他のマイクロサービスと通信します。

次の図は、複数のマイクロサービスで構成されるアプリケーションのアーキテクチャを示しています。

図microservice_architecture.pngの説明

マイクロサービスを使用すると、疎結合サービスの集合としてアプリケーションを設計できます。マイクロサービスはシェアナッシング・モデルに従い、ステートレス・プロセスとして実行されます。このアプローチにより、アプリケーションのスケーリングとメンテナンスが容易になります。

APIレイヤーは、マイクロサービスへのすべてのクライアント・リクエストのエントリ・ポイントです。APIレイヤーにより、マイクロサービスはHTTP、gRPCおよびTCP/UDPを介して相互に通信することもできます。
ロジック・レイヤーは、単一のビジネス・タスクに焦点を当て、他のマイクロサービスへの依存を最小限に抑えます。このレイヤーは、マイクロサービスごとに異なる言語で記述できます。
データ・ストア・レイヤーは、データベース・ストレージ・エンジンやログ・ファイルなどの永続性メカニズムを提供します。マイクロサービスごとに個別の永続データ・ストアを使用することを検討してください。Oracleは、複数のプラガブル・データベースを備えたデータベース・コンテナを提供し、マイクロサービスがセキュリティ、HAおよびスケーリングのためにデータを簡単に分離できるようにします。また、SaaSアプリケーションは、マルチテナンシを安全な方法で利用できます。また、コンバージド・データベースは、データからより豊富なインサイトを得るために、さまざまなデータを1つの屋根の下にまとめます。

通常、各マイクロサービスは、軽量ランタイム環境を提供するコンテナで実行されます。

マイクロサービス・アーキテクチャとモノリシック・アーキテクチャの違い

マイクロサービス・アーキテクチャを使用してアプリケーションの設計を開始する前に、このアーキテクチャが従来のモノリシック・アーキテクチャとどのように異なるかを理解する必要があります。

アプリケーション設計は、ビジネス要件の解決とビジネス・ロジックの実装に重点を置いています。モノリシック・アーキテクチャでは、アプリケーション全体が、すべてのビジネス・ロジックを含む単一のユニットとして構築されます。マイクロサービス・アーキテクチャでは、ビジネス・ロジックは複数の疎結合サービスとして編成されます。

次の図は、モノリシック・アーキテクチャとマイクロサービス・アーキテクチャを示しています。

図monolithic_vs_microservice.pngの説明

次の表に、マイクロサービスとモノリシック・アーキテクチャの違いをまとめます。

特性	Microservices Architecture	モノリシック建築
ユニット設計	アプリケーションは、疎結合サービスで構成されます。各サービスは、単一のビジネス・タスクをサポートします。	アプリケーション全体が単一のユニットとして設計、開発およびデプロイされます。
機能の再利用	マイクロサービスは、その機能を任意のクライアントに公開するAPIを定義します。クライアントは他のアプリケーションであってもかまいません。	アプリケーション間で機能を再利用する機会は限られています。
アプリケーション内での通信	アプリケーションのマイクロサービスは、互いに通信するために、リクエスト/レスポンス通信モデルを使用します。一般的な実装では、HTTPプロトコルに基づくREST APIコールを使用します。	内部プロシージャ(ファンクション・コール)により、アプリケーションのコンポーネント間の通信が容易になります。内部プロシージャ・コールの数を制限する必要はありません。
技術の柔軟性	各マイクロサービスは、マイクロサービスが解決するように設計されている問題に最も適したプログラミング言語とフレームワークを使用して開発できます。	通常、アプリケーション全体が単一のプログラミング言語で記述されます。
データ管理	分散型: 各マイクロサービスは独自のデータベースを使用できます。	一元化: アプリケーション全体が1つ以上のデータベースを使用します。
デプロイメント	各マイクロサービスは、アプリケーション内の他のマイクロサービスに影響を与えずに、個別にデプロイされます。	ただし小規模な変更の場合は、アプリケーション全体を再デプロイして再起動する必要があります。
メンテナンス性	マイクロサービスはシンプルで、集中的で、独立しています。そのため、アプリケーションの保守が容易になります。	アプリケーションのスコープが増加すると、コードのメンテナンスがより複雑になります。
レジリエンシ	アプリケーション機能は、複数のサービスに分散されます。マイクロサービスに障害が発生しても、他のマイクロサービスが提供する機能は引き続き使用できます。	コンポーネントの障害は、アプリケーション全体の可用性に影響する可能性があります。
スケーラビリティ	各マイクロサービスは、他のサービスとは無関係にスケーリングできます。	ビジネス要件がアプリケーションの特定の部分のみをスケーリングする場合でも、アプリケーション全体をスケーリングする必要があります。

マイクロサービス・アーキテクチャの採用に関する考慮事項

新しいアプリケーションを設計する場合は、高レベルのスケーラビリティ、柔軟性および信頼性を必要とするアプリケーションのマイクロサービス・アーキテクチャを検討します。異なるプログラミング言語とフレームワークを使用して、各コンポーネントを開発できます。

アプリケーションの機能を限定されたスコープを持つ集中型サービスに分割できる場合は、モノリシック・アプリケーションをマイクロサービスに移行することを検討してください。マイクロサービス・アーキテクチャに移行できない複雑なモノリシック・アプリケーションについては、マイクロサービスとして新しい機能のみを開発することを検討してください。

サービス間の相互依存関係は、サービスの再デプロイメント中に使用できないアプリケーションの量に影響を与える可能性があります。アプリケーションの設計中に、このような依存関係の問題を解決します。

モノリシックなアプリケーションのリファクタリングは困難です。マイクロサービス・アーキテクチャを使用する場合は、プロジェクトの開始からそのアーキテクチャを計画します。

マイクロサービスを開発する際には、分散システムの複雑さを考慮し、リモート・コールが遅く、失敗する可能性があることを覚えておいてください。ユースケースに応じて、一貫性、可用性およびパーティション許容範囲のバランスをとる必要があります。

マイクロサービス・アーキテクチャが関与する操作の複雑さに備えてください。モノリシック・アプリケーションをマイクロサービス・アーキテクチャに移動する前に、次の前提条件を満たすことをお薦めします:

迅速なプロビジョニング: サーバーを迅速にプロビジョニングする機能
基本的な監視: サービスの問題とビジネス上の問題を検出する機能。サービスの問題には、サービスの可用性、機能エラーおよびパフォーマンスの問題が含まれます。
迅速なアプリケーション・デプロイメント: 任意のサービスをテスト環境および本番環境にすばやくデプロイする機能

マイクロサービス・アーキテクチャのメリットがコストを上回っていることを確認してください。

マイクロサービス・アーキテクチャでの通信メカニズムについて

マイクロサービス・アーキテクチャでは、サービスは複数のサーバー上で実行されます。これらのサービス間の通信は、HTTP、AMQP、TCPなどのプロトコルを介して行われます。HTTP/RESTおよび非同期メッセージングは、最も広く使用されているプロトコルです。

WebサービスのREST APIでは、一般的にHTTPプロトコルが使用されます。HTTPメソッド(GET、POST、PUT、DELETEなど)では、クライアントはUniform Resource Locator (URL)を使用してアプリケーション・リソースにアクセスして操作できます。

クライアントは、アプリケーション機能のエントリ・ポイントを表すREST APIを介してサービスにリクエストを送信します。クライアントは、直接またはAPIゲートウェイを介してマイクロサービスと通信できます。

APIゲートウェイ・パターンは、サービスへのすべてのリクエストに対して単一のエントリ・ポイントを定義します。クライアント・リクエストが到着すると、APIゲートウェイはリクエストを適切なサービスにルーティングします。

APIゲートウェイ・パターンのバリアントは、フロントエンドのバックエンド・パターンで、クライアントの種類ごとに個別のAPIゲートウェイを定義します(たとえば、モバイル・クライアント用のゲートウェイとWebアプリケーション用のゲートウェイ)。

サービス間の通信を最小限に抑えることをお薦めします。通信が不可欠な場合、非同期通信が望ましい。リクエストを送信するサービスは、レスポンスを待たずに操作を続行できます。

メッセージング・キューおよびストリーミング・システムは、非同期通信を提供する理想的な方法であり、データベースに統合されると、データ操作およびメッセージ送信のためのトランザクション・セマンティクスを提供します。これにより、マイクロサービスはよりシンプルでスケーラブルな導入が可能になります。REST APIを使用すると、マイクロサービス間の通信が排他的に同期され、通常はスケーリングが制限されます。

必須サービスおよびロールについて

このソリューションには、次のサービスが必要です。

Oracle Cloud Infrastructure Database (Oracle Autonomous Databaseを含む様々な選択肢)
Oracle Cloud Infrastructure Container Engine for Kubernetes
Oracle Backend for Spring Boot and Microservices

各サービスに必要なロールは次のとおりです。

サービス名: ロール	必須...
Oracle Cloud Infrastructure Database: `SYSTEM`または`ADMIN`	Spring BootおよびMicroservicesOracle Backend for Spring Boot and Microservices用のOracle Backendを構成するときに、データベース・アクセスをプロキシするユーザーを作成します。`SYSTEM`または`ADMIN`は機能しますが、権限が過剰であるため、本番環境では使用しないでください。
Oracle Cloud Infrastructure Container Engine for Kubernetes: `CLUSTER_MANAGE`	Oracle Cloud Infrastructure Container Engine for Kubernetesクラスタと、3つのワーカー・ノードを持つノード・プールを作成します。
Oracle Backend for Spring Boot and Microservices: `ROLE_ADMIN`	Oracle Backend for Spring Boot and Microservicesをインストールします。

必要なものを取得するには、Oracle製品、ソリューションおよびサービスを参照してください。