オートスケール環境で運用する

オートスケール環境とは

AWS や Azure などのパブリッククラウド環境が提供する「オートスケール」サービスを利用することができます。ビルドした Wagby アプリケーション (wagbyapp) が1つ以上のインスタンスで実行されるため負荷分散、耐障害性の向上につなげることができます。

特徴は次のとおりです。

ロードバランサ

ロードバランサが必要です。なおロードバランサでは Sticky Session を有効にしません。利用者はどのwagbyappにつながってもよい状態となっています。

セッション情報の共有

Wagby ではログオンする利用者ごとに「セッション」を作成します。セッションには利用者固有の情報が格納されており、ログオフするまでこれらは保持されています。

オートスケール環境では、このセッションに格納されている情報はキーバリューストアデータベースである Redis に格納されています。そのためどのインスタンスを使ってもセッション情報は維持されています。

キャッシュの整合性

オートスケール環境では、個々のインスタンスに割り当てられるIPアドレスを事前に知ることができません。そのためインスタンスごとに保持しているキャッシュ情報の整合性を保つためのメッセージ送受信はメッセージキューを使います。

設定方法

パブリッククラウドの設定

あらかじめ次のサービスを設定してください。（設定方法の詳細は割愛します。詳細はWagby代理店へお問い合わせください。）

• インスタンスのオートスケールを有効にする。AWSの場合はEC2インスタンスのオートスケール設定を使う。上限数なども指定できる。
• メッセージキューの設定。AWSの場合は Amazon MQ を使う。
• Redisの設定。[詳細...]

Designerの設定

オートスケールを有効にする

"環境 > サーバ > オートスケール" 欄に用意されている "オートスケールを有効にする" をチェックします。

メッセージキューの設定

"オートスケールを有効にする" を設定したとき、メッセージキューサービスを有効にする必要があります。オートスケールは ActiveMQ を使います。"環境 > アプリケーション > ActiveMQ" 欄を設定します。

HTTPセッションの設定

セッション情報の共有を行うため、HTTPセッションの格納方式に「Spring Session Redis」を指定します。同時に Redis サーバのパラメータを設定します。

動作の確認

オートスケール環境の動作テストシナリオの例を示します。

1. 事前に jgroup のデータを1件登録しておく。
2. インスタンスA にて jgroup の主キー 1000 の詳細データを取得する。(この時 A には主キー 1000 のデータのキャッシュが保持される。)
3. 同様に、インスタンスB でも jgroup の主キー 1000 の詳細データを取得する。(B にも主キー 1000 のデータのキャッシュが保持される。)
4. インスタンスA で jgroup の主キー 1000 のデータの更新処理を行う。このときキャッシュ整合性を担保するため、メッセージキューを介してAとBにキャッシュクリアを指示するメッセージが発行され、いずれのインスタンスもキャッシュがクリアされる。
5. インスタンスB で jgroup の主キー 1000 の詳細データを取得する。インスタンスAの変更結果が反映されていれば、キャッシュクリアの同期が行われていると判断できる。(キャッシュクリアの同期に失敗していた場合は、手順3と同じデータが取得されることになる。)

REST API サーバとして利用する

オートスケール環境に対応した Wagby アプリケーション (wagbyapp) を REST API サーバ専用として用いることで、サーバ部分の処理を Wagby に集約させることができます。

Redisの必要性

• リクエストヘッダに “X-Wagby-Authorization” をセットする使い方に限定する場合は、Redis は不要です。（セッションを維持する必要がないため）
• REST API 呼び出し時に、リクエストヘッダにセッションIDを付与してセッションを維持する場合は、Redis が必要です。

ロックの扱い

オートスケール環境に対応した Wagby アプリケーション (wagbyapp) で、ロック方式は「悲観ロック」「楽観ロック」いずれも利用できます。

Wagbyの標準は悲観ロック方式です。オートスケール環境では、悲観ロックはテーブルで管理する設定が自動的に有効になります。

ジョブスケジュールの制御

オートスケール環境では、Wagbyが提供するジョブスケジュールの起動方式として次のいずれかを指定することができます。

• "1インスタンス" : 指定時刻になったとき、いずれか一つのインスタンスだけでジョブが実行される。（どのインスタンスかを指定することはできない。）
• "全インスタンス" : 指定時刻になったとき、起動されているすべてのインスタンスでジョブが実行される。

前者はエクスポート処理やプログラムによるデータ操作処理など、複数のインスタンスで実行する必要がない場合に有効です。後者はメンテナンスモード切り替えなど、複数のインスタンスで起動されることが必要な場合に有効です。

設定方法

ジョブスケジュールで実行対象式を指定します。通常は "1インスタンス" を指定します。

システムログ閲覧

オートスケール環境ではログ出力は wagbyapp/logs フォルダ内の system.log 等のログファイルに出力は行わず、標準出力に出力するように変更します。これは下記の理由によるものです。

• 複数サーバで実行された際に各サーバにログファイルが保存されている場合、閲覧するには各サーバにアクセスする手間が発生します。
• 各クラウドサービスにて、標準出力されたログを一括して管理する方法があります。Dockerではfluentd(ログ管理)、AWSではAmazon CloudWatch Logs、Azureでは「Azure Container Instances でコンテナーのログとイベントを取得する」にて、ログを取得できます。

ログを標準出力するようにするため、ビルド前にカスタマイズファイルを追加します。この修正方法についてはDocker向けのカスタマイズファイルをご覧ください。（このページの後半部で、修正ファイルをダウンロードできます。）

仕様・制約

ライセンスの制約

オートスケールはUnlimited/Corporateライセンスのみで動作します。Projectライセンスではご利用いただけません。

技術情報

オートスケールに関連するその他の機能8.3.1

• パスワードリマインダ機能にも対応しています。パスワードリマインダで発行される一時URLは、どのインスタンスに接続しても有効です。
• ログオンユーザ管理機能の拡張。オートスケール運用時でも、ログオンユーザ一覧表示やセッションの強制切断機能を利用できます。
• メンテナンスモード機能の拡張。一つのノードをメンテナンスモードとしたとき、他のすべてのノードもメンテナンスモードに切り替わります。
• 全文検索インデックスを保存できるフォルダを変更できます。Docker利用時に設定しやすくすることを意図しています。

ファイル操作に関する注意点

オートスケール環境で、あるインスタンスのファイルを操作しても、他のインスタンスへ自動反映されるわけではありません。インスタンスはそれぞれ独立しており、また停止される場合もあります。停止されたインスタンス内のフォルダに保存したファイルは通常、インスタンスの停止時に消失します。これらのことから、ファイルの操作は次の点を配慮してください。

• 共有フォルダを用意し、すべてのインスタンスが同じフォルダにアクセスできるようにする。AWS であれば Amazon EFS になります。Azure であれば Storage になります。
• 共有フォルダではなく、データベースを使う。Wagbyでモデル定義を行えば、そのモデル内のデータはすべてのインスタンスで共有できます。

よくある質問と回答

オンプレミス環境でもオートスケールを試すことはできますか

可能ですが非推奨です。オートスケールに対応したパブリッククラウド環境でお試しください。

Wagbyのオートスケールでは Redis や ActiveMQ といったサービスは必須ですか

Redis は必須ではありません。[詳細...]

MQ はキャッシュ以外にもジョブやアップロード更新などで利用しており、今後も利用するケースを増やす計画があります。そのため、オートスケール環境では MQ は必須であるとお考えください。