Microservices Architectureについて学ぶ

多言語、拡張性、保守とデプロイが容易で、可用性が高く、障害を最小限に抑えるアプリケーションを設計する場合は、マイクロサービス・アーキテクチャを使用してクラウド・アプリケーションを設計およびデプロイします。

マイクロサービス・アーキテクチャでは、各マイクロサービスが単純なタスクを所有し、REST APIリクエストなどの軽量通信メカニズムを使用してクライアントまたは他のマイクロサービスと通信します。

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

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

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

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

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

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

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

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

図monolithic_vs_microservice.pngの説明

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

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

これらの特性の詳細は、Microservices: a definition of this new architecture term (Martin Fowler and James Lewis, 2014)を参照してください。

Microservices Architectureの採用に関する考慮事項

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

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

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

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

マイクロサービスを開発する場合は、分散システムの複雑さを考慮してください。リモート呼出しは遅くなり、失敗する可能性があることに注意してください。ユースケースに応じて、一貫性、可用性およびパーティション・トレランスのバランスを取る必要があります。

マイクロサービス・アーキテクチャに関連する操作の複雑さに備えて準備します。Martin Fowlerによると、モノリシック・アプリケーションをマイクロサービス・アーキテクチャに移行する前に、次の前提条件を満たす必要があります。

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

マイクロサービス・アーキテクチャの利点がコストを上回ることを確認します。

詳細は、Microservice Prerequisites (Martin Fowler, 2014)を参照してください。

Microservices Architectureの通信メカニズムについて

マイクロサービス・アーキテクチャでは、サービスは複数のサーバーで実行されます。これらのサービス間の通信は、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 Cloud Infrastructure Container Engine for Kubernetes

少なくとも、ユーザーのグループがコンパートメント内のinstance-family、volume-family、virtual-network-family, cluster-family、object-familyおよびdatabase-familyリソース・タイプを管理できるようにするポリシーを定義します。また、テナンシのreposリソース・タイプへのアクセス権を付与します。

必要なクラウド・サービスを取得するには、Oracle SolutionsのOracle Cloudサービスを取得する方法を参照してください。