非同期処理の概要
最終更新日: 2020年3月14日
R8 | R9
Wagbyには「ジョブ」という単位で特定の業務を実行する枠組みが提供されています。標準では時間指定によるジョブの実行が可能です。これはシステム管理者が設定する機能です。
ここで説明する非同期処理は、一般ユーザが実行したいジョブを「キュー」に登録することを実現します。キューに蓄積されたジョブは先頭から順に実行されます。このキューは「メッセージングミドルウェア」という別のソフトウェアが提供します。
Wagbyのダウンロード処理やアップロード更新処理には時間がかかることがあります。これを非同期処理で行うことができます。利用者の操作は次のようになります。
メッセージングミドルウェアとは、メッセージを管理するためのソフトウェアです。次のような特徴があります。
メッセージングミドルウェアを Wagby へ適用することにより、同時実行を制限することでリソースの急激な消費を防ぐというメリットがあります。
現在のWagbyのダウンロード、アップロード更新は利用者からの要求があると即時実行されます。このため、複数要求があると、すべてを同時に実行するため、処理速度の低下やメモリ消費量の増大につながる懸念がありました。
ジョブの実行をキューから取得することにより、ジョブを順に1つずつ実行することができるようになるため、サーバの急激な負荷上昇を抑えることができると期待できます。
メッセージングミドルウェアにはさまざまな製品があります。IBMのWebSphere MQ、オラクルのOracle Advanced Queue、マイクロソフトのMSMQといった商用製品に加え、JBoss Messaging、Apache ActiveMQ、Rabbit MQ といったオープンソースの製品もあります。
Wagby は Apache ActiveMQ, AmazonMQ, Rabbit MQ に対応しています。両者の特徴は次の通りです。
Wagbyが提供する非同期処理は、上のいずれの製品を利用しても実現できます。
Apache ActiveMQ Artemis を選択したとき、インメモリでの動作を指定することができます。この場合、Wagbyアプリケーション(wagbyapp)が動作する JVM にインメモリのメッセージキューが用意されます。別途 Apache ActiveMQ Artemis をインストールすることなく、このインメモリのメッセージキューを使ってジョブを登録することができるようになります。
この方法は手軽に非同期処理を実現できるというメリットがありますが、専用サーバをもたないためキューの管理にかかわる（専用サーバが提供する）堅牢性、監視性などの運用支援がありません。Wagbyアプリケーションを再起動した場合、キューの内部も消えるため、未処理のジョブは失われます。（専用サーバがあれば未処理のジョブはサーバが管理するため、Wagbyアプリケーション再起動時にジョブを復旧することができます。）このようなデメリットもあるため、本番運用では専用サーバの利用を推奨します。インメモリ動作は開発環境ならびにテスト環境での動作確認用と位置づけるのがよいでしょう。
Wagby では非同期ジョブ状態を管理するためのテーブル jfcjobstatus を有しています。このテーブルの登録と更新は Wagby 内部で行いますので、開発者は直接、このテーブルを更新しないようにしてください。
ジョブとキューの考え方
メッセージングミドルウェア
Wagby へのメリット
さまざまなメッセージングミドルウェア
Rabbit MQ8.1.0
Apache ActiveMQ Artemis8.2.3
Amazon MQ8.2.3
サーバをインストールしない運用（インメモリでの動作）
ジョブ状態の管理