付録H.12 呼び出し処理に時間が掛かる場合の影響局所化
RESTアプリケーションの呼び出し処理に時間が掛かる場合の影響局所化について説明します。
- 重要
-
この項の内容は,アプリケーション呼び出しサービスに関する性能要件がある場合に参照し,検討してください。特に,平時のRESTアプリケーションのレスポンス時間として著しく長いもの(例えば300秒など)があるシステムで検討する必要がある内容を記載しています。
- 〈この項の構成〉
(1) 問題点
RESTアプリケーションのレスポンス時間として著しく長いものがある場合,次の問題が発生します。
ここでは,レスポンス時間が短いref識別子をA,レスポンス時間が著しく長いref識別子をBとします。
- <問題点>
-
A(レスポンス時間が短い方)の作業が生成されてから完了となるまでの処理時間が,B(レスポンス時間が著しく長い方)のRESTアプリケーションのレスポンス時間の影響を受けて長くなってしまいます。
この結果,Aを含む案件の遷移時間も長くなります。
- <発生条件>
-
次のどちらかに該当する場合に発生します。
(1)アプリケーション呼び出しサービスのEARを1つ稼働する(デフォルトの構成はEARが1つなので該当する)。
(2)AとBをアプリケーション呼び出し制御情報の同じグループにする(デフォルトの設定はref識別子共通設定だけなので該当する)。
問題点について説明します。次の図は発生条件に該当する場合のアプリケーション呼び出しサービスによるA,Bの作業群の処理を示しています。
|
|
- <説明>
-
発生条件に該当する場合,A,Bがともに実行間隔を満たすと,A,Bの作業群は同じEARによって,まとめて処理されます。処理順序は不定なので,図のようにB→Aの順で処理されることがあります。
また,次の図は発生条件に該当する場合の,Aの作業1件の処理の流れを示します。
|
|
- <説明>
-
Aの作業1件が生成されてから完了するまでの処理時間(図中の1.〜3.)には,常にAの作業群の処理時間が含まれますが,通常は早く(実行間隔以内に)終わります。しかし,発生条件に該当すると,Aの作業群だけでなくBの作業群の処理時間も含まれることになります(図H-13に赤で示した処理時間がすべて含まれます)。つまり,Aの作業1件が生成されてから完了するまでの処理時間(図中の1.〜3.)が,BのRESTアプリケーションのレスポンス時間に依存して長くなってしまいます。
(2) 対策
前述の問題点を解消するには次の対策(1)および(2)を両方とも実施します。レスポンス時間が短いref識別子をA,レスポンス時間が著しく長いref識別子をBとします。
(1)アプリケーション呼び出しサービスのEARを複数稼働する。
(2)AとBをアプリケーション呼び出し制御情報の別グループにする(AまたはBを個別のref識別子として登録してもよい)。
次の図は,対策を実施した場合のアプリケーション呼び出しサービスによるA,Bの作業群の処理を示しています。
|
|
- <説明>
-
対策を実施した場合,A,Bがともに実行間隔を満たした場合でも,A,Bの作業群が同じEARによってまとめて処理されることはありません。図のように,EAR01がBの作業群を処理中の場合は,EAR02がAの作業群を処理します。これによって,Aの作業1件が生成されてから完了するまでの処理時間にBの作業群の処理時間が含まれなくなります。
(3) レスポンス時間が著しく長いref識別子同士のグループ化
RESTアプリケーションのレスポンス時間が著しく長いref識別子が複数あり,かつ実行間隔ごとに生成される作業数がWorkManagerの最大スレッド数(デフォルト値:10)と比べて著しく少ない場合は,グループ化することで効率が向上します。
効率向上の詳細を説明します。効率向上を説明するために,次のような場合を仮定します。
- <仮定>
-
-
アプリケーション呼び出しサービスのEARを2つ稼働する。
-
レスポンス時間が著しく長いref識別子をC,Dとする。実行間隔ごとに生成される作業数がCは2件,Dは1件とする(WorkManagerの最大スレッド数のデフォルト値の10と比べて著しく少ない)。
-
次の図はC,Dをグループ化しない場合の,アプリケーション呼び出しサービスによるC,Dの作業1件の処理を示します。
|
|
- <説明>
-
C,Dをグループ化しない場合,図のようにC,Dの作業は別のEARによって処理されます。
次の図はC,Dをグループ化した場合の,アプリケーション呼び出しサービスによるC,Dの作業1件の処理を示します。
|
|
- <説明>
-
C,Dをグループ化した場合,図のようにC,Dの作業はEAR01によってまとめて処理されます。つまり,グループ化しなかった場合に比べてEAR01の遊びのスレッドが減り,またEAR02のスレッドが空きます。EAR02は他の処理に使えるため効率が向上します。
(4) レスポンス時間が著しく長いref識別子がある場合の総EAR数
RESTアプリケーションのレスポンス時間として著しく長いものがある場合,アプリケーション呼び出しサービスの総EAR数は次の式を満たすように決定してください。総EAR数とはすべてのJ2EEサーバのアプリケーション呼び出しサービス(EAR)の合計数です。
総EAR数>=レスポンス時間が著しく長いものを含むアプリケーション呼び出し制御情報の登録数+1
これによって,すべてのアプリケーション呼び出しサービスが,レスポンス時間が著しく長いref識別子だけで占有されることを防ぐことができます。
式中の「レスポンス時間が著しく長いものを含むアプリケーション呼び出し制御情報の登録数」は,次の表の項番1,2,3を合計したものです。
|
項番 |
種類 |
カウント方法 |
|---|---|---|
|
1 |
ref識別子共通設定 (Common) |
|
|
2 |
ref識別子 |
登録したref識別子のうち,レスポンス時間が著しく長いものの数 |
|
3 |
グループ |
登録したグループのうち,レスポンス時間が著しく長いものを含むグループの数 |
(5) その他の考慮事項
その他に考慮する内容の記載個所を次に示します。これらの記載内容にも従ってください。