MicroProfile によるマイクロサービス開発

Eclipse MicroProfile は、Enterprise Java™ 環境でマイクロサービス・アプリケーションを開発するためのプログラミング・モデルを定義します。 これは、Enterprise Java コミュニティーにマイクロサービスを提供する、 Eclipse Foundation の下のオープン・ソース・プロジェクトです。 MicroProfile は Liberty でサポートされます。

MicroProfile では、弾力性がありセキュアで、モニターが容易なマイクロサービスを作成するための多数の仕様が定義されます。
表 1. Eclipse MicroProfile 1.2 に含まれる内容
仕様 説明
JSR 346: Contexts and Dependency Injection for Java EE 1.1 CDI は、Enterprise Java ランタイム内のオブジェクトの注入とライフサイクルを管理する一連のサービスを定義します。
JSR 339: JAX-RS 2.0: The Java API for RESTful Web Services JAX-RS は、Java API for RESTful Web Services です。
JSR 353: Java API for JSON Processing JSON-P は、JSON を処理するための Java API です。
Eclipse MicroProfile Config 1.1 構成は、アプリケーション構成を管理するための Java API および SPI です。
Eclipse MicroProfile Fault Tolerance 1.0 Fault Tolerance では、外部サービスの呼び出し時に障害を処理するための戦略を提供します。
Eclipse MicroProfile Health Check 1.0 Health Check を使用すると、コンポーネントはその稼働状況を広範囲のシステムに報告できます。
Eclipse MicroProfile Health Metrics 1.0 Health Metrics では、アプリケーションでモニター・データを公開するための統一された方法を提供します。
Eclipse MicroProfile JWT Propagation 1.0 JWT 伝搬により、 Java EE ロール・ベースのアクセス制御 (RBAC) を使用した認証および許可に JSON Web Token (JWT) を使用できます。

既知の制約事項

  • CDI は MicroProfile API で幅広く使用されていますが、Liberty では、エンタープライズ・バンドル・アーカイブ (EBA) にパッケージ化された OSGi Web アプリケーションでの CDI はサポートされません。 代わりに、MicroProfile を使用するアプリケーションを Web アプリケーション・アーカイブ (WAR) またはエンタープライズ・アプリケーション・アーカイブ (EAR) にパッケージ化します。
  • MicroProfile Fault Tolerance 1.0 は、他のサービスに対する呼び出しを管理するように設計されています。 トランザクション・コンテキスト内のリソースに対する更新を管理するようには設計されていません。 CICS® リソースは、 @Bulkhead、 @CircuitBreaker、 @Fallback、 @Timeout または @Retryの注釈が付けられたメソッドでは更新しないでください。 CICS は、JTA が使用されている場合でも、例外が発生したときにこれらの更新がリカバリーされることを保証できません。
  • mpJwt-1.0 フィーチャーが Liberty JVM サーバーの server.xml で有効になっている場合、すべての認証を JWT ベアラー・トークンを使用して行う必要があります。 他の形式の認証を使用するには、別個の Liberty JVM サーバーを使用する必要があります。

CICS Liberty JVM サーバーのサービス・アーキテクチャー

モノリシック・アーキテクチャー

モノリシック・アーキテクチャーでは、単一の単位でアプリケーションを実装します。 内部的にはロジックをモジュール形式にすることができますが、外部的には、アプリケーションは全体的に使用可能であるか、まったく使用不可であるかのいずれかになります。 モノリスはマイクロサービスと比較して良好に機能し、セキュリティーおよびトランザクション・コンテキストを管理する場合、それほど複雑ではありません。 モノリスのスケーリングでは、アプリケーション全体のインスタンスを追加する必要があり、各パーツを個別にスケーリングすることはできません。
図1： モノリシック・アーキテクチャー
モノリシック・アーキテクチャーでは、単一の単位でアプリケーションを実装します。 内部的にはロジックをモジュール形式にすることができますが、外部的には、アプリケーションは全体的に使用可能であるか、まったく使用不可であるかのいずれかになります。

バッキング・サービス

バッキング・サービスを使用すると、バックエンド・データおよびプログラムをメイン・アプリケーションから分離できます。 データとプログラムを別々のアプリケーションにすることで、プラットフォームに依存しない通信方法（例えば HTTP、ソケット、メッセージキューなど）で呼び出されます。 これらのソースと通信するためのすべてのロジックを保持するメイン・アプリケーションの代わりに、これらのサービスに対して何らかの責任が与えられます。

CICS では、z/OS Connect を使用し、CICS プログラムを REST API を介してバッキング・サービスとして公開します。 この例では、アプリケーションは JDBC を使用してデータベースと通信します。 E メールの送信には SMTP が使用され、z/OS Connect を介した CICS プログラムの呼び出しには HTTP が使用されます。

図2： バッキング・サービス
バッキング・サービスにより、アプリケーションとアプリケーション・リソースを分離できます。 すべてのアプリケーション・ロジックを単一のユニットに含めるのではなく、サービスを公開して、内部サービスと外部サービスに簡単にアクセスできるようにすることができます。

ホスト・サービス

サービスは、メイン・アプリケーションをさまざまなコンポーネントからさらに分離するために、CICS でホストされます。 バッキング・サービスと同様に、追加機能は CICS Web サービスを介して CICS で公開されるか、またはサーブレット、JAX-RS、JAX-WS などのテクノロジーを使用して、アプリケーションにより CICS Liberty で公開されます。

JAX-RS は RESTful Web サービスを作成するための一般的なテクノロジーであり、JAX-WS は、リモート手続き呼び出し (RPC) 指向の Web サービスを作成するために使用されます。
図3： ホスト・サービス
ホスト・サービスは、中央コアにアプリケーションの複数の部分を持ちます。これは、ホスト・サービスが独自の呼び出し可能サービスによって制御されることを意味します。
注: REST と RPC はどちらも、マイクロサービスでの通信に対して同等に有効なオプションです。 REST はリソース管理に重点を置いています。 RPC はアクションに重点を置いています。 マイクロサービス・アーキテクチャーでは、REST、RPC、またはその他のテクノロジーは必須ではありません。

マイクロサービス

完全なマイクロサービス・アーキテクチャーは、分離されたサービスが相互接続された Web であり、単一の中心点はありませんが、専用のエントリー・ポイントは存在する場合があります。 サービスは、必要に応じて相互に通信できます。 マイクロサービスのスケーリングでは、スケーリングを必要とするパーツのインスタンスを追加する必要があります。 マイクロサービスは、モノリスよりも障害に対して弾力性があります。
図4： マイクロサービス
完全なマイクロサービス・アーキテクチャーは、分離されたサービスが相互接続された Web であり、単一の中心点はありませんが、専用のエントリー・ポイントは存在する場合があります。

CICS でのサービスのスケーリング

CICS では、領域のトポロジーおよびセットアップに応じて、サービスを複数の方法でスケーリングできます。 通常、マイクロサービスは単一のコンテナーに分離されます。 CICS では、サービスまたはサービスのセットは、領域または JVM サーバー内で分離できます。 スケーリングを行うには、同じサービスまたはサービスのセットをホストする複数の CICS 領域を実行します。 また、スレッド数を増加させて JVM サーバーをスケーリングすることもできます。

マイクロサービスの保護

可能な場合、マイクロサービスではパブリック・ネットワークをオフにしておく必要があります。 API ゲートウェイを使用して、マイクロサービスへのアクセスを制御できます。 MicroProfile では、マイクロサービス・エンドポイントの役割ベースのアクセス制御 (RBAC) に Open ID Connect (OIDC) ベースの JSON Web Token (JWT) を使用するための方式を提供します。 セキュリティー・トークンにより、さまざまなサービスにわたるユーザー ID の単純で相互運用可能な伝搬が可能となります。

MicroProfile JWT Authentication 1.0 では、JWT ベアラー・トークンに基づいてユーザーを認証および許可する機能を提供します。 トークンをサービス・コードに注入して、ID をマイクロサービス・ネットワーク全体に伝搬するために使用できます。 JWT の伝搬は、アウトバウンド要求の許可 HTTP ヘッダーにベアラー・トークンとして JWT を組み込むことにより、手動で行うことができます。 あるいは、Liberty は、 authnToken が構成された server.xml で webTarget エレメントを構成することによって、JWT を自動的に伝搬することができます。以下に例を示します。
<webTarget uri="http://microservice.example.ibm.com/protected/*" authnToken="mpjwt" />
重要: JWT ID は、自動的にはユーザー・レジストリーにマップされず、 CICS タスク・ユーザー ID に伝搬されません。 ID マッピングを使用可能にするには、 server.xml内の <mpJwt> エレメントに mapToUserRegistry=”true” 構成属性を追加します。
Liberty での MicroProfile JWT 認証の構成について詳しくは、 MicroProfile JSON Web トークンの構成を参照してください。

マイクロサービスでのデータ整合性

マイクロサービスで分散トランザクションを使用することは容易ではありません。 代わりに、saga パターンなどの代替のトランザクション戦略が使用されます。この場合、イベントはサービスで更新された後に公開されます。 例えば、サービス A とサービス B にどちらも必須の更新が含まれる場合、以下の順序で行われます。
  1. A の更新が保留状態になります。
  2. A から B へメッセージが送信されます。
  3. B の更新が完了状態になります。
  4. B から A へメッセージが送信されます。
  5. A の更新が完了状態になります。

マイクロサービスを使用する場合

マイクロサービスを適用するのに最適なシチュエーションは、アプリケーションをより小さな分離されたサービスに分解可能な場合です。 マイクロサービスを使用すると、制御されたスケーリング、独立したデプロイメント、およびより自律型の開発が可能となります。 マイクロサービスのアーキテクチャーにより、デプロイメントおよびデータ整合性においては特に、複雑性が増す可能性があります。 HTTP などのプロトコルを介した通信では、メモリー内の呼び出しと比較して、パフォーマンス・コストが増加します。 コンポーネントを個別にスケーリングできるようにすることで、コンポーネントの障害に対する弾力性が向上します。 マイクロサービス・アーキテクチャーを管理する際には、正常でないサービスの診断を支援するためにモニター・ソリューションがさらに重要となります。