こんにちは。Red Hat Decision Manager ジャック3日目です！
に引き続き、その3をお送りします。
ルールエンジンを適用したほうが良いケース・よくないケースは？
「変更の多いところにはルールエンジン、そうでないところはJavaで」というお話をよく聞きますが、この基準で適用を判断することはオススメしません。アプリケーションは時代の流れや業務の修正などによって常に変わっていくものです。業務アプリケーションの三大要素である、ルール・データ・プロセスについては、管理としては集中させ、互いを疎結合にしてサービス化・マイクロサービス化して稼働させることで可変性最大限に引き出せます。
アプリケーションアーキテクチャとして、ルールを「ディシジョンサービス」、データを「データサービス」、プロセスを「プロセスサービス」と位置づけ、チェック・判断・計算・推論の類は全て「ディシジョンサービス」とすることを強くオススメします。サービスという考えを導入して機能をカテゴライズすることで、一部はソースコードに、一部はルールエンジンに、一部はSQLとして等とロジックの分散化を排除すことが可能です。管理上においては、ロジックはディシジョンサービスに集中させるべきと考えています。
一方、業務ではないルール（制約）もプログラム上は出てきます。例えば、ある項目がnullかどうかを判断しないとNull Pointer Exceptionが出てしまうような場合、例えばDBに投入する際の桁あふれなどを防ぐための桁数チェックなどは、システム側の制約になります。このようなチェックは、Javaであればpojoのレベルでアノテーションを付けることでチェックすることも可能です。その場合は「業務に関連しない、システムとしての単項目チェックはpojoにてチェックすること」などと設計書に明記しておくことをお勧めします。
ただし、ある項目のチェックにおいて、A事業部とB事業部では同じ項目でも解釈が違うのでチェックすべき内容が違うとなると、それは業務ルールになりますので、ルールエンジン側でチェックを掛けるほうが良いケースになります。データの使い方をよく考えることが重要です。
ルールエンジンの適用基準は、「アプリケーションの改変をスムースに行うという観点で、アプリケーションアーキテクチャとしてディシジョンサービスを想定した時にその役割を担うものの全て」が大前提となります。そのうえで業務的な制約や使い方になっているかどうかを吟味して決定することをお勧めします。
Business Centralは使うのか？
Red Hat Decision Managerには、ルールの作成・管理の為のWeb ApplicationであるBusiness Centralが添付されています。Phreakアルゴリズムを利用するDRL形式のルール記述、意思決定表形式のルール記述、BPMN2.0のモジュールを利用したルールフローの記述が可能です。新しいルールの記述方式であるDMN形式にも対応しています。FACT(Javaのclassに相当）の為のツールも備わっています。また、ルールのテスト、シミュレーションに必要な画面等も用意されています。 ルールの実行環境としてDecision Server (KieServer)を利用した、REST形式で呼び出す場合は、Business Centralとの親和性が高く、簡単なルールであれば、Javaの知識をほとんど持たずともルールを記述することは可能です。
しかしながら、Decision Serverは、多数のアプリケーションからリクエストを受け付けることが可能になるため、CPU/Memoryのサイジングが難しいです。また、アプリケーションからはRESTでの呼出しになるために、月末締めバッチ処理等の大量一括処理には向きません。
ご採用頂いている日本の多くの事例においては、REST呼出しの他にEJB/POJOの呼出し等も多く、またFACTの設計として複雑な構造を持つものや、Javaによるメソッドが追加されることがあり、Javaによる開発が伴います。Business Centralでの作業よりもCodeReady Studio (旧名 JBoss Developer Studio) やMicrosoft Excelを利用したルール開発・ルール呼出しアプリ開発が多いのが実情です。
テストはどのようにすればよいのか？
書いたルールに対するテストについてです。通常のJava等の開発であれば、作ったメソッド毎にテストケースを書いてテストをする、いわゆる単体テストを行うのが一般的です。単体テストの場合、全ての分岐を通るようなテストパターンを作ったりします。
ルールの場合、ルール一つ一つに対する単体テストを行うことは稀です。というのも、記述するルールの多くは単純なルールが多く、それはルールを評価するというよりもルールエンジンを評価するものに近くなってしまいます。品質が保証されていないコミュニティ版をご利用になるのであれば、そのようなテストも意味があるかもしれませんが、製品として提供しているRed Hat Decision Managerの場合は品質を保証しているわけですから、ルールエンジンを評価するようなテストは不要です。
ルールは複数のルールをまとめて構成し、ディシジョンサービスとして提供するのが一般的です。その場合、結合テストのようにディシジョンサービスへの入出力の結果をもってテストを行います。さらに、ルールエンジンが採用しているPhreakアルゴリズムは、FACTがルールによって書き換えられたことをトリガーに再評価を行う機構を有しています。この場合、データやルールによっては数百万通りにも及ぶ組み合わせができる可能性があり、パスとして定義することが事実上不可能になります。その意味でも、ルールに与える入力値と期待値を予め用意しておき、ルールエンジンの実行結果と期待値を比較した上で合否判定を行う方法をお勧めしています。
ルールエンジンはトレースのログを出力することができます。ログを出力すると性能の低下がみられるために本番環境では無効化しますが、開発・テスト環境においては入力したFACTがどのような順番でルールが実行されたのか、Audit Logを取ることができます。テストにおいて否定されたデータが有る場合、そのデータのみを開発環境で流し、Audit Logを取得して動作の検証を行います。 開発ツールであるCodeReady Studioを利用すると、Break Pointを置いたステップ実行によるデバッグも可能です。
ルールの全てをExcelで編集できるのか？
ルールエンジン=意思決定表(Excelのシート)のイメージが強いと思います。表形式はわかりやすいのです。意思決定表は、ルールエンジンが動作するために必要なDRL形式のルールを生成するためのツールという位置づけです。つまり、意思決定表で記述したものは全てDRLに変換されて動作します。 意思決定表で記載すると扱いやすいルールは、同じような判定条件が1,000件未満であるような場合になります。それ以外の場合は、DRLと併用します。
大概の場合、意思決定表は固定値や範囲値を持ちます。その行数や列数が少ない場合は編集しやすいので便利ですが、その数が10,000にもなると、シートをスクロールするだけでも時間がかかります。このような場合、究極的に申し上げると、意思決定表にせずに、マスターデータに相当するような判定する値を持ったFACTとルールに入力されたFACTとを比較する、メタルールのような形式にすることで、ルールの数を減らしてデータ同士のマッチングにできます。10,000を超えるような判定は「マスターデータ」としてデータベースで扱うほうが頻繁な変更対しては扱いやすくなりますし、ルールは固定値を持たない汎用的なルールとして記述できます。
データとルールの整理を行い、ルールのメンテナンス性や性能面などを総合的に評価した上で、DRL形式や意思決定表形式をうまく組み合わせて利用することをお勧めします。
次でラストー！
Chief Technologist 梅野
