Microservices for Java EE Developers (Japanese)

今日、マイクロサービスのコンセプトは単に新しいだけではなくなっています。DevOpsの登場、コンテナ技術ブーム、デプロイ自動化ツールによって、マイクロサービスは開発者が手掛けるアプリケーションの構造を変えつつあります。マイクロサービスはJava EE開発者にとっていかにして有効な選択肢となり得るのか、そしてPayara Microとそれが提供する完璧なプラットフォームによってどのようなメリットが得られるのかについてみてゆきましょう。

This blog is also available in English here.

マイクロサービスの概要

マイクロサービス・アーキテクチャの主な目的は、アプリケーションをより小さな独立したコンポーネントに分割して、より扱いやすく、デプロイしやすく、スケールしやすく、長期間にわたってメンテナンスしやすくすることです。どこかで聞き覚えがあることでしょう。それもそのはずで、これらは多くの開発者が大昔からずっと取り組んできていることなのです。カプセル化、凝集性、サービス指向アーキテクチャへの正しい理解により、私達は長い間に渡ってこのような「分割統治法」をソフトウェア・アーキテクチャに適用してきました。おそらく、これから先もそうなることでしょう。

では、マイクロサービスの長所とは何でしょうか。マイクロサービスは対極となる従来型の手法であるモノリシック・アプリケーションと比較すると理解しやすいでしょう。

モノリシック・アプリケーション、あるいは単にモノリスともいいますが、それは通常大きな業務アプリケーションで、単一のデプロイ可能なパッケージとして構成されています。もし新しいコンポーネントもしくは既存コンポーネントのアップグレードを行いたい場合には、モノリス全体を一度アップデートしなければなりません。これは業務アプリケーションを開発する通常の方法であり、多層構造の考え方（UI、ミドルウェア・サービス、永続化、データ）に注目して、各層単位で関心事を分割します。

モノリスは従来型の考え方に基づく普通のアプリケーションであるのに対して、マイクロサービスのアプローチはアプリケーションを独立したコンポーネント（またはサービス）に分割し、各コンポーネントは以下のような基準を満たすものとなります。

• 小さいこと。
• まとまっていること。例えば単一の機能にフォーカスしていること。
• インタフェースを公開し、同一アプリケーションまたは外部のサービスが使用できるようにしていること。
• 独立して管理できること。すなわち、単独でコーディング、テスト、デプロイ、高速なスケールが可能であること。
• 自身の扱うデータについて応答できること。
• 他のサービスから完全に独立していること。直接的な依存関係を必要としていないこと。

モノリス vs. マイクロサービス

では、すべてのケースにおいて、従来型のモノリシックなアプリケーションの代わりにマイクロサービスを使うべきなのでしょうか。決してそうとは限りません。マイクロサービスは単に新しいアーキテクチャのスタイルを定義するものではなく、アプリケーションの開発チームに対して異なるやり方も要求するためです。

モノリスを使用する場合とマイクロサービスを使用する場合で、それぞれ以下のような利点と欠点があります。

利点として考慮すべき事柄は緑、欠点として考慮すべき事柄は赤、ソフトウェア要求または組織の環境によってメリットが変化するものはオレンジで示す。

マイクロサービスは組織がアプリケーションを構造的な方法で開発する助けになります。しかし、アプリケーションはビジネスにとって重要ではなく、品質指標 (パフォーマンス、可用性、スケーラビリティ、セキュリティ等) がない場合など、伝統的なモノリシックなアプローチの方が十分適している場合もあります。

マイクロサービスとJava EE

Java EE仕様はモノリシック・アプリケーションの作成を容易にします。Java EE開発者にもたらす主なメリットは、特定のコンテナ・サービスがネットワーク処理、トランザクション管理、リソース・ライフサイクルのような技術的な関心事を取り扱うため、それらに煩わされる必要がないことです。これにより開発者の仕事がシンプルとなり、代わりにビジネスの関心事に注力することができます。

Java EEの場合、モノリシック・アプリケーションの例は以下のような特性を持つe-コマース・アプリケーションでしょう。

• 複数のモジュール (モノリスの層を結合する) からなるEARファイルで構成される
• 連携を扱うEJBモジュール (SOAP Webサービス、メッセージ処理、等)
• JPA、JDBC、JCAといった伝統的な方法でデータ・ストアにアクセスする共通の永続化レイヤーとしてのEJBモジュール
• ユーザー・インタフェースとなるWebアプリケーションに相当する複数のWARモジュール。ここではアプリケーションが3つのWARモジュールを持っているものとしましょう。1つは管理インタフェース、プロバイダーまたは販売者が使用するもの、購入者向けのものです。
• アプリケーションはJava EEによって開発されるため、ほとんどのコードはJavaで記述されます。
• WARモジュールについて、ユーザー・インタフェースはおそらくJavaScriptを伴うJSFまたはJSPでコーディングされます。これによりアプリケーション全体は一貫した同じWeb技術によって構成されることになるでしょう。

こうして見ると複雑に感じられることでしょう。上記のシナリオは初期のJava EEで用いられたものです。しかし現在では、Maven、OSGi、Java EEアプリケーションのモジュラー化、アプリケーション全体の単一WARファイルによるデプロイにより、Java EE上でのモノリスの開発は容易になっています。しかし、このe-コマース・アプリケーションをマイクロサービスとして開発するには、シンプルなWARは十分ではありません。

マイクロサービスを作成するのにGlassFish (およびPayara Server) のようなJava EEアプリケーション・サーバーに含まれるAPIを使用することには何の技術的な制約もありません。ただし、いくつかの注意点があります。

• 各マイクロサービスは完全に単独でのデプロイが可能でなければなりません。つまり各サービスはそれぞれが単独のJava EEコンテナによって構成されることを意味します。つまり。例えばアプリケーションが10のマイクロサービスから構成されているとするならば、各サービスを配備するために10の独立したアプリケーション・サーバーのインストールが必要となります。
• ほとんどのアプリケーション・サーバーは決して軽量とは言えず、その複雑さと提供機能を考慮する必要があります。例えば、Payara ServerのFull Profileは現時点でおよそ117 MBあります。
• ほとんどのアプリケーション・サーバーが起動時間を短縮化してきているにもかかわらず、アプリケーション・サーバーは特定のサービスでは使用しない多くのコンポーネントまで準備するため、いくらかのオーバーヘッドがあります。例えば、GlassFishのドメインを起動する時には、サーバーはメッセージング・サブシステムを初期化しますが、これは一部の例外を除き、多くのサービスでは必要としません。

Payara Micro はこれらを考慮して開発しました。より小さなサイズで、JARとしてパッケージ可能で、開発者は以下のシンプルなコマンドでマイクロサービスを容易に実行することができます。

java -jar payara-4.1.1.163.jar --deploy user-service.war 

各サービスをこのコマンドで実行しても、サービスが起動するまで長い時間を待つ必要や、サーバーを何度もインストールする必要はありません。Payara MicroはJava EE Web Profileをベースとしており、複雑でレガシーなAPI (例えばJMS、JCA、JAX-WS) は使用できなくなっています。ただし、マイクロサービスの技術的要求を考慮すると、これらがなくても問題ありません。依然としてサーブレット、JSP、JSF、CDI、JAX-RS、JPA、JSON-P等が使用可能だからです。

• お勧めの方法

  これだけでは、Payara Microだけでマイクロサービス・アプリケーションを構築するのは十分ではありません。以下にJava EEでマイクロサービスを構築する際に私が個人的にお勧めしている方法を挙げます。

  • アプリケーションをWARプロジェクトとしてパッケージしてください。EARを使用してパッケージする必要はありません。これはモジュール構成によるもので、マイクロサービスは最小限の開発単位を用いて構成すべきです。
  • すべてのサービス間の連携は可能な限りHTTPとRESTで定義します。これによりアプリケーションと組み合わせる他のサービス (Java、Java EE、Payara Microで開発されていない) との通信が可能になります。各マイクロサービスはJAX-RSで定義されたRESTエンドポイントを持ちます。これらのエンドポイントの完全なドキュメントは通信規約を明確にするためスタート時から明確にしておく必要があります。そのためにSwaggerアプリケーションの仕様をお勧めします。これはとてもパワフルで、JAX-RSとも親和性が高いものとなっています。
  • Payara Microが提供するCDI event busにより、あるサービスから別のサービスにイベントを伝搬させることが可能です。このような非同期通信により、サービスは分割しやすくなり、リアクティブ・モデルを適用しやすくなります。しかし、これはPayara Micro固有の機能であり、Payara Microにデプロイしたマイクロサービスでのみ使用できることに注意してください。Java EEとPayaraを開発に選んだ場合には、同じアプリケーションに属するサービス間の通信のみを考慮してください。
  • 常にステートレスなコンポーネントだけを使用してください。ステートフルなコンポーネントはスケールさせるのが複雑なだけでなく、マイクロサービスのセット間におけるユーザー・データの受け渡しをも難しくしてしまいます。
  • CDIビーンでは、@RequestScopedと@ApplicationScopedだけ使用する。
  • @Stateless セッション・ビーンのみを使用する。
  • HTTPセッション・オブジェクトを保存しない。デフォルトでは、HTTPセッション・オブジェクトはWebアプリケーションが管理するため、たとえそれらを全く使用していなくても生存期間の短い (およそ5分) セッションが定義されます。
  • Webアプリケーションのユーザー・インタフェースではHTML5を活用するようにしてください。今日では、AngularJSやReactJSといったフレームワークはリッチなWebインタフェースを構築するのに良いツールです。
  • もしユーザー・インタフェースでJSFページの仕様を検討しているのであれば、ステートレス・ビュー(<f:view transient=”true”>) を使用するようにしてください。
  • 必要に応じて、JCacheを用いて特別なキャッシュ・コンポーネントをサービスにコーディングしてください。Payara Microでは、Hazelcastが使用可能で、クラスタ内のキャッシュ設定がシンプルになります。
  • データ・ストアを必要とするサービスの場合は、H2、SQLite、Java DB (JDKに付属し追加の依存性設定が不要です) といった小型のリレーショナル・データベースの使用を検討してください。そうすることでJPAによるオブジェクト・リレーショナル能力を活用することができます。もしより高速でよりスケールの容易なデータベースが必要であれば、適切なNoSQL (MongoDBやCouchbase) に変更しましょう。ほとんどのNoSQLデータベースはJava APIと豊富なドキュメントを提供しているため、以降に関しては心配はいりません。
  • Payara Serverが持つ、Hazelcastによる自動クラスタリング機能の長所を活用してください。Payara Microを使用することで、各サービスのクラスタ名を簡単に定義することができます。

  java -jar payara-4.1.1.163.jar --deploy login-service.war --clusterName loginService

  • Dockerコンテナは必須です。Dockerイメージによるアプリケーションのデプロイ構成により、マイクロサービスのデプロイ自動化を容易にすることができます。さらに良いことに、Payara Microの公式イメージを使用することができます。
  • 最後に、Apache Mesos、Consul、Google Kubernetes、Docker Swarmのような、マイクロサービスのクラスタをオーガナイズするオーケストレーション・サールの使用を検討してください。
  
  
  

MicroProfile

Payara Microはマイクロサービスに向いていますが、開発者がずっと小さなフットプリントでサービスを実装するための要求を満たすには十分とは言えません。そこでPayara、Red Hat、IBM WebSphere Liberty、Tomitribe、London Java Communityによって構成される新しいコミュニティ・グループは、エンタープライズJava開発者をターゲットとしたマイクロサービスのイニシアティブ、MicroProfileを提唱しています。MicroProfileの主な目的は、アプリケーション・サーバーがマイクロサービス環境を対象とするコンパクト版のランタイムを実装する際に使用できる機能一式をデザインすることです。

• 短い起動時間
• より小さなバイナリ・サイズ
• メモリ消費量の削減
• クライアント側による負荷分散
• リアクティブ・プログラミング・モデルのサポート(非同期受信、メッセージ中心呼び出し、等)
• サーキット・ブレーカー機構のサポート

現時点ではMicroProfileはCDI、JAX-RS、JSON-Pの各仕様への準拠に集中しています。このプロジェクトを進めていく上で、同じように含めた方が良いと思われる他のAPIや機能について投票してください。

まとめ

マイクロサービスはすぐそこまで来ています。大企業もスタートアップもそこに十分なメリットが得られるのであればマイクロサービス・アーキテクチャの実装を検討すべきでしょう。それだけにJava EEを置き去りにすることはできず、また開発者がこのスタイルに移行するためJava EEは進化しなければなりません。Payara Microは理想的なスタート地点であり、特に既にGlassFishやPayara Serverに慣れているのであれば、Java EEアプリケーションをデプロイし動作させるのはとても簡単です。

マイクロサービスは銀の弾丸ではなく、共有された知識に過ぎないことに注意してください。伝統的なモノリシックなアプローチは依然として有効であり、マイクロサービスへの切り替えはメリットが必要性と用途に合致する時に行ってください。マイクロサービスへの移行は皆さんが直面する技術的なチャレンジを良く理解するだけに留まらず、同様に組織とビジネスにとってのチャレンジでもあることを理解しておいてください。