こんにちは。
今回のデモでは、Payara 5 で新しく導入した、ドメイン・データ・グリッドについてご紹介します。
このデモは大きく２つのパートに分かれます。前半はドメイン・データ・グリッドの構築方法を中心に見てゆきます。後半では実際に構築したドメイン・データ・グリッドとロードバランサーの組み合わせ例をご紹介します。
こちらがデモ環境の構成です。このデモでは、Microsoft Azure 上に 6 つの Linux VM インスタンスを用意して行います。
まず、フロントエンドに 2 つの VM を作成し、それぞれ Payara Server と Payara Micro を配置します。その後ろに、内部ロードバランサーを介して、バックエンドに 4 つの VM を作成し、それぞれ Payara Micro を配置します。ユーザーからのリクエストをフロントエンドで処理して、その結果をバックエンドのマイクロサービスに渡す、そのようなシナリオをイメージしていただけると分かりやすいかと思います。
これだけのデモ環境を最初から作成するのは時間がかかりますので、今回は、デモ環境の構築が完了し、すべての VM インスタンスが起動したところからスタートしたいと思います。
【デモ１】
それでは、前半のデモを始めましょう。前半では、フロントエンドの Payara Server と Payara Micro を使って、Payara Server のデータ・グリッドに Payara Micro を追加していく様子をご覧いただきたいと思います。
まず、こちらの Payara Server の管理コンソールをご覧ください。
これはドメイン管理サーバーを起動した直後のデータ・グリッドの状態を表しています。この時点では、ドメイン管理サーバーが唯一のメンバーですので、インスタンス一覧は 1 行のみ表示されています。
それでは、Payara Micro を起動して、データ・グリッドに参加させてみましょう。
$ java -jar payara-micro-5.181.jar –clustermode domain:192.168.184.4:4900 –autobindhttp
ここで鍵となるのが Payara Micro 5 で新たに追加された、–clustermode というオプションです。
これまでの Payara Micro はクラスタを構成する際にマルチキャスト通信を使用していました。ところが、クラウド環境ではマルチキャスト通信がサポートされていないか、あるいは、サポートされていたとしても複雑な設定が必要となります。
そこで Payara 5 では、従来のマルチキャスト通信に加えて、新たにユニキャスト通信もサポートし、クラウド環境で扱いやすいようにしました。
Payara Server はデータ・グリッドを導入するにあたって、デフォルトでユニキャスト通信を使用するように設定されています。
一方、Payara Micro では、後方互換性のためデフォルトではマルチキャスト通信を使用します。Payara Micro でユニキャスト通信を使用するには、–clustermode オプションを使用します。このオプションのパラメータには、ユニキャスト通信でデータ・グリッドに参加することを示す domain モード、ドメイン管理サーバーのアドレスおよびポート番号の 3 つを指定します。
なお、今回のデモ環境では、フロントエンドの Payara Server にはパブリック IP とプライベート IP の両方が設定されていますが、データ・グリッドを構成するのはプライベート IP 側になります。ドメイン管理サーバーのポート番号はデフォルトで 4900 となります。
今回は HTTP ポートの重複を防ぐため、–autobindhttp オプションも付けました。
それでは、Payara Micro のインスタンスを実行してみましょう。
どうやらデータ・グリッドに参加できたようです。
正しく参加できているか、管理コンソールで確認してみましょう。インスタンス一覧に「MICRO」というインスタンスが追加され、全部で 2 行になっていることがご覧いただけるかと思います。
それでは、もう 1 つの VM でも Payara Micro を起動して、データ・グリッドに参加させてみましょう。手順は先ほどと全く同じです。
もう一度、管理コンソールを確認してみましょう。インスタンス一覧が 3 行となり、うち 2 つが「MICRO」になっていることがお分かりいただけるかと思います。
いかがでしたでしょうか。これでデータ・グリッドの構築が完了しました。Payara Micro にオプションを 1 つ追加した他は、デフォルトの設定を変更していません。とても簡単です。データ・グリッドの構築は 1 つのホストからでも試すことができますので、ぜひお手持ちの PC でお試しください。
【デモ１ａ】
ところで、管理コンソールはデータ・グリッドに参加している Payara Micro インスタンスに対して、asadmin コマンドを発行することができます。
今回は deploy コマンドを発行してみましょう。
現時点で Payara Micro インスタンスにはアプリケーションがデプロイされていません。今回は、あらかじめ ping.war という、自身の IP アドレスを返すだけの簡単なアプリケーションを用意しました。これをデプロイしてアプリケーションが正しく動作するか確かめてみましょう。
こちらのテキストボックスに発行する asadmin コマンドを入力し、ボタンをクリックします。しばらくお待ちください。これで 2 つの Payara Micro インスタンスに ping アプリケーションがデプロイされました。
それでは、実際にデプロイされたか、確かめてみましょう。これから 2 つのインスタンスにアクセスしますので、その結果をご覧ください。
以上のように、管理コンソールから、データ・グリッドに参加している Payara Micro のインスタンスを操作することができます。
【デモ２】
それでは、後半のデモに移ります。
後半では、フロントエンドからの HTTP アクセスを、内部ロードバランサーを経由して 4 つの Payara Micro インスタンスに分散させる様子をご覧いただきたいと思います。
ただし、内部ロードバランサーに対しては、外部の UI から動作を確認する方法がありません。そこで、フロントエンドの VM のコンソールから直接 curl コマンドでロードバランサーにアクセスし、そのレスポンスが分散先のインスタンスから返ってくることをもって確認としましょう。
先ほどの構成図をもう一度ご覧ください。後半のデモでは、下段の 4 インスタンスとその上にある内部ロードバランサーの動きを見てゆきます。
まず、各インスタンスの IP アドレス末尾が 6 ～ 9、内部ロードバランサーの IP アドレスの末尾が 10 になっていることを押さえておいてください。これをもって分散先のインスタンスを確認しようと思います。
ロードバランサーに対するアクセスは、先ほどのデモで使用したフロントエンドの VM から行うこととします。
それでは、クライアントから curl コマンドで内部ロードバランサーにアクセスして、どのインスタンスから応答があるか確かめてみましょう。
$ curl http://192.168.184.10:8080/ping
それぞれのインスタンスに負荷分散されていることを確かめるため、何度かアクセスを繰り返します。
<< Retry until all instances respond >>
以上で、ロードバランサーへのリクエストがすべてのインスタンスに分散していることがわかりました。
4 minutes
