MicroProfileってなにそれ？ - MicroProfileの仕様と実装

前回はMicroProfileの登場からMicroProfileが目指すものまで説明しました。今回はMicroProfileの中身となるMicroProfileの仕様と実装について、私見も交えながら説明したいと思います。若干長い説明となりますが、最後まで目を通していただけたら幸いです。

早速ですがMicroProfile5.0に含まれている仕様^[1]を並べると下のとおりとなります。

図をパッと見てCDIやJAX-RSなど見慣れた、もしくは耳にしたことがあるJakarta EEの仕様が含まれているのが分かると思います。これが正に前回の説明にあった「Jakarta EEや既に存在するJavaエコシステムの活用」に当たります。

昨今のJavaアプリケーション開発ではオブジェクトの管理やオブジェクトの依存性の注入(Dependency Injection)を行うDIコンテナは必須となっていますが、そのDIの手段としてMicroProfileではJakarta EEのCDIを取り入れ活用しています。また、RESTはマイクロサービスアーキテクチャで必須となりますが、これもJakarta EEのJAX-RSが取り入れられています。

このようにMicroProfileはJakarta EEの仕様がベースとなっているため、Jakarta EEと非常に親和性の高いAPI体系となっています。

そして、次に注目すべき仕様としてOpenTracingやMetricsなどがあります。

マイクロサービスアーキテクチャで重要性が増す非機能要件として、システムがどのような状態になっているか観測可能かを意味する可観測性と障害から回復しサービスを継続する回復性があります。MicroProfileではこの可観測性と回復性を実現する仕様としてOpenTracingやMetrics、Health, Fault Toleranceが含まれています^[2]。

これらの仕様が含まれている点が前回の説明でMicroProfileの目的として掲げられていた「マイクロサービスアーキテクチャで必要となる標準APIや機能の提供」をよく表しています。

MicroProfileに含まれるそれぞれの仕様の内容は下記のとおりとなります。 仕様にはMicroProfileの実装を提供する実装ベンダー観点とそれを利用する利用者観点、双方の内容が含まれています（なので若干小難しくなっています）

MicroProfileはあくまでも仕様のため、MicroProfileを使うにはMicroProfile仕様に準拠した実装が必要となります。そして、この仕様と実装の関係は基本的にJakarta EEと同じとなります。

例えばJakarta EE仕様の1つであるJPAであれば、その実装としてHibernateやEclipseLinkがありますが、これと同様にMicroProfileも1つの仕様に対して複数の実装が存在するものがあります。また、Jakarta EE対応のアプリケーションサーバ（以降、アプリケーションサーバ）であれば、対応するプロファイル^[6]に含まれるすべての実装がアプリケーションサーバから提供されます。

よって、アプリケーションサーバ上でWebアプリケーションを稼働させる場合、warのWEB-INF/libにJPAなど利用したい実装（ライブラリ）を個別に配置する必要はありません。

これはJakarta EEの実装は基盤となるアプリケーションサーバから提供されるためです。MicroProfileの機能を利用する場合も基本的にこれと同様となります。つまり、MicroProfileを利用する場合は対応する基盤を利用ことになります。

と、ここで基盤と敢えてボンヤリ書いたことには理由があります。それはMicroProfileの実装形態が大きく2つあるからです。そこで次からは具体的なMicroProfileの対応製品を見ていきたいと思います。

筆者の独断と偏見でMicroProfileの実装^[7] ならコレ！というものを5つ選び、ブランドロゴを並べてみました。

ロゴを見てもらうと良く知っている製品が並んでいるかと思います。そうです、MicroProfileの利用形態の1つは、MicroProfileに対応したアプリケーションサーバを使うことになります。

OpenLibertyやPayara、WildFlyはJakarta EEはもちろんのこと、MicroProfileにも対応しています。ですので、MicroProfile対応のアプリケーションサーバを使っていれば、追加で何かを導入することなく、MicroProfileの機能を利用することができます^[8] 。また、MicroProfile対応のアプリケーションサーバで稼働している既存のアプリケーションにMicroProfileを利用した処理を追加することももちろん可能です。

もう1つの形態は、マイクロサービスアーキテクチャで利用されることを目的として開発されたQuarkusやHelidonといったMicroProfileフレームワーク^[9]の利用となります。

マイクロサービスアーキテクチャはアプリケーションサーバ上で稼働させていたモジュラーモノリス^[10]といった比較的大きな1つのアプリケーションを複数のモジュールに分割し、分割した1つ1つのモジュールを独立した1つのJavaプロセスとして動作させるものとなります。しかし、このモジュールを動作させる基盤としアプリケーションサーバを用いることにはやや問題があります。

それはメモリやディスクのフットプリントです。単純に今まで1つで賄っていたアプリケーションサーバを分割したモジュールの数だけ用意する必要があると言われた場合、感覚的に「えっ！？」となることは容易に理解いただけると思います。

また、アプリケーションサーバにはServletやJSFと言ったMPA(MultiPageApplication)に関するUI機能や分散トランザクションなどの堅牢性に関する仕組みが多く含まれてきます。アプリケーションによってはこれらが有効に機能するケースが多くありますが、マイクロサービスアーキテクチャではREST APIとしてサービスを提供するのみで、UIを提供することはありません。

トランザクションについてもデータの一貫性が常に求められる分散トランザクションではなく、間隔が空いても最終的にはデータの一貫性が保たれればよしとする結果整合性によるトランザクションが一般的に用いられます。

よって、マイクロサービスアーキテクチャの実行基盤にアプリケーションサーバを用いた場合、利用しない無駄な機能により大なり小なりメモリとディスクが消費されます。そのため、端的に不必要に高機能とも言えます。

そこで選択肢となるのが、先ほど出てきたQuarkusやHelidonといったMicroProfileフレームワークとなります。MicroProfileフレームワークはそれ自身でWebサーバの機能を内包しているためExecutable Jarとして、javaコマンドから直接アプリケーションを起動することができます。つまり、アプリケーションの実行にアプリケーションサーバを必要としません。

また、含まれる機能はMicroProfile実装とマイクロサービス向けに追加された各フレームワークの固有機能のみとなり、UIや分散トランザクションと言ったマイクロサービスアーキテクチャで使われることがない機能は含まれません。よって、アプリケーションサーバと比較した場合、軽量となります。

ここで軽量と表現すると貧弱と言ったネガティブなイメージを与えますが、UIを持たずHTTPのエンドポイントとしてサービスを公開するマイクロサービスのアプリケーション開発ではMicroProfileに含まれるAPIや機能で十分事が足ります。このため、既存アプリケーションも一緒に稼働させると言った制約がない限り、マイクロサービスアーキテクチャの基盤にアプリケーションサーバを選択する理由はありません。

MicroProfile対応製品の各種情報と勝手な一口コメントでこのテーマを終わりにします。

前回のMicroProfileの登場でも軽く触れましたが、MicroProfileの一部であったMicroProfile ConfigはJakarta EE10に取り込まれる予定^[13]となっています。また、MicroProfile Config同様に今後Jakarta EEに取り込まれることが噂されるMicroProfile仕様もいくつかあります。

これらのことから、今後はMicroProfileの成果がJakarta EEに積極的にフィードバックされていくのではないかと思われます。

Java EE時代はJavaアプリケーションのデファクトであるSpring Frameworkの後追いや劣化版的な否めませんでした。これがもし今後は標準化団体主導で新しいアーキテクチャが切り開かれ、結果それが標準化としてデファクトになることがなるのであればそれは健全で歓迎すべきことではないかと思います（そうなるかは別ですが・・）。

MicroProfileは1.0リリースから約6年経ちバージョンも5.0となった現在、実践でも十分に使える仕様になってきていると個人的に実感しています。Javaによる現実的で実践的なマイクロサービスアーキテクチャの未来としてこの機会をきっかけに是非MicroProfileにも注目していただければと思います。

多くのアプリケーションは標準準拠がそれだけでアーキテクチャの目的となることはありません。標準準拠はあくまでも私たちがアーキテクチャ上の課題を解決するための1つの手段でしかありません。

よって、Jakarta EEやMicroProfileなどの標準仕様を採用する場合は、標準に準拠することで「何を得たいか」、「何を解決したいか」、そして「それは他のアーキテクチャを選択するよりも大事なことなのか」を考えることが重要となります。

Spring FrameworkではなくJava EEを採用したが、Java EEはSpring Frameworkよりも○○なので、イケてない、失敗だったなどと言ったコメントや評価をたまに見聞きしたりしますが、なぜJava EEを選択したのか実際に聞いてみると、その多くは「標準だから」です。標準を利用することは目的ではありません。Jakarta EEやMicroProfileに対してこのような残念な評価がなくなることを期待し今回は終わりにしたいと思います。