モノリスからマイクロサービスへ。いつJavaアプリケーションを変換すべきか？ (2020/10/01)

https://blogs.oracle.com/cloud-infrastructure/from-monolith-to-microservice-when-should-you-convert-your-java-applications
投稿者：Dmitry Kornilov | Director, Software Development
多くの企業が、モノリス型のオンプレミス型アプリケーションからクラウドネイティブのマイクロサービスへの移行を考えている大きな理由の1つに、クラウドがあります。
クラウドは、ロードバランサー、監視・トレースツール、自動回復サービスなど、
クラウドを利用しなければ自分で実装・管理しなければならないサービスなど、多くの便利なサービスを提供しています。
マイクロサービスは、ある意味でクラウド向けに設計されており、スケーラビリティとポータビリティの両方を提供しています。
しかし、Javaベースのモノリシック・アプリケーションを変換するべきでしょうか？

マイクロサービスが答えにならない場合

マイクロサービスを選択するには、トレードオフが必要です。
モノリスアプリケーションをマイクロサービスに移行するという選択をする前に、
開発者はマイクロサービスのアーキテクチャが自分たちに合っていない可能性があることを理解しておく必要があります。

Netflixを構築していますか？

スケーラビリティは、マイクロサービスを利用する主な利点の1つです。
各サービスは他のサービスから独立してスケールできるので、さらに柔軟性が高くなります。
多くの場合、モノリスアプリケーションは限られた数のオフィスユーザーのために作成されます。
この場合、マイクロサービスを使用することはオーバーヘッドになる可能性があります。
スケーリングが必要な場合でも、アプリケーションサーバーに別のクラスタノードを追加することで解決できます。

あなたはポリグロットですか？

マイクロサービスのもう一つの利点は、サービスごとに異なるプログラミング言語を使用できることです。
いいですよね？自分のビジネスロジックに合った言語を最も効果的に使うことができます。しかし、いくつかの欠点もあります。

1つは金銭的な配慮です。
複数の言語を使用するには、これらの言語に精通した開発者を雇う必要があります。
高い確率で、これらの開発者は、専門知識を持っている言語以外の言語で書かれたサービスをサポートすることができません。
異なる言語でのプログラミングが可能な開発者は、コストが高くなります。そのため、より高い予算が必要となります。

ポリグロットに反対するもう一つの理由は、レガシーコードです。
Java EEで書かれたモノリスをJavaで書かれたマイクロサービスに壊す方が簡単です。
彼らはプログラミング言語を共有しているので、深刻な変更をすることなくコードの一部を新しいサービスにコピーすることができます。
これらのコードを異なるプログラミング言語で書き換えるのは別の話です。

共有コードもデータベースも不要

通常、モノリスアプリケーションは単一のデータベースで動作するように設計されており、
データ転送オブジェクトやエンティティなどのコードをすべてのコンポーネント間で共有しています。
しかし、マイクロサービスアーキテクチャでは、すべてのサービスを独立させておくことが最善の方法です。
それらはいかなるコードもデータベースと共有すべきではありません。
各マイクロサービスは、他のサービスから独立した独自のデータストレージを使用するべきです。
だから、慎重にデータベース構造とモノリスのデータベースアプリケーション層を再設計して、
データの一貫性を壊すことなく複数のストレージをサポートできるようにする必要があります。
私の意見では、ここに最も力を入れるべきだと思います。

トランザクションが問題になる可能性がある

アプリケーションが銀行や他の金融分野にある場合、トランザクションは要件の1つになります。
Java EEはトランザクションをしっかりとサポートしており、モノリスアプリケーションでは問題ありません。
マイクロサービスでは、状況は異なります。
マイクロサービス間の分散トランザクションをサポートすることは、より複雑な作業であり、より多くの労力を必要とします。
@Transactionalアノテーションを追加して、それ以外のすべてをアプリケーションサーバが裏で行うような簡単なことではありません。
不可能ではありませんが、より複雑です。Sagaパターンやロングランアクション(LRA)を使用します。

マイクロサービス依存地獄の準備はできていますか？

マイクロサービスアーキテクチャを用いて設計されたアプリケーションでは、モノリスよりも管理しなければならないサービスの数が多くなります。
依存関係の数が多いと、特に依存関係の管理も難しくなります。

テストが問題になる可能性がある

個々のサービスをテストするのは問題ではありません。
実際、マイクロサービスアプリケーションの各サービスは、個々のモノリスコンポーネントよりも、より良いテストを行うことができます。
一方で、アプリケーションロジックが異なるチームが所有する複数のサービスの間で分割されるようになったため、統合テストはより困難になります。

もう一つの問題は、未使用のコードです。
モノリスでは、それを検出するのは簡単です。
マイクロサービスでは、どの API メソッドが使用されていて、どの API メソッドが陳腐化しているのかを判断するのは困難です。
チームはそれを検出するためにいくつかのトレース方法を考えるべきです。

決断したとき

これで、あなたは潜在的な問題を認識し、これらの問題を解決または回避する方法を知ったので、あなたはモノリスを壊す準備ができました。おめでとうございます。
いくつかのアドバイスをしたいと思います。

可能であれば、一つのプログラミング言語にこだわる

モノリスが Java で書かれていると仮定して、マイクロサービスにも Java を使うことをお勧めします。
前述したように、同じ言語を維持することで、コードの一部を簡単に再利用することができ、
モノリスで働いていたのと同じチームが新しいアプリケーションで働くことができます。
他の言語の開発者を雇う必要はありません。しかし、あるコードが他の言語に完璧にフィットするのであれば、それは意味がありません。

パターンの使用

マイクロサービスへの移行を支援するために、StranglerパターンやAnti-Corruption Layerパターンなど、いくつかのデザインパターンが開発されました。
それらがどのように機能するのかを説明するのは、次回のブログ記事のトピックです。

マイクロサービス向けに設計されたフレームワークを使用

最近のJavaフレームワークの中には、Helidon、Quarkus、Micronautなどのマイクロサービスを開発するために設計されたものもあります。
これらのフレームワークはすべて、小さなフットプリント、小さなメモリ消費量、高速な起動時間でアプリケーションを生成することができます。
これらのパラメータは、クラウドネイティブサービスにとって最も重要なものです。
これら3つのフレームワークはすべて、アプリケーションからGraalVMネイティブイメージを構築することも可能です。
ネイティブイメージは、ネイティブに実行できるOS依存のバイナリです。
つまり、アプリケーションはほぼ瞬時に起動し、メモリ消費も最小限に抑えられます。

GraalVMのトレードオフ

Java Hotspot仮想マシン（VM）を使うと、実行環境を知っているので、その環境に基づいてコードを最適化することができます。
即効性はありませんが、最終的にはGraalVMを使ってコンパイルした実行コードよりもさらに高速になる可能性があります。

そのため、モノリスがSpringを使って書かれている場合は、マイクロサービスにSpring Bootを使いましょう。
Java EEアプリケーションであれば、最高の互換性のオプションを提供してくれるので、Helidon MPを使いましょう。
また、クラウドネイティブサービスを構築するために設計されたオープンソース仕様の最新のコレクションであるMicroProfileをサポートしています。
MicroProfileはEclipse Foundationでホストされており、IBM、Red Hat、Oracleなど多くのベンダーがサポートしています。

最後の注意事項

アプリケーションがマイクロサービスを必要としないのであれば、マイクロサービスのルートに行く必要はありません。
しかし、既存のJavaアプリケーションをマイクロサービスに変換することに意味があるのであれば、その変換を迅速かつ容易にするためのツールを探してください。

オラクルがマイクロサービス開発を簡素化する方法の詳細については、
当社のブログ「How a Converged Database Simplifies the Persistence Layer for Microservices」をお読みください。

Dmitry Kornilov氏はオラクルのソフトウェア開発担当ディレクターで、
クラウド・ソフトウェアの設計および開発、プロジェクトHelidon、マイクロサービス、
オープンソース・ソフトウェア、アプリケーション・サーバー、Java EE/Jakarta EE、JSON関連の仕様を専門としています。