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

最終更新日: 2021年12月14日
R8 | R9

オートスケール環境とは

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

図1 Wagbyのオートスケール環境

特徴は次のとおりです。

ロードバランサ

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

利用者 X が、ログオン時にはインスタンス A につながり認証されたとします。Sticky Session がないため、その後のアプリケーション画面操作でインスタンス B につながるかも知れません。このような場合でも適切に動作します。

セッション情報の共有

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

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

REST API 利用限定であれば Redis が不要なケースもあります。[詳細...]

キャッシュの整合性

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

クラスタリングとの違い

クラスタリング方式では、起動しておくWebサーバ数は固定であり、それぞれのWebサーバは双方で通信できるよう、通信相手のURLを事前に知っておく必要があります。オートスケールは台数が可変です。

設定方法

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

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

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

Designerの設定

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

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

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

メッセージキューの設定

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

図3 ActiveMQの設定
設定欄説明
送信先 "ブローカー接続" を指定します。(インメモリでは動作しません) "ブローカー接続"
ブローカーURL 接続先のメッセージキューサービスのURLを設定します。例えば AWS であれば、Amazon MQ を有効にしたとき、そのサービスにアクセスするための URL がわかります。
ユーザ名 メッセージキューに登録したユーザ名を指定します。
パスワード 上記ユーザのパスワードを指定します。
"ジョブを受信するキューの名前" は空白としてください。オートスケールのために利用するキューは自動設定されます。

HTTPセッションの設定

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

図4 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の必要性

ロックの扱い

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

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

Wagbyが提供するシステムモデル(juserなど)は悲観ロック方式です。そのためオートスケール環境では開発者が用意したモデルが楽観ロックでも、システムモデルは悲観ロックが適用されます。この悲観ロックはすべてテーブルで管理されるものとなります。

注意

悲観ロックテーブルは別途、データベースに用意する必要があります。[詳細...]

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

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

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

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

設定方法

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

図5 ジョブスケジュールで実行対象を指定する

システムログ閲覧

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

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

注意

注意:この変更によって "管理処理 > システムログ閲覧"、"管理処理 > 統計情報"、ログを監視するジョブ(AlterMailFromLog)機能は利用できなくなります。(system.log ファイルが生成されないためです。)

仕様・制約

ライセンスの制約

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

技術情報

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

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

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

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

よくある質問と回答

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

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

オンプレミスでもリソース監視と仮想環境の自動構築技術を組み合わせた環境を自前で構築することで可能です。この構築技術はインフラストラクチャに精通したエンジニアにご相談ください。Wagbyのサポート範囲外となります。

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

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

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