簡単なデプロイメント・グループの作成 はじめに

入門ブログシリーズの続きとして、 このブログでは2インスタンスからなるシンプルなHazelcastデプロイメント・グループをどのようにセットアップするのかを実演します。デプロイメント・グループはクラスタを代替するためにPayara 5で導入されました。デプロイメント・グループはサーバーを管理し、単一のデプロイ対象について、インスタンスが同一構成を共有するクラスタリングを可能とする、より柔軟な方法を提供します。デプロイメント・グループの詳細についてはこちらをご覧ください。

開発環境で 「概念実証」を行うには単一サーバーで十分であるのに対して、商用環境ではサービスの信頼性を担保し将来の拡張を可能にするため、アプリケーションを複数の冗長なホストに渡って高い信頼性でホスティングすることが常に要求されます。Payara Serverでは、簡単にインスタンスを作成しHazelcastを用いたデプロイメント・グループへ追加することが可能で、分散したアプリケーションの構成がとても行いやすくなっています。

必要条件

このブログを進めるには、以下のものが必要です。

• Payara Serverをインストール済みのUbuntuホスト1台
• JDK 8をインストール済みのUbuntuホスト1台 (Payara Serverは後程インストールします)
• Payara Examplesリポジトリのrest-jcacheサンプル・アプリケーション

最初のステップとしてSSHノードを構成します。SSHノードの詳細と、なぜここでSSHノードを使用するのかについては、概要のブログをご覧ください。

Payara ServerのSSHノードの構成とインストール

前提条件が整ったら、クラスタを作成する最初のステップは、2番目のUbuntuホスト ("computer2") にPayara Server自身をインストールして元のUbuntuホスト ("computer") と通信できるように構成することです。

双方のホストではGNU/Linux OSが稼働しているため、2番目のホストのフルコントロールを要求して、computer2上にSSHノードを作成することになります。ノード作成の一環として、とても便利なPayara Serverの機能のアドバンテージを受けることもできます。Payara Serverは自身のZIPアーカイブを作成して、それをリモート・ノード上にインストールすることができるのです (そのため、両方のインストレーションは同じものであることが保証され、時間も節約することができます)。

以上から、computer2を構成する大まかなは以下のようになります。

• SSH通信を受け入れるように構成する
• DASで新しいSSHノードを作成する
• Payara ServerをSSHノードにインストールする

SSHサーバーのインストール

SSH通信を受け取るためには、computer2 はSSHサーバーがリスンしていなければなりません。今回使用するUbuntuの仮想マシンにはSSHサーバーがデフォルトではインストールされていないので、UbuntuのリポジトリからOpenSSHサーバーをインストールします。

sudo apt install openssh-server

Ubuntu 16.04以前のバージョンでは "apt-get install" を使用します。

OpenSSHサーバーはインストール後に自動で起動します。"netstat -lnt | grep 22" を実行するとポート22 (既定のSSHポート) が開かれ、通信をリスンしていることが分かります。

Payara Server上で新しいSSHノードを作成する

SSHノードを2番目のUbuntuホストにセットアップしたので、新しいノードを問題なく作成することができます。“Nodes” ウィンドウで “New” ボタンをクリックしてください。 

ここでは以下に示す新しいノードのプロパティを入力する必要があります。

• Name: ノードにユニークな名前を付けます。後で識別しやすいような名前にします。ここではcomputer2としました。
• Type: ドロップダウン・メニューからSSHを選択し、リモート・アクセスをセットアップできるようにします。
• Node Host: computer2のIPアドレスを入力します。
• Install Payara Server: これを有効化すると、Payara Serverをcomputer2へ自動的にインストールします。Payara Serverはローカル・インストレーションのZIPアーカイブを作成し、それをリモート・ノードへコピーします。インストレーションの場所は “Installation Directory” で変更することができます (既定では現在のホストと同一のパスです)。
• SSH Port: SSHポートを設定します。既定値は22です。
• SSH User Name: computer2上におけるユーザー名を設定します。
• SSH User Authentication: この例では password認証を使用しますが、SSHではキーファイルまたは他の場所に保存したパスワードのエイリアスを指定することもできます。
• SSH User Password: computer2で使用するパスワードを設定します。

各項目を埋めたら OK ボタンを押下してください。"A long-running process has been detected" というポップアップが表示されても心配はいりません。Payara Serverインストレーションのコピーを作成してそれを2番目のUbuntuホストにインストールするしばらくの間、一時停止しているだけです。

Payara Serverインストレーションが問題なく転送されると、ノードが作成され、 “Nodes” ページに戻ります。

新しいスタンドアロン・インスタンスの作成

リモート・ノードをセットアップしたことで基礎の部分は出来上がりました。次は各ノードに1つずつある2つのインスタンスを、アプリケーションをデプロイできるように構成します。2つのインスタンスが同一の構成を共有し、それらをデプロイメント・グループに追加することで、Payara 4のクラスタと似たものにすることができます。まず、以前のクラスタのように一箇所の変更が両方のインスタンスに反映されるようにするため、両方のインスタンスが参照する新しい構成を作成する必要があります。

新しい構成の作成

Hazelcastクラスタ用の新しい構成を作成するには、左側のツリー上の “Configurations” 親ノードをクリックして構成ページを開き、 “New…” ボタンをクリックしてデプロイメント・グループ用の新しい構成を作成します。

すべての新規Payara Serverインストレーションには、2つの構成が存在します。

• server-config は管理サーバー (“server” という名前) が使用する構成です。これを変更するとDASに影響を及ぼします。
• default-config はテンプレートとして使うために提供されており、他の構成はここから派生しています。これはインスタンスから参照することはできませんが、新しい構成としてコピーを作成することができます。

何か変更を加えることでDASの構成に悪影響を及ぼしたくないので、ここではdefault-configをコピーしてdg-configという名前にします。

デフォルトの設定で、新しい構成を保存します。

ローカルのスタンドアロン・インスタンスの作成

次に、新しい構成を使用するインスタンスを作成する必要があります。Localhost上にインスタンスを作成するには、Instancesページの “New” をクリックします。

• Instance Name: DASのローカルにあることが明確になるよう "local-instance" としました。
• Node: localhost-production ノードはDASのローカルにあるデフォルトのノードです。
• Configuration: 先ほど作成した dg-config をここで選択します。また、構成を参照していることを確認する必要があります。

“OK” を押下して最初のインスタンスの作成を完了します。

リモート・インスタンスの作成

以下のようにリモート・ノードを対象として上記と同様の手順を繰り返すことで、ローカル・ノード上にインスタンスを容易に作成することができます。

“OK” ボタンを押下して2番目かつ最後のインスタンスを作成し、Instancesページに戻ります。すると “Stopped” と示された2つのインスタンスがあるはずです。左側のチェックボックスで両方のインスタンスを選択して起動します。

デプロイメント・グループの作成

では、サーバー・インスタンスを互いに関連付けるため、デプロイメント・グループを作成しましょう。これにより、アプリケーションを各インスタンスに対して同時にデプロイすることができるようになります。

デプロイメント・グループを作成するには、 左側のツリー上にある “Deployment Groups” 親ノードをクリックして構成ページを開き、新規デプロイメント・グループを作成するため “New…” ボタンをクリックします。

作成ページ上で、デプロイメント・グループ名の構成を確認し、作成したインスタンスをデプロイメント・グループに追加してください。

“OK” をクリックするとデプロイメント・グループが作成されます。

デプロイメント・グループの作成後は、デプロイメント・グループのページからすべてのインスタンスの起動および停止が可能になります。

キャッシュ・レプリケーションのデモ

Payara Exampleアプリケーションのビルド

GitHub上のPayara Examplesリポジトリには、Payara Serverで利用可能な各機能のデモのプロジェクトが満載です。ここではHazelcastがシームレスにデータを分散する rest-jcache を使用することにします。ただし、まずプロジェクトをダウンロードしてビルドする必要があります。

1. リポジトリをダウンロードしてビルドするにはGitおよびMavenをインストールしておく必要があります。どちらもUbuntuのリポジトリに存在するため、以下のようにインストール可能です。
   
   sudo apt install git maven
2. 1番目のUbuntuホストに以下のコマンドでPayara Examplesリポジトリをクローンします。
   
   git clone https://github.com/Payara/Payara-Examples
   
   
3. サンプル rest-jcacheをビルドしたいので、ダウンロードしたリポジトリで、"payara-examples/rest-examples/rest-jcache" ディレクトリに移動します。

その後、"mvn clean install" コマンドを実行してMavenによるプロジェクトをビルドすることができます。

Mavenは自動的に依存ライブラリをダウンロードしてプロジェクトをビルドします。コンパイルされたWebアプリケーションはWARファイルとしてtargetディレクトリ内に保存されます。

これでテスト・アプリケーションがビルドできました。それではこれをデプロイしてみましょう。

Payara Exampleアプリケーションのデプロイ

クラスタの分散キャッシュ機能をテストするため、アプリケーションをすべてのインスタンスにデプロイして、それから1つのインスタンスのローカル・キャッシュの値を編集することで同時にクラスタ全体のデータが変更されることのデモを行うため、いくつかのデータを追加します。

最初に、ページのツリーから "Applications" ページを選択し、 "Deploy..." をクリックします。

次に、 "Browse..." ボタンでビルドしたアプリケーションをアップロードします。どちらのインスタンスも “Selected Targets” に存在しないことを確認し、代わりに新しく作成したデプロイメント・グループを追加します。

サンプル・アプリケーションを用いたデプロイメント・グループのテスト

rest-jcache アプリケーションはJAX-RS RESTメソッド上でJCache APIアノテーションを使用し、"cache" エンドポイントをリスンします。GET、PUTおよびDELETEリクエストに対応しています。

• GET
  @GET アノテーションが付加された getJSON() メソッドは、 “cache” リソースへのGETリクエスト時に呼び出されます。@CacheResult アノテーションは名前付きキャッシュの値を検索して、キャッシュが存在する場合にはキャッシュされた値を読みだしメソッド本体を実行しないようにするJCacheアノテーションです。キャッシュが存在しない場合には、メソッド本体が実行されて “helloworld” という文字列を返します。現実のアプリケーションでは、これはデータベースの検索に該当します。
• PUT
  @PUT アノテーションが付加されたputJSON() メソッドは、HTTP PUTリクエストに対応して呼び出されます。@CachePut アノテーションはメソッド・シグネチャの @CacheKey および @CacheValue アノテーションとともに使用され、名前付きキャッシュへ与えられた値を設定します。GETメソッドで同じキャッシュ名が使用されるため、キーをPUTで更新するとGETにも反映されます。
• DELETE
  同様に、HTTP DELETEリクエストが来た時、与えられたキーに該当する値を削除するため、JCacheアノテーション (@CacheRemove) とともにJAX-RS アノテーション (@DELETE) を使用します。

まず、2番目のUbuntuホストでデフォルト値の “Helloworld” が返され、値を編集するとそれが1番目のUbuntuホストにも保存され、Hazelcastがクラスタのすべてのメンバーにキャッシュ・エントリを自動的に作成する様子を見てみましょう。

1. キー "payara" のデフォルト値を読み込む
   データはキーと値のペアとしてJSON形式でアプリケーションに保存されます。キャッシュが存在しないキーを読みだそうとするとデフォルト値 “helloworld” が取得されます。以下のリクエストによってローカル・インスタンスから値を取得してみましょう。
   
   curl "http://<Local_IP>:<Local_Instance_Port>/rest-jcache-1.0-SNAPSHOT/webresources/cache?key=payara"

ご覧の通り、現時点では "payara" に値が保存されていないため、ローカル・インスタンスからはデフォルト値が返ってきました。

2. リモート・インスタンスのキー "payara" に新しい値を追加する

以下のコマンドで "payara" キーに値を追加することができます。

curl -H "Content-Type: application/json" -X PUT -d "badassfish" "http://<Remote_IP>:<Remote_Instance_Port>/rest-jcache-1.0-SNAPSHOT/webresources/cache?key=payara"

Hazelcastキャッシュのおかげで、この更新されたキーと値のペアはデプロイメント・グループをまたがって即座に分散されます。

3. 新しい値をローカル・インスタンスから読み出す

最初のコマンドを再実行すると新しい値をすぐに確認することができます。

curl "http://<Local_IP>:<Local_Instance_Port>/rest-jcache-1.0-SNAPSHOT/webresources/cache?key=payara"

また、HazelcastによるPayara Serverのクラスタが動作していることもわかりました。これでデプロイメント・グループが適切に構成され、アプリケーションのデプロイと、今後のブログでご紹介する予定のデプロイメント・グループの負荷分散構成や適切なセッション・ハンドリングといった新しいスケーラビリティのほとんどを始められるようになります。