[Microservices]Hibernateを使ったHelidonマイクロサービスの作成とデプロイ　パート1／ Building And Deploying A Helidon Microservice With Hibernate Part 1

新しい考え方を導入するとき、後では解決しがたい問題を招き入れてしまうこともあるため、これらを自問してみることは重要です。

コードに進む前にマイクロサービスでのデータ管理のいくつかのパターンを定義するところから始めましょう。マイクロサービスの場合の最もわかりやすいパターンは、共有データベースパターンとサービス毎のデータベース（あるいはスキーマ）パターンです。ここから紹介していきます。

モノリスでは、通常我々はデータを単一のリレーショナルデータベースに保持します。これによりJOINを使ったクエリを書いたり、ACIDトランザクションを使ってデータ一貫性を保証したりと、永続化とクエリにまつわる部分を簡単に済ますことができます。共有データベースのマイクロサービスパターンでは、複数のサービスが単一のデータベースを共有しており、それぞれがテーブルをJOINしながらクエリをしてデータを取得したり、トランザクションを使用して一貫性を保証できる信頼性のあるやり方でデータを更新したりします。このことにより、このパターンは新人開発者たちにも理解しやすいものになっていますが、一方でAPIが複雑になってくると課題も生まれてきます。カラムを追加したりデフォルト値を変更したりすると同じテーブルにアクセスしているサービスを壊してしまうかもしれないため、スキーマの変更は他のサービスの開発者たちと調整したうえで行わなければなりません。また、長時間に渡るトランザクションが共有テーブル上でロックを保持することにより、他のサービスをブロックしてしまうかもしれません。更に、このパターンでは全てのサービスがデータをトラディショナルなリレーショナルデータベースに保持する前提となっており、NoSQLやGraph DBでドキュメントを利用する可能性を排除してしまっています（ただし少し後に紹介するようなワークアラウンドはあります）。

サービス毎のデータベース（あるいはスキーマ）パターンは共有データベースパターンのいくつかの欠点に対処しています。サービスがそれぞれ自身のデータベースを持っており、これは要はデータベースがサービスの実装の一部であるということを意味しています。このやり方ではスキーマの変更は他のサービスには影響しないということになります。なお、サービスごとにデータベース・サーバーを持つ必要は必ずしもありません。多くの場合サービスごとに独立したテーブル（他のサービスからはアクセスを制限されたユーザー、パーミッションをそれぞれのテーブルに付与しておきます）というかたち、あるいはサービスごとにユニークなスキーマを割り振るというかたちで実現されます。サービス毎のデータベースを利用するということはすなわち、サービスそれぞれの必要に応じて最も適した種類のデータベースを使えるようになるということを意味します。もちろん、このパターンにはデメリットもあります。トランザクションの管理が難しくなります。参照整合性の保証は簡単ではなくなるでしょう。データをJOINしてのクエリは不可能ではないにしても難しいでしょう。

ここまでこのシリーズではマイクロサービスとは何か、あなたはなぜそれを使うべきなのかもしれないのかについて長々と語ってきましたが、理論を理解するのに最良な方法はいつもコードを見ることですよね。ということでようやくコードを見ていくことにします。このシリーズでは、何回かに分けてソーシャルメディア形式のアプリケーションのためのAPIを作っていきます。この中ではクラウドの様々な機能を使うだけでなく、いくつかの異なったマイクロサービスパターンを活用でき、そこに付き物となる興味深い問題への対処方法を紹介していくことになります。

このサービスではHelidon MPをHibernateとともに利用し、ユーザーをOracle ATPインスタンスの user テーブルに永続化します。始めるために、Helidon Mavenアーキタイプを使いサービスのためにいくつかのファイルと構成の土台を作っていきましょう。以下がコマンドです（お好みに応じてパスを修正してもいいし、そのまま使ってもいいです）：

生成されたコードを見たり直したりする前に、このマイクロサービス用のスキーマユーザーを作成しておきましょう。可動しているATPインスタンスにadminユーザーとして接続し、次のクエリを実行する必要があります。このポストシリーズで紹介されているSQL Developer Webを使うと簡単にできます。準備ができたら、以下を実行してください（パスワードを強いものに修正するのをお忘れなく）。

SQL Developer Webを使っているなら、adminユーザーで以下のコマンドを使い各スキーマが有効化されていることを確かめておく必要があります：

上記のコマンドでは、プレースホルダの値は以下のように置き換えてください：

ユーザーアクセスを有効化したら、ADMINユーザーから当該ユーザーにSQL Developer WebにアクセスするためのURLを提供しましょう。このURLはADMINユーザーがSQL Developer WebにアクセスするためのURLと同じものですが、ただし admin/ の部分はschema-alias/で置き換えてください。

これ以降、私達は usersvc ユーザーを使っていくので、一旦SQL Developer Web（その他のツールをお使いならそのツール）からログアウトして先程作成した新しいユーザー名とパスワード、および上記で説明した適切なURLでログインし直しましょう。 usersvc でログインしたら、以下を実行してマイクロサービス用のテーブルを作成します：

次に、依存モジュールを取得しておく必要があります。プロジェクトルートに /build-resource というフォルダを作成し、更にその配下に /libsというサブディレクトリを作成してください。ATPインスタンスと接続するために必要となるOJDBCドライバーをプロジェクトで使えるように、以下のJARファイルを取得する必要があります：

Download the JARs from Oracle and place them in /build-resource/libs.  We also need to publish these to our local Maven repo so that when we run the application locally they'll be properly resolved. The following commands should help you out with that:
OracleからJARをダウンロードし、 /build-resource/libsに置きましょう。また、ローカルのMavenリポジトリにこれらをパブリッシュしておき、ローカルでアプリケーションを稼働させたときにこれらが適切にリゾルブされるようにしておきましょう。以下のコマンドでできます：

次にpom.xmlファイルを修正し、JPAに必要な依存ライブラリであるHibernate、JacksonおよびOJDBCのJARを含むようにしておきます。次のエントリをdependenciesセクションに追加してください：

そしてHibernateの永続化に係る設定を追加する必要があります。
/src/main/resources/META-INFに persistence.xml という名前で以下のようにファイルを作成してください：

そのディレクトリに行ってから、 microprofile-config.properties を以下のように修正します：

これで事前に必要な設定は全て終えたので、アプリケーションコードに進めます。生成された GreetApplication.java を探してください。それを修正してもいいですし、削除して新しく作るのでもいいんですが、結局の所以下のコードを含む UserApplication.java が必要になります：

Use the same process (modify or replace) for GreetingProvider to end up with a UserProvider that looks like so:
同様に GreetingProvider についても修正または削除して再作成して以下のUserProvider を作ります：

ここで UserProvider クラスはアプリケーション稼働時には生成された設定値を格納します。ここまででマイクロサービスの実ロジックを書き始める準備ができました。このシリーズの次のポストでは、コードを深く掘り下げていき、サービスをOracle Cloud上にデプロイ、稼働させてみます。